Which integrations are available for this server?

Allows interaction with GitHub through MCP server management, enabling repository and issue management. Allows integration with iTerm2 terminal emulator via MCP, enabling terminal command execution. Provides tools for reading and editing Jupyter notebooks, including cell manipulation and output handling. Allows integration with Neovim editor via MCP, enabling code editing capabilities. Allows interaction with Slack through MCP server management, enabling messaging and channel operations.

How do I use Hanzo MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Hanzo MCP analyze the project structure and list dependencies" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Hanzo MCP

by Dream-AI-4444

Overview Schema Source Related Servers Discussions Admin

Python

Local

Hanzo MCP

Hanzo AI + Platform capabilities via the Model Context Protocol (MCP).

Overview

This project provides an MCP server that enables access to Hanzo APIs and Platform capabilities, as well as providing development tools for managing and improving projects. By leveraging the Model Context Protocol, this server enables seamless integration with various MCP clients including Claude Desktop, allowing LLMs to directly access Hanzo's platform functionality.

example

Related MCP server: harmonyos-dev-mcp

Features

Code Understanding: Analyze and understand codebases through file access and pattern searching
Code Modification: Make targeted edits to files with proper permission handling
Enhanced Command Execution: Run commands and scripts in various languages with improved error handling and shell support
File Operations: Manage files with proper security controls through shell commands
Code Discovery: Find relevant files and code patterns across your project
Project Analysis: Understand project structure, dependencies, and frameworks
Jupyter Notebook Support: Read and edit Jupyter notebooks with full cell and output handling
Vector Search: Semantic search of your codebase with multiple embedding provider options

Tools Implemented

Tool	Description
`read_files`	Read one or multiple files with encoding detection
`write_file`	Create or overwrite files
`edit_file`	Make line-based edits to text files
`directory_tree`	Get a recursive tree view of directories
`get_file_info`	Get metadata about a file or directory
`search_content`	Search for patterns in file contents
`content_replace`	Replace patterns in file contents
`run_command`	Execute shell commands (also used for directory creation, file moving, and directory listing)
`run_script`	Execute scripts with specified interpreters
`script_tool`	Execute scripts in specific programming languages
`project_analyze_tool`	Analyze project structure and dependencies
`rule_check`	Search for and retrieve cursor rules that define AI coding standards for specific technologies
`run_mcp`	Manage and interact with multiple MCP servers (browser automation, Slack, GitHub, etc.)
`read_notebook`	Extract and read source code from all cells in a Jupyter notebook with outputs
`edit_notebook`	Edit, insert, or delete cells in a Jupyter notebook
`symbol_find`	Find symbol definitions in a file or directory
`symbol_references`	Find references to a symbol in a file or directory
`ast_explore`	Explore and visualize the AST of a file
`ast_query`	Query the AST using tree-sitter query language
`symbolic_search`	Perform various symbolic search operations (related symbols, patterns, usages, etc.)
`vector_index`	Index files or directories in the vector store for semantic search
`vector_search`	Search the vector store with semantic search capabilities
`vector_delete`	Delete documents from the vector store
`vector_list`	List indexed documents in the vector store
`think`	Structured space for complex reasoning and analysis without making changes

Getting Started

Usage

Configuring Claude Desktop

You can run it with uvx run hanzo-mcp without installation. Configure Claude Desktop to use this server by adding the following to your Claude Desktop configuration file:

{
  "mcpServers": {
    "hanzo": {
      "command": "uvx",
      "args": [
        "--from",
        "hanzo-mcp",
        "hanzo-mcp",
        "--allow-path",
        "/path/to/your/project"
      ]
    }
  }
}

Make sure to replace /path/to/your/project with the actual path to the project you want Claude to access.

Advanced Configuration Options

You can customize the server using other options:

{
  "mcpServers": {
    "hanzo": {
      "command": "uvx",
      "args": [
        "--from",
        "hanzo-mcp",
        "hanzo-mcp",
        "--allow-path",
        "/path/to/project",
        "--name",
        "custom-hanzo",
        "--transport",
        "stdio"
      ]
    }
  }
}

Using with External MCP Servers

Hanzo MCP can integrate with other MCP servers like iTerm2-MCP or Neovim-MCP. You can enable and manage these servers in several ways:

Using the command line:

# Directly specify MCP server commands
uvx run hanzo-mcp --allow-path /path/to/project --mcp="npx -y iterm-mcp" --mcp="npx -y @bigcodegen/mcp-neovim-server"

