Elasticsearch MCP (VSee Fork)

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity. For example, find_entities_by_metric filters entities by metrics, get_usage_summary provides aggregated usage data, and get_visit_trends focuses on time-series trends. The descriptions reinforce non-overlapping functionalities, making tool selection straightforward.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern (e.g., get_usage_summary, find_entities_by_metric, top_change). The naming is uniform across all eight tools, using snake_case and descriptive terms that clearly indicate their functions without any deviations or mixed conventions.
Tool Count5/5
With 8 tools, the server is well-scoped for analytics and data retrieval in an Elasticsearch context. Each tool serves a specific analytical purpose (e.g., breakdowns, trends, distributions), and none appear redundant or trivial, making the count appropriate for the domain.
Completeness4/5
The toolset covers core analytics operations like summaries, trends, breakdowns, and distributions, with good coverage for metrics such as visits, ratings, and subscriptions. A minor gap exists in CRUD operations (e.g., creating or updating data), but this is reasonable given the server's focus on querying and analysis rather than data manipulation.
Average 3.8/5 across 8 of 8 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers limited behavioral insight. It mentions the tool 'returns' specific data types (visits, counts, etc.) and breakdowns, indicating a read-only operation, but doesn't disclose critical traits like rate limits, authentication needs, data freshness, or error handling. For a tool with 6 parameters and no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the core purpose and filters, the second details return values. It's front-loaded with key information and avoids redundancy. However, it could be slightly more concise by integrating the filter and return details more seamlessly, but overall it earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters with full schema coverage but no annotations or output schema, the description is moderately complete. It covers the tool's purpose and return data, which helps compensate for the lack of output schema. However, for a read operation with multiple filters and grouping options, it should ideally mention output structure implications (e.g., how grouping affects the summary format) to be fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 6 parameters with details like formats, defaults, and enums. The description adds minimal value beyond the schema by listing filter options (account, group, subscription) and mentioning grouping, but doesn't explain parameter interactions or semantics (e.g., how 'groupBy' affects output). Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get usage summary for a time period' with specific metrics like visits, unique counts, ratings, and call duration. It distinguishes itself from siblings like 'get_visit_trends' or 'get_rating_distribution' by offering a comprehensive summary rather than focused breakdowns. However, it doesn't explicitly contrast with all siblings (e.g., 'get_platform_breakdown'), keeping it from a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning optional filters (account, group, subscription) and grouping, suggesting it's for aggregated analytics. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_visit_trends' for time-series data or 'get_subscription_breakdown' for detailed tier analysis. No exclusions or prerequisites are stated, leaving usage somewhat open-ended.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and partially discloses behavior by mentioning optional filtering, default values, and return metrics, but lacks details on rate limits, authentication needs, or error handling, which are important for a tool with 7 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose and then detailing optional features and return values in a single, efficient sentence with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity with 7 parameters and no annotations or output schema, the description is moderately complete but could better address behavioral aspects like data freshness or limitations, though it adequately covers purpose and basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds marginal value by mentioning optional filtering and default topN behavior, but does not provide significant additional semantics beyond what the schema specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get breakdown') and resources ('top N platforms or platform versions by usage'), distinguishing it from siblings like get_usage_summary or get_visit_trends by focusing on platform/version breakdowns rather than general usage or trends.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning filtering options and role support, but does not explicitly state when to use this tool versus alternatives like get_subscription_breakdown or get_rating_distribution, leaving the agent to infer based on the breakdown focus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the tool's behavior by specifying it 'Always returns metrics grouped by subscription tier' with detailed breakdowns, but lacks information on permissions, rate limits, error handling, or data freshness. It adequately describes the output structure but misses operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by essential output details. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is mostly complete. It clearly states the purpose, output structure, and time-based operation. However, it lacks details on error cases or example usage, which could enhance completeness for a reporting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the two parameters (startDate, endDate) with formats and defaults. The description adds no additional parameter semantics beyond implying a time period, which is already covered by the schema. Baseline 3 is appropriate as the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Compare subscription tiers') and resource ('Enterprise, Premium, FVC, BVC, Plus') with detailed scope ('across a time period'). It distinguishes from siblings by focusing on subscription-tier comparison rather than entities, fields, platform breakdowns, ratings, usage summaries, visit trends, or top changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_platform_breakdown' or 'get_usage_summary', nor any prerequisites or exclusions. The description implies usage for time-period comparisons but lacks explicit context for tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the return format ('time series data points with visit counts and unique counts') and grouping behavior, but lacks details on permissions, rate limits, error handling, or data freshness. It adds some context but misses key operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded in a single, efficient sentence that states the core functionality upfront. Every phrase adds value without redundancy, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no annotations, no output schema), the description is moderately complete. It covers the purpose and return format but lacks output details (e.g., data structure, pagination) and behavioral context (e.g., performance, limits). For a trend analysis tool with rich parameters, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'optional grouping by subscription, account, or group' and 'daily, weekly, or monthly intervals', which are already covered in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get visit/usage count trends') and resources ('time series data points with visit counts and unique counts'). It distinguishes from siblings by focusing on temporal trends with grouping options, unlike summary or breakdown tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'trends over time' and 'optional grouping', but does not explicitly state when to use this tool versus alternatives like 'get_usage_summary' or 'get_platform_breakdown'. No exclusions or clear alternatives are provided, leaving usage guidance incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by specifying that it 'Returns entities matching ALL criteria with their metric values,' clarifying the filtering logic. However, it lacks details on performance implications (e.g., rate limits, latency), error handling, or pagination beyond the 'limit' parameter, which is a gap for a tool with 10 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose and key usage notes. It efficiently lists metrics and clarifies filtering behavior. However, the metric list is lengthy and could be summarized more concisely, and the sentence structure is slightly dense, making it less than perfectly streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no annotations, no output schema), the description is adequate but has gaps. It covers purpose, metrics, and filtering logic well, but lacks details on return format, error cases, or performance considerations. Without an output schema, the description should ideally hint at the response structure, which it does not, leaving the agent uncertain about what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds some value by listing available metrics and explaining the single vs. multiple metric usage, but it does not provide additional semantic context beyond what the schema offers (e.g., explaining 'account_count (groups only)' is already in the schema). Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find groups or accounts filtered by metrics.' It specifies the verb ('find'), resource ('groups or accounts'), and filtering mechanism ('by metrics'). It distinguishes itself from siblings by focusing on metric-based filtering rather than breakdowns, trends, or summaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: it explains when to use single vs. multiple metrics ('Supports single metric (legacy) or multiple metrics (recommended)'), lists available metrics, and notes that accounts can be filtered by group. However, it does not explicitly state when to use this tool versus sibling alternatives like 'get_usage_summary' or 'top_change', which might offer overlapping functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by describing the return format ('rating buckets with counts and percentages, plus statistics') and grouping capabilities. However, it doesn't mention important behavioral aspects like whether this is a read-only operation, potential rate limits, authentication requirements, or what happens with invalid parameters. The description adds useful context but leaves gaps in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences that front-load the core functionality and follow with supporting details. Every phrase earns its place by either specifying the tool's purpose, describing the output format, or explaining grouping capabilities. There's no wasted language or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (8 parameters, no output schema, no annotations), the description does well by covering the core functionality, output format, and grouping capabilities. However, it could be more complete by mentioning the absence of an output schema (users must infer the return structure from the description) and providing more guidance on when this tool is most appropriate versus sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds value by explaining the grouping capability ('Supports grouping by subscription, account, or group for comparative analysis') and clarifying the statistical output ('average, min, max, total count'), which helps users understand the tool's capabilities beyond individual parameter documentation. However, it doesn't provide additional syntax or format details for parameters beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get rating distribution', 'Returns rating buckets with counts and percentages, plus statistics') and identifies the resources involved ('provider and/or patient ratings'). It distinguishes this tool from siblings by focusing specifically on rating distribution analysis rather than entity finding, field indexing, or other breakdown types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through phrases like 'over a time period' and 'for comparative analysis', suggesting this tool should be used when temporal analysis or grouped comparisons are needed. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_usage_summary' or 'get_visit_trends', nor does it mention any exclusions or prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behaviors: it explains how the previous period is automatically calculated, describes the return format (ranked items with counts and changes), and mentions support for filtering. However, it lacks details on permissions, rate limits, or error handling, leaving some gaps for a tool with 6 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the purpose and return format, the second adds behavioral details. Every sentence earns its place by providing essential information without redundancy, making it front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a 6-parameter tool with no annotations and no output schema, the description is reasonably complete. It covers the core functionality, return format, and key behavioral aspects like period calculation. However, it could improve by detailing output structure more explicitly or addressing potential limitations, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema, only implicitly referencing parameters like 'groupBy', 'direction', and 'subscription' without providing additional semantics. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Find top N accounts or groups with highest visit/usage increase or decrease'), identifies the resource ('accounts or groups'), and distinguishes from siblings by focusing on ranking by change between periods rather than general metrics or breakdowns. It explicitly mentions what it returns, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for analyzing changes in visits/usage over time, but does not explicitly state when to use this tool versus alternatives like 'get_visit_trends' or 'get_usage_summary'. It mentions filtering by subscription tier, which provides some context, but lacks clear guidance on scenarios or exclusions compared to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by explaining the default index behavior ('stats-*'), the filtering capabilities, and the purpose of field discovery. However, it doesn't mention potential rate limits, authentication requirements, or what the output format looks like (though there's no output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with clear front-loading of the core purpose, followed by usage guidelines and important warnings. Every sentence earns its place by providing specific guidance or context without redundancy. The warning section is appropriately highlighted with emoji and capitalization.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, 100% schema coverage, and no output schema, the description does well by explaining the tool's purpose, usage context, and behavioral constraints. However, it doesn't describe what the return values look like (field format, structure, or examples), which would be helpful given the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the purpose of field filtering ('optional filtering by field name and type'), providing context about when to use the index parameter (only when explicitly requested), and giving examples of type filters ('keyword fields for exact matches or text fields for full-text search').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get all fields') and resource ('from an Elasticsearch index'), specifies the optional filtering capabilities, and distinguishes this tool from its siblings by focusing on field discovery rather than data retrieval or analysis. It explicitly mentions discovering available fields, their types, and correct field names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('when you need to discover available fields... before constructing queries') and when not to use it (⚠️ IMPORTANT warning about not specifying the index parameter unless explicitly requested). It also explains the specific use cases like being unsure about field names or looking for fields with specific types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![elasticsearch-mcp-server MCP server](https://glama.ai/mcp/servers/mlei06/elasticsearch-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/mlei06/elasticsearch-mcp-server)

Score Badge

Copy to your README.md:

[![elasticsearch-mcp-server MCP server](https://glama.ai/mcp/servers/mlei06/elasticsearch-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/mlei06/elasticsearch-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mlei06/elasticsearch-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server