OpenSearch MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific OpenSearch operations. There is no overlap between tools like get_cluster_health (health status), get_mapping (index structure), and search_documents (document queries). Each tool name precisely indicates its unique function within the OpenSearch domain.
Naming Consistency5/5
All tools follow a consistent verb_noun naming pattern throughout. The pattern is predominantly 'get_' for retrieval operations and 'list_' for listing operations, with specific exceptions like 'generate_' and 'search_' that maintain the same structure. No mixing of conventions like camelCase or snake_case variations.
Tool Count5/5
With 14 tools, this server is well-scoped for OpenSearch operations, covering monitoring, configuration, and data querying aspects. Each tool earns its place by addressing distinct needs like cluster health, index management, and document search, without being overly sparse or bloated.
Completeness4/5
The tool set provides strong coverage for monitoring, configuration retrieval, and search operations in OpenSearch. Minor gaps exist, such as the absence of tools for creating or updating resources (e.g., indices, policies), but agents can still perform core read and diagnostic workflows effectively.
Average 2.8/5 across 14 of 14 tools scored. Lowest: 1.7/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

Behavior1/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. 'Get index mapping' gives no information about whether this is a read-only operation, what permissions might be required, whether it has side effects, rate limits, or what format the response takes. For a tool with zero annotation coverage, this description fails to provide any behavioral context.
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 extremely concise at just three words. While this represents under-specification rather than optimal conciseness, from a pure structural perspective, it's front-loaded with no wasted words. Every word earns its place, even though those words provide minimal information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of what appears to be an Elasticsearch-related tool (based on sibling tool names), no annotations, no output schema, and 0% schema description coverage, this description is completely inadequate. It doesn't explain what 'mapping' means in this context, what the tool returns, or how it differs from similar tools. The description fails to provide the necessary context for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the single required parameter 'index'. With 0% schema description coverage, the schema only indicates it's a required string parameter. The description doesn't explain what 'index' refers to, what format it should be in, or provide any examples. It fails to compensate for the complete lack of schema documentation.
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 'Get index mapping' is a tautology that essentially restates the tool name 'get_mapping' with the addition of 'index'. It doesn't specify what 'mapping' refers to (e.g., Elasticsearch index mapping, data structure mapping, configuration mapping) or what the operation actually retrieves. While it mentions a resource ('index mapping'), the verb 'Get' is too generic and doesn't distinguish this from sibling tools like 'get_settings' or 'get_index_templates'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 any prerequisites, appropriate contexts, or exclusions. With sibling tools like 'get_settings', 'get_index_templates', and 'list_indices' available, there's no indication of how this tool differs or when it should be selected over those alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'Get cluster statistics' provides no information about whether this is a read-only operation, what permissions might be required, whether it has rate limits, what format the statistics are returned in, or any other behavioral characteristics. The description is minimal and fails to disclose any meaningful behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Get cluster statistics') - just three words. While this avoids unnecessary verbosity, it's arguably under-specified rather than appropriately concise. For a tool with no parameters and no annotations, more context would be helpful. The structure is simple but lacks the front-loaded completeness that would make it truly effective.
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 lack of annotations, no output schema, and the presence of multiple similar sibling tools, the description is incomplete. 'Get cluster statistics' doesn't explain what statistics are returned, how they differ from other cluster monitoring tools, or what the agent can expect from using this tool. For a tool in what appears to be an Elasticsearch/OpenSearch monitoring context with many alternatives, this minimal description leaves significant gaps.
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 zero parameters, and the input schema has 100% description coverage (though it's empty). With no parameters to document, the description doesn't need to add parameter semantics beyond what the schema provides. The baseline for zero parameters is 4, as there's no parameter information that could be missing or inadequately described.
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 'Get cluster statistics' is a tautology that essentially restates the tool name 'get_cluster_stats'. While it correctly identifies the verb ('Get') and resource ('cluster statistics'), it doesn't provide any specific details about what kind of statistics are retrieved or how this differs from sibling tools like 'get_cluster_health' or 'get_shard_allocation'. The purpose is stated but lacks differentiation 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 Guidelines1/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 multiple sibling tools that appear related to cluster monitoring (e.g., 'get_cluster_health', 'get_hot_threads', 'get_recovery_status'), there's no indication of what specific statistics this tool provides or when it should be preferred over other cluster-related tools. The description is completely silent on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. The description only states what the tool does (generates a URL) without revealing any behavioral traits: it doesn't mention whether this requires authentication, has rate limits, returns a permanent or temporary URL, or what format the URL follows. This is inadequate for a tool with 4 required 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 a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool that generates URLs, though the brevity comes at the cost of missing important contextual information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 required parameters, no annotations, no output schema), the description is severely incomplete. It doesn't explain what the tool returns (just a URL string? with what properties?), how parameters interact, or any error conditions. For a URL generation tool with multiple time and query parameters, this leaves too many questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 4 parameters have descriptions in the schema. The tool description provides absolutely no information about what the parameters mean, their expected formats, or how they influence the generated URL. For example, it doesn't explain what 'query' should contain or how 'from_time' and 'to_time' should be formatted.
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 'Generate' and the resource 'OpenSearch Dashboards Discover view URL', making the purpose specific and understandable. However, it doesn't distinguish this tool from its siblings (which are primarily query/retrieval tools), missing the opportunity to clarify that this generates URLs rather than performing data 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?
The description provides no guidance on when to use this tool versus alternatives. Given the sibling tools include 'search_documents' and 'list_indices', there's no indication whether this URL generation is for visualization purposes, sharing links, or integration with other systems. No exclusions or prerequisites are mentioned.
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, the description carries full burden but only states the action without disclosing behavioral traits. It doesn't cover permissions, rate limits, response format, or whether it's read-only or has side effects, which is a significant gap for a tool with no annotation support.
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 extremely concise with a single phrase, front-loaded and zero waste. Every word earns its place, though this brevity contributes to gaps in other dimensions.
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 doesn't provide enough context for the agent to understand the tool's behavior, parameters, or output, making it inadequate for a tool with one required parameter.
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%, and the description adds no parameter semantics beyond the schema. It doesn't explain what 'index' means, valid values, or examples, failing to compensate for the lack of schema documentation.
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 'Get index settings' clearly states the action (get) and resource (index settings), but it's vague about what 'settings' encompasses and doesn't differentiate from siblings like 'get_mapping' or 'get_index_templates' which also retrieve index-related information. It avoids tautology but lacks specificity.
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. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone among similar tools like 'get_mapping' or 'list_indices'.
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 'gets' information, implying a read-only operation, but does not specify permissions, rate limits, side effects, or response format. 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 is a single, efficient sentence with no wasted words. It is front-loaded and directly states the tool's purpose, making it easy to parse and understand 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 lack of annotations, no output schema, and low schema description coverage, the description is incomplete. It does not compensate for these gaps by explaining parameters, return values, or behavioral details, making it inadequate for a tool with one required parameter and no structured context.
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?
The input schema has 1 parameter with 0% description coverage, and the tool description does not mention any parameters. It fails to explain what 'latest_index' means or how it affects the shard allocation distribution, leaving the parameter semantics undocumented and 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 tool's purpose as 'Get index shard allocation distribution,' specifying the action ('Get') and resource ('index shard allocation distribution'). It distinguishes from siblings like 'get_cluster_health' or 'list_indices' by focusing on shard allocation, but does not explicitly differentiate in the description text.
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 does not mention prerequisites, context, or exclusions, leaving the agent to infer usage from the purpose alone without explicit 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 the full burden of behavioral disclosure. It mentions 'custom query' but fails to describe key traits such as authentication needs, rate limits, pagination behavior, or what happens on errors (e.g., invalid index). This leaves significant gaps in understanding the tool's operation and 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 a single, efficient sentence with zero wasted words, front-loading the core action and context. It is appropriately sized for the tool's complexity, making it easy 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 tool's complexity (search with custom queries), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It omits details on return values, error handling, and operational constraints, 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.
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 for undocumented parameters. It only vaguely references 'custom query' without explaining what 'index' and 'body' parameters represent, their formats, or examples. This adds minimal value beyond the schema, failing to clarify parameter meanings adequately.
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 ('search') and resource ('documents'), and specifies the context ('in an opensearch index with a custom query'), making the purpose evident. However, it does not explicitly differentiate from siblings like 'list_indices' or 'get_mapping', which focus on metadata rather than document content, so it falls short of 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. It lacks information on prerequisites (e.g., index existence), exclusions (e.g., when not to use it), or comparisons to sibling tools like 'list_indices' for browsing indices, leaving the agent without contextual usage cues.
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 only states the action ('Get') without detailing aspects like whether it's a read-only operation, potential side effects, authentication needs, rate limits, or response format. This is insufficient for a tool with zero annotation coverage, as it omits critical behavioral context.
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 extremely concise—a single phrase—with no wasted words. It is front-loaded and directly states the tool's purpose, making it efficient and easy to parse. This is an example of optimal brevity for a simple tool.
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 lack of annotations and output schema, the description is incomplete. It does not explain what 'health status' includes (e.g., metrics, state details) or the return format, leaving gaps in understanding the tool's behavior and output. For a tool with no structured data support, more descriptive context is needed.
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 does not add parameter details, which is appropriate given the schema's completeness. A baseline score of 4 is assigned as it aligns with the schema without redundancy or gaps.
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 'Get cluster health status' clearly states the action (get) and target resource (cluster health status), which is adequate for understanding the basic purpose. However, it lacks specificity about what 'health status' entails (e.g., metrics, state) and does not differentiate from sibling tools like 'get_cluster_stats' or 'get_recovery_status', making it somewhat vague.
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. The description does not mention any context, prerequisites, or exclusions, and it fails to reference sibling tools that might overlap in functionality (e.g., 'get_cluster_stats'). This leaves the agent without direction on appropriate 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. 'Check hot threads on nodes' implies a read-only operation, but it lacks details on permissions needed, rate limits, output format (e.g., text or JSON), or whether it affects node performance. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Check hot threads on nodes' is a single, efficient sentence with no wasted words. It is appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration. Every word earns its place, making it highly concise.
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 monitoring tools and the lack of annotations and output schema, the description is incomplete. It does not explain what 'hot threads' are, how the output is structured, or any behavioral traits like safety or performance impact. For a tool that likely returns diagnostic data, more context is needed to be fully 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, meaning no parameters are documented in the schema. The description does not add parameter details, which is acceptable since there are no parameters to explain. This aligns with the baseline of 4 for zero parameters, as the description does not need to compensate for missing schema information.
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 'Check hot threads on nodes' states a clear verb ('check') and resource ('hot threads on nodes'), providing a basic purpose. However, it lacks specificity about what 'hot threads' means in this context (e.g., CPU-intensive threads in Elasticsearch) and does not distinguish this tool from siblings like 'get_tasks' or 'get_cluster_stats', which might also relate to node monitoring. This makes it vague but not tautological.
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 does not mention any context, prerequisites, or exclusions, such as when to prefer this over 'get_tasks' for thread analysis or 'get_cluster_health' for overall node status. Without such information, users must 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get current tasks' but doesn't clarify if this is a read-only operation, what permissions might be required, whether it's real-time or cached data, or any rate limits. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Get current tasks in cluster'. It's front-loaded with the core action and resource, with zero wasted words. Every part of the sentence contributes directly to the tool's purpose, making it highly concise and well-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 of cluster tasks and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'tasks' entail, the format or structure of the returned data, or any behavioral aspects like error handling. For a tool in a monitoring context with siblings that might overlap, more context is needed to guide effective use.
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 the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it correctly implies no parameters are required by not mentioning any. This aligns well with the schema, earning a baseline score above 3 due to the absence of parameters.
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 'Get current tasks in cluster' states a clear verb ('Get') and resource ('tasks in cluster'), but it's vague about scope and lacks differentiation from potential sibling tools. It doesn't specify what types of tasks (e.g., indexing, search, administrative) or what 'current' means temporally, which could be important given siblings like 'get_cluster_stats' and 'get_recovery_status' that might overlap in monitoring functions.
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 siblings like 'get_cluster_health', 'get_cluster_stats', and 'get_recovery_status', which might also provide task-related insights, there's no indication of when this specific tool is appropriate, leaving the agent to guess based on 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 full burden for behavioral disclosure. It states 'Get' implying a read operation, but doesn't specify if it's safe, requires permissions, has rate limits, or what the return format looks like (e.g., JSON structure, pagination). This leaves significant gaps for a tool that likely interacts with a system like Elasticsearch.
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 with zero waste. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place without redundancy or fluff.
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 index templates in systems like Elasticsearch, the description is incomplete. With no annotations, no output schema, and minimal behavioral details, it lacks information on return values, error handling, or operational context. Siblings suggest this is part of a cluster management suite, but the description doesn't leverage that context.
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 appropriately doesn't mention parameters, focusing on the tool's purpose. A baseline of 4 is given since no parameters exist, and the description doesn't add unnecessary 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 'Get index template configurations' clearly states the action (get) and resource (index template configurations). It distinguishes from siblings like 'get_mapping' or 'get_settings' by specifying the exact resource type. However, it doesn't specify scope (e.g., all templates vs specific ones) or format details, 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. It doesn't mention prerequisites, context for usage, or comparisons to sibling tools like 'list_index_patterns' or 'list_indices'. The agent must 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 but doesn't describe what 'list' entails—such as whether it returns all patterns, supports pagination, requires permissions, or has rate limits. 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 with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word contributes directly to stating the tool's purpose.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., format, structure of index patterns) or behavioral aspects like error handling. For a tool in a complex domain like OpenSearch, more context is needed to guide effective use.
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, but it also doesn't compensate for any gaps since there are none. A baseline of 4 is given as it meets the minimal requirement for a parameterless tool.
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 ('List') and resource ('OpenSearch Dashboards index patterns'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_indices' or 'get_index_templates', which might have overlapping functionality in the same 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?
No guidance is provided on when to use this tool versus alternatives like 'list_indices' or 'get_index_templates'. The description lacks context about specific use cases, prerequisites, 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. It states the action but doesn't cover important aspects like whether this is a read-only operation, potential performance impacts, rate limits, or authentication needs. This is a significant gap for a tool that interacts with a cluster.
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 highly efficient and easy to parse.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., list format, pagination) or behavioral traits like safety or performance. For a cluster interaction tool, this leaves critical gaps.
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 zero parameters, and the schema description coverage is 100% (though empty). The description doesn't need to add parameter details, so it meets the baseline for a parameterless tool. No additional value is required beyond stating the purpose.
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 ('List') and resource ('all indices in the Opensearch cluster'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_index_patterns' or 'get_index_templates', 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?
The description provides no guidance on when to use this tool versus alternatives like 'list_index_patterns' or 'get_index_templates'. It lacks context about use cases, prerequisites, or exclusions, leaving the agent with minimal 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 the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves: no information about permissions required, rate limits, pagination, error handling, or what 'configurations' includes. For a read operation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple retrieval tool with no parameters.
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 complete for understanding what it retrieves. However, with no annotations and no output schema, it lacks details about behavioral traits and return format, leaving gaps for the agent to infer.
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 with 100% schema description coverage, so the schema fully documents the absence of inputs. The description adds no parameter information, which is appropriate since there are none. The baseline for 0 parameters is 4, as no compensation is needed.
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 ('ISM policies and their configurations'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling tools that might also retrieve policy information, as none of the listed siblings appear to directly overlap with ISM policies.
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, context for use, or how it differs from other data retrieval tools in the sibling list (e.g., get_settings, get_index_templates). This leaves the agent without 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 the full burden of behavioral disclosure. It mentions retrieving 'recovery status and estimated completion time', which implies a read-only operation, but fails to detail aspects like authentication requirements, rate limits, error conditions, or what specific 'recovery' refers to (e.g., cluster recovery, index recovery). This leaves significant gaps in understanding the tool's 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 is a single, clear sentence with no wasted words, making it highly concise and front-loaded. Every part of the sentence directly contributes to explaining the tool's purpose, earning its place without unnecessary elaboration.
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 is low (0 parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It states what the tool retrieves but lacks context on the recovery process, output format, or how it integrates with sibling tools like 'get_cluster_health'. This leaves the agent with insufficient information for fully informed usage.
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 does not need to add parameter semantics beyond the schema, and it appropriately avoids mentioning any. A baseline of 4 is applied for zero-parameter tools, as there is no missing information to compensate for.
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 ('Get') and resource ('recovery status and estimated completion time'), making it immediately understandable. However, it doesn't distinguish this tool from potential sibling tools that might also retrieve status information, such as 'get_cluster_health' or 'get_cluster_stats', 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?
The description provides no guidance on when to use this tool versus alternatives like 'get_cluster_health' or 'get_cluster_stats', nor does it mention any prerequisites or context for usage. It merely states what the tool does without indicating appropriate scenarios or exclusions.
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:

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

Score Badge

Copy to your README.md:

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

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