# Or use the management UI
uvx run hanzo-mcp-servers ui

Using the registry:

# View available servers
uvx run hanzo-mcp-servers registry search

# Install a server from the registry
uvx run hanzo-mcp-servers registry install iterm2

Configuring Claude Desktop System Prompt

To get the best experience with Hanzo MCP, you need to add the provided system prompt to your Claude Desktop client. This system prompt guides Claude through a structured workflow for interacting with Hanzo platform services and managing project files.

Follow these steps:

Locate the system prompt file in this repository at doc/system_prompt
Open your Claude Desktop client
Create a new project or open an existing one
Navigate to the "Project instructions" section in the Claude Desktop sidebar
Copy the contents of doc/system_prompt and paste it into the "Project instructions" section
Replace {project_path} with the actual absolute path to your project

The system prompt provides Claude with:

A structured workflow for analyzing and modifying code
Best practices for project exploration and analysis
Guidelines for development, refactoring, and quality assurance
Special formatting instructions for mathematical content

This step is crucial as it enables Claude to follow a consistent approach when helping you with code modifications.

Cursor Rules Support

Hanzo MCP includes support for Cursor Rules, which allow you to define custom guidelines for AI-generated code. These rules help ensure that code generation follows your project's specific best practices and coding standards.

How It Works

Built-in Rules: The package comes pre-installed with rules for common technologies like JavaScript, TypeScript, Python, and their frameworks.
Project-Specific Rules: You can create your own .cursorrules or .rules files in your project directory.
Rules Format: Rules files support YAML frontmatter with metadata about the rules, followed by markdown-formatted guidelines.

---
name: My Custom Rules
description: Custom rules for my project
technologies:
  - JavaScript
  - React
focus:
  - frontend
---

# My Custom Rules

## Code Style
1. Use functional components with hooks
2. Follow naming conventions...

Using the Rule Check Tool

You can search for and retrieve rules using the rule_check operation in the dev tool:

result = await dev(
    ctx,
    operation="rule_check",
    query="react",             # Search for React-related rules
    project_dir="/path/to/project",  # Optional: look in project directory
    include_preinstalled=True,      # Include built-in rules
    detailed=False                  # Set to True for full rule content
)

This helps AI assistants like Claude follow your project's coding standards and best practices when generating or modifying code.

Symbol Tools Support

Hanzo MCP includes advanced symbol analysis tools powered by tree-sitter, which provides powerful code understanding and navigation capabilities.

Features

Symbol Finding: Locate definitions of variables, functions, classes, methods, and more
Reference Finding: Discover where symbols are used throughout a codebase
AST Exploration: Navigate and understand code structure via Abstract Syntax Trees
Symbolic Search: Find related symbols and patterns across files

Language Support

The symbol tools support multiple programming languages, including:

Python
JavaScript/TypeScript
Java
C/C++
Go
Ruby
Rust
And more

Installation

To use the symbol tools, you need to install the optional dependencies:

pip install hanzo-mcp[symbols]

Or include it with all dependencies:

pip install hanzo-mcp[all]

Using the Symbol Tools

Access the symbol tools through the dev tool:

# Find symbols in a file
result = await dev(
    ctx,
    operation="symbol_find",
    path="/path/to/file.py",
    symbol_name="MyClass"  # Optional: specific symbol to find
)

# Find references to a symbol
result = await dev(
    ctx,
    operation="symbol_references",
    path="/path/to/project",
    symbol_name="my_function",
    recursive=True
)

# Explore AST of a file
result = await dev(
    ctx,
    operation="ast_explore",
    path="/path/to/file.py",
    output_format="structure"  # Options: json, text, html, structure
)

# Perform symbolic search
result = await dev(
    ctx,
    operation="symbolic_search",
    project_dir="/path/to/project",
    search_type="related_symbols",
    symbol_name="MyClass"
)

Sub-MCP Servers Support

Hanzo MCP can integrate with and manage multiple specialized MCP servers, providing a unified interface to a wide range of capabilities:

Built-in Server Support

Browser Automation: The browser-use server allows Claude to control a web browser, navigate to URLs, click buttons, fill forms, and more.
Computer Use: The computer-use server (disabled by default) provides full computer access capabilities.
Service Integrations: Automatically enabled when API keys are available:
- Slack: Interact with Slack channels and messages
- GitHub: Manage repositories, issues, and pull requests
- Linear: Work with tickets and project management

Using the Run MCP Tool

Manage and interact with sub-MCP servers using the run_mcp operation in the dev tool:

