mihomo-ai-failover

Server Quality Checklist

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

Latest release: v0.2.2
Disambiguation4/5
Most tools have clear, distinct purposes, but a few pairs like get_status/list_pools and check_provider_paths/run_health_check could be confused without careful reading. The detailed descriptions help differentiate them, so overall ambiguity is low.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (e.g., preview_install, run_health_check, uninstall_monitor). There are no mixed conventions, and the verb clearly indicates the action.
Tool Count4/5
With 20 tools, the set is on the heavier side, but each tool addresses a distinct phase of the failover lifecycle (preview, install, monitor, rollback). Given the complexity of the domain, the count is justifiable, though some status tools could potentially be consolidated.
Completeness4/5
The tool surface covers the full lifecycle from environment diagnosis and provider overrides to installation, monitoring, and uninstallation. Minor gaps exist, such as no direct tool for updating failover settings after initial config, but users can work around this.
Average 3.9/5 across 20 of 20 tools scored. Lowest: 3.1/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 9, 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds value by specifying that credentials, subscriptions, server addresses, and exit IPs are never returned, plus the 100-event limit—important context beyond the annotations.
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, no fluff, front-loaded with the action. 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?
The tool has 4 parameters, none described in schema or description. While an output schema exists and annotations cover safety, the lack of parameter explanations and usage guidance makes it incomplete. For example, config_path and provider_id are unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters (limit, config_path, provider_id, include_node_names) with 0% description coverage, and the description does not mention any of them. It fails to explain filtering or configuration options, leaving the agent to guess.
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 'Read up to 100 local sanitized events' with a specific verb (Read) and resource (sanitized events), and the title adds 'failover events'. This distinguishes it from sibling status/health tools, though it doesn't explicitly name them.
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. It doesn't mention any use case, prerequisites, or exclusions. The description is purely functional with no context for tool selection.
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?
Annotations already declare destructive and idempotent behavior. The description adds operational context by requiring a specific confirmation string and mutation opt-in, which is not present in structured data. However, it does not detail what files are overwritten or the backup mechanism beyond 'latest backed-up', so some gaps remain.
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 concise sentences: the first delivers the core action, the second states the required prerequisite. No filler or redundant information, and the most critical operational detail (confirmation value) is front-loaded in the second sentence.
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?
For a destructive mutation with two path parameters, the description is too sparse. It provides the confirmation string but fails to explain how to populate `backup_path` and `config_path` or when to use this tool relative to install/uninstall operations. The output schema exists but does not compensate for these input-side gaps.
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 description coverage is 0%, so the description must compensate. It only clarifies the expected value for `confirmation`, leaving `backup_path` and `config_path` entirely unaddressed. The schema titles provide vague hints ('Backup Path', 'Config Path') but no functional meaning, making correct invocation uncertain.
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 a specific action ('Restore the latest backed-up Clash Verge enhancement files') with a clear verb and resource. It distinguishes this tool from install/uninstall siblings by focusing on rollback, though 'persistent profile integration' in the title is not echoed in the description, creating slight ambiguity.
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 only mentions a prerequisite ('Requires mutation opt-in and confirmation=ROLLBACK_PROFILE_INTEGRATION') but provides no guidance on when to use this tool versus alternatives. Sibling tools like install_failover and uninstall_monitor are not referenced, leaving the selection context unclear.
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?
Annotations already mark this as read-only, idempotent, and non-destructive. The description adds valuable behavioral context: node names are opt-in and exit IPs are never returned, which is a privacy-relevant constraint not covered by annotations.
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 that immediately state the primary output and then a key behavioral note. No excess verbiage; front-loaded with the most important information.
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 output schema exists, so return values are covered, and the read-only nature is annotated. However, all three parameters are undocumented, which is a significant gap for a tool that has optional filtering and inclusion toggles. The description provides a good overview but is incomplete for full tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for parameter documentation, but it only hints at 'node names are opt-in' without explaining config_path or provider_id. This leaves agents unable to understand parameter purposes from either the schema description or the tool description.
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 active, warm, and cold pool counts plus independent-exit statistics, which is a specific verb+resource. It differentiates from siblings like list_provider_profiles by focusing on failover pool data, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing pool counts, but provides no explicit when-to-use or when-not-to-use guidance relative to sibling tools like get_status or run_health_check. There are no exclusions mentioned, so it's clear but not directive.
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?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations by revealing that node names are hidden unless include_node_names is true, which affects the output. This is a meaningful behavioral disclosure without contradicting the annotations.
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 sentences, front-loaded with the primary action and output, followed by a conditional behavioral note. Every word earns its place, and no unnecessary details or redundancy are present.
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 the output schema exists and annotations cover safety, the description provides a reasonable overview of the tool. However, it omits usage context and does not explain the meaning or effect of config_path and provider_id, leaving some gaps for a complete understanding of when and how to invoke the tool.
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?
With 0% schema description coverage, the description must explain all parameters. It only clarifies include_node_names, leaving config_path and provider_id unexplained. These parameters are not self-evident, so the description does not sufficiently compensate for the schema's lack of information.
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 with a specific verb ('Return') and a concrete list of resources ('controller, dedicated Provider group, health state, and pool counts'). It distinguishes itself from siblings like get_service_status or run_health_check by detailing the exact failover status components. The node name hiding behavior adds additional specificity, 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 its many siblings. It lacks any mention of alternatives, prerequisites, or exclusions. Users are left to infer usage solely from the tool's purpose, which is a clear gap given the large sibling list.
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?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds specific context by detailing what is not returned (hostnames, node names, exit IPs, credentials) and clarifies it covers both public templates and local enablement state, going beyond generic read-only hints.
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?
A single sentence that starts with the verb 'List', front-loading the primary action, and packs in scope plus exclusions without redundancy. Every word contributes value.
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 listing tool with a provided output schema and read-only annotations, the description covers purpose and safety exclusions. The only gap is the undocumented config_path parameter, which would improve completeness but is not severely detrimental.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (config_path) has no schema-level description, and the tool description never mentions it. With 0% schema coverage, the description fails to compensate, leaving the agent without any guidance on how or why to use the parameter.
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 public Provider templates and local enablement state, and explicitly excludes sensitive data. This differentiates it from siblings like discover_provider_domains which might return such data.
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 a safe listing use case by specifying exclusions, but it does not explicitly state when to use this tool versus alternatives or name any sibling tools. There is no direct 'use this when...' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly=false, idempotent=true, destructive=false. The description adds the confirmation requirement and clarifies that it restarts if already running, which aligns with the idempotent hint and adds context beyond annotations. No contradictions.
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 with the action front-loaded. It contains no redundant phrases and includes the key requirement without wasting words.
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 having an output schema and simple purpose, the description fails to document config_path and leaves the 'mutation opt-in' mechanism unexplained. It also does not indicate when to use the tool versus related operations. The confirmation requirement is present, but the overall guidance is incomplete for a tool with zero schema descriptions.
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%, so the description must explain parameters. It mentions the confirmation constant ('confirmation=START_LAUNCH_AGENT') but gives no explanation for config_path, which is left completely opaque. The agent knows confirmation's expected value but not what config_path does or when to set it.
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 uses a specific verb ('Start or restart') and identifies the resource ('installed monitor'), clearly distinguishing it from siblings like stop_monitor or install_failover. The title reinforces the target as the failover LaunchAgent.
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 provides a prerequisite (mutation opt-in and confirmation constant) but offers no explicit guidance on when to choose this tool over alternatives like install_failover or stop_monitor. The usage is implied by the name and title, but there are no exclusionary instructions or alternative references.
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?
Annotations already declare readOnlyHint and idempotentHint, and the description adds the concrete behavioral detail that it does not alter Clash Verge. This reinforces the read-only nature without contradicting annotations.
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 entire description is two sentences: the first states the operation, the second clarifies no side effects. No filler or redundancy.
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?
With an output schema present, return format is covered elsewhere. However, the description leaves parameter semantics unexplained and lacks explicit context for when to apply versus preview, creating gaps for an agent selecting the tool.
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 schema has 0% description coverage and the description only alludes to 'exact-domain additions' and 'optional Provider enablement' without explaining config_path, critical_domains, or enabled semantics. It does not compensate for the lack of schema descriptions.
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 uses 'Preview' as a specific verb and identifies the resource 'local private overlay' with 'exact-domain additions' and 'optional Provider enablement'. It clearly distinguishes itself from apply_provider_overlay by stating it does not write files.
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 this is a safe dry-run by explicitly stating 'This does not write files or change Clash Verge,' but it does not name alternative tools or state conditions for when to use preview versus apply. Thus usage guidance is implied, not explicit.
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?
Annotations already indicate read-only and non-destructive behavior. The description adds valuable context: 'Defaults to OpenAI' (default provider behavior) and 'never switches nodes' (explicitly no failover). This goes beyond the annotation hints and clarifies the tool's non-disruptive nature.
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 sentences, with each sentence carrying distinct value: the first defines the action and scope, the second covers default and constraints. No filler or redundancy.
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 tool is simple with rich annotations and an output schema, so the description doesn't need to explain return values. However, the complete lack of parameter descriptions (0% schema coverage) leaves gaps for config_path and include_node_name. The description is adequate for purpose and behavior but not fully complete for parameter understanding.
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 description coverage is 0%, so the description must compensate. It only hints at provider_id semantics via 'Defaults to OpenAI,' but config_path and include_node_name are left unexplained. This is insufficient for three parameters with no schema descriptions.
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 purpose: 'Probe direct connectivity and the configured Provider path through its selected AI group.' It uses a specific verb ('probe') and resource, and the title adds 'read-only Provider health check.' The phrase 'never switches nodes' distinguishes it from failover-related 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it is a read-only health check that defaults to OpenAI and does not switch nodes. This signals it is safe to run anytime, but it does not explicitly mention alternatives or when to prefer this over similar tools like check_provider_paths.
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?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds value by listing the specific aspects inspected and the recommended usage context, providing additional behavioral context beyond the annotations.
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 concise sentences, with the action verb front-loaded and a clear list of inspected items. Every word earns its place; no redundant or vague language.
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?
The output schema exists, so return values are covered. The description explains what is inspected and provides usage context. A minor gap is the lack of differentiation from the sibling tool run_health_check, but overall it is sufficiently complete for a diagnostic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the config_path parameter at all, and schema description coverage is 0%. Since the schema provides no details, the description should compensate but fails to explain the purpose or format of the optional parameter.
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 uses the specific verb 'Inspect' followed by a clear enumeration of resources (macOS, Clash Verge paths, Unix controller, system proxy, AI group, LaunchAgent). It clearly distinguishes from sibling tools by focusing on environment diagnosis rather than status or health checks.
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 explicitly states 'Use before any installation or troubleshooting action,' providing a clear when-to-use directive. It does not mention when not to use or alternative tools, but the usage context is well-defined.
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?
Annotations already indicate mutation (readOnlyHint=false), idempotency, and non-destructiveness. The description adds valuable context beyond annotations: it explicitly states 'does not modify Clash Verge by itself', discloses the confirmation requirement, and implies a user-approval gate. This enriches the behavioral profile without contradicting annotations.
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 that are front-loaded with the primary action and scope, followed by a key limitation and a prerequisite. Every sentence adds information; no filler.
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 the tool has six parameters and a mutation operation with confirmation gates, the description provides the essential confirmation value and one behavioral limitation, but it omits the meaning of critical_domains, config_path, and what a successful write returns (though an output schema exists). It is minimally adequate but leaves notable gaps for a complex tool.
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?
With 0% schema description coverage, the description must compensate. It gives meaning to 'exact_domains' (via 'exact domains'), 'enabled' (via 'optional Provider enablement'), and 'confirmation' (via the required literal string), but it ignores provider_id, config_path, and critical_domains. For a six-parameter tool, this is insufficient coverage.
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 uses a specific verb ('Write') and names the resource ('private Provider overlay'), with precise content ('user-approved exact domains and optional Provider enablement'). It also distinguishes itself from siblings by clarifying it does not modify Clash Verge, making it the apply step vs preview.
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 the prerequisite of user approval and explicitly states the requirement for mutation opt-in and a specific confirmation value. However, it does not explicitly name alternative tools (e.g., preview_provider_overlay) or state when not to use this tool, so it falls short of full 5.
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?
The annotations already indicate readOnlyHint=false and idempotentHint=true. The description adds valuable behavioral context by requiring a specific confirmation value and mutation opt-in, and by clarifying that Clash Verge is not changed. This goes beyond the structured annotations without contradicting them.
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 concise sentences with all information front-loaded. Every phrase earns its place, with no redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the presence of annotations, and an output schema, the description is mostly sufficient. It covers the action and the confirmation requirement, but omits the semantics of config_path, which prevents a perfect score.
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 0%, so the description must compensate. It gives explicit meaning for the confirmation parameter ('confirmation=STOP_LAUNCH_AGENT') but says nothing about config_path, leaving a gap in understanding. This is partial compensation but not complete.
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's function with a specific verb ('Stop') and resource ('the monitor'), and adds the scoping detail 'without changing Clash Verge' that distinguishes it from uninstall or modification tools. However, no sibling tool is explicitly named, so it falls slightly short of full differentiation.
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 provides a clear prerequisite: 'Requires mutation opt-in and confirmation=STOP_LAUNCH_AGENT', which tells the agent what must be supplied. It does not explicitly state when to use this tool versus alternatives like uninstall_monitor or simulate_failover, so it lacks a 'when-not-to-use' statement.
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?
Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description adds valuable behavioral details: the tool runs probes twice (direct and proxy), does not require the Provider group to exist, and never switches nodes. These are not implied by the annotations and help the agent predict side effects and prerequisites.
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 sentences, front-loaded with the action, and adds relevant safety context in the second sentence. There is no redundant or extraneous content; every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and rich annotations, the description covers the core behavior and key preconditions (direct vs proxy, no provider group requirement, no node switching). The only notable gap is the lack of config_path semantics, but the tool is still adequately described for most use cases.
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 description coverage is 0%, so the description must compensate. However, it provides no direct explanation of provider_id or config_path. 'Provider probes' implies provider_id identifies the provider, but config_path is entirely omitted. The description only offers implicit, partial meaning, relying on schema property titles for the rest.
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 specific action: 'Run the configured Provider probes once over a direct connection and once through the current macOS system-proxy path.' This distinguishes it from sibling tools like diagnose_environment or run_health_check by focusing on comparing direct vs proxy paths. The verb and resource are concrete and 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?
It provides clear context for when to use: it is read-only, does not require the Provider group to exist, and never switches nodes. This implies it is safe for connectivity diagnostics without preparation or side effects. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
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?
Annotations already indicate idempotent and non-destructive behavior. The description adds value by disclosing the backup-and-integrate workflow and the mandatory confirmation token, which are behavioral traits not present in annotations. No contradiction.
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?
One sentence, front-loaded with the action and separated from the requirement. No wasted words, each clause carries meaning.
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?
The description gives a solid overview of the workflow, prerequisites, and confirmation requirement. Output schema covers return values, and annotations cover safety. The main gap is missing explanations for two optional parameters, but they are optional and reasonably self-descriptive.
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?
With 0% schema coverage, the description must compensate by explaining parameters. It only provides meaning for 'confirmation', specifying the required value. 'config_path' and 'start_when_ready' have no added semantics beyond their names and defaults, leaving the agent to guess their roles.
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 states a clear, specific action: back up and integrate persistent AI group/rules, then install the LaunchAgent. It distinguishes from sibling tools like preview_install and simulate_failover by focusing on the actual installation step.
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 signals this is the mutating, actual installation step by requiring mutation opt-in and a specific confirmation string. It does not explicitly name alternatives, but the context is clear enough for an agent to differentiate from preview/simulation 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?
The description discloses that the tool previews changes and reports the environment, adding behavioral detail beyond the annotations (which already declare readOnlyHint, idempotentHint, and destructiveHint false). It also explicitly states 'without writing files,' reinforcing the non-destructive nature. No contradictions with annotations.
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 sentence that front-loads the action ('Preview') and conveys the scope ('persistent Clash Verge group/rule changes') and side-effect-free nature ('without writing files'). Every phrase is meaningful with no redundancy.
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 read-only preview tool with one optional parameter and an output schema, the description covers the main behavior and non-mutation. However, the unaddressed parameter semantics create a minor gap in how to use the tool effectively.
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 schema's only parameter, config_path, is not described in the description, and schema coverage is 0%. The name gives a hint, but the description does not explain how it relates to the preview (e.g., path to a Clash Verge configuration file). This leaves ambiguity for the agent.
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 action ('Preview'), the resource ('persistent Clash Verge group/rule changes'), and its scope ('report the environment without writing files'). This distinguishes it from sibling tools like install_failover and diagnose_environment by emphasizing the preview-only, non-destructive behavior.
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 phrase 'without writing files' provides clear context that this is a dry-run/simulation tool, implying it should be used before actual changes. However, it does not explicitly name alternatives or state when not to use it, though the sibling tools suggest install_failover is for actual installation.
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?
Annotations already mark the tool as idempotent and non-destructive, but the description adds the crucial behavioral detail that it requires mutation opt-in and a specific confirmation token. This context is beyond what annotations provide.
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 with no redundancy. Every piece of information is useful: the action and the prerequisite confirmation, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations cover safety, the description adds the key mutation requirement. It could elaborate on overwrite behavior or the meaning of 'auto-discovered', but the core purpose and invocation condition are covered.
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 descriptions for the parameters, and the description only clarifies the 'confirmation' parameter by specifying the exact expected value. The 'config_path' parameter remains semantically vague, though its purpose is somewhat inferred from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'write' and identifies the resource as 'auto-discovered local config', clearly stating the tool's function. The title reinforces that this writes a failover config, distinguishing it from sibling tools like simulate_failover or install_failover.
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 provides an explicit usage requirement: mutation opt-in and the confirmation value 'WRITE_LOCAL_CONFIG'. This tells the agent when the tool can be invoked and what to provide, though it does not mention alternatives or when to avoid using it.
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?
Beyond the annotations (readOnlyHint, idempotent, non-destructive), the description adds critical behavioral details: sanitization, a 60-second cap, and the special handling of temporal-only candidates (hidden by default, never auto-recommended even when requested). This gives the agent concrete expectations about output and internal logic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place. The main action is front-loaded, followed by output exclusions and a nuanced behavioral note. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists and annotations cover safety, the description adequately explains the tool's purpose, constraints, and key behavior. It leaves parameter details to the schema but is otherwise complete for selecting and invoking the tool.
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% and the description provides only indirect hints about parameters (e.g., 'up to 60 seconds' hints at duration_seconds, 'explicitly requested' hints at include_temporal_candidates). It does not clearly map behavior to parameter names or explain the role of config_path or provider_id.
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 a specific verb ('Observe') and resource ('sanitized Mihomo connection hostnames'), and clearly scopes the action to 'while the user exercises one Provider.' It also distinguishes itself from siblings by emphasizing the sanitized, limited nature of the observation and explicitly listing what it never returns.
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 provides a clear usage context ('while the user exercises one Provider') and excludes use cases by stating 'Never returns URLs, paths, connection IDs, IPs, or chains.' However, it does not name specific alternative tools or explicitly say 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) already cover safety, and the description adds the specific behavioral detail that it checks both installation and running status. No contradictions or additional warnings needed for this simple read 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?
A single, front-loaded sentence states the exact action and resource. Every word contributes value, with no filler or repetition.
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 read-only status check with no parameters, an output schema, and clear annotations, the description is fully sufficient. It conveys the essential purpose without omitting anything relevant.
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 no parameters, and schema coverage is 100% (vacuous). The description adds no parameter details, but with zero parameters the baseline of 4 is appropriate; no additional meaning 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 uses a specific verb ('Return') and resource ('per-user failover LaunchAgent') with a clear scope ('installed and running'). It distinguishes from sibling tools like get_status or run_health_check by naming the exact component and check performed.
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 when-to-use or alternative guidance is provided. However, the description clearly implies the tool is for checking the installation and running state of the failover LaunchAgent, so usage is inferable but not contrasted with siblings.
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?
The description discloses key behavioral traits: it is destructive (moves plist to Trash), it does not remove persistent Clash profile changes, and it requires confirmation. This goes beyond the annotations (destructiveHint=true, idempotentHint=true) by specifying exactly what is affected and the confirmation requirement. No contradiction with annotations.
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 three concise sentences, each providing essential information: the core action, what is not removed, and the prerequisite. No wasted words, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action, scope limitations, and prerequisites. The output schema is provided, so return values are handled separately. It is slightly incomplete in not addressing the config_path parameter or potential effects of not providing confirmation, but for an uninstall tool with a narrow purpose, it is largely sufficient.
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 crucial meaning for the confirmation parameter, specifying the exact required value 'UNINSTALL_LAUNCH_AGENT'. However, it does not explain the 'config_path' parameter at all, leaving its purpose ambiguous. Since schema coverage is 0%, the description only partially compensates for the lack of parameter documentation.
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 specific action: 'Stop the monitor and move its plist to Trash.' It identifies the resource (monitor/plist) and verb, and distinguishes itself from siblings like stop_monitor by clarifying it also removes the plist and mentions persistent Clash profile changes are not removed. The title 'Uninstall failover LaunchAgent' aligns with the description.
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 provides clear usage context: it requires mutation opt-in and a specific confirmation value ('confirmation=UNINSTALL_LAUNCH_AGENT'). It implies this is the tool for full uninstall rather than just stopping (stop_monitor). However, it does not explicitly name alternatives or exclusions, so it falls short of a 5.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond annotations by specifying 'isolated deterministic simulation' and explicitly reinforcing 'No live proxy is changed'. This discloses determinism and isolation, which are not apparent from annotations alone.
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 sentences, front-loaded with the main action. The second sentence provides essential safety context without redundancy. Every word contributes to understanding the tool's purpose and behavior, achieving maximum conciseness.
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?
With no parameters, rich annotations, and an output schema, the description is complete. It enumerates the specific areas simulated (adaptive failure gates, timing, connection preservation, ranking) and explicitly states the no-live-change guarantee. There is no missing critical context for an agent to select and invoke this 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 tool has zero parameters, so the baseline score is 4. The description has no need to explain parameter semantics; the empty schema and description coverage are consistent. No additional parameter information 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 action: 'Run an isolated deterministic simulation' with a specific resource domain (adaptive failure gates, prepared-route timing, connection preservation, distinct-exit ranking). This distinguishes it from siblings like install_failover or start_monitor, which represent actual live changes.
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 provides clear context and implied usage: it is a simulation and 'No live proxy is changed', so it is safe for testing failover behavior without affecting production. However, it does not explicitly name alternative tools or state when not to use it, missing the highest bar for explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations: the evidence is "time-limited" (implying TTL behavior), it requires the monitor to be stopped, and it mandates a confirmation token. This complements the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) without contradiction.
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 constraints. No wasted words; every clause adds information, making it highly concise and well-structured.
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 tool with 7 parameters, annotations, and an output schema, the description covers core purpose, key preconditions, and main parameter constraints. It leaves the "reason" parameter unexplained and the exact meaning of "exit fingerprint" is domain-specific, but overall it is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 0%, the description compensates by explaining the "status" parameter ("must be confirmed or rejected") and the "confirmation" parameter ("confirmation=RECORD_WEB_FEEDBACK"). It also implies "ttl_seconds" via "time-limited." However, it doesn't explain the "reason" parameter or optional config_path/provider_id semantics, so it's not fully complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description begins with "Record time-limited browser evidence..." which is a specific verb+object, and it distinguishes from siblings by explicitly stating "This never switches a proxy." The tool clearly records observed exit fingerprint evidence for a Provider/node, making its 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?
Explicitly states prerequisites: "requires the monitor to be stopped, mutation opt-in, and confirmation=RECORD_WEB_FEEDBACK." Also clarifies a key exclusion: "This never switches a proxy," which helps differentiate from failover/overlay tools. However, it doesn't name specific alternative tools for when not to use this one, so it's not a perfect 5.
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-ai-failover MCP server](https://glama.ai/mcp/servers/doublebearoliver-cyber/mihomo-ai-failover/badges/card.svg)](https://glama.ai/mcp/servers/doublebearoliver-cyber/mihomo-ai-failover)

Score Badge

Copy to your README.md:

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

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/doublebearoliver-cyber/mihomo-ai-failover'

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