Elasticsearch/OpenSearch MCP Server

Server Quality Checklist

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

Latest release: v2.0.6
Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific resources and actions in Elasticsearch/OpenSearch. The tools cover index management, document operations, alias handling, cluster monitoring, and search with no overlapping functionality. Even the general_api_request tool is clearly distinguished as a fallback for unsupported APIs.
Naming Consistency5/5
The tools follow a highly consistent verb_noun naming pattern throughout (e.g., create_index, delete_document, get_cluster_health, search_documents). All tools use snake_case with clear action verbs followed by resource nouns, making the API surface predictable and readable.
Tool Count5/5
With 16 tools, this server is well-scoped for the Elasticsearch/OpenSearch domain. It provides comprehensive coverage of core operations without being overwhelming. Each tool serves a specific, necessary function in the database management workflow, and the count aligns well with the complexity of the domain.
Completeness4/5
The toolset provides excellent coverage of core Elasticsearch/OpenSearch operations including CRUD for indices and documents, alias management, cluster monitoring, and search. The general_api_request tool elegantly handles edge cases. Minor gaps might include bulk operations or specific monitoring endpoints, but agents can work around these using the general tool.
Average 2.9/5 across 16 of 16 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- 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 Apache 2.0.
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?
No annotations are provided, so the description carries full burden. 'Search for documents' implies a read operation but doesn't disclose behavioral traits like whether this is paginated, what format results return, authentication requirements, rate limits, or error conditions. The description mentions parameters but doesn't explain search behavior beyond the basic action.
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 concise with only 3 lines. The first sentence states the purpose, followed by a parameter section. However, the structure with 'Args:' formatting is somewhat redundant since parameters are already documented in the schema, and the content is too sparse to be truly helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 0% schema coverage, no annotations, no output schema, and nested objects in parameters, the description is incomplete. It doesn't explain what the tool returns, how search results are structured, what the 'body' object should contain, or provide context about the document system. For a search tool with complex parameters, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists 'index: Name of the index' and 'body: Search query' which adds minimal meaning beyond parameter names. However, it doesn't explain what an 'index' is in this context, what format the 'body' query should take, or provide examples. With 2 parameters and no schema descriptions, this is inadequate compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search for documents' which is a tautology of the tool name 'search_documents'. It doesn't specify what kind of documents, what system they're in, or how the search works. While it mentions the verb 'search' and resource 'documents', it lacks specificity and doesn't distinguish this from potential sibling tools like 'get_document' or 'index_document'.
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?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_document' (retrieve specific document), 'index_document' (add document), and 'delete_by_query' (delete via query), there's no indication of when search is appropriate versus direct retrieval or other query-based operations. The description doesn't mention prerequisites like needing an existing index.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action 'Delete' but doesn't disclose critical behavioral traits: whether this is destructive, irreversible, requires specific permissions, affects data permanently, or has side effects like removing associated documents. This is a significant gap for a deletion tool.
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 brief and front-loaded with the core action. However, the 'Args:' section is redundant since it mirrors the schema without adding value, slightly reducing efficiency. Overall, it's concise but could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description is incomplete for a deletion tool. It lacks details on behavior, parameters, return values, and error handling, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only repeats the parameter name 'index' as 'Name of the index', adding minimal meaning beyond the schema. It doesn't explain format constraints, valid index names, or examples, leaving the parameter poorly defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Delete' and resource 'an index', which is clear but minimal. It doesn't differentiate from sibling tools like 'delete_document' or 'delete_by_query', leaving ambiguity about what type of index this deletes versus other deletion operations.
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. With siblings like 'delete_document' and 'delete_by_query', the description doesn't clarify if this deletes entire indices versus specific content, or mention prerequisites like index existence checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Create a new index' which implies a write/mutation operation, but it doesn't specify permissions required, whether this is idempotent, potential side effects, error conditions, or what happens on success. For a creation tool with zero annotation coverage, 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 appropriately sized with a clear purpose statement followed by parameter explanations in a structured format. Every sentence adds value, and there's no redundant information. It could be slightly more front-loaded with key behavioral details, but overall it's efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a creation tool with no annotations, no output schema, and 2 parameters (one optional with nested configuration possibilities), the description is incomplete. It lacks information on what the tool returns, error handling, dependencies, or how it fits into broader workflows with sibling tools like 'index_document'. This makes it inadequate for reliable agent use.
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?
The description adds basic semantics for both parameters ('index: Name of the index' and 'body: Optional index configuration including mappings and settings'), which provides meaning beyond the 0% schema description coverage. However, it doesn't detail format constraints, examples, or how 'body' interacts with 'index', leaving some ambiguity. With 2 parameters and low schema coverage, this is adequate but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new index' which clearly indicates the verb and resource, but it's somewhat vague about what an 'index' represents in this context. It doesn't distinguish this tool from similar operations like 'index_document' or 'get_index' among the sibling tools, leaving room for confusion about the specific domain.
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?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'index_document' and 'get_index' available, there's no indication of prerequisites, typical use cases, or distinctions between creating an index and other index-related operations, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool deletes documents, implying a destructive mutation, but lacks critical details: it doesn't mention whether deletions are permanent, if there are rate limits, what permissions are required, or what happens on errors. The description is minimal and leaves key behavioral traits unspecified.
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 concise and front-loaded: the first sentence states the core purpose clearly. The Args section is structured but could be more integrated. There's no wasted text, though it borders on under-specification rather than optimal brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with 2 parameters, nested objects in body, no output schema, and no annotations), the description is incomplete. It fails to address critical context like deletion consequences, error handling, query examples, or output expectations. For a mutation tool with zero annotation coverage, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists parameters with brief explanations ('Name of the index', 'Query to match documents for deletion'), but these add minimal semantic value beyond the schema's property names. It doesn't explain index naming conventions, query syntax, or provide examples, leaving significant gaps in parameter understanding.
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: 'Deletes documents matching the provided query.' It specifies the verb ('deletes') and resource ('documents'), and distinguishes it from siblings like delete_document (single document) and delete_index (entire index). However, it doesn't explicitly contrast with all alternatives like general_api_request.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer delete_by_query over delete_document (for bulk deletion) or delete_index (for removing entire indices), nor does it discuss prerequisites like index existence or query validation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action is a deletion, implying mutation, but lacks critical details: whether it's destructive (likely yes, but not confirmed), permission requirements, error handling (e.g., if alias doesn't exist), or side effects (e.g., impact on queries using the alias). This leaves significant gaps for safe agent operation.
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, with the core purpose in the first sentence and parameters listed concisely below. There's no wasted text, though the structure could be slightly improved by integrating parameter details more seamlessly rather than as a separate 'Args' section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with no annotations, 2 parameters, 0% schema coverage, and no output schema), the description is incomplete. It lacks behavioral context (e.g., safety, errors), usage guidance, and output details, making it inadequate for reliable agent invocation without external knowledge.
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?
The description lists both parameters ('index' and 'name') with brief labels, but schema description coverage is 0%, so the schema provides no additional details. The description adds basic meaning (e.g., 'index' is the index name, 'name' is the alias name), compensating somewhat for the coverage gap, but doesn't explain format, constraints, or examples, keeping it at a baseline level.
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 verb ('Delete') and resource ('an alias for a specific index'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'delete_index' or 'delete_document', which would require mentioning it only removes alias mappings, not the underlying data.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., alias must exist), exclusions (e.g., cannot delete if in use), or refer to sibling tools like 'list_aliases' for checking or 'put_alias' for creating aliases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the tool deletes a document, implying a destructive mutation, but doesn't mention critical details like whether deletion is permanent, requires specific permissions, has side effects (e.g., on related data), or returns confirmation. For a destructive tool with zero annotation coverage, this is a significant gap.
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 with two sentences: one for the core purpose and one for parameter listing. It's front-loaded with the main action. The parameter section is clear but could be integrated more seamlessly. There's minimal waste, though the formatting with 'Args:' feels slightly verbose for such a short description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a destructive tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks information on behavioral consequences (e.g., irreversibility), error conditions, return values, and system context. The description should do more to compensate for the absence of structured metadata.
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 0%, so the description must compensate. It lists both parameters (index and id) with brief explanations, adding meaning beyond the schema's bare titles. However, it doesn't explain what an 'index' represents in this context, valid ID formats, or constraints (e.g., index must exist). The description partially compensates but leaves key semantics unclear.
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 action ('Delete') and target ('a document by ID'), making the purpose immediately understandable. It distinguishes from siblings like delete_index (which deletes entire indices) and delete_by_query (which deletes based on queries rather than ID). However, it doesn't specify what type of document or system this applies to, leaving some ambiguity.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., document must exist), when not to use it (e.g., for bulk deletions), or refer to sibling tools like delete_by_query for different deletion methods. Usage is implied only through the tool name and basic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 only states the basic action without mentioning permissions, error handling, rate limits, or what 'alias information' entails (e.g., format, scope). This is inadequate for a tool with no annotation coverage.
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 brief and front-loaded with the main purpose, followed by parameter documentation. It avoids unnecessary words, though the formatting with 'Args:' could be more integrated. Overall, it's efficient but not perfectly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on behavior, return values, and error cases, making it insufficient for an agent to use the tool effectively without additional context.
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 0%, so the schema provides no parameter details. The description adds the meaning of 'index' as 'Name of the index', which is minimal but compensates slightly. However, it doesn't explain constraints or examples, leaving gaps in understanding.
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 verb 'Get' and the resource 'alias information for a specific index', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'list_aliases' or 'get_index', which would require explicit comparison to achieve a score of 5.
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 'list_aliases' or 'get_index'. The description only states what it does without indicating context or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the action ('Get') but doesn't clarify if this is a read-only operation, what permissions are required, error handling (e.g., for missing documents), or response format. This leaves significant gaps for a tool that likely interacts with a data store.
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 front-loaded with the core purpose ('Get a document by ID.') followed by parameter details in a structured 'Args:' section. It avoids unnecessary fluff, but the parameter explanations are very brief, bordering on under-specified, which slightly reduces efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a document retrieval tool with no annotations, no output schema, and low parameter documentation, the description is incomplete. It doesn't explain what 'Get' returns (e.g., document content, metadata), error cases, or behavioral traits like idempotency, making it inadequate for safe and effective use by an AI agent.
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?
The description lists both parameters ('index' and 'id') with brief labels, but schema description coverage is 0%, so the schema provides no additional details. The description adds minimal semantics (e.g., 'Name of the index' and 'Document ID'), which is better than nothing but doesn't fully compensate for the lack of schema documentation, such as format examples or constraints.
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 verb ('Get') and resource ('a document by ID'), making the purpose immediately understandable. It distinguishes from siblings like 'search_documents' (which retrieves multiple documents) and 'index_document' (which creates/updates). However, it doesn't explicitly mention what 'Get' entails (e.g., retrieval of metadata/content), keeping it from a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives like 'search_documents' for queries or 'get_index' for index-level info. It lacks context about prerequisites (e.g., needing an existing document ID) or exclusions, offering only basic parameter info without usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a read operation ('Returns information'), implying it's non-destructive, but doesn't cover aspects like authentication needs, rate limits, error conditions, or response format. For a tool with zero annotation coverage, 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 appropriately sized with two sentences: one stating the purpose and one documenting the parameter. It's front-loaded with the core functionality. The 'Args' section is clear but slightly verbose for a single parameter, keeping it from a perfect score.
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 moderate complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the purpose and parameter but lacks details on usage context, behavioral traits, or output structure. Without annotations or output schema, more completeness would be beneficial, but it meets a basic threshold.
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?
The description includes an 'Args' section that documents the single parameter 'index' as 'Name of the index', adding meaning beyond the input schema (which has 0% description coverage). However, it doesn't provide details like format examples or constraints, so it partially compensates for the schema gap but not fully, warranting a baseline score.
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: 'Returns information (mappings, settings, aliases) about one or more indices.' It specifies the verb ('Returns'), resource ('indices'), and type of information returned. However, it doesn't explicitly differentiate from siblings like 'list_indices' or 'get_document', which would require a 5.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'list_indices' (which might list index names without details) or 'get_document' (which retrieves specific documents), leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the action ('Creates or updates') but fails to describe key traits like whether this is idempotent, what happens if the ID is omitted, permission requirements, or error conditions. This leaves significant gaps for a mutation tool.
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 front-loaded with the core purpose in the first sentence, followed by a parameter list. It avoids unnecessary fluff, but the parameter section could be more integrated into the flow rather than a separate block, slightly affecting structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (mutation tool with 3 parameters, no annotations, no output schema, and 0% schema coverage), the description is incomplete. It lacks details on behavior, error handling, return values, and how it differs from siblings, making it inadequate for safe and effective use by an agent.
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 0%, so the schema provides no param descriptions. The description lists parameters with brief notes ('Optional document ID'), adding some semantics beyond the schema. However, it doesn't explain the format of 'document' data or constraints on 'index', only partially compensating for the coverage gap.
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 verb ('Creates or updates') and resource ('a document in the index'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from siblings like 'create_index' or 'update_document' (if such a tool existed), which prevents a perfect score.
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 'create_index' for index creation or 'get_document' for retrieval. The description lacks context about prerequisites, such as whether the index must exist, or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states the basic action. It doesn't disclose behavioral traits such as whether this is a mutation (implied by 'Create or update'), what permissions are needed, if it's idempotent, error conditions, or side effects. This is inadequate for a tool that likely modifies system state.
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 brief and front-loaded with the main purpose, followed by parameter listings. It avoids unnecessary words, though the parameter section could be more integrated. Overall, it's efficient but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, nested object, no output schema, no annotations), the description is incomplete. It lacks details on behavior, parameter usage, error handling, and output, making it insufficient for safe and effective tool invocation in this context.
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 0%, so the description must compensate. It lists the three parameters with brief labels ('Name of the index', etc.), adding minimal semantic context beyond the schema's property names. This provides some value but doesn't explain format, constraints, or what 'body' contains, leaving significant gaps.
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 action ('Create or update') and resource ('alias for a specific index'), making the purpose understandable. However, it doesn't differentiate from siblings like 'create_index' or 'get_alias', which would require more specific context about when to use this versus those alternatives.
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 'create_index' or 'list_aliases'. The description only states what it does, not when it's appropriate, leaving the agent to infer usage from the name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns information, implying a read-only operation, but doesn't disclose any behavioral traits such as performance impact, rate limits, authentication needs, or what 'health' includes (e.g., node status, indices health). The description is minimal and lacks critical context for safe use.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple tool, though it could be more informative. The structure is front-loaded with the core action, but it lacks depth that might be useful for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of cluster health monitoring and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'health' entails, the format of the return values, or any behavioral considerations. For a tool that likely returns critical operational data, this minimal description leaves significant gaps in understanding.
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?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter semantics, but this is acceptable given the absence of parameters. A baseline of 4 is appropriate as the schema fully covers the input requirements, and the description doesn't need to compensate.
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 with a specific verb ('Returns') and resource ('basic information about the health of the cluster'). It distinguishes from siblings like 'get_cluster_stats' by focusing on 'health' rather than general statistics, though it doesn't explicitly differentiate them. The purpose is clear but could be more specific about what 'health' entails.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'get_cluster_health' over 'get_cluster_stats' or other monitoring tools, nor does it specify prerequisites or exclusions. Usage is implied only by the tool's name and description, with no explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the tool returns statistics but doesn't specify whether this is a read-only operation, if it requires authentication, potential rate limits, or what the output format looks like. This is a significant gap for a tool with zero annotation coverage.
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 a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of cluster statistics and the lack of annotations and output schema, the description is incomplete. It doesn't explain what specific statistics are returned, the format of the output, or any behavioral traits like safety or performance implications, which are crucial for effective tool invocation.
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?
The tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. A baseline score of 4 is given as it avoids unnecessary parameter details.
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 with a specific verb ('Returns') and resource ('high-level overview of cluster statistics'), making it easy to understand what the tool does. However, it doesn't explicitly distinguish this from its sibling 'get_cluster_health', which also provides cluster-related information, so it misses full differentiation.
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?
The description provides no guidance on when to use this tool versus alternatives like 'get_cluster_health' or other cluster-related tools. It lacks context about specific use cases, prerequisites, or exclusions, leaving the agent without clear direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states 'List all aliases,' which implies a read-only operation returning all items, but doesn't specify format, pagination, sorting, or error conditions. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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 a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, achieving maximum efficiency.
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 simplicity (0 parameters, no annotations, no output schema), the description is adequate but minimal. It covers the basic purpose but lacks behavioral details like return format or error handling. For a list operation in a context with many sibling tools, more guidance would be helpful.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. Baseline is 4 for zero parameters, as the description doesn't need to compensate for any schema gaps.
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 action ('List') and resource ('aliases'), making the purpose immediately understandable. It distinguishes from siblings like 'get_alias' (singular) and 'put_alias' (create/update), though it doesn't explicitly mention these distinctions. The description is specific but lacks explicit sibling differentiation.
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?
The description provides no guidance on when to use this tool versus alternatives like 'get_alias' (for a specific alias) or 'list_indices' (for a different resource type). There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. 'List all indices' implies a read-only operation, but it doesn't specify whether this requires permissions, how results are returned (e.g., pagination, format), or potential side effects. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 'List all indices' is extremely concise—just three words—and front-loaded with the core action. There's no wasted language or unnecessary elaboration, making it efficient and easy to parse.
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 simplicity (0 parameters, no output schema), the description is minimally adequate. It states what the tool does but lacks details on behavior, usage context, or output format. With no annotations and no output schema, it should ideally provide more context about what 'list' entails (e.g., returns an array of index names), but it's sufficient for a basic listing function.
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?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. A baseline of 4 is justified since no parameters exist, and the schema fully covers this.
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 'List all indices' clearly states the verb ('List') and resource ('indices'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_index' (which retrieves a specific index) or 'list_aliases' (which lists aliases rather than indices), so it doesn't fully distinguish from alternatives.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that this is for retrieving all indices at once (unlike 'get_index' for a single index) or compare it to other listing tools like 'list_aliases'. There's no context about prerequisites, timing, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool performs HTTP requests but doesn't describe authentication requirements, rate limits, error handling, response formats, or what types of operations are possible. For a general-purpose API tool with 4 parameters, this leaves significant behavioral aspects undocumented.
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 purpose first, usage guidelines second, and parameter explanations in a clear Args section. Every sentence adds value without redundancy, and the formatting makes it easy to parse despite the multi-line presentation.
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?
For a general-purpose API tool with 4 parameters, no annotations, and no output schema, the description provides adequate basics but lacks important context. It covers purpose and usage well but misses behavioral details like authentication, error handling, and response structure. The parameter explanations are minimal but exist, making this complete enough for basic understanding but insufficient for confident use.
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?
The description lists all 4 parameters with brief explanations, but with 0% schema description coverage, it doesn't fully compensate. It provides basic semantics (method is HTTP method, path is endpoint, params are query parameters, body is request body) but lacks format details, examples, or constraints. This is the minimum viable explanation given the schema's lack of descriptions.
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: 'Perform a general HTTP API request' and specifies it's for Elasticsearch/OpenSearch APIs without dedicated tools. It distinguishes from siblings by indicating this is a catch-all for APIs not covered by specific tools like create_index or search_documents. However, it doesn't explicitly name the resource being accessed beyond 'API'.
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 usage guidance: 'Use this tool for any Elasticsearch/OpenSearch API that does not have a dedicated tool.' This clearly indicates when to use this tool versus the many specific sibling tools listed, establishing clear boundaries and alternatives.
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/Rbedoyag/Elasticsearch-MCP-SERVER/badges/card.svg)](https://glama.ai/mcp/servers/Rbedoyag/Elasticsearch-MCP-SERVER)

Score Badge

Copy to your README.md:

[![Elasticsearch-MCP-SERVER MCP server](https://glama.ai/mcp/servers/Rbedoyag/Elasticsearch-MCP-SERVER/badges/score.svg)](https://glama.ai/mcp/servers/Rbedoyag/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/Rbedoyag/Elasticsearch-MCP-SERVER'

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