# List available MCP servers
result = await dev(ctx, operation="run_mcp", subcommand="list")

# Start a specific MCP server
result = await dev(ctx, operation="run_mcp", subcommand="start", server_name="browser-use")

# Get info about a server
result = await dev(ctx, operation="run_mcp", subcommand="info", server_name="browser-use")

# Add a custom MCP server
result = await dev(
    ctx,
    operation="run_mcp",
    subcommand="add",
    name="custom-server",
    command="uvx",
    args=["my-custom-mcp-server"],
    env={"API_KEY": "your-api-key"}
)

When enabled, these additional MCP servers allow Claude to perform a much wider range of tasks without requiring those capabilities to be implemented in the main MCP server.

Meta MCP Server

For advanced users who want to run multiple MCP servers simultaneously, we provide a MetaMCPServer that seamlessly orchestrates a main MCP server and multiple sub-MCP servers:

Features

Unified Interface: Manage everything through a single entry point
Automatic Configuration: Detect and initialize servers based on available API keys
Asynchronous Operations: All server operations use asyncio for smooth performance
Dynamic Tool Discovery: Automatically expose tools from all running sub-servers

Installation

Install with all optional dependencies:

pip install hanzo-mcp[all]  # Includes all optional dependencies

Or install just what you need:

pip install hanzo-mcp[subservers]  # Just sub-server support
pip install hanzo-mcp[rules]       # Just rules support
pip install hanzo-mcp[vector]            # Vector store with API-based embeddings (VoyageAI, OpenAI, Anthropic)
pip install hanzo-mcp[vector,sentencetransformer]  # Vector store with local embedding support

Command-Line Usage

hanzo-meta-mcp --allow-path /path/to/project [options]

Options:

--name: Name of the server (default: "hanzo-meta")
--transport: Transport to use (stdio or sse, default: stdio)
--allow-path: Paths to allow access to (can be specified multiple times)
--config: Path to a configuration file (JSON)
--disable-proxy-tools: Disable proxy tools for sub-MCP servers
--disable-auto-start: Disable automatic starting of sub-MCP servers

Configuration File

You can define your Meta MCP Server configuration in a JSON file:

{
  "mcp": {
    "name": "hanzo-meta"
  },
  "sub_mcps": {
    "browser-use": {
      "enabled": "auto",
      "command": "uvx",
      "args": ["mcp-server-browser-use"],
      "env": {
        "CHROME_PATH": "/path/to/chrome"
      }
    },
    "github": {
      "enabled": "auto",
      "command": "uvx",
      "args": ["mcp-server-github"],
      "env": {
        "GITHUB_TOKEN": "your-github-token"
      }
    }
  }
}

Programmatic Usage

You can also use the MetaMCPServer programmatically in your own Python scripts:

import asyncio
from hanzo_mcp.meta_mcp import MetaMCPServer

async def main():
    # Create the Meta MCP Server
    meta_server = MetaMCPServer(
        name="hanzo-meta",
        allowed_paths=["/path/to/project"],
        sub_mcps_config={
            "browser-use": {
                "enabled": "true",
                "command": "uvx",
                "args": ["mcp-server-browser-use"]
            }
        }
    )

    # Start sub-MCP servers
    await meta_server.start()

    # Run the server
    meta_server.run()

# Run the async main function
if __name__ == "__main__":
    asyncio.run(main())

Security

This implementation follows best practices for securing access to your filesystem:

Permission prompts for file modifications and command execution
Restricted access to specified directories only
Input validation and sanitization
Proper error handling and reporting

Development

To contribute to this project:

Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add some amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request

Vector Store Embedding Options

Hanzo MCP includes a powerful vector store for semantic code search based on ChromaDB. It supports multiple embedding providers that can be enabled by setting the appropriate environment variables:

Available Embedding Providers

VoyageAI (Recommended)
- Models: voyage-large-2
- Environment Variables: VOYAGE_API_KEY or CHROMA_VOYAGE_API_KEY
- Install: pip install voyageai
OpenAI
- Models: text-embedding-3-small, text-embedding-3-large
- Environment Variables: OPENAI_API_KEY or CHROMA_OPENAI_API_KEY
- Install: pip install openai
Anthropic
- Models: claude-3-embedding-1
- Environment Variables: ANTHROPIC_API_KEY or CHROMA_ANTHROPIC_API_KEY
- Install: pip install anthropic
SentenceTransformer (Optional, No API Key Required)
- Models: all-MiniLM-L6-v2
- No environment variable required
- Install: pip install hanzo-mcp[vector,sentencetransformer]

