Elasticsearch MCP: 403 action is unauthorized (API key lacks privileges)

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: 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: The cluster is fine; the index name is wrong. List the indices that actually exist and fix the name in your query. Typos and date-suffixed index patterns are the usual culprits.

{"error":{"root_cause":[{"type":"index_not_found_exception","reason":"no such index [logs-2026.10.02]"}]}}

Fix it

1. List the indices that exist. Use the MCP server's list-indices tool, or curl:

curl -u elastic:YOUR_PASSWORD "your-cluster/_cat/indices?v"

Expected: a table of index names. Compare against the name in your query.

2. Fix the name. Common mistakes:

   • Date math: logs-2026.10.02 vs logs-2026-10-02 (dots vs dashes).
   • Aliases vs concrete names: query the alias, not the backing index, or vice versa.
   • Case: index names are lowercase by convention; uppercase fails.

3. If the index should exist but does not, create it or check you are pointed at the right cluster (dev vs prod URLs get mixed up).

   Expected: the search returns hits instead of the exception.

When to use this

• Auth and connection work, but searches fail with index_not_found_exception.
• The index name contains a date or was typed by hand.

When NOT to use this

• The error is 401 or 403. That is auth, not the index name.
• All indices are missing. Then you are pointed at the wrong cluster.

Compatibility

• elastic/mcp-server-elasticsearch, any Elasticsearch client.
• Elasticsearch 7.x, 8.x.

Why it happens

Elasticsearch treats index names as exact identifiers with no fuzzy matching. MCP agents often construct index names from dates or guess them from context, and a single wrong character produces this error instead of results. It is the search equivalent of a typo in a table name.

Edge cases

• Wildcards (logs-*) avoid the exact-name problem but can hit too many indices. Prefer them for exploration, exact names for production queries.
• Data streams have a backing-index naming scheme. Query the data stream name, not the .ds- backing index.
• If the index was just created, allow a moment for cluster state to propagate, though this is rarely the issue.

The elastic/mcp-server-elasticsearch exposes search tools that take an index name. Querying a nonexistent index returns indexnotfoundexception with nosuchindexexception type. This is standard Elasticsearch behavior: index names are exact, and a typo, a date-suffixed index that has not been created yet, or an index in a different cluster all produce this error. The fix is listing indices via the MCP server's list-indices tool or _cat/indices and correcting the name.