Skip to main content
Glama
opensearch-project

opensearch-mcp-server-py

Official
by opensearch-project
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Remote

OpenSearch logo

OpenSearch MCP Server

opensearch-mcp-server-py is a Model Context Protocol (MCP) server for OpenSearch that enables AI assistants to interact with OpenSearch clusters. It provides a standardized interface for AI models to perform operations like searching indices, retrieving mappings, and managing shards through both stdio and streaming (SSE/Streamable HTTP) protocols.

Key features:

  • Seamless integration with AI assistants and LLMs through the MCP protocol

  • Support for both stdio and streaming server transports (SSE and Streamable HTTP)

  • Built-in tools for common OpenSearch operations

  • Dynamic per-call connection parameters for targeting different clusters without server reconfiguration

  • Easy integration with Claude Desktop and LangChain

  • Secure authentication using basic auth, IAM roles, header-based auth, and OpenSearch mTLS

For detailed setup, including Kubernetes deployment and mTLS configuration, see the User Guide.

Related MCP server: OpenSearch MCP Server

Installing opensearch-mcp-server-py

Opensearch-mcp-server-py can be installed from PyPI via pip:

pip install opensearch-mcp-server-py

Zero-Config Setup

The server can be started with no environment variables at all. Agents provide connection details dynamically on each tool call:

{
  "mcpServers": {
    "opensearch": {
      "command": "uvx",
      "args": ["opensearch-mcp-server-py"]
    }
  }
}

With this setup, agents pass opensearch_url and authentication parameters directly when calling any tool. This is useful when agents discover endpoints from a knowledge base, runbook, or SOP, or when a single agent needs to work with multiple clusters in one session. See Dynamic Connection Parameters for details.

Available Tools

By default, only core tools are enabled to provide essential OpenSearch functionality:

Core Tools (Enabled by Default)