Embedding Provider Configuration

Hanzo MCP supports multiple embedding providers for vector search that can be configured with environment variables:

The default installation (pip install hanzo-mcp[vector]) includes support for API-based embedding providers but requires you to set at least one of these environment variables:
- VOYAGE_API_KEY or CHROMA_VOYAGE_API_KEY for VoyageAI (recommended)
- OPENAI_API_KEY or CHROMA_OPENAI_API_KEY for OpenAI
- ANTHROPIC_API_KEY or CHROMA_ANTHROPIC_API_KEY for Anthropic
For local embedding support without API keys, install with: pip install hanzo-mcp[vector,sentencetransformer]

The system will automatically select the best available embedding provider based on what's available. If neither API keys nor sentence_transformers are available, vector operations will fail with a clear error message.

Using Vector Search

# Index a directory for vector search
result = await dev(
    ctx,
    operation="vector_index",
    path="/path/to/project",
    recursive=True,
    file_pattern="*.py"  # Optional: only index Python files
)

# Perform semantic search
result = await dev(
    ctx,
    operation="vector_search",
    query_text="How does authentication work?",
    project_dir="/path/to/project",
    n_results=5  # Return top 5 results
)

License

This project is licensed under the MIT License - see the LICENSE file for details.

Available Tools

7 tools

devC

Universal development tool for all project operations.

This tool provides a unified interface for all development operations, including file operations, command execution, project analysis, notebook operations, and vector store operations.

Args: operation: The operation to perform **kwargs: Additional arguments specific to the operation

Returns: Operation result as JSON or text

ParametersJSON Schema

Name	Required	Description	Default
`ctx`	Yes
`operation`	Yes
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It mentions returning JSON or text but does not disclose important traits like side effects, destructive potential, authentication needs, or rate limits. The description is insufficient.

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 adequately structured with a brief summary and docstring-like signature, but it includes redundant phrases like 'Universal development tool for all project operations' and 'This tool provides a unified interface' which add little value. It could be more concise.

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

Completeness1/5

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

Given the complexity of a 'universal' development tool, the description is severely incomplete. It lacks enumeration of possible operations, explanation of the 'ctx' parameter, examples, and any details about behavior. With no annotations and 0% schema coverage, this description fails to equip the agent.

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

Parameters2/5

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

Schema coverage is 0%. The description adds minimal value: 'operation: The operation to perform' and 'kwargs: Additional arguments' are nearly tautological. The 'ctx' parameter is not explained at all, leaving a significant gap.

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

Purpose2/5

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

The description is vague, stating 'Universal development tool for all project operations' without specifying what operations it supports or how it differs from sibling tools that are more specific (e.g., disable_external_server). The use of 'universal' and 'all' makes the purpose unclear.

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. The description says 'for all project operations' but does not provide conditions for usage, exclusions, or mention of sibling tools. The agent receives no help in choosing this tool over others.

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

disable_external_serverC

Disable an external MCP server.

Args: name: The name of the server to disable

Returns: The result of the operation

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It only says 'disable' without clarifying side effects, permissions, or what happens to existing connections. Insufficient behavioral details.

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?

Short but excessively minimal. Every sentence is functional but missing crucial context. Could be more informative without adding verbosity.

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?

Despite an output schema existing, the description fails to explain return values meaningfully. With low schema coverage and no annotations, the description should fill gaps but does not.

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

Parameters2/5

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

Schema coverage is 0%. Description only says 'name: The name of the server to disable,' which merely restates the schema's property name. No added meaning like format, source, or constraints.

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 'Disable an external MCP server,' which is a specific verb+resource. It distinguishes from siblings like enable_external_server and list_external_servers.

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 or when not to use this tool, no mention of prerequisites, consequences, or alternatives. Sibling tools exist but no differentiation beyond the name.

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

enable_external_serverB

Enable an external MCP server.

Args: name: The name of the server to enable

Returns: The result of the operation

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, and the description only says 'Enable' without disclosing behavioral traits such as idempotency, state changes, permissions required, or error conditions. The return value is vaguely described as 'the result of the operation'.

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

Conciseness5/5

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

The description is extremely concise with no wasted words, uses a clear Args/Returns structure, and front-loads the purpose. Every sentence contributes to the basic understanding.

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

Completeness3/5

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

