mihomo-mcp

by Aris-qin

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0-dev
Disambiguation5/5
Each tool targets a distinct resource+action: proxy_test vs proxy_test_group are clearly separate (single proxy vs group), provider_list/healthcheck/update_url each cover a unique provider operation, and mode_set, connections_list, and version are unambiguous. No two tools could be easily confused.
Naming Consistency4/5
Names are mostly snake_case with a resource prefix and a verb (proxy_list, proxy_select, provider_update_url, mode_set), but 'version' is a bare noun and 'provider_healthcheck' is a compound rather than a clear verb_noun pattern. The slight inconsistencies are minor and do not harm readability.
Tool Count5/5
10 tools is within the well-scoped 3-15 range. Each tool serves a meaningful operational purpose for controlling a mihomo proxy client, with no redundancy or bloat.
Completeness4/5
Core proxy operations are covered: list proxies, select proxy, test single/group latency, manage providers, set mode, view connections, and version. Missing features like config read/write or connection termination are minor gaps that do not block primary workflows.
Average 4.3/5 across 10 of 10 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on August 7, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return behavior (204 no-content), the force-refresh/delay measurement, and that results are in provider_list. However, it doesn't mention potential side effects, permissions, or error conditions, so transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, an Args list, and a Returns note. Every sentence provides necessary information without redundancy, making it exceptionally 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 simple tool with one parameter and no output schema, the description is fairly complete. It covers the action, the parameter, the return value, and how to access the result state. It could add error handling or prerequisites, but these are not essential given the tool's simplicity.
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 schema has no description for the 'provider' parameter, but the description adds meaning by labeling it as 'provider name' and giving an example ('MyVPN'). This compensates for the 0% schema coverage, though it doesn't elaborate on format or constraints beyond a simple string.
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 action: 'Trigger health check on a provider (force-refresh + delay measurement).' This specifies the verb (trigger), resource (provider), and additional effect. While it references provider_list for observing results, it doesn't explicitly distinguish this from sibling tools like provider_update_url, but the intent is clear.
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 implies usage by explaining the effect and that the health state is observable via provider_list, but it doesn't explicitly state when to use this tool over alternatives or any exclusions. The context is present but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It explains the meaning of each mode (rule, global, direct), which is helpful, but it does not mention side effects, persistence, reversibility, or permission requirements. This is partial transparency but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single introductory sentence followed by a bulleted list of mode definitions. It is front-loaded with the main purpose and contains no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter tool with no output schema, the description covers the essential semantics: the mode values and their effects. It lacks minor context such as whether the mode change is persistent or scoped to a session, but overall it is sufficiently complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines a string parameter with no enum or description, yielding 0% schema coverage. The description fully compensates by enumerating the valid values ('rule', 'global', 'direct') and describing the behavior of each, adding critical meaning that the schema lacks.
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 ('Switch operating mode') and the resource (operating mode), explicitly listing the three possible modes. This distinguishes it from sibling tools like proxy_test or provider_list, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor are there any exclusions or prerequisites. It merely describes what the tool does without contextualizing its use relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description must disclose behavior. 'List' implies a read-only operation with no side effects. The description also specifies return fields, giving a clear expectation of output. It does not mention any rate limits or pagination, but for a list tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, then the return format. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully specifies the tool's purpose and output structure, including the list element fields. Since there is no output schema, this return format detail is essential and provided. No pagination or ordering info, but not required for a straightforward list.
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, so the schema is empty. The description adds no parameter semantics because there are none to describe. Baseline 4 applies.
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 opens with 'List all proxy providers' – a specific verb+resource pair that clearly names the operation. It distinguishes from siblings like proxy_list (proxies vs providers) and provider_healthcheck (list vs health status).
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?
There is no guidance on when to use this tool over alternatives. It doesn't mention that provider_healthcheck is for checking health, or that provider_update_url is for updating. For a simple listing tool, usage is implied but not explicitly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It goes beyond a simple statement by explaining the return type (list of connection objects), the empty-list meaning, and the underlying mihomo detail ({connections: null} on idle). This adds useful behavioral context beyond a mere read hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences—one for purpose, one for edge-case behavior. Every word earns its place, and the structure is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool without an output schema, the description sufficiently covers the return value, the field list, and the empty-case behavior. This is complete for the tool's simplicity.
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, so schema coverage is trivially 100%. The description doesn't need to explain parameters, and it adds value by describing return behavior, earning the baseline 4 for no-param tools.
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 lists active connections and enumerates the included fields (source ip, host, rule, chains, upload, download). This specific verb+resource pairing distinguishes it from sibling tools that manage proxies or providers.
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?
Usage is implied by the description—it's the tool to call when you need active connection details. However, there is no explicit when-to-use/not-to-use guidance or mention of alternatives, leaving the agent to infer context from the tool's name and sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool returns both the package version and the connected mihomo version, which implies a connection to a mihomo instance. This adds useful context beyond what a bare 'version' tool might suggest, though it does not detail error behavior or network dependencies.
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, focused sentence that states the exact purpose without extraneous words. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—no parameters, no annotations, no output schema—the description fully covers what the tool does and what it returns. It explains both the package version and the connected mihomo version, which is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline score of 4 applies. The description does not need to elaborate on parameter semantics because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the mihomo-mcp package version and the connected mihomo version. The verb 'Return' specifies the action and the resources are explicitly named, distinguishing this from sibling tools focused on proxies, providers, and connections.
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 does not explicitly state when to use this tool versus alternatives, but the purpose is self-evident: to retrieve version information. There are no sibling tools that perform a similar function, so usage is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns the new selection and that Mihomo returns 400 when the proxy isn't in the all-list, which is useful error behavior. This goes beyond a bare 'switch' statement, though it doesn't address permissions or 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 concise and structured, leading with the main action in one sentence, followed by an Args block that lists parameters and a short behavior/error note. Every sentence provides value and there is no fluff.
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 simple 2-parameter tool with no output schema, the description covers the action, parameter formats, return value, and a key error condition. It doesn't mention what happens if the group doesn't exist, but overall it provides sufficient context for an agent to invoke the tool correctly.
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 schema has no descriptions and 0% coverage, but the description compensates by defining both parameters with examples ('GLOBAL', 'Manual' for group; '🇭🇰香港01 [1×] - Lv.4' for proxy). This adds meaning and helps the agent understand expected string formats, though it could be even more explicit about the exact source of the proxy names.
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 opens with a specific action: 'Switch a Selector/URLTest group to a specific proxy.' This clearly identifies the verb (switch), the resource (group), and the object (proxy). It also distinguishes the tool from sibling tools like proxy_test_group by focusing on selection rather than testing.
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?
The description implies proper usage by specifying applicable group types (Selector/URLTest) and noting the proxy must be in the group's all-list. It doesn't explicitly mention alternatives or when not to use this tool, but the context is clear enough for straightforward selection tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It details the return structure (name, type, current, node count) and explains type-specific behavior for Selector/URLTest versus Direct/Reject/Compatible groups. It stops short of describing potential side effects or error conditions, but for a list operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, starting with the primary action, then listing the return fields, and finally adding important type-specific behavior. Every sentence contributes meaningful information without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter list tool without an output schema, the description is complete. It covers the full response format, includes field meanings, and explains expected behavior for different group types, which is sufficient for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, giving a baseline of 4 per the rubric. The description does not need to provide parameter semantics since there are none, and the schema already reflects an empty object. No additional meaning is required.
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 all proxy groups with current selection and node count, using a specific verb and resource. It distinguishes itself from sibling tools like provider_list and proxy_test_group by focusing on proxy groups and their metadata.
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?
The description clearly implies when to use the tool: when you need an overview of proxy groups with their active selection and node counts. It does not explicitly exclude alternatives or reference sibling tools, but the context is clear enough that an agent can infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: results are sorted by delay, failed probes show delay=-1 and are placed at the end. It does not explicitly mention whether the operation is read-only or if it triggers external network requests, but the testing nature is implied. This is above-average transparency for a network-testing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, followed by a clear Args list and a Returns section. Every sentence earns its place, and the formatting makes it easy to scan. There is no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description covers all essential aspects: the action, each parameter's meaning, return value structure, sorting behavior, and failure handling. It is sufficiently complete for an agent to select and invoke the tool correctly without additional documentation.
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 schema has 0% description coverage, so the description must compensate. It explains all four parameters (group, url, timeout_ms, concurrency) with concise roles, and even highlights the concurrency default. This goes beyond the schema, which only provides titles and defaults. It does not mention the URL default, but the schema covers that, so the description adds sufficient value.
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's function: 'Test latency of every proxy in a group, sorted by delay (fastest first).' This is a specific verb+resource pair that distinguishes it from sibling tools like proxy_test, which likely targets a single proxy. The scope (every proxy in a group) is explicit.
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?
The description implies usage context by specifying the action (test a group) and the inputs (group, url, timeout, concurrency). It does not explicitly name alternatives or state when not to use this tool, but the group-based scope is clear enough compared to siblings. A 4 is appropriate since the context is clear but without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so excellently. It discloses that the URL is forwarded to mihomo via PUT, used immediately, and explicitly states it is not cached, logged, or written to disk. This is meaningful behavioral context beyond the bare schema.
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 compact and well-structured: a purpose statement, a brief Args list, and a behavioral note. Every sentence adds value, and the most important information is front-loaded in the first line.
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 simple two-parameter mutation tool with no output schema, the description covers the action, parameters, and non-persistence behavior. It is complete enough for an agent to select and invoke it, though it does not mention error cases or the return value; those are not critical given the tool's simplicity.
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 0%, but the description documents both parameters: provider is the provider name, and url is the new subscription URL with the key caveat that it is forwarded and never persisted. This adds practical meaning beyond the plain string type definitions, though 'provider name' is slightly tautological.
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 opens with a specific verb+resource: 'Update a provider's subscription URL and trigger a refresh.' This clearly distinguishes it from sibling tools like provider_list or provider_healthcheck, which handle listing and health checks, not URL updates.
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?
The description implies its use case clearly: when a provider's subscription URL needs to be changed and a refresh triggered. It does not explicitly name alternative tools or state when not to use it, but the context is unambiguous for this simple update operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return format (delay in ms), failure behavior (returns -1), timeout defaults, and the precondition that the proxy must be in a group's all-list. It does not explicitly state that the operation is non-destructive or has no side effects, but for a latency test the key behaviors are covered, earning a 4.
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, front-loaded with the main purpose, and uses a clear Args/Returns structure. Every sentence adds value: purpose, parameter details, and return behavior. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 3 parameters and no output schema, the description is complete: it covers the action, all parameters with defaults, return value, failure case, and a prerequisite. Sibling tools exist but the description adequately defines this tool's unique role without needing further elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains all three parameters: proxy (with the group all-list requirement), url (with default), and timeout_ms (with default). This adds significant meaning beyond the bare schema types and defaults, fully compensating for the coverage gap.
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 starts with 'Test latency (ms) for a single proxy,' which clearly identifies the action (test), the resource (latency for a proxy), and the scope (single proxy). This distinguishes it from sibling proxy_test_group, which tests a group, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is for a single proxy, and mentions the proxy must match a group's all-list, which provides context. However, it does not explicitly mention the alternative proxy_test_group for group testing or state when not to use this tool. This is clear context without explicit exclusion, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mihomo-mcp MCP server](https://glama.ai/mcp/servers/Aris-qin/mihomo-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Aris-qin/mihomo-mcp)

Score Badge

Copy to your README.md:

[![mihomo-mcp MCP server](https://glama.ai/mcp/servers/Aris-qin/mihomo-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Aris-qin/mihomo-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Aris-qin/mihomo-mcp'

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