Core tools are grouped under the core_tools category and can be disabled at once using OPENSEARCH_DISABLED_CATEGORIES=core_tools. Avoid creating custom categories with this name as they will override the built-in category.

  • ListIndexTool: Lists all indices in OpenSearch with full information including docs.count, docs.deleted, store.size, etc. If an index parameter is provided, returns detailed information about that specific index.

  • IndexMappingTool: Retrieves index mapping and setting information for an index in OpenSearch.

  • SearchIndexTool: Searches an index using a query written in query domain-specific language (DSL) in OpenSearch.

  • GetShardsTool: Gets information about shards in OpenSearch.

  • ClusterHealthTool: Returns basic information about the health of the cluster.

  • CountTool: Returns number of documents matching a query.

  • ExplainTool: Returns information about why a specific document matches (or doesn't match) a query.

  • MsearchTool: Allows to execute several search operations in one request.

  • [GenericOpenSearchApiTool]: A flexible tool that can call any OpenSearch API endpoint with custom paths, methods, query parameters, and request bodies. Reduces tool explosion by providing a single interface for all OpenSearch APIs.

Additional Tools (Disabled by Default)

The following tools are available but disabled by default. To enable them, see the Tool Filter section in the User Guide.

  • GetClusterStateTool: Gets the current state of the cluster including node information, index settings, and more.

  • GetSegmentsTool: Gets information about Lucene segments in indices, including memory usage, document counts, and segment sizes.

  • CatNodesTool: Gets information about nodes in the OpenSearch cluster, including system metrics like CPU usage, memory, disk space, and node roles.

  • GetNodesTool: Gets detailed information about nodes in the OpenSearch cluster, including static information like host system details, JVM info, processor type, node settings, thread pools, installed plugins, and more.

  • GetIndexInfoTool: Gets detailed information about an index including mappings, settings, and aliases. Supports wildcards in index names.

  • GetIndexStatsTool: Gets statistics about an index including document count, store size, indexing and search performance metrics.

  • GetQueryInsightsTool: Gets query insights from the /_insights/top_queries endpoint, showing information about query patterns and performance.

  • GetNodesHotThreadsTool: Gets information about hot threads in the cluster nodes from the /_nodes/hot_threads endpoint.

  • GetAllocationTool: Gets information about shard allocation across nodes in the cluster from the /_cat/allocation endpoint.

  • GetLongRunningTasksTool: Gets information about long-running tasks in the cluster, sorted by running time in descending order.

Agentic Memory Tools (Disabled by Default)

The following tools expose the OpenSearch Agentic Memory API — a server-side memory system built into OpenSearch itself. The OpenSearch cluster manages memory containers, sessions, and inference (LLM-based extraction of facts from conversations). These tools require OpenSearch 3.3.0 or later.

When to use: You want OpenSearch to own the full memory lifecycle — including LLM-based inference to extract facts from raw conversations, structured memory types (sessions, working, long-term, history), and server-managed namespacing. Best for production agentic pipelines where memory management should be centralized and not depend on the MCP client.

Setup: You must create a memory container in OpenSearch before using these tools (one-time admin operation requiring LLM connector and embedding model configuration). See Agentic Memory Tools in the Agent Memory Guide.

Enable with OPENSEARCH_ENABLED_CATEGORIES=agentic_memory. When memory_container_id is configured via the agentic_memory config section or OPENSEARCH_MEMORY_CONTAINER_ID environment variable, it is automatically pre-filled in all tool calls.

Observability Tools (Disabled by Default)

Observability tools are grouped under the observability category and can be enabled using OPENSEARCH_ENABLED_CATEGORIES=observability or by adding enabled_categories: [observability] to the config file. Alternatively, enable the analytics category to get both observability and skills tools at once.

  • PPLQueryTool: Executes a PPL (Piped Processing Language) query against OpenSearch. PPL provides a pipe-based syntax for querying data (source=<index> | <command> | <command>), supporting filtering, aggregation, sorting, deduplication, and field selection. Supports jdbc, csv, and raw output formats.

Search Relevance Workbench Tools (Disabled by Default)

Search Relevance Workbench tools are grouped under the search_relevance category and can be enabled at once using OPENSEARCH_ENABLED_CATEGORIES=search_relevance or by adding enabled_categories: [search_relevance] or explicitly adding individual tools to their config file. See the Tool Filter section in the User Guide for additional information about how to filter tools.

Skills Tools (Disabled by Default)

Skills tools are grouped under the skills category and can be enabled at once using OPENSEARCH_ENABLED_CATEGORIES=skills or by adding enabled_categories: [skills] to the config file. Alternatively, enable the analytics category to get both skills and observability tools at once. See the Tool Filter section in the User Guide for additional information about how to filter tools.

  • DataDistributionTool: Analyzes data distribution patterns and field value frequencies within OpenSearch indices. Supports both single dataset analysis and comparative analysis between two time periods to identify distribution changes.

  • LogPatternAnalysisTool: Detects anomalous log patterns and sequences through comparative analysis between baseline and selection time ranges. Supports log sequence analysis with trace correlation, log pattern difference analysis, and log insights analysis for error detection.

  • MetricChangeAnalysisTool: Compares percentile distributions (P50, P90) of all numeric fields between a baseline and a selection time range, then returns the top fields ranked by change score. Useful for identifying which numeric metrics shifted most during an anomaly window.

Memory Tools (Opt-in)

Memory tools give the MCP agent itself persistent, cross-session memory backed by OpenSearch. The agent decides what to save as plain-text statements; OpenSearch stores and semantically indexes them. Enable with MEMORY_TOOLS_ENABLED=true. See the Agent Memory Guide for full setup instructions.

When to use: You want a lightweight, agent-driven memory layer that works with any MCP-compatible IDE (Kiro, Claude Code, Cursor). The agent controls what gets remembered — no LLM connectors or embedding models to configure on the OpenSearch side. Requires Amazon OpenSearch Service (managed domain 2.19+ or Serverless) for automatic semantic enrichment. See the Agent Memory Guide for full setup instructions.

  • SaveMemoryTool: Saves facts, decisions, and preferences to persistent storage with automatic semantic enrichment.

  • SearchMemoryTool: Searches memories using natural language with recency-aware ranking.

  • DeleteMemoryTool: Removes outdated or incorrect memories by document ID.

Tool Parameters

All tools accept the following optional connection parameters that override the server's environment variable configuration on a per-call basis. When all are omitted, the server uses its configured environment variables or cluster config as usual. When you supply opensearch_url, the credentials must come from that same call: the server will not use its own credentials against a URL a caller chose, unless the operator sets OPENSEARCH_ALLOW_AMBIENT_AWS_FALLBACK=true to share its AWS credentials.

Parameter

Type

Description

opensearch_url

string

OpenSearch endpoint URL. Overrides OPENSEARCH_URL.

opensearch_username

string

Username for basic auth. Overrides OPENSEARCH_USERNAME.

opensearch_password

string

Password for basic auth. Overrides OPENSEARCH_PASSWORD.

opensearch_no_auth

boolean

Connect without authentication. Overrides OPENSEARCH_NO_AUTH.

aws_region

string

AWS region. Overrides AWS_REGION.

aws_iam_arn

string

IAM role ARN. Overrides AWS_IAM_ARN.

aws_profile

string

AWS profile name. Overrides AWS_PROFILE.

aws_opensearch_serverless

boolean

Use OpenSearch Serverless. Overrides AWS_OPENSEARCH_SERVERLESS.

opensearch_ssl_verify

boolean

Set true to require SSL certificate verification. A false value is ignored, since only OPENSEARCH_SSL_VERIFY may disable it.

opensearch_timeout

integer

Connection timeout in seconds. Overrides OPENSEARCH_TIMEOUT.

This allows agents to dynamically target different clusters per tool call without reconfiguring the server (single mode only). Credentials must come from the same call as the URL, unless OPENSEARCH_ALLOW_AMBIENT_AWS_FALLBACK=true lets the server sign caller-supplied URLs with its own AWS credentials. OPENSEARCH_SSRF_GUARD=true restricts caller-supplied URLs to public HTTPS addresses. See Dynamic Connection Parameters in the User Guide for details and examples.

In addition to the common connection parameters above, each tool accepts its own specific parameters:

Note: The opensearch_url parameter listed under individual tools below is part of the common connection parameters described above. All common connection parameters (opensearch_username, opensearch_password, aws_region, etc.) are available on every tool but are not repeated in each tool's parameter list for brevity.

  • ListIndexTool

    • opensearch_url (optional): The OpenSearch cluster URL to connect to

    • index (optional): The name of the index to get detailed information for. If provided, returns detailed information about this specific index instead of listing all indices.

  • IndexMappingTool

    • opensearch_url (optional): The OpenSearch cluster URL to connect to

    • index (required): The name of the index to retrieve mappings for

  • SearchIndexTool

    • opensearch_url (optional): The OpenSearch cluster URL to connect to

    • index (required): The name of the index to search in

    • query_dsl (required): The search query in OpenSearch Query DSL format

    • format (optional): The format of SearchIndexTool response. options are csv and json

    • size (optional): The size of SearchIndexTool response. Default is 10, maximum is 100 (configurable). To change the maximum limit, set max_size_limit via CLI arguments or config file. See Tool Customization for details.

  • GetShardsTool

    • opensearch_url (optional): The OpenSearch cluster URL to connect to

    • index (required): The name of the index to get shard information for

  • ClusterHealthTool

    • opensearch_url (optional): The OpenSearch cluster URL to connect to

    • index (optional): Limit health reporting to a specific index

  • CountTool

    • opensearch_url (optional): The OpenSearch cluster URL to connect to

    • index (optional): The name of the index to count documents in

    • body (optional): Query in JSON format to filter documents

  • ExplainTool

    • opensearch_url (optional): The OpenSearch cluster URL to connect to

    • index (required): The name of the index to retrieve the document from

    • id (required): The document ID to explain

    • body (required): Query in JSON format to explain against the document

  • MsearchTool

    • opensearch_url (optional): The OpenSearch cluster URL to connect to

    • index (optional): Default index to search in

    • body (required): Multi-search request body in NDJSON format

  • GetClusterStateTool

    • opensearch_url (optional): The OpenSearch cluster URL to connect to

    • metric (optional): Limit the information returned to the specified metrics. Options include: _all, blocks, metadata, nodes, routing_table, routing_nodes, master_node, version

    • index (optional): Limit the information returned to the specified indices

  • GetSegmentsTool

    • opensearch_url (optional): The OpenSearch cluster URL to connect to

    • index (optional): Limit the information returned to the specified indices. If not provided, returns segments for all indices

  • CatNodesTool

    • opensearch_url (optional): The OpenSearch cluster URL to connect to

    • metrics (optional): A comma-separated list of metrics to display. Available metrics include: id, name, ip, port, role, master, heap.percent, ram.percent, cpu, load_1m, load_5m, load_15m, disk.total, disk.used, disk.avail, disk.used_percent

  • GetNodesTool

    • opensearch_url (optional): The OpenSearch cluster URL to connect to

    • node_id (optional): A comma-separated list of node IDs or names to limit the returned information. Supports node filters like _local, _master, master:true, data:false, etc. Defaults to _all.

    • metric (optional): A comma-separated list of metric groups to include in the response. Options include: settings, os, process, jvm, thread_pool, transport, http, plugins, ingest, aggregations, indices. Defaults to all metrics.

  • GetIndexInfoTool

    • opensearch_url (optional): The OpenSearch cluster URL to connect to

    • index (required): The name of the index to get detailed information for. Wildcards are supported.

  • GetIndexStatsTool

    • opensearch_url (optional): The OpenSearch cluster URL to connect to

    • index (required): The name of the index to get statistics for. Wildcards are supported.

    • metric (optional): Limit the information returned to the specified metrics. Options include: _all, completion, docs, fielddata, flush, get, indexing, merge, query_cache, refresh, request_cache, search, segments, store, warmer, bulk

  • GetQueryInsightsTool

    • opensearch_url (optional): The OpenSearch cluster URL to connect to

  • GetNodesHotThreadsTool

    • opensearch_url (optional): The OpenSearch cluster URL to connect to

  • GetAllocationTool

    • opensearch_url (optional): The OpenSearch cluster URL to connect to

  • GetLongRunningTasksTool

    • opensearch_url (optional): The OpenSearch cluster URL to connect to

    • limit (optional): The maximum number of tasks to return. Default is 10.

  • CreateAgenticMemorySessionTool

    • memory_container_id (auto-populated): The ID of the memory container where the session will be created. Automatically set when configured via agentic_memory config or OPENSEARCH_MEMORY_CONTAINER_ID env var. (Path Parameter)

    • session_id (optional): A custom session ID. If not provided, a random ID is generated. (Body Parameter)

    • summary (optional): A session summary or description. (Body Parameter)

    • metadata (optional): Additional metadata for the session provided as key-value pairs. (Body Parameter)

    • namespace (optional): Namespace information for organizing the session. (Body Parameter)

  • AddAgenticMemoriesTool

    • memory_container_id (auto-populated): The ID of the memory container to add the memory to. Automatically set when configured. (Path Parameter)

    • messages (conditional): A list of messages. Required when payload_type is conversational. (Body Parameter)

    • structured_data (conditional): Structured data content. Required when payload_type is data. (Body Parameter)

    • binary_data (optional): Binary data content encoded as a Base64 string for binary payloads. (Body Parameter)

    • payload_type (required): The type of payload. Valid values are conversational or data. See Payload types. (Body Parameter)

    • namespace (optional): The namespace context for organizing memories (for example, user_id, session_id, or agent_id). If session_id is not specified in the namespace field and disable_session: false (default is true), a new session with a new session ID is created. (Body Parameter)

    • metadata (optional): Additional metadata for the memory (for example, status, branch, or custom fields). (Body Parameter)

    • tags (optional): Tags for categorizing memories. (Body Parameter)

    • infer (optional): Whether to use an LLM to extract key information (default: false). When true, the LLM extracts key information from the original text and stores it as a memory. See Inference mode. (Body Parameter)

  • GetAgenticMemoryTool

    • memory_container_id (auto-populated): The ID of the memory container from which to retrieve the memory. Automatically set when configured. (Path Parameter)

    • type (required): The memory type. Valid values are sessions, working, long-term, and history. (Path Parameter)

    • id (required): The ID of the memory to retrieve. (Path Parameter)

  • SearchAgenticMemoryTool

    • memory_container_id (auto-populated): The ID of the memory container. Automatically set when configured. (Path Parameter)

    • type (required): The memory type. Valid values are sessions, working, long-term, and history. (Path Parameter)

    • query (required): The search query using OpenSearch query DSL. (Body Parameter)

    • sort (optional): Sort specification for the search results. (Body Parameter)

  • UpdateAgenticMemoryTool

    • memory_container_id (auto-populated): The ID of the memory container. Automatically set when configured. (Path Parameter)

    • type (required): The memory type (sessions, working, or long-term).(Path Parameter)

    • id (required): The ID of the memory to update.(Path Parameter)

    • Session memory request fields:

      • summary (optional): The summary of the session. (Body Parameter)

      • metadata (optional): Additional metadata for the memory (for example, status, branch, or custom fields). (Body Parameter)

      • agents (optional): Additional information about the agents. (Body Parameter)

      • additional_info (optional): Additional metadata to associate with the session. (Body Parameter)

    • Working memory request fields

      • messages (optional): Updated conversation messages (for conversation type). (Body Parameter)

      • structured_data (optional): Updated structured data content (for data memory payloads). (Body Parameter)

      • binary_data (optional): Updated binary data content (for data memory payloads). (Body Parameter)

      • tags (optional): Updated tags for categorization. (Body Parameter)

      • metadata (optional): Additional metadata for the memory (for example, status, branch, or custom fields). (Body Parameter)

    • Long-term memory request fields

      • memory (optional): The updated memory content. (Body Parameter)

      • tags (optional): Updated tags for categorization. (Body Parameter)

  • DeleteAgenticMemoryByIDTool

    • memory_container_id (auto-populated): The ID of the memory container from which to delete the memory. Automatically set when configured. (Path Parameter)

    • type (required): The type of memory to delete. Valid values are sessions, working, long-term, and history. (Path Parameter)

    • id (required): The ID of the specific memory to delete. (Path Parameter)

  • DeleteAgenticMemoryByQueryTool

    • memory_container_id (auto-populated): The ID of the memory container from which to delete the memory. Automatically set when configured. (Path Parameter)

    • type (required): The type of memory to delete. Valid values are sessions, working, long-term, and history. (Path Parameter)

    • query (required): The OpenSearch DSL query to match memories for deletion. (Body Parameter)

  • DataDistributionTool

    • index (required): Target OpenSearch index name.

    • selectionTimeRangeStart (required): Start time for analysis target period.

    • selectionTimeRangeEnd (required): End time for analysis target period.

    • timeField (required): Date/time field for filtering.

    • baselineTimeRangeStart (optional): Start time for baseline period.

    • baselineTimeRangeEnd (optional): End time for baseline period.

    • size (optional): Maximum number of documents to analyze. Default is 1000.

  • LogPatternAnalysisTool

    • index (required): Target OpenSearch index name containing log data.

    • logFieldName (required): Field containing raw log messages to analyze.

    • selectionTimeRangeStart (required): Start time for analysis target period.

    • selectionTimeRangeEnd (required): End time for analysis target period.

    • timeField (required): Date/time field for time-based filtering.

    • traceFieldName (optional): Field for trace/correlation ID.

    • baseTimeRangeStart (optional): Start time for baseline comparison period.

    • baseTimeRangeEnd (optional): End time for baseline comparison period.

  • MetricChangeAnalysisTool

    • index (required): Target OpenSearch index name.

    • selectionTimeRangeStart (required): Start of the selection (anomaly) period.

    • selectionTimeRangeEnd (required): End of the selection (anomaly) period.

    • baselineTimeRangeStart (required): Start of the baseline period.

    • baselineTimeRangeEnd (required): End of the baseline period (should be at or before selectionTimeRangeStart).

    • timeField (required): Date/time field for filtering.

    • topN (optional): Number of top fields to return, ranked by change score. Default is 10.

    • size (optional): Maximum number of documents to analyze. Default is 1000.

More tools coming soon. Click here

User Guide

For detailed usage instructions, configuration options, and examples, please see the User Guide.

Agent Memory

The OpenSearch MCP server includes two distinct memory systems. Both use OpenSearch as the storage backend but differ in who controls the memory lifecycle and what infrastructure they require.

Choosing the right approach

Memory Tools (MEMORY_TOOLS_ENABLED)

Agentic Memory Tools (agentic_memory category)

Who stores memories

The MCP agent decides what to save as plain-text statements

OpenSearch processes raw conversations and extracts facts via LLM inference

Setup complexity

Low — index is auto-created on first use

High — requires creating a memory container with LLM connector and embedding model

OpenSearch version

Amazon OpenSearch Service 2.19+ or Serverless

OpenSearch 3.3.0+

Semantic search

Yes, via AWS automatic semantic enrichment

Yes, via configured embedding model

Memory structure

Flat — each memory is a plain-text statement

Structured — sessions, working, long-term, and history types

LLM inference

No — agent writes exactly what it wants to remember

Optional (infer: true) — OpenSearch uses an LLM to extract facts from conversations

Best for

IDE agents (Kiro, Claude Code, Cursor) that need quick setup and cross-session continuity

Production agentic pipelines where memory management should be centralized and server-owned

Use Memory Tools when you want a lightweight, agent-driven memory layer that works out of the box with any MCP-compatible IDE. The agent controls what gets remembered. See the Agent Memory Guide for setup.

Use Agentic Memory Tools when you want OpenSearch to own the full memory lifecycle — including LLM-based extraction of facts from raw conversations, structured memory types, and server-managed namespacing. See the Agent Memory Guide for setup.

Contributing

Interested in contributing? Check out our:

Code of Conduct

This project has adopted the Amazon Open Source Code of Conduct. For more information see the Code of Conduct FAQ, or contact opensource-codeofconduct@amazon.com with any additional questions or comments.

License

This project is licensed under the Apache v2.0 License.

Copyright

Copyright 2020-2021 Amazon.com, Inc. or its affiliates. All Rights Reserved.

Available Tools

9 tools
ClusterHealthToolC

Returns basic information about the health of the cluster.

ParametersJSON Schema
NameRequiredDescriptionDefault
indexNo
aws_regionNoAWS region for IAM/Serverless authentication.
aws_iam_arnNoIAM role ARN for role-based authentication.
aws_profileNoAWS profile name for authentication.
opensearch_urlYesOpenSearch endpoint URL.
opensearch_no_authNoIf true, connect without authentication.
opensearch_timeoutNoConnection timeout in seconds.
opensearch_passwordNoPassword for basic authentication.
opensearch_usernameNoUsername for basic authentication.
opensearch_ssl_verifyNoIf false, disable SSL certificate verification.
aws_opensearch_serverlessNoIf true, use OpenSearch Serverless service.

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description alone must disclose behavioral traits. It only says 'Returns basic information', which gives no insight into safety (e.g., read-only), idempotency, required permissions, or what specific data is returned. This is insufficient for an agent to anticipate side effects or authorization needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that is easy to parse. While it could include more detail without becoming verbose, the current length is efficient and front-loaded.

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 has 11 parameters covering complex authentication scenarios and no output schema, the description is too brief. It does not explain the nature of the 'basic information' returned, how to select among authentication methods, or any context about cluster health checks, leaving significant gaps for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has high coverage (91%) with descriptions for most parameters. The description adds no additional information beyond what the schema already provides, so it meets the baseline but does not surpass it.

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 states the tool returns 'basic information about the health of the cluster', which clearly indicates the purpose. However, it does not specify that it is an OpenSearch cluster, and 'basic information' is somewhat vague, leaving room for ambiguity compared to a more detailed purpose statement.

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 sibling tools such as ListIndexTool or SearchIndexTool. There is no mention of prerequisites, recommended context, or alternatives, leaving the agent without strategic selection cues.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

CountToolC

Returns number of documents matching a query.

ParametersJSON Schema
NameRequiredDescriptionDefault
bodyNoRequest body
indexNo
aws_regionNoAWS region for IAM/Serverless authentication.
aws_iam_arnNoIAM role ARN for role-based authentication.
aws_profileNoAWS profile name for authentication.
opensearch_urlYesOpenSearch endpoint URL.
opensearch_no_authNoIf true, connect without authentication.
opensearch_timeoutNoConnection timeout in seconds.
opensearch_passwordNoPassword for basic authentication.
opensearch_usernameNoUsername for basic authentication.
opensearch_ssl_verifyNoIf false, disable SSL certificate verification.
aws_opensearch_serverlessNoIf true, use OpenSearch Serverless service.

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description fails to disclose behavioral traits beyond returning a count. It does not mention that the operation is read-only or describe the impact of the 'body' parameter on the query. Critical details about authentication, timeouts, or error handling are omitted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise at one sentence, but it could be improved by adding a brief note on usage or linking to the schema for parameter details. It is front-loaded with the core 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 12 parameters, no output schema, and no annotations, the description is insufficient. It does not explain the 'body' parameter's role in the query, limitations like max count, or how to handle authentication parameters. The tool's complexity demands more 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 high (92%), so the schema already documents most parameters. The description adds no additional context about parameter usage or how they relate to the count operation, such as the role of 'body' in defining the query.

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 returns a count of documents matching a query, which matches the tool name and distinguishes it from sibling document retrieval tools like SearchIndexTool. However, it does not explicitly differentiate from other sibling tools.

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 such as SearchIndexTool or MsearchTool. The description lacks explicit when-to-use or when-not-to-use instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ExplainToolC

Returns information about why a specific document matches (or doesn't match) a query.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYes
bodyYesRequest body containing the query to explain.
indexYes
aws_regionNoAWS region for IAM/Serverless authentication.
aws_iam_arnNoIAM role ARN for role-based authentication.
aws_profileNoAWS profile name for authentication.
opensearch_urlYesOpenSearch endpoint URL.
opensearch_no_authNoIf true, connect without authentication.
opensearch_timeoutNoConnection timeout in seconds.
opensearch_passwordNoPassword for basic authentication.
opensearch_usernameNoUsername for basic authentication.
opensearch_ssl_verifyNoIf false, disable SSL certificate verification.
aws_opensearch_serverlessNoIf true, use OpenSearch Serverless service.

TDQS

C2.9/5.0
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. It only states the high-level purpose without disclosing that this is a read-only operation, what the response format is, or any prerequisites like authentication handled via parameters. The description adds minimal behavioral context beyond the obvious.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, no wasted words. It could incorporate more context without being verbose. It is efficiently concise but lacks details that would improve utility.

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?

With 13 parameters, no output schema, and no annotations, the description is incomplete. It does not mention that it executes an OpenSearch explain API, what the expected return structure is, or any usage caveats. Much context is missing for a tool with this complexity.

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 85%, so the schema already documents most parameters. The description does not add any meaning beyond the schema; it does not explain that 'id' is the document ID or 'body' is the query. Baseline 3 is appropriate given high schema coverage.

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 it returns information about why a document matches or doesn't match a query. It uses specific verbs ('returns information') and resource ('specific document'). However, it does not differentiate from sibling tools like SearchIndexTool, which is a related but distinct function.

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 on when to use this tool versus alternatives. It does not mention that it is for debugging scoring or that it requires an existing query. Sibling tools like SearchIndexTool have overlapping contexts, but no exclusions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GenericOpenSearchApiToolA

A flexible tool for calling any OpenSearch API endpoint. Supports all HTTP methods with custom paths, query parameters, request bodies, and headers. Use this when you need to access OpenSearch APIs that don't have dedicated tools, or when you need more control over the request. Leverages your knowledge of OpenSearch API documentation to construct appropriate requests.

ParametersJSON Schema
NameRequiredDescriptionDefault
bodyNoRequest body for GET/POST/PUT requests. Can be a JSON object, string, or None
pathYesThe API endpoint path (e.g., "/_search", "/_cat/indices", "/my_index/_doc/1"). Should start with "/".
methodNoHTTP method to use (GET, POST, PUT, DELETE, HEAD, PATCH)GET
headersNoAdditional HTTP headers to include in the request
aws_regionNoAWS region for IAM/Serverless authentication.
aws_iam_arnNoIAM role ARN for role-based authentication.
aws_profileNoAWS profile name for authentication.
query_paramsNoQuery parameters to include in the request URL as key-value pairs
opensearch_urlYesOpenSearch endpoint URL.
opensearch_no_authNoIf true, connect without authentication.
opensearch_timeoutNoConnection timeout in seconds.
opensearch_passwordNoPassword for basic authentication.
opensearch_usernameNoUsername for basic authentication.
opensearch_ssl_verifyNoIf false, disable SSL certificate verification.
aws_opensearch_serverlessNoIf true, use OpenSearch Serverless service.

TDQS

A3.8/5.0
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. However, it does not disclose potential side effects, authentication requirements beyond what's in the schema, error handling, or rate limits. For a generic API tool that can perform destructive operations (e.g., DELETE), 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 concise, comprising two well-structured sentences. It is front-loaded with the core purpose and immediately provides usage context. Every sentence adds value with no redundancy.

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 high complexity (15 parameters, no output schema, no annotations), the description is incomplete. It does not address error handling, response format, or authentication workflow beyond parameter names. The examples in the schema partially compensate, but the description itself lacks completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already fully describes each parameter (e.g., path, method, body). The description adds no additional meaning beyond 'supports all HTTP methods' and 'custom paths,' which aligns with the schema. Baseline 3 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 flexible tool for calling any OpenSearch API endpoint, supporting all HTTP methods and custom paths. It explicitly differentiates from siblings by noting when to use it: for APIs without dedicated tools or when more control is needed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance: 'Use this when you need to access OpenSearch APIs that don't have dedicated tools, or when you need more control over the request.' It also mentions leveraging your knowledge of OpenSearch API documentation, which helps the agent understand the expected workflow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GetShardsToolB

Gets information about shards in OpenSearch

ParametersJSON Schema
NameRequiredDescriptionDefault
indexYesThe name of the index to get shard information for
aws_regionNoAWS region for IAM/Serverless authentication.
aws_iam_arnNoIAM role ARN for role-based authentication.
aws_profileNoAWS profile name for authentication.
opensearch_urlYesOpenSearch endpoint URL.
opensearch_no_authNoIf true, connect without authentication.
opensearch_timeoutNoConnection timeout in seconds.
opensearch_passwordNoPassword for basic authentication.
opensearch_usernameNoUsername for basic authentication.
opensearch_ssl_verifyNoIf false, disable SSL certificate verification.
aws_opensearch_serverlessNoIf true, use OpenSearch Serverless service.

TDQS

B3.1/5.0
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. However, it only says 'Gets information', implying a read operation, but does not state side effects, authentication requirements, or any other behavioral traits. The description fails to add value beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no wasted words, and the main action is front-loaded. However, the brevity sacrifices completeness and context, preventing a perfect score.

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?

The tool has 11 parameters including complex authentication options and no output schema. The description does not explain what 'information about shards' includes, the return format, or how the parameters relate to the operation. This is insufficient for a tool of this complexity.

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% with all parameters described. The description adds no additional meaning beyond what the schema already provides, so a baseline score of 3 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 the verb 'Gets' and the resource 'information about shards in OpenSearch', which is specific and distinct from sibling tools like ClusterHealthTool or SearchIndexTool. The purpose is unambiguous.

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 on when to use this tool versus alternatives or when not to use it. The description lacks any contextual hints about appropriate use cases, prerequisites, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

IndexMappingToolB

Retrieves index mapping and setting information for an index in OpenSearch

ParametersJSON Schema
NameRequiredDescriptionDefault
indexYesThe name of the index to get mapping information for
aws_regionNoAWS region for IAM/Serverless authentication.
aws_iam_arnNoIAM role ARN for role-based authentication.
aws_profileNoAWS profile name for authentication.
opensearch_urlYesOpenSearch endpoint URL.
opensearch_no_authNoIf true, connect without authentication.
opensearch_timeoutNoConnection timeout in seconds.
opensearch_passwordNoPassword for basic authentication.
opensearch_usernameNoUsername for basic authentication.
opensearch_ssl_verifyNoIf false, disable SSL certificate verification.
aws_opensearch_serverlessNoIf true, use OpenSearch Serverless service.

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must convey behavioral traits. It states 'Retrieves,' implying a read-only operation, but does not disclose error handling (e.g., if index does not exist), authentication requirements beyond the schema, rate limits, or potential performance impact. This is insufficient for an agent to understand side effects.

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 of 12 words. It includes the verb, resource, and context with no extraneous information. Every word earns its place.

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 11 parameters (mostly connection-related) and no output schema, the description is incomplete. It does not describe what the returned mapping/setting information looks like or that it includes both mapping and settings. The agent lacks detail on expected return structure, which is critical for using the output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add meaning beyond what the schema already provides for the 11 parameters. It does not clarify how connection parameters map to different auth methods or that 'index' is required. No additional value over 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 identifies the tool's purpose: retrieving index mapping and setting information for an OpenSearch index. The verb 'Retrieves' specifies the operation, and the resource 'index mapping and setting information' is precise. This distinguishes it from sibling tools like ClusterHealthTool (cluster-level) or SearchIndexTool (search queries).

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?

No explicit guidance is provided on when to use this tool versus alternatives. While the purpose implies it is for inspecting index configuration, there is no mention of prerequisites (e.g., the index must exist) or common usage patterns. The description does not advise against use in write-heavy contexts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ListIndexToolA

Lists indices in the OpenSearch cluster. If an index name or pattern is specified, return only information about the provided index or index pattern. The include_detail flag controls output: if False, returns only index name(s); if True (default), returns full metadata.

ParametersJSON Schema
NameRequiredDescriptionDefault
indexNoThe name of the index or index pattern to get information for.
aws_regionNoAWS region for IAM/Serverless authentication.
aws_iam_arnNoIAM role ARN for role-based authentication.
aws_profileNoAWS profile name for authentication.
include_detailNoWhether to include detailed information. If False, returns only index name(s). If True, returns full metadata.
opensearch_urlYesOpenSearch endpoint URL.
opensearch_no_authNoIf true, connect without authentication.
opensearch_timeoutNoConnection timeout in seconds.
opensearch_passwordNoPassword for basic authentication.
opensearch_usernameNoUsername for basic authentication.
opensearch_ssl_verifyNoIf false, disable SSL certificate verification.
aws_opensearch_serverlessNoIf true, use OpenSearch Serverless service.

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries full burden. It explains behavior for listing all indices vs specific patterns and detail control, but does not disclose read-only nature, authentication prerequisites, or potential performance impacts.

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-load the purpose and dive into details. No redundant or missing words. Efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a listing tool with 12 params (mostly auth), the description covers core behavior well. It explains output format (names vs metadata) but omits error handling, required permissions, or connection setup. Still, it's fairly complete given the presence of schema descriptions.

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. The description reiterates the include_detail and index parameters but adds no new meaning beyond what's in the schema descriptions. No enums or nested objects to clarify.

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 lists OpenSearch indices, optionally filtering by name/pattern, and controlling detail level with include_detail flag. This distinguishes it from sibling tools like SearchIndexTool and GetShardsTool.

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?

No explicit guidance on when to use this tool vs alternatives. The description implies use for listing indices but does not mention when not to use or compare to siblings like ClusterHealthTool or SearchIndexTool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

MsearchToolC

Allows to execute several search operations in one request.

ParametersJSON Schema
NameRequiredDescriptionDefault
bodyYesRequest body as NDJSON format: alternating lines of header and query objects ending with \n. Alternatively, pass a JSON array [header, query, header, query, ...] and the tool will convert it to NDJSON for you.
indexNo
aws_regionNoAWS region for IAM/Serverless authentication.
aws_iam_arnNoIAM role ARN for role-based authentication.
aws_profileNoAWS profile name for authentication.
opensearch_urlYesOpenSearch endpoint URL.
opensearch_no_authNoIf true, connect without authentication.
opensearch_timeoutNoConnection timeout in seconds.
opensearch_passwordNoPassword for basic authentication.
opensearch_usernameNoUsername for basic authentication.
opensearch_ssl_verifyNoIf false, disable SSL certificate verification.
aws_opensearch_serverlessNoIf true, use OpenSearch Serverless service.

TDQS

C2.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavior but only says 'execute search operations'. It omits important details such as authentication requirements, return format, and error handling. The schema covers parameters, but the description adds minimal context.

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 a single sentence, which is concise but lacks substance. It could include more helpful information without becoming verbose.

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 (12 parameters, no output schema, multiple authentication options), the description is far too minimal. It does not explain how to construct the NDJSON body, what the response looks like, or how it differs from similar tools.

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 92%, so most parameters are well-documented. The tool description adds no extra meaning beyond what the schema provides, so it meets the baseline.

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 it executes several search operations in one request, which matches the name 'MsearchTool'. However, it does not differentiate from sibling tools like SearchIndexTool or GenericOpenSearchApiTool.

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 does not mention that it is intended for batching multiple searches to reduce overhead, nor does it exclude single-search usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

SearchIndexToolB

Searches an index using a query written in query domain-specific language (DSL) in OpenSearch. PREREQUISITE: You need to know the mappings of the index before constructing queries.

ParametersJSON Schema
NameRequiredDescriptionDefault
sizeNoNumber of search results to return. The maximum allowed value is 100, unless overridden by configuration.
indexYesThe name of the index to search in
formatNoOutput format: "json" or "csv"json
query_dslYesThe search query in OpenSearch query DSL format. For keyword-type fields (mapping shows "type": "keyword"), use field name DIRECTLY - do NOT add .keyword suffix. For text-type fields with .keyword subfields, use the .keyword suffix for exact matches. For date/time range queries, MUST include "format" parameter (commonly "format": "strict_date_optional_time||epoch_millis"), e.g. {"range": {"timestamp": {"gte": "2025-12-29T17:15:12Z", "lte": "2025-12-30T08:15:12Z", "format": "strict_date_optional_time||epoch_millis"}}}; if using non-ISO formats, adjust "format" accordingly.
aws_regionNoAWS region for IAM/Serverless authentication.
aws_iam_arnNoIAM role ARN for role-based authentication.
aws_profileNoAWS profile name for authentication.
opensearch_urlYesOpenSearch endpoint URL.
opensearch_no_authNoIf true, connect without authentication.
opensearch_timeoutNoConnection timeout in seconds.
opensearch_passwordNoPassword for basic authentication.
opensearch_usernameNoUsername for basic authentication.
opensearch_ssl_verifyNoIf false, disable SSL certificate verification.
aws_opensearch_serverlessNoIf true, use OpenSearch Serverless service.

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions it is a search operation, which implies read-only, but does not explicitly state whether it modifies data, requires specific permissions, or has rate limits. The behavioral disclosure is minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences and includes a prerequisite. It is concise and front-loaded with the core purpose. However, it could be slightly more structured with separate sections, but it is efficient.

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 (14 parameters, 3 required, no output schema), the description is incomplete. It does not explain the return format, pagination, error handling, or how to use it in conjunction with sibling tools. The prerequisite is useful but insufficient for a comprehensive understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds significant value for the 'query_dsl' parameter with detailed instructions on .keyword suffix and date format, which goes beyond the schema's description. Other parameters mostly repeat schema info, but the query_dsl guidance elevates this score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches an index using OpenSearch query DSL, which is a specific verb and resource. However, it does not differentiate from sibling tools like CountTool or MsearchTool, which also operate on indices.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a prerequisite about knowing index mappings, which provides some usage guidance. However, it does not mention when to use this tool versus alternatives like CountTool or ExplainTool, nor does it specify 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev0.11.0
    • ChangedExplainTool1 field changed
      • changedInput schema / required
        Previous value: -[
-  "body",
-  "index",
-  "id",
-  "opensearch_url"
-]New value: +[
+  "id",
+  "index",
+  "body",
+  "opensearch_url"
+]
  2. 9 tool updatesv0.9.0
    • First observedClusterHealthTool
    • First observedCountTool
    • First observedExplainTool
    • First observedGenericOpenSearchApiTool
    • First observedGetShardsTool
    • First observedIndexMappingTool
    • First observedListIndexTool
    • First observedMsearchTool
    • First observedSearchIndexTool
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Scored across 9 tools

Disambiguation5/5

Each tool targets a distinct OpenSearch operation (cluster health, count, explain, shards, mappings, list indices, search, msearch) with no overlap. The generic API tool is clearly positioned as a fallback for unsupported endpoints.

Naming Consistency5/5

All tool names follow a consistent PascalCase pattern: <Action><Resource>Tool (e.g., ClusterHealthTool, SearchIndexTool). No deviations or mixed conventions.

Tool Count5/5

9 tools is well-scoped for an OpenSearch server, covering core operations (health, search, count, mappings, etc.) without being overwhelming or too sparse.

Completeness3/5

Missing dedicated tools for index CRUD (create, delete, update) and document operations beyond search/count. The generic API tool can fill these gaps, but it requires manual API knowledge, making it less accessible.

Maintenance

ActivityActive
ResponsivenessWithin a week

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • OpenSearch MCP Server

    solanabughunter-glitch
    A
    license
    B
    quality
    D
    maintenance
    opensearch-mcp-server-py is a Model Context Protocol (MCP) server for OpenSearch that enables AI assistants to interact with OpenSearch clusters. It provides a standardized interface for AI models to perform operations like searching indices, retrieving mappings, and managing shards through both stdio and streaming (SSE/Streamable HTTP) protocols.
    11
    Apache 2.0

  • OpenSearch MCP Server

    stackblaze
    A
    license
    Not graded
    quality
    A
    maintenance
    Enables AI assistants to interact with OpenSearch clusters for searching indices, retrieving mappings, and managing shards through the MCP protocol.
    Apache 2.0

  • Elasticsearch MCP Server

    gpremo-re
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that enables AI assistants to directly interact with Elasticsearch for searching, aggregating, and retrieving documents from indices, supporting full-text search, semantic search, and various query modes.
    38
    MIT

Latest Blog Posts

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/opensearch-project/opensearch-mcp-server-py'

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