For a simple enable action with one parameter and an output schema, the description is minimally adequate but missing context about what 'external' means or the relationship to sibling tools like run_mcp. The absence of usage guidelines and behavioral transparency reduces 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?

With 0% schema description coverage, the description adds minimal meaning by stating 'The name of the server to enable,' which is slightly more informative than the schema's 'Name' title. However, it lacks details like accepted formats or constraints.

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 enables an external MCP server, using a specific verb and resource. It distinguishes from sibling tools like disable_external_server and list_external_servers, 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 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, no prerequisites, and no context for the operation. The agent 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.

list_external_serversB

List available external MCP servers.

Returns: A list of available external MCP servers

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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 explain behavioral traits. It only states the return type but does not disclose read-only nature, potential authorization needs, or side effects. The minimal description leaves significant gaps.

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, using only two lines. However, it could include more useful context without becoming verbose. It is efficient but slightly underspecified.

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

Completeness3/5

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

The description is adequate for a simple list tool, especially with an output schema providing return value details. It lacks information about filtering, ordering, or server status, but the context signals indicate low 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?

The tool has zero parameters, and schema coverage is 100% (trivially). Per guidelines, baseline is 4. The description adds no extra parameter meaning, but none is needed.

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 action ('List') and the resource ('available external MCP servers'). It is unambiguous and distinguishes itself from sibling tools that enable/disable or run servers.

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 like enable_external_server or run_mcp. The description does not provide context for appropriate usage.

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

run_mcpC

Run operations on MCP servers.

Args: operation: The operation to perform (list, start, stop, info, restart) server: The server to operate on (optional, for specific server operations) **kwargs: Additional arguments for the operation

Returns: Operation result

ParametersJSON Schema

