get_mappings tool fails with "error decoding response body" when nested type is omitted in properties

[NavaneethaKannan]

When using the get_mappings tool, the server throws "Request failed (remote): error decoding response body" if a nested property is defined without explicitly specifying "type": "nested", even though the mapping is valid according to Elasticsearch specifications.

Example Mapping That Fails:

{ "mappings": { "properties": { "title": { "type": "text" }, "created_at": { "type": "date" }, "comments": { "properties": { "user": { "type": "keyword" }, "message": { "type": "text" }, "posted_at": { "type": "date" } } } } } }

Example mapping that works:

{ "mappings": { "properties": { "title": { "type": "text" }, "created_at": { "type": "date" }, "comments": { "type": "nested", "properties": { "user": { "type": "keyword" }, "message": { "type": "text" }, "posted_at": { "type": "date" } } } } } }

Difference: The working mapping includes "type": "nested" for the "comments" property.

The first mapping is valid and accepted by Elasticsearch, but the get_mappings tool fails to process it. This behavior is unexpected and may indicate a bug or an undocumented constraint in the tool’s handling of mappings.

Expected Behavior:
The tool should correctly decode and return mappings even when the "type": "nested" is omitted, as long as the mapping is valid per Elasticsearch standards.

Environment:
Elasticsearch version: 8.17.6
mcp-server-elasticsearch version: latest
Tool: get_mappings

[colin-stubbs]

Can confirm I am seeing the same thing against an Elastic Cloud managed 9.1.x deployment.

Manual testing of the API key confirms the permissions provided to the API key are fine as I can view the mappings in the response body when directly requesting /<%INDEX%>/_mappings

Any MCP client that uses the Elastic MCP server returns "MCP error -32603: error decoding response body"

Cursor's summary from self testing,

Summary of Elasticsearch MCP Tools Testing
I have successfully tested the available Elasticsearch MCP server tools. Here's what I found:
✅ Working Tools:

1. get_shards - FULLY FUNCTIONAL

• Successfully returned information about 918 shards across all indices
• Provided detailed shard information including index names, shard numbers, states, document counts, and storage sizes
• Shows indices from various data streams (logs, metrics, traces) and system indices

2. esql (ES|QL Query Tool) - FULLY FUNCTIONAL

• Successfully executed ES|QL queries against Elasticsearch indices
• Tested basic queries: FROM index | LIMIT 5
• Tested filtered queries: FROM index | WHERE field == value | LIMIT 3
• Returned rich, structured data with all fields from the documents
• Handled complex field structures (nested objects, arrays) properly

❌ Non-Functioning Tools:

1. get_mappings - NOT WORKING

• Attempted to get field mappings for multiple indices
• All attempts resulted in errors with no results returned
• This tool appears to have connectivity or permission issues

Test Results Summary:

• Total Tools Available: 3
• Working Tools: 2 (67%)
• Non-Working Tools: 1 (33%)

Recommendations:

• The ES|QL tool is excellent and provides powerful querying capabilities for Elasticsearch data
• The get_shards tool works well for cluster health and index information
• The get_mappings tool needs investigation - it may have permission issues or require different authentication
• Consider testing the get_mappings tool with different index names or checking Elasticsearch permissions
• The core functionality for querying and monitoring Elasticsearch is working well through the ES|QL and get_shards tools, which cover the most important use cases for data analysis and cluster monitoring.

[Danouchka]

+1