mcp-opensearch

Server Quality Checklist

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

Latest release: v0.3.2
Disambiguation5/5
Each tool has a clearly distinct purpose: search, count, terms, histogram, stats, compare, explain, etc. No two tools overlap in functionality, and the descriptions make the differences explicit.
Naming Consistency4/5
All tools share the uniform 'opensearch_' prefix, but the action part varies between nouns (e.g., opensearch_terms) and imperative verbs (e.g., opensearch_list_indices). This is minor inconsistency but not confusing.
Tool Count5/5
With 17 tools, the server covers the full scope of OpenSearch read operations: connectivity, health, indices, mapping, search, aggregations, and specialized queries. The count feels right for the domain.
Completeness4/5
The tool set is comprehensive for read-only queries, including escape hatch for unmapped endpoints. Missing a dedicated get-document-by-ID tool is a minor gap, but search and explain cover it indirectly.
Average 4.5/5 across 17 of 17 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 25 commits in the last 12 weeks
- Last stable release on June 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses concrete behavior: 50 full docs ≈ 237 KB, omitting time filters scans full index (slow/expensive), and adding time range reduces query time up to 15×. With no annotations, this adds significant behavioral context beyond mere functionality.
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?
Two well-structured sentences with no fluff. First sentence defines purpose, second provides critical usage advice. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters and output schema, the description covers the core purpose and most critical performance considerations. Output schema makes return format documentation unnecessary. A minor omission is lack of guidance on offset pagination, but offset is well-described in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining why source_fields and from_ts/to_ts are important for performance and context usage, going beyond their schema 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?
Clearly states 'Full-document retrieval using Lucene syntax', which is specific and distinguishes from sibling tools like opensearch_count or opensearch_stats that do not return full documents. However, it does not explicitly mention when to use this over alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides important best practices (pass source_fields to limit size, add time range to reduce cost) but does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions computing diff and percent change automatically but does not disclose any other behavioral traits (e.g., rate limits, auth needs, destructive actions). Adequate for a read-like operation but lacks full 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?
Three sentences: first states core action, second gives usage guidance, third lists use cases. Front-loaded, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema, so return values need not be explained. Description covers purpose, usage, and intended outcomes. Could mention aggregation behavior, but adequate for 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 100%, so baseline is 3. The description does not add extra meaning beyond the schema; it explains the overall purpose but not individual parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it compares top values of a field between two time windows, and distinguishes from sibling opensearch_terms by emphasizing automatic diff/percent change calculation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using this tool over manual double calls to opensearch_terms, and lists use cases (detect new patterns, activity changes). No explicit when-not or alternatives beyond opensearch_terms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions single round-trip and fielddata heap avoidance, but with no annotations, more behavioral details (limits, errors) would be helpful.
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?
Two focused sentences, no fluff, front-loaded with key benefit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema covers return values. Description covers usage context and a gotcha. Lacks error/permission info but adequate for a simple aggregation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema does the heavy lifting. Description adds .keyword context but little extra semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs multi-field terms aggregation in a single round-trip, distinguishing it from looping opensearch_terms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends over looping opensearch_terms and provides .keyword guidance, but lacks explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It adds constraints ('Exact index name only — no wildcards') and metadata context (_id field), but does not disclose authorization needs, side effects (likely read-only, but unstated), or rate limits.
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?
Three concise sentences: purpose, usage context, constraint. Front-loaded with the core action, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and schema coverage is high, description provides sufficient context for an agent to use the tool. Lacks mention of error scenarios or output structure, but output schema compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters. Description adds clarifying context: 'Exact index name only' for index, 'as returned by a prior search' for doc_id, and Lucene query format for query_string. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'explain' and resource 'why a document matches or doesn't match a query'. Differentiates from siblings by specifying use after opensearch_search and requiring a known document ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('after opensearch_search returns unexpected results') and prerequisites ('known document ID'). Does not explicitly state when not to use, but context implies it's only for analysis of specific docs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It reveals key traits: only returns fields that appear in sampled documents, fields absent won't be listed, requires search privilege, and sample_size max 100. It could be more explicit about the trade-off of small sample sizes leading to incomplete results, but overall it provides sufficient 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 only three sentences, each serving a distinct purpose: stating the primary use case, explaining a key limitation, and comparing with a sibling tool while giving actionable advice. No words are wasted, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. It covers purpose, usage, behavioral traits, and parameter guidance. It could mention that the index must exist or how errors are handled, but for a relatively simple tool, it is highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds some context around sample_size by suggesting increasing it for broader coverage and mentioning the max of 100. However, it does not add significant new meaning beyond what the schema already provides for other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose as a fallback for opensearch_get_mapping when the mapping API is blocked, and that it samples live documents to discover fields. It clearly distinguishes itself from the sibling tool opensearch_get_mapping, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (as a fallback when the mapping API is blocked) and why it is preferred in certain contexts (only requires search privilege). It also provides guidance on adjusting sample_size for broader coverage, giving clear usage recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations available, so the description carries full burden. It discloses that fine intervals over long ranges are rejected for resource protection, but does not explicitly state that the tool is read-only or describe other behavioral traits like idempotency or authorization needs. Some transparency provided, but not exhaustive.
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?
Three concise sentences with no filler. First sentence states purpose, second gives primary usage guideline, third warns of a constraint. Front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, return values need no elaboration. The description covers key usage nuances (range necessity, interval behavior) and constraints. Minor omission: explicit mention that it produces histograms, but purpose implies that. Good completeness for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond schema: mandates from_ts/to_ts usage, recommends 'auto' interval, and explains rejection of fine intervals. This extra guidance raises the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Event count over time' with specific verb (count) and resource (events over time), and emphasizes the range requirement which distinguishes it from search or raw data retrieval tools. Siblings like opensearch_search, opensearch_terms, etc., have different purposes.
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?
Explicitly advises to 'always specify from_ts and to_ts' and recommends using interval='auto' when unsure. Warns that fine intervals over long ranges are rejected pre-query, providing clear when-to-use and safety constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does well to disclose key behaviors: never returns content, and full index scan timing. Could mention that it returns a single count value, but output schema likely covers that.
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?
Two sentences, efficient and front-loaded with the most important information about purpose and when to use. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of an output schema, the description covers all necessary context: what it does, when to use it, and a performance note. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add significant meaning beyond what is already in the schema for parameters like from_ts, to_ts, query_string, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is the fastest way to count documents matching a condition and explicitly says it never returns content. This distinguishes it from sibling tools like opensearch_search.
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?
Directly advises to prefer this tool over opensearch_search when only a count is needed, and provides performance context about full index scan duration when time filters are omitted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It reveals that nested fields are returned flattened to dot-notation, which is a key behavioral detail. It also implies the operation is read-only and requires specific permissions. Lacks mention of error formats or pagination, but the output schema provides additional structure.
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?
Two sentences, front-loaded with the core purpose, no fluff. Every sentence adds value: the first states what it does, the second provides the alternative and behavioral detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description is complete. It covers purpose, usage guidance, and a key behavioral trait. The sibling tool is mentioned, providing full 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 coverage is 100% and the sole parameter 'index' is well-described in the schema. The description does not add extra semantic meaning beyond the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'see all field names and types', specifying the verb 'see' and resource 'field names and types'. It distinguishes itself from the sibling tool opensearch_discover_fields by explaining the permission difference and data scope.
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?
Explicitly states when to use this tool versus the alternative: 'if you get 403 use opensearch_discover_fields instead'. Also explains the privilege difference (indices:admin/mappings/get vs search privilege), giving clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read operation but does not explicitly state read-only behavior, permissions, or potential side effects. For a simple read tool this is adequate but not fully transparent.
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?
Two sentences, front-loaded with the core purpose, followed by motivational examples and a sibling reference. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (one parameter with full schema coverage) and existence of an output schema, the description sufficiently explains what the tool does and when to use it, with illustrative examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The tool description adds value by listing what settings are retrieved for the given index, giving context beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets index settings, listing specific items (shard count, replicas, etc.). It also distinguishes from a sibling by advising to use opensearch_get_mapping for field schema exploration.
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?
Explicitly says when to use: to understand unexpected index behavior, with concrete examples. Also gives an alternative tool for a different purpose, providing clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes return values (backend, version, URL, username) and how to interpret the username for error diagnosis. Could mention if it has side effects, but it's a simple test.
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?
Two concise sentences with purpose front-loaded. Every sentence adds value: first states the primary action, second gives actionable diagnostic advice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple test tool with no parameters and an output schema presumably documenting return fields, the description is complete. It covers purpose, usage order, and key output interpretation.
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?
No parameters, so baseline 4. Description adds meaning by explaining the output fields and their use, which adds value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for confirming connectivity and seeing the active backend. It uses specific verbs like 'call first' and explains the purpose, distinguishing it from data retrieval siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call first in every session' and explains why, including debugging 403 errors. It lacks explicit when-not-to-use, but the context strongly implies it's the initial connectivity check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses required privilege (cluster:monitor/health) and error handling (403). Without annotations, this is transparent about access and safety. Could explicitly state it is a read-only operation, but the description is still informative.
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?
Three sentences cover privilege, returns, and usage without wasted words. Information is front-loaded and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema, the description adequately covers privilege, return fields, and use case. It is complete for tool selection and basic 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?
No parameters exist in the input schema, and schema coverage is 100%. Baseline score of 4 applies as there is nothing to add beyond what the schema already defines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns cluster status with specific fields (green/yellow/red, node count, active shards, unassigned shards). It distinguishes itself from sibling opensearch_test by suggesting fallback on 403, clarifying its purpose.
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?
Explicitly advises when to use: to confirm backend is not degraded before trusting query results. Also provides a conditional alternative: if 403, use opensearch_test. This gives clear when-to and when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It states the tool is read-like, returns specific fields, and requires Dashboards backend. However, it omits behavior if backend is down (e.g., empty result vs error) and does not explicitly label as read-only, but it is sufficiently transparent for its simplicity.
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?
Two concise sentences, front-loaded with purpose and alternative, no wasted words. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple (0 parameters, output schema exists). Description covers purpose, use case, return fields, and dependency. No gaps given the 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?
Input schema has zero parameters (100% coverage trivially). Baseline for 0 params is 4. No parameter information needed; description focuses on output and usage, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Dashboards-only alternative to opensearch_list_indices' that 'returns id, title, and time field name for each index pattern'. It uses specific verbs and resource (list index patterns) and distinguishes from sibling opensearch_list_indices.
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?
Explicitly says when to use: when '_cat/indices access is blocked'. Also mentions prerequisite: 'Requires the Dashboards backend to be active'. This clearly distinguishes from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description adds valuable behavioral context: the tool returns specific fields (doc count, store size, health), sorting behavior, and the potential for a 403 error with an alternative. However, it does not explicitly state if the operation is read-only or mention other constraints like rate limits, so one point off.
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?
Three sentences efficiently cover the fallback, return data, and usage hint. No fluff or redundancy; every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an existing output schema, the description provides complete context: return structure, sorting, error handling, and a concrete use case. There is no missing information.
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?
There are zero parameters and schema coverage is 100%, so the baseline is 4. The description does not need to add parameter semantics, but it does add usage context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns all indices sorted by name with doc count, store size, and health. It also explains the use case of finding exact index name before querying and describes the date-sharded naming pattern, distinguishing it from sibling tools like opensearch_search or opensearch_cluster_health.
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?
Explicitly provides a fallback alternative (opensearch_list_index_patterns) for lower privilege requirements, and explains when to use the tool (before querying for exact index name). This gives clear guidance on when to use this tool vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses that the tool errors gracefully on non-numeric fields, implying safety. It does not cover other behaviors like performance or pagination, but the output schema exists to describe return values.
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 two paragraphs: first states purpose and constraint, second details error handling and alternative. Every sentence adds value, and it is front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple stats tool with full schema coverage and an output schema, the description covers the numeric constraint, error behavior, and alternative tool. It provides sufficient context for correct agent 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?
Schema coverage is 100%, baseline 3. The description adds critical context: the field must be numeric and provides example formats ('rule.level', 'data.bytes'), which is not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool computes min/max/avg/std for a numeric field, with a specific verb and resource. It distinguishes itself from opensearch_terms by noting the alternative for keyword fields.
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?
Explicitly states the tool only works on numeric fields, warns of a 400 error for text fields, and recommends opensearch_terms for keyword fields. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are present, the description carries the full burden. It discloses the heap warning and fielddata loading concerns for analyzed fields, but doesn't describe the return format or pagination behavior. Output schema covers return format, making this adequate.
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?
Three sentences, front-loaded with the core purpose, every sentence adds essential information with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and parameters are fully described, the description provides all necessary context: purpose, usage rules, and behavioral caveats, making it complete for effective tool 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?
With 100% schema coverage, baseline is 3. The description adds value by giving concrete field examples ('agent.name', 'rule.id') and usage advice, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a 'frequency table for a keyword field' returning 'top N values with their document counts,' which precisely defines the tool's purpose and distinguishes it from siblings like opensearch_multi_terms and opensearch_search.
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?
Provides explicit when-to-use advice (keyword fields), a concrete fix for common issues ('append .keyword'), and a clear prohibition ('never use on analyzed text fields') with a reason, offering complete guidance for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses a critical failure mode (404 if PPL plugin not installed) and explains that it executes a query (implying read operation). However, it does not explicitly state whether the tool is read-only or if it can mutate data, which is a minor 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 concise and well-structured: a one-line purpose, a usage guideline, syntax format, and a list of common commands. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter with complete schema coverage and presence of an output schema, the description thoroughly covers syntax, common commands, alternative tool guidance, and a failure case. It is fully sufficient for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'query' with 100% schema coverage. The description adds significant value by providing PPL syntax, common commands (where, stats, fields, sort, head) and their usage, far exceeding the schema's bare description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a PPL query against OpenSearch, using a specific verb and resource. It distinguishes from sibling tool opensearch_search by noting PPL vs Lucene syntax, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to prefer over opensearch_search for multi-step pipeline operations, warns about non-interchangeability with Lucene, and mentions a specific failure condition (404 if plugin missing). Provides clear when-to-use and not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that only GET is supported, write/admin paths are blocked, and that dedicated tools have safety guards and better error messages, implying reduced safety for this tool.
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?
Extremely concise with three short sentences. First sentence states primary purpose, second gives usage guidance, third clarifies limitations. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (context indicates exists), description does not need to explain return values. It covers allowed operations, usage context, and limitations completely for a single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the 'path' parameter. The description adds value by specifying it must start with '/' and giving an example ('/_nodes/stats'), which complements the schema well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is an 'escape hatch for any read GET endpoint not covered by other tools', specifying the verb (GET), the resource (OpenSearch endpoints), and distinguishing it from sibling tools by naming dedicated tools for specific operations.
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?
Explicitly states when to use (when no dedicated tool exists) and when not to (use dedicated tools for search/count/terms/histogram). Also warns that write/admin paths are blocked, providing clear guidance on appropriate usage.
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:

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

Score Badge

Copy to your README.md:

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

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/bunnyiesart/mcp-opensearch'

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