Name	Required	Description	Default
`ctx`	Yes
`operation`	Yes
`server`	No
`kwargs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It states operations but does not explain side effects (e.g., stopping a server, state changes) or authorization needs. The return value is described only as 'Operation result', lacking detail.

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 relatively concise using a docstring format. It front-loads the purpose and lists parameters clearly. However, the 'kwargs' description is slightly misleading, and the structure could be tighter.

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

Completeness3/5

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

Given moderate complexity and presence of an output schema (not shown), the description covers the main operations but lacks detail on individual operations' behavior and return structure. It is adequate but not thorough.

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

Parameters3/5

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

The description adds meaning to the 'operation' parameter by listing valid values (list, start, stop, info, restart) and describes 'server' as optional. However, it describes 'kwargs' as '**kwargs' (implying a dictionary) while the schema defines it as a string, causing potential confusion. Schema coverage is 0%, so the description partially compensates but is inconsistent.

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

Purpose3/5

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

The description states 'Run operations on MCP servers' and lists operations (list, start, stop, info, restart), indicating a management tool. However, it does not differentiate from sibling tools like list_external_servers or disable_external_server, leaving ambiguity about when this tool should be used versus others.

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 lists operations but does not specify prerequisites or contexts where this tool is appropriate (e.g., managing the MCP server itself vs. external servers).

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

set_auto_detectB

Set whether to auto-detect external MCP servers.

Args: enabled: Whether to enable auto-detection

Returns: The result of the operation

ParametersJSON Schema

Name	Required	Description	Default
`enabled`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It only states the action without explaining side effects, persistence, or scope (e.g., does it affect current session or persist?).

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 short and front-loaded with the main purpose. However, the Args section repeats information already in the schema, which could be omitted for conciseness.

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

Completeness3/5

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

For a simple boolean toggle tool with an output schema, the description is nearly adequate but lacks detail on return value and any side effects, making it slightly incomplete.

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

Parameters2/5

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

The parameter description 'Whether to enable auto-detection' adds minimal value beyond the schema's title 'Enabled'. With 0% schema description coverage, the description should provide more context, such as default behavior or impact.

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 action ('Set') and the resource ('auto-detect external MCP servers'), distinguishing it from sibling tools that manually enable/disable specific servers.

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 vs alternatives like enable_external_server or disable_external_server. The agent is left to infer context.

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

thinkA

Use the tool to think about something.

It will not obtain new information or make any changes to the repository, but just log the thought. Use it when complex reasoning or brainstorming is needed. For example, if you explore the repo and discover the source of a bug, call this tool to brainstorm several unique ways of fixing the bug, and assess which change(s) are likely to be simplest and most effective. Alternatively, if you receive some test results, call this tool to brainstorm ways to fix the failing tests.

Args: thought: Your thoughts or analysis

Returns: Confirmation that the thinking process has been recorded, possibly with enhanced analysis

ParametersJSON Schema

Name	Required	Description	Default
`thought`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

No annotations provided, but description explicitly states that the tool does not obtain new information or make changes, only logs thoughts. This fully discloses 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.

Conciseness4/5

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

Well-structured with Args and Returns sections. Examples are helpful but slightly verbose; however, front-loading with purpose is effective.

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?

Covers purpose, side effects, usage context, and return value. For a simple tool with one parameter and no output schema, this is complete.

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 description adds semantic meaning to the 'thought' parameter by labeling it as 'Your thoughts or analysis', which is not present in the schema. With only one parameter and 0% schema coverage, this adds value.

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 that the tool is used to think and log thoughts without making changes. It distinguishes itself from siblings by focusing on internal reasoning rather than external operations.

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?

Provides explicit examples of when to use the tool (e.g., after exploring code or receiving test results). Does not specify alternatives but context implies it's for reasoning tasks.

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.

7 tool updatesv0.1.29May 28, 2026
- First observeddev
- First observeddisable_external_server
- First observedenable_external_server
- First observedlist_external_servers
- First observedrun_mcp
- First observedset_auto_detect
- First observedthink

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.9/5.0

Scored 2026-05-28 07:40 across 7 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: 'dev' handles project operations, server management tools (enable/disable/list external servers, run_mcp, set_auto_detect) focus on external MCP server lifecycle, and 'think' is for reasoning. No overlaps in functionality.

Naming Consistency2/5

Naming is inconsistent: 'dev' and 'think' are bare verbs, server management tools use snake_case (e.g., 'disable_external_server'), and 'run_mcp' follows a different pattern. No uniform verb_noun or prefix convention.

Tool Count4/5

With 7 tools, the count is appropriate for the dual focus on development and server management. It is not overly large, but the single 'dev' tool may be overloaded, potentially justifying more tools.

Completeness3/5

The tool set covers basic CRUD for external servers and a general development interface, but lacks specific tools for project management or detailed operations (e.g., file editing, command execution are subsumed under 'dev'). This leaves potential gaps for complex workflows.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Algenta MCP Server B
io.github.thyn-ai
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
Data Platforms Search RAG Systems
1402
neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
DATPAQ
com.datpaq
34 production API tools over one hosted MCP endpoint.
Developer Tools
2
mcp-serverOAuth
com.agilitycms
An MCP server that provides access to Agility CMS. See https://mcp.agilitycms.com for more details.
Content Management Systems Developer Tools
2

Related MCP Servers

Hanzo MCPofficial
Coding Agents Developer Tools Code Analysis
hanzoai
A
license
C
quality
A
maintenance
An MCP server that enables Claude and other LLM clients to access Hanzo AI platform capabilities and provide powerful code management tools for analyzing, modifying, and understanding projects.
Updated 5 days ago (2026-09-15 23:10 UTC)
7
62 npm
1
MIT
harmonyos-dev-mcp
Developer Tools Testing & QA Tools
Deslord319
F
license
D
quality
B
maintenance
Enables HarmonyOS device discovery, app build and deployment, UI automation, E2E inspection, and log validation through MCP tools.
Updated 2 months ago (2026-07-29 08:34 UTC)
18
12
-
MCP Security Server
Developer Tools File Systems
danduh
A
license
B
quality
D
maintenance
Enables file operations, npm package management, and configuration checking through MCP.
Updated 3 months ago (2026-06-24 16:43 UTC)
10
6 npm
1
MIT
ProjectsMCP
File Systems Version Control Browser Automation
offdutysorcerer-code
F
license
Not graded
quality
B
maintenance
A plugin-based MCP platform providing tools for project file management, Git operations, browser automation, and command execution.
Updated 7 days ago (2026-09-14 05:04 UTC)
-

Hanzo MCP

Overview

Features

Tools Implemented

Getting Started

Usage

Configuring Claude Desktop

Advanced Configuration Options

Using with External MCP Servers

Configuring Claude Desktop System Prompt

Cursor Rules Support

How It Works

Using the Rule Check Tool

Symbol Tools Support

Features

Language Support

Installation

Using the Symbol Tools

Sub-MCP Servers Support

Built-in Server Support

Using the Run MCP Tool

Meta MCP Server

Features

Installation

Command-Line Usage

Configuration File

Programmatic Usage

Security

Development

Vector Store Embedding Options

Available Embedding Providers

Embedding Provider Configuration

Using Vector Search

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Hanzo MCPofficial