Elasticsearch MCP: 401 missing authentication credentials (set ES_API_KEY)

Not specified by the original author.

TL;DR: Your MCP server is reaching Elasticsearch but not logging in. Elasticsearch 8 has security on by default and answers every unauthenticated request with 401. Create an API key in Kibana and give it to the MCP server as ES_API_KEY.

{"error":{"root_cause":[{"type":"security_exception","reason":"missing authentication credentials for REST request [/]"}]},"status":401}

Fix it

1. In Kibana, go to Stack Management, Security, API Keys. Create a key. Important: the walkthrough notes that read-only does not include permission to list all indices, so grant the privileges the server needs (superuser works; scope it down if you can).
2. Copy the encoded key value (the long base64 string), not the raw api_key field.
3. Set it in the MCP server config. For elastic/mcp-server-elasticsearch:

{
  "env": {
    "ES_URL": "your-cluster",
    "ES_API_KEY": "your-encoded-api-key"
  }
}

Alternatively use ES_USERNAME and ES_PASSWORD with the elastic superuser.

4. Restart the MCP client.

   Expected: tools like list indices and search return data instead of 401.

When to use this

• Every Elasticsearch tool call fails with 401 missing authentication credentials.
• curl without auth to the cluster returns the same 401 body (proves the cluster is up and security is on).

When NOT to use this

• The error is unable to authenticate with credentials set. The key is wrong, expired, or invalidated. Create a new one.
• The error is 403. Auth worked; the key lacks privileges. Broaden the role descriptors.
• Connection refused or timeout. The cluster is unreachable.

Compatibility

• elastic/mcp-server-elasticsearch.
• Elasticsearch 8.x with security enabled (default), Elastic Cloud, self-hosted.

Why it happens

Elasticsearch 8 enables security by default, unlike older versions that answered anonymously. The MCP server has no credentials unless you configure them, so the first thing it hits is the 401. The error is verbose but the meaning is simple: nobody logged in.

Edge cases

• Use the encoded value from the API key creation response. The raw api_key plus id pair also works but the encoded form is one string.
• Invalidated or expired keys fail with unable to authenticate, not missing authentication credentials. Different message, different fix: make a new key.
• Give each integration its own API key with an expiration, so rotation does not break everything at once.

The elastic/mcp-server-elasticsearch connects to the cluster at ESURL and authenticates with the configured credentials. Without them, Elasticsearch 8 (security on by default) returns 401 with reason missing authentication credentials for REST request. This exact response is documented in the Security Onion + Elasticsearch MCP walkthrough (medium.com/@uhtavi0), where curl -k https://CONTAINERIP:9200 without credentials returns the 401 missing authentication credentials body, and the fix is creating an API key in Kibana and configuring the MCP server with it. Source: https://medium.com/@uhtavi0/security-operations-with-elasticsearch-mcp-and-security-onion-26c3819bebd6

Not specified by the original author.

TL;DR: 403 means you logged in fine but your API key is not allowed to do that. The read-only sounding roles do not cover everything the MCP server needs (like listing indices). Recreate the API key with the missing privileges.

{"error":{"root_cause":[{"type":"security_exception","reason":"action [indices:admin/get] is unauthorized for API key id [...]"}]},"status":403}

Fix it

1. Identify the denied action in the error. indices:admin/get is list-indices, indices:data/read/search is search.
2. In Kibana, Stack Management, Security, API Keys, create a new key with explicit role descriptors covering what the server needs. Example for a search workload:

{
  "elasticsearch": {
    "cluster": ["monitor"],
    "indices": [{"names": ["logs-*"], "privileges": ["read", "view_index_metadata"]}]
  }
}

For a quick unblock, superuser works, then scope it down.

3. Replace ES_API_KEY in the MCP server config with the new encoded key. Restart the client.

   Expected: the denied tools now work.

When to use this

• Auth succeeds (no 401) but tools fail with 403 unauthorized.
• Some tools work and others do not. The working ones are within the key's privileges.

When NOT to use this

• The error is 401 missing authentication credentials. No credentials are being sent at all.
• The error is 401 unable to authenticate. The key itself is bad. Make a new one rather than broadening roles.

Compatibility

• elastic/mcp-server-elasticsearch.
• Elasticsearch 8.x with API key auth.

Why it happens

API keys carry role descriptors that gate every action. The minimal-looking roles do not include the admin-ish actions MCP tools need, like listing indices or getting mappings. People create a key with just read and then wonder why half the tools 403.

Edge cases

• Invalidating the old key after switching avoids confusion about which key is live.
• Key privileges are fixed at creation. You cannot widen an existing key; you must create a new one.
• The elastic superuser password works everywhere but should not be the MCP server's daily credential. Use scoped API keys.

The elk-setup troubleshooting table (cloud-prakhar/elk-setup elk-curl-auth-operations.md) documents this exact symptom: 403 ... action [...] is unauthorized, with the cause API key lacks the privilege and the fix recreate the key with the needed role_descriptors. The Security Onion Elasticsearch MCP walkthrough (medium.com/@uhtavi0) notes the same trap during API key creation: read-only does not include permission to list all indices, so privileges must be set to superuser (or the needed roles) for the MCP server's tools to work. Source: https://github.com/cloud-prakhar/elk-setup/blob/HEAD/elk-curl-auth-operations.md

Not specified by the original author.

TL;DR: Weaviate Cloud requires an API key and your MCP server is not sending one. Set WEAVIATE_API_KEY in the server's environment alongside WEAVIATE_URL. Local Docker Weaviate does not need this, which is why the same config breaks when you move to Cloud.

401 Unauthorized

(From Weaviate Cloud, surfaced through the MCP server's tools.)

Fix it

1. In the Weaviate Cloud dashboard, create an API key for your cluster. Copy it.
2. Set both variables in the MCP client config env block:

{
  "env": {
    "WEAVIATE_URL": "https://your-cluster.weaviate.cloud",
    "WEAVIATE_API_KEY": "your-weaviate-api-key"
  }
}

3. Restart the MCP client.

   Expected: 401 is gone, collection tools work.

When to use this

• Tools fail with 401 against a *.weaviate.cloud URL.
• The same config works against local Docker Weaviate.

When NOT to use this

• Local Docker Weaviate with auth disabled. No key is needed; check the URL.
• Connection refused or timeout. The instance is unreachable.

Compatibility

• weaviate/mcp-server-weaviate and Weaviate-backed MCP servers.
• Weaviate Cloud.

Why it happens

Weaviate Cloud mandates API key auth on every request. Local Docker images ship with auth off for convenience. Configs migrate from local to Cloud carrying only the URL, and the missing key produces a bare 401 with no hint about what to set.

Edge cases

• The Cloud URL is https://. Plain http:// fails differently.
• API keys are per-cluster. A key for cluster A does not work on cluster B.
• If you enabled auth on self-hosted Weaviate (APIKEY auth), the same variable applies. Check how your server maps it.

The weaviate-cloud secure coding rules (tikitribe/claude-secure-coding-rules rules/rag/vector-managed/weaviate-cloud/CLAUDE.md) show the correct Weaviate Cloud connection pattern: weaviate.connecttoweaviatecloud with clusterurl from WEAVIATEURL and authcredentials=AuthApiKey from WEAVIATEAPIKEY. Weaviate Cloud requires API key authentication; without the key the server gets 401 Unauthorized. Local Docker Weaviate typically runs without auth, which is why configs copied from local setups break against Cloud. Source: https://github.com/tikitribe/claude-secure-coding-rules/blob/HEAD/rules/rag/vector-managed/weaviate-cloud/CLAUDE.md