Skip to main content
Glama
seohyunjun

OpenSearch MCP Server

by seohyunjun

get_hot_threads

Identify high-CPU threads on OpenSearch nodes to diagnose performance bottlenecks and optimize cluster resource usage.

Instructions

Check hot threads on nodes

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The main handler function for the 'get_hot_threads' tool. It queries the OpenSearch '/_nodes/hot_threads' endpoint, filters lines containing CPU usage percentages ('%'), and returns the results as TextContent. Handles errors gracefully.
    async def get_hot_threads() -> list[TextContent]:
        """
        Get hot threads information from all nodes, filtering for CPU percentage data.
        Returns only thread information containing percentage signs, indicating CPU usage.
        If no threads show percentage usage, indicates no hot threads were found.
        """
        self.logger.info("Fetching hot threads information...")
        try:
            response = self.es_client.transport.perform_request(
                'GET',
                '/_nodes/hot_threads'
            )
            # Filter lines containing '%'
            hot_lines = [line for line in str(response).split('\n') if '%' in line]
            
            if hot_lines:
                return [TextContent(type="text", text='\n'.join(hot_lines))]
            else:
                return [TextContent(type="text", text="No hot threads detected in the cluster.")]
        except Exception as e:
            self.logger.error(f"Error fetching hot threads: {e}")
            return [TextContent(type="text", text=f"Error: {str(e)}")]
  • The @mcp.tool decorator registers the get_hot_threads handler function with the MCP server, providing a description for the tool.
    @mcp.tool(description="Check hot threads on nodes")
  • Invocation of register_tools on the AdminClusterTools instance, which triggers the registration of get_hot_threads and other admin cluster tools.
    admin_cluster_tools.register_tools(self.mcp)
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Check hot threads on nodes' implies a read-only operation, but it lacks details on permissions needed, rate limits, output format (e.g., text or JSON), or whether it affects node performance. For a tool with zero annotation coverage, this is a significant gap in transparency.

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

Conciseness5/5

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

The description 'Check hot threads on nodes' is a single, efficient sentence with no wasted words. It is appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration. Every word earns its place, making it highly concise.

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

Completeness2/5

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

Given the complexity of monitoring tools and the lack of annotations and output schema, the description is incomplete. It does not explain what 'hot threads' are, how the output is structured, or any behavioral traits like safety or performance impact. For a tool that likely returns diagnostic data, more context is needed to be fully helpful.

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

Parameters4/5

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

The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description does not add parameter details, which is acceptable since there are no parameters to explain. This aligns with the baseline of 4 for zero parameters, as the description does not need to compensate for missing schema information.

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

Purpose3/5

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

The description 'Check hot threads on nodes' states a clear verb ('check') and resource ('hot threads on nodes'), providing a basic purpose. However, it lacks specificity about what 'hot threads' means in this context (e.g., CPU-intensive threads in Elasticsearch) and does not distinguish this tool from siblings like 'get_tasks' or 'get_cluster_stats', which might also relate to node monitoring. This makes it vague but not tautological.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, such as when to prefer this over 'get_tasks' for thread analysis or 'get_cluster_health' for overall node status. Without such information, users must infer usage from the tool name alone.

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

Install Server

Other Tools

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

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