Clash Control MCP

by huaqing0

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0-rc.1
Disambiguation5/5
Each tool has a highly specific purpose within a clear hierarchical namespace (e.g., clash.verge.*, clash.runtime.*). Descriptions are detailed and unique, making it easy to distinguish between similar tools like list vs inspect variants.
Naming Consistency5/5
All tools follow a consistent pattern: `clash.<category>.<action>`. The hierarchy is uniform, verbs are descriptive (get, set, list, inspect, configure), and snake_case is used throughout without deviations.
Tool Count2/5
At 66 tools, the server is excessively large. While the Clash Verge domain is complex, this many tools in a single server creates cognitive overload and violates typical MCP scoping. The count far exceeds the 15–25 range considered reasonable.
Completeness4/5
The tool set covers a broad and deep range of operations: profiles, configuration, runtime control, preferences, optimization diagnostics, and recovery. Minor gaps exist (e.g., no direct runtime config write), but core workflows are well-supported.
Average 4.1/5 across 66 of 66 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It implies a read-only operation ('list') but does not explicitly state that it is safe or that it has no side effects. It also does not disclose any behavioral traits such as data freshness or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and front-loaded with the core purpose. It avoids fluff, though it could be slightly expanded without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should clarify the return value, but it says only 'summarized' without specifying fields. Pagination mechanics (cursor usage) are also left implicit. The description feels incomplete for an agent to confidently use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all three parameters (100% coverage). The description adds minimal extra meaning beyond framing them for paginated listing. Baseline 3 is appropriate.
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 (list), resource (Verge profiles), and key features (summarized, paginated). It distinguishes this tool from sibling tools like inspect (detailed single profile) or activate (profile selection). However, 'summarized' is vague and could be more specific.
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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. An agent must infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not mention side effects, read-only nature, prerequisites, error behavior, or performance implications. The return value is described minimally as 'config keys and summary'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences with no unnecessary information. Every word is functional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool, the description is adequate. However, given the lack of output schema and annotations, and the presence of many sibling tools, more context about error handling, usage flow, or relationship to other profile tools would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for uid ('Profile UID to inspect'). The tool description adds that it inspects 'by uid' and returns 'config keys and summary', but does not provide additional semantic detail beyond the schema.
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 inspects a Verge profile by UID and returns config keys and summary. It differentiates from sibling inspect tools by specifying 'Verge profile', though it could be more explicit about what distinguishes it from other profile inspect tools like inspect_chain.
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 usage context is provided. Given many sibling tools (e.g., list, activate, refresh, other inspect tools), the description offers no guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions setting a config value and 'light confirmation', but does not explain side effects, whether a restart is needed, or any permissions beyond the owner hint. This is insufficient for a mutation 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 a single sentence with no unnecessary words. It includes a useful parenthetical context and is perfectly sized for a simple tool. Every part serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers the basic action and the confirmation requirement. However, it lacks important behavioral context (e.g., immediacy of effect, prerequisites) that would make it fully complete. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (enum for value, boolean required for confirmed) with 100% coverage. The description adds only the phrase 'light confirmation', which doesn't materially enhance understanding beyond the schema. Baseline of 3 is appropriate.
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 uses a specific verb 'Set' and identifies the resource 'log-level' in 'config.yaml', with an owner qualifier. This clearly distinguishes it from other set_* tools like set_ipv6, though the 'verge_clash_base owner' phrase may be unclear to some.
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 does not provide any when-to-use or when-not-to-use guidance, nor does it mention alternative tools (e.g., clash.config.validate_change for staged changes). It only implies changing the log level, leaving the agent to decide appropriateness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It does not state whether the diagnostics are read-only, require privileges, are destructive, or what the output looks like. Key behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that lists the diagnostic targets efficiently. It is concise with no wasted words, though it could be structured as a bullet list for scanability.
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?
While the tool has no parameters and no output schema, the description still lacks details on what the diagnostic output looks like, how to interpret results, or whether it performs any actions beyond checking connectivity. Somewhat incomplete for a diagnostic 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 input schema has no parameters, so the description does not need to add parameter meaning. Baseline score 4 is appropriate because no parameter information is necessary.
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 specifies a clear verb (Run) and resource (comprehensive diagnostics) and lists concrete components (Mihomo connectivity, Verge detection, etc.), distinguishing it from sibling tools that focus on settings, profiles, or optimization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like clash.optimize.diagnose_network, nor does it mention prerequisites, limitations, or exclusions. It simply describes what it does without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It says 'Auto-allowed' but does not clarify side effects (e.g., making network requests) or whether it modifies state. The return of delay and jitter is mentioned but the format is unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two front-loaded sentences, no redundant information, and every sentence 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 no output schema, the description covers return values (median delay and jitter). It mentions predefined targets and multiple samples, but could be more explicit about the return structure and units.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds context like 'multiple samples' and 'predefined test targets', but does not elaborate on parameter formats or behaviors beyond what the schema already provides.
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 'Test delay for a specific proxy' with a specific verb and resource, and details that it uses multiple samples and returns median delay and jitter. However, it does not explicitly differentiate from sibling tools like clash.optimize.health_checks, which may also test proxy performance.
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 mentions 'Uses predefined test targets only (no arbitrary URL)' which provides a negative condition (when not to use), but lacks explicit guidance on when to use this tool versus alternatives or prerequisites like proxy existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it does not write configuration but omits what happens on success/failure, error conditions, or whether the operation is idempotent. The agent lacks insight into side effects or validation behavior.
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, no redundancy. The action and resource are front-loaded, and the second sentence provides critical clarification. 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?
With no output schema or annotations, the description should explain what the tool returns (e.g., success status or transaction state). It also lacks prerequisites or error handling. For a simple tool with one parameter, the current description is incomplete for an agent to use reliably.
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 single parameter 'transactionId' is described in the schema as 'Persisted pending transaction ID'. The tool description adds context by specifying it must be a PENDING_RESTART transaction. This adds marginal value but does not provide format or source details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resumes verification of a persisted PENDING_RESTART transaction after a restart, and explicitly notes it does not write configuration. This distinguishes it from sibling tools like apply_transaction or rollback.
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 context for use (after restart) but does not explicitly state when not to use it or name alternative tools. It implies it is only for resuming pending transactions, but an agent would benefit from knowing not to use it for applying or rolling back.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the action and confirmation requirement but does not disclose effects on config, whether changes are reversible, or if a reload is triggered.
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 short sentences with no filler. Essential information is front-loaded. Efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple boolean setter with confirmation, the description is adequate but lacks details on return values, side effects, or what happens after setting. Could be more complete.
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 provides 100% coverage with descriptions for both boolean parameters. Description adds no extra meaning beyond schema, so baseline 3 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?
Description clearly states the action 'Set ipv6 in config.yaml' with specific resource and owner context 'verge_clash_base owner'. It is distinct from sibling tools like set_unified_delay or set_log_level.
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?
Implies usage for enabling/disabling IPv6, but no explicit guidance on when to use this tool vs alternatives like other config setters or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares 'Read-only' and mentions fingerprinting of script content as raw bytes. However, without annotations, it lacks details on failure modes, authentication requirements, or rate limits. The behavioral transparency is adequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and communicates the purpose clearly. It is front-loaded with the main action and additional details about fingerprinting. While it could be slightly more concise, it avoids redundancy and is well-structured.
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 lack of an output schema, the description does not specify the format or content of the return value. It mentions inspection and fingerprinting but omits what the agent can expect as a result. For an inspect tool, this is a notable gap.
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 single parameter 'uid' is fully described in the input schema (regex constraint, default behavior). The description adds context about file path resolution and fingerprinting, but does not enhance understanding of the parameter beyond the schema. With 100% schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'inspect' and the specific resource: the active profile's referenced Script/Override owner or a specific script UID. It also mentions the read-only nature, which helps distinguish it from sibling tools like clash.profiles.inspect.
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 inspecting overrides but does not provide explicit guidance on when to use this tool vs. alternatives like clash.profiles.inspect. No when-not-to-use or prerequisite conditions are 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?
No annotations provided, so description must disclose behaviors. It mentions 'summarized, paginated results' indicating it returns a summary and uses cursor-based pagination, but lacks details on rate limits, authentication, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, clear and to the point, no fluff. Slightly more structure (e.g., listing key behaviors) could improve clarity without much length increase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description gives minimal context. 'Summarized, paginated results' is a start, but agents may need more about response structure or error handling. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 3 parameters. The description adds 'paginated' context, but does not significantly enhance understanding beyond schema. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'policy groups', and specifies 'summarized, paginated results'. This differentiates it from siblings like 'get_proxy_group' (singular) and other list 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?
No explicit guidance on when to use this tool vs alternatives. The pagination hint implies usage for large sets, but no when-not or alternative mentions.
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?
No annotations provided, so description carries the burden. It discloses the key behavior (no write) and lists change types, but lacks details on error handling, idempotency, or side effects. Adequate but not exhaustive.
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, front-loaded with purpose and key behavior, no fluff. Every sentence earns its place.
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?
No output schema, so description should explain diff format; it only mentions 'generate a diff preview' without detail. Lacks contextual info like prerequisites (workspace must exist) or workflow position among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description summarizes change types and gives examples, but adds minimal semantic value beyond what schema descriptions already provide.
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 the specific action: apply semantic changes and generate a diff preview. It clearly distinguishes from sibling tools by emphasizing no file writes and listing supported change types. The verb 'preview' and scope are 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 use for previewing changes before committing, but does not explicitly state when to use this tool vs. alternatives like validate_change or apply_transaction. No exclusions or context for sibling differentiation.
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?
With no annotations, the description must disclose behavioral traits. It mentions 'DNS resolution verification included' and the strong confirmation flow, which adds value. However, it does not describe permissions required, reversibility, side effects, or error states.
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 purpose, and includes critical operational notes. No wasted words; every sentence is essential.
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 lack of output schema and no annotations, the description should cover return values, error conditions, and postconditions. It mentions verification but not what is returned. The tool is a configuration mutation, and the description omits these important details.
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?
All three parameters are described in the schema with 100% coverage. The tool description repeats the confirmation pattern from the schema but does not add new semantic meaning to the parameters themselves. The baseline of 3 is appropriate.
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 specifies the action (configure DNS kernel section) and the target file (dns_config.yaml owned by verge_dns_base). However, it does not explicitly distinguish this tool from similar siblings like clash.optimize.dns, missing an opportunity for 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 explicit step-by-step guidance: call first without confirmed to get nonce, then call with confirmed=true and the nonce. This is strong usage guidance. It does not mention when to avoid using this tool or suggest alternatives.
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 that 'light confirmation is required' and that the tool returns COMMITTED only after persistence, runtime, GUI-refresh, and five-state verification succeed. This gives good insight into the post-invocation behavior and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the core action and key behavioral details. It is front-loaded with the verb and resource, and every clause adds value. However, it could be slightly restructured for readability.
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 tool's low complexity (two boolean params, no output schema) and no annotations, the description covers the essential behavioral context: the need for confirmation, the verification steps, and the return condition. It adequately informs an agent about the tool's operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (value and confirmed) with clear descriptions. The description adds 'Light confirmation required,' which reinforces the confirmed parameter but does not provide additional semantic value beyond the schema. With 100% schema coverage, a score of 3 is appropriate.
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 verb 'Set' and the resource 'unified-delay', making the tool's purpose clear. It mentions 'authenticated native Clash Verge Adapter', which hints at its specific domain but does not explicitly differentiate it from sibling tools like 'set_ipv6' or 'set_log_level'.
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 the tool is used to set unified delay and mentions the requirement for confirmation and the conditions for returning COMMITTED. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it reference alternative tools for similar actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates an audit function but does not explicitly state whether the tool is read-only, has side effects, or requires specific permissions. The lack of behavioral details (e.g., no mention of being safe to call anytime) leaves ambiguity for a diagnostic 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 a single sentence with an appended list of output fields, making it concise and front-loaded with the verb 'Audit'. Every element provides relevant information without waste.
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 there are no parameters and no output schema, the description does a good job explaining the output structure (current fact, potential impact, applicability condition). However, it could be more complete by mentioning the scope of issues detected or any prerequisites, though the simplicity of the tool mitigates this gap.
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, so schema coverage is trivially 100%. The description appropriately adds no extra parameter info, as none exist. A score of 4 is the baseline for zero-parameter 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 the tool audits configuration for issues and provides conditional recommendations, specifying the output structure (current fact, potential impact, applicability condition). It is distinct from sibling tools like clash.config.get_effective or clash.optimize.*, which either retrieve config or perform specialized optimizations.
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 the tool is for diagnosing configuration issues, but it does not explicitly state when to use it vs. alternatives such as clash.config.validate_change or clash.optimize.health_checks. No prerequisites or exclusions are mentioned, leaving the agent to infer usage context.
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?
No annotations are provided, so the description carries full burden. It discloses the rollback, restore, and reload actions, and the confirmation requirement. However, it does not detail what happens if the reload fails, whether the operation is destructive, or if it can be undone. Some behavioral context is given 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 very concise with two sentences. The first sentence front-loads the primary action and resource, and the second adds the confirmation requirement. 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?
Given the tool's simplicity (2 parameters, no output schema, no annotations), the description sufficiently explains the purpose and the need for confirmation. However, it could mention the return value or success/failure behavior to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add meaningful information beyond the schema for either parameter, as both are already described in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Rollback' and the resource 'previously applied transaction', and mentions restoring the original config file and reloading Mihomo. It distinguishes itself from sibling tools like apply_transaction and preview_change.
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 mentions the confirmation requirement but does not provide explicit guidance on when to use this tool vs alternatives such as apply_transaction or preview_change. The context is implied but not directly 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 provided, the description bears the full burden of behavioral disclosure. It explicitly states the tool is read-only, does not carry auth credentials, and does not call billing endpoints. It also clarifies that HTTP 401/403 are not network failures. However, it does not mention potential rate limits or the exact probe budget behavior, so a score of 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 5 sentences, with the core purpose front-loaded. It efficiently lists checks and non-checks. Could be slightly more streamlined, but no unnecessary words exist.
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 no output schema, the description fails to explain what the tool returns (e.g., diagnosis results structure). The input parameters are adequately described, but the output is not addressed, leaving the agent uncertain about the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema. It mentions 'skipProbes' and 'probeBudgetMs' but repeats schema content without deeper semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a read-only OpenAI network reachability diagnosis. It specifies the verb 'diagnoses', the resource 'OpenAI service', and lists specific checks (rule coverage, endpoint reachability). It distinguishes from sibling optimize tools by focusing solely on OpenAI.
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 states it is read-only and what it does not do (e.g., collect API keys), but lacks explicit guidance on when to use this tool versus alternatives like 'clash.optimize.diagnose_network'. The usage context is implied but not clearly differentiated from general network diagnosis tools.
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?
No annotations provided, so description carries full burden. It discloses the two-phase preview/nonce flow, capability gating, and JS file handling. However, it lacks detail on what 'optimistic fingerprint verification' entails, whether the update is destructive, or the exact side effects of the operation. More concrete behavioral traits (e.g., 'modifies the active override file') would improve clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, constraint (JS files), and process (two-phase). Front-loaded with the core action. No fluff, but the dense terminology 'optimistic fingerprint verification' could be clarified. Still, very concise for the complexity.
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's complexity (5 params, no output schema), the description covers the core behavior but leaves gaps: no mention of return value, no explanation of 'override owner', and the two-phase flow is implied but not explicit. With no output schema, agents might need to infer success/failure from the nonce pattern. Schema coverage is high, but the lack of output schema and annotations raises the completeness bar.
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?
All 5 parameters are described in the schema (100% coverage), setting a baseline of 3. The description adds valuable context about the two-phase execution (explaining the role of confirmNonce and confirmed), which goes beyond the schema's individual descriptions. This additional semantics justifies a 4.
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's a 'Capability-gated update of a YAML Override owner' via a specific adapter, and adds unique constraints (JS files not supported, two-phase execution). This distinguishes it from sibling read-only tools like 'clash.override.inspect' and other update tools like 'clash.merge.update'.
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 when to use (for YAML Override updates requiring capability gating) and when not (for JS scripts), but does not explicitly guide the agent to choose this tool over siblings like 'clash.merge.update' or mention prerequisites like requiring a preview call first. The two-phase execution hint is useful but not a direct usage directive.
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?
No annotations are provided, so the description must communicate behavioral traits. It notes the tool returns specific status fields, but it does not explicitly state that it is read-only or free of side effects. The behavior is mostly implied by the name 'get_status', but explicit transparency is lacking.
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 efficiently states the purpose and lists key aspects. There is no unnecessary information; every word adds value. It is front-loaded and easy to parse.
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 tool has no parameters and no output schema, the description covers the essential information by listing the fields returned. However, it could be slightly more complete by stating the return structure (e.g., an object with these fields) or clarifying that it is a simple read operation. Nonetheless, it is sufficient 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 the schema covers everything. The description adds meaning by enumerating the content of the status (version, mode, ports, etc.), which gives the agent context on what information will be retrieved. This exceeds the baseline expectation for a parameterless tool.
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 retrieves Mihomo runtime status and lists specific fields it returns (version, mode, ports, connections count, traffic totals). It uses a specific verb ('Get') and resource ('Mihomo runtime status'), and it is distinguishable from sibling tools like 'clash.runtime.list_connections'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the tool is simple and has no parameters, the description does not mention that it is safe to call at any time or that it is read-only, nor does it differentiate from other query tools like 'clash.doctor' or 'clash.runtime.list_proxy_groups'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 transparency. It reveals that the tool performs a read operation, but lacks details about what happens if the file is missing, permissions required, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is appropriately concise and front-loaded with the key action and resource.
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 (no parameters, no output schema), the description adequately conveys what the tool does. It could be slightly more complete by mentioning that it returns all settings, but it is sufficient for a read-only operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%. The baseline for 0 parameters is 4, and the description does not need to add parameter semantics since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'network and runtime settings' from a specific source 'verge.yaml'. This differentiates it from sibling tools like get_directories and get_active_profile which read different information.
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 reading settings but provides no explicit guidance on when to use this tool versus alternatives. There is no mention of exclusions or 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?
Discloses side effects: updates memory and verge.yaml, emits GUI refresh, verifies both states, and requires confirmation. Given no annotations, this covers behavioral traits well, though it does not mention failure scenarios.
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: first for main action, second for side effects, third for requirement. Front-loaded, no fluff, every sentence earns its place.
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 no output schema or annotations, the description provides good context on effects and confirmation. Lacks return value or error details, but adequate for a simple toggle with side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds no new meaning beyond schema; 'light confirmation required' hints at confirmed parameter but doesn't elaborate.
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?
Description clearly states the tool enables or disables auto-close connection. The verb and resource are specific, but it does not explicitly differentiate from sibling set_* tools like set_ipv6, though the distinct resource makes it 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?
Description mentions 'light confirmation required' but provides no explicit guidance on when to use this tool versus alternatives. No exclusions or context for when not to 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?
Although no annotations are provided, the description explicitly states 'Read-only; does not modify manifests, snapshots, profiles, or runtime state.' This clearly communicates that the tool is non-destructive and safe to use, adding essential behavioral context.
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 exceptionally concise with only two sentences, delivering key information upfront without any redundant or extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and safety, but does not describe the return value or output format. Given the tool's simplicity (no params, no output schema), the missing details about the inspection result limit completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%. With no parameters, a baseline score of 4 is appropriate as the description correctly indicates no input 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 'Inspect' and clearly identifies the resource as 'durable transaction and recovery state'. It distinguishes from sibling inspection tools by emphasizing its focus on recovery state and its read-only nature.
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 does not provide guidance on when to use this tool versus alternatives like clash.runtime.get_status or clash.profiles.inspect. There is no mention of prerequisites, preferred scenarios, or exclusions.
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?
No annotations provided, so description must convey behavior. It discloses the generated nature and default output, but does not mention error behavior, idempotency, or rate limits. Adequate but not thorough.
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 concise sentences, each delivering unique value: identifies the file, clarifies persistence, and explains default vs. parameter usage. 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 read tool with one optional parameter and no output schema, the description is mostly complete. It explains what is returned (summary vs. section). Could mention output format or error states, but given simplicity, this is 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?
Schema description coverage is 100% (one parameter 'section' described). The description only says 'Use "section" for specific block,' which essentially restates the schema's 'Optional: get a specific config section.' No additional semantic value beyond what schema provides.
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 clearly states 'Get Verge generated config' and distinguishes it from persistent config by explicitly noting it's a generated file, not a persistent source. Contrasts with sibling tools like clash.config.get_persistent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage context: 'Returns summary by default' and 'Use "section" for specific block.' Implicitly guides against using for persistent data by stating 'NOT a persistent source.' Does not explicitly list alternatives but context is clear.
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 full burden. It discloses read-only behavior and adds a key behavioral detail: script files are fingerprinted by raw content (not YAML-parsed), which is beyond a simple read-only statement. This helps the agent understand how fingerprints are computed. However, it does not mention any potential side effects or 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?
Extremely concise: two sentences with no wasted words. The first sentence front-loads the core purpose, and the second adds a specific behavioral nuance. Ideal for quick agent comprehension.
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 zero parameters and no output schema, the description explains what is inspected (layers and fingerprints) sufficiently for a decision. A minor gap is that it does not hint at the output format (e.g., a list or object), but the detail on fingerprinting compensates. Overall, it is complete enough for the use case.
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 schema coverage is effectively 100%. The description does not need to add parameter info. Baseline 4 is appropriate as it neither adds nor detracts from parameter understanding.
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 clearly states the verb 'Inspect' and the resource 'active profile's full reference chain', listing specific layers (profile, merge, script, rules, proxies, groups) with per-layer fingerprints. It effectively distinguishes from sibling inspect tools like clash.profiles.inspect which likely inspects only the profile layer, not the full chain.
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 mentions 'Read-only' but provides no guidance on when to use this tool versus alternatives such as clash.profiles.inspect, clash.merge.inspect, or other inspect tools. There is no explicit context for when-not-to-use or preferred scenarios.
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?
No annotations are provided, so the description must disclose behaviors. It mentions the confirmation requirement and the limitation of not supporting bulk close. However, it does not discuss potential destructive consequences or authorization needs, leaving some transparency gaps.
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, front-loaded sentences. Every phrase adds value: action, scope, limitation, and requirement. 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?
Given the tool's simplicity (close a connection by ID), the description covers core aspects: what, how, constraint. No output schema exists, so return values aren't needed. Slight missing detail on expected behavior after close (e.g., success/failure), but still largely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema's own descriptions (e.g., 'Light confirmation required' hints at confirmed, but doesn't elaborate). No parameter-specific guidance.
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 explicitly states 'Close a specific connection by ID,' specifying the action and resource. It also distinguishes from the unsupported batch close operation, giving clear scope.
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 tells when to use (specific connection) and mentions what is not supported (closing all connections). It also notes 'Light confirmation required,' guiding the agent to set confirmed=true. However, it does not provide explicit alternatives for bulk close.
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 burden. It declares read-only, safe, paginated, and that it does not expose credentials. These are key behavioral traits, though authentication needs and rate limits are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the 'Read-only' trait, and contains no filler. Every sentence 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 4 parameters and no output schema, the description lists return fields (names, types, liveness, delay history) and pagination. It is fairly complete, but could mention if more fields exist or the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema, which already covers group, limit, cursor, and filter adequately.
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 reads candidate names, types, liveness, and delay history for a single policy group, explicitly distinguishing it from siblings like list_proxy_groups (which lists groups) and test_proxy_delay (which tests delay).
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 detailed group info but lacks explicit guidance on when to use vs. alternatives like list_proxy_groups or select_proxy. No 'when-to-use' or 'when-not-to-use' statements.
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 full burden. It discloses the per-provider lock preventing concurrent refresh, the need for light confirmation, and that it does not modify persistent config. This goes beyond the schema but could still elaborate on lock behavior, auth, 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?
Three sentences, each conveying meaningful information without redundancy. The purpose is stated first, followed by key behavioral details. No filler or unnecessary 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 refresh tool with two required parameters and no output schema, the description covers the essential behavioral traits (lock, confirmation, persistence). It is complete enough for an AI agent to use correctly, though it could mention typical use cases or results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing descriptions for both 'name' and 'confirmed'. The description adds marginal value by stating 'by name' and 'Light confirmation required', but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Refresh a rule provider by name'), specifies the resource type ('rule provider'), and distinguishes it from the similar sibling tool 'clash.runtime.refresh_proxy_provider' which refreshes proxy providers. The mention of per-provider lock adds specificity.
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 notes that 'Light confirmation required' (via the confirmed parameter) and that it does not modify persistent config, but lacks explicit guidance on when to use this over alternatives like 'clash.runtime.refresh_proxy_provider' or other operations. No when-not-to-use conditions or prerequisites are mentioned.
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?
With no annotations, the description fully carries transparency. It reveals two operating modes (atomic sync vs runtime-only) and mentions a confirmation parameter. However, it does not detail side effects like connection behavior or error handling, leaving the agent somewhat uncertain about what happens after the switch.
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 sentences, each adding significant information: main action, behavioral variation, and parameter requirement. It is front-loaded and efficient, with no unnecessary text.
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 three parameters and no output schema, the description covers the essential behavior, including the two modes and the confirmation. It is nearly complete but could mention the return value or typical response to be fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds 'Light confirmation required' which ties to the 'confirmed' parameter, but does not provide further semantic enrichment beyond the schema's descriptions of group and proxy.
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 'Switch proxy in a Selector group,' which is a clear verb-resource pair. It distinguishes this tool from siblings like 'clash.runtime.test_proxy_delay' or 'clash.runtime.list_proxy_groups' by focusing on the selection action within a group.
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 for switching a proxy in a selector group, which is distinct from other runtime tools. It does not explicitly state when to use the fallback versus full synchronization mode, nor does it list alternatives, but the purpose is clear enough for selection among siblings.
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?
No annotations provided, so the description carries the full burden. It describes the return fields but does not disclose whether the operation is read-only or has side effects. For a detection tool, it is likely safe, but this is not explicitly stated.
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, front-loaded sentence that conveys all essential information without redundancy. It is appropriately concise for a simple tool.
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 tool's simplicity (0 parameters, no output schema), the description is adequate. It lists the returned data points. It could be improved by mentioning that it is a read-only operation, but it is still complete enough for this context.
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 the input schema is empty. The description correctly implies no input is needed. Per guidelines, 0 params earns a baseline of 4, and no additional parameter info is necessary.
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 retrieves detection results from Clash Verge Rev, listing specific fields (version, paths, config root, portable mode, compatibility). It distinguishes itself from sibling tools like get_settings or get_directories by focusing on detection/identification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. However, its zero-parameter nature and focus on detection imply it is a preliminary call. No mention of exclusions or prerequisites.
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?
No annotations are provided, so the description carries full burden. It implies a read-only operation but does not explicitly state that it is non-destructive, requires no special permissions, or whether it returns cached vs real-time data. The description is adequate but lacks explicit behavioral disclosure.
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 of 12 words, front-loaded with the action and resource, followed by a list of returned fields. No wasted words, every part earns its place.
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?
Despite having no output schema, the description lists the expected fields (uid, type, name, path, selected proxies), providing sufficient completion for a simple getter. It does not explain the output format explicitly, but the listing implies an object with those keys.
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 per instructions. The description does not need to add parameter information, and the schema already covers 100% of parameters (none).
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 specifies the verb 'Get', the resource 'currently active Verge profile', and lists the fields returned (uid, type, name, path, selected proxies). This distinguishes it from sibling tools like clash.profiles.list which list all profiles, and other getters like get_settings.
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 states what the tool does but provides no guidance on when to use it versus alternatives, no exclusions, and no prerequisites. However, given the tool has no parameters and is a simple getter, the context is clear enough for appropriate use.
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 provided, the description fully bears the burden of transparency. It discloses capability gating, two-phase preview/nonce execution, optimistic fingerprint verification, compensation, and the ability to target inactive profiles without switching them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and front-loaded with the main action. However, the first sentence is dense with jargon, slightly reducing clarity. It could be more streamlined, but it is not overly verbose.
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 complex tool with 5 parameters, no output schema, and a two-phase process, the description covers the key aspects: purpose, capability gating, nonce execution, and inactive profile selection. It lacks detail on return values or 'compensation,' but overall adequate.
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?
All 5 parameters have schema descriptions (100% coverage). The description adds extra meaning beyond the schema, particularly regarding targetProfileUid's ability to select inactive profiles and the nonce/confirmation workflow. This elevates it above the baseline of 3.
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?
Clearly states the tool performs a capability-gated update of a Merge YAML owner using a strategic merge patch. It distinguishes itself from sibling tools like clash.merge.inspect by focusing on updates, and describes the two-phase execution process.
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 explicit guidance on when to use this tool versus alternatives such as clash.override.update or other merge tools. The description implies usage for updating merge profiles, but lacks when-not scenarios or comparative context.
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?
Discloses capability-gating, rejection of duplicates/drift, two-phase preview/nonce, and stable fingerprint anchors. No annotations exist, so description carries full burden; it is largely transparent but misses explicit destructive 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?
Three concise sentences front-load the core action and context; no wasted words, efficient for agent consumption.
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?
Explains key behaviors (fingerprint anchors, rejections, two-phase) but lacks specifics on return values, error handling, and relationship to clash.rules.remove. Could be more complete for a complex tool with no output schema.
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 has 100% description coverage, but the overall description enriches understanding with fingerprint anchor concept and two-phase execution, adding value beyond individual parameter 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 it adds rules to a section with prepend/append/delete via stable fingerprints, distinguishing it from sibling tools like clash.rules.remove and clash.rules.inspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs siblings like clash.rules.remove, despite the 'delete' section causing overlap. Context is implied but not stated.
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 carries the full burden. It discloses read-only/safe behavior, redaction of sensitive data (IPs, local paths), and pagination. This is good but lacks details on pagination mechanics.
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 'Read-only', no wasted words. Efficient and clear.
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?
No output schema exists, so description should explain return format. It mentions 'connection summaries' and redaction but not full structure or pagination metadata (like next cursor). Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds no extra parameter-specific info beyond what the schema already provides (limit, cursor, filter).
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 connection summaries, is read-only, safe, paginated, and includes IDs for use with close_connection. It distinguishes from sibling tools like close_connection and other list tools.
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 by mentioning IDs for close_connection, providing context. However, it does not explicitly state when to use vs alternatives or exclude cases.
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?
No annotations provided, so description carries full burden. Mentions strong confirmation and risk assessment, but does not detail consequences of enabling LAN access or required permissions. Adequate but not exhaustive.
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 short sentences, front-loaded with purpose, then usage. No redundancy or fluff.
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?
No output schema; description does not mention return values or success/failure indicators. The risk assessment is noted but not elaborated. Missing completeness for an action 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?
Schema covers all 3 parameters with descriptions. Description adds value by explaining the nonce mechanism and the confirmation workflow, which goes beyond the schema's static 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?
Description clearly states the action ('Configure allow-lan in config.yaml') and identifies the owner ('verge_clash_base owner'), distinguishing it from other configuration tools like configure_tun or configure_dns_override.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow: 'Strong confirmation required (call first without confirmed to get nonce)', guiding the agent on the two-step process. Does not compare to alternatives, but the context is clear.
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?
No annotations are provided, so the description carries full burden. It discloses the two-step confirmation process and mentions system-level verification, but does not explain side effects (e.g., whether changes persist across restarts, require elevated permissions, or could disrupt connectivity).
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 conveying all critical information: purpose, owner, and multi-step usage. No redundant wording. Perfectly front-loaded and efficient.
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?
While the confirmation process is well described, the tool lacks an output schema and annotations. The description does not specify return values, failure modes, or the nature of system-level verification. For a configuration mutation, more context about persistence and impacts would improve completeness.
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 coverage is 100% with each parameter having a description. The description adds operational context: the patch parameter's example ({enable: true, stack: 'system'}) clarifies expected structure, and the confirmation process explains how confirmed and confirmNonce interact. This goes beyond the schema alone.
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?
Clearly identifies the action (Configure), resource (TUN section), and target (config.yaml). The description also notes the owner context (verge_clash_base), making the purpose specific 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?
Explicitly describes the strong confirmation process: first call without confirmed to get nonce, then retry with nonce. This guides the agent on correct invocation. However, it does not indicate when to prefer this tool over siblings like configure_dns_override or configure_ports.
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?
With no annotations provided, the description must carry the burden of behavioral disclosure. It states the tool retrieves config but does not explicitly declare it as a safe read-only operation or mention any side effects, permissions, or limitations.
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 consists of two concise sentences that efficiently convey the tool's purpose and parameter usage without unnecessary 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 retrieval tool with one optional parameter and no output schema, the description provides sufficient context: what it returns, default behavior, and parameter usage. It could mention possible section values more comprehensively, but it's adequate.
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 parameter 'section' is described in the schema, but the tool description adds context by explaining the default return and how the parameter modifies output, which goes beyond the schema's 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 clearly states the tool retrieves the Mihomo runtime effective config from the API, and distinguishes between a summary return and specific section retrieval. This differentiates it from sibling tools like 'get_generated' and 'get_persistent'.
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 explains default behavior and how to use the optional 'section' parameter to get a specific config block. It does not explicitly mention when not to use this tool, but the guidance is clear for the intended use case.
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?
No annotations are provided, so description carries the full burden. It discloses what the tool returns and explicitly states a behavioral constraint (not returning generated yaml). It doesn't mention side effects, permissions, or performance, but as a read operation with no parameters, the description is sufficiently transparent.
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. First sentence states the purpose and scope. Second sentence clarifies an exclusion and points to an alternative. No redundant information.
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 (zero parameters, no output schema), the description is complete enough. It explains what is returned and what is not. Could be improved by briefly noting the return format, but it's adequate for agent use.
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 no parameters, so baseline is 4. Description does not need to add param info. It correctly implies that no inputs are 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 explicitly states the verb 'Get' and the resource 'persistent config sources summary', listing specific components. It also distinguishes from the sibling tool 'clash.config.get_generated' by stating what it does not return.
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 when to use this tool (to get persistent config summary) and when not to (if needing generated yaml), and explicitly names the alternative 'clash.config.get_generated'. However, it does not address other siblings like 'get_effective'.
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 clearly states the tool does not write, which is key for safety. It lists the checks performed (YAML, schema, fingerprints, risk). It does not mention error handling, return format, or required permissions, but the core behavioral traits are disclosed.
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: first states purpose and checks, second states non-write nature. No extraneous words. Front-loaded with verb and resource. Highly concise and 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 tool's simplicity (1 param, no output schema, no annotations), the description covers the main aspects: what it validates and that it's read-only. It lacks details on return values (e.g., validation result format) but is mostly complete for a validation tool.
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?
Only one parameter (workspaceId) with schema coverage 100%. The description adds that the ID comes from create_workspace, which provides context. However, no additional parameter-specific details are given, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool validates a workspace's modified config, listing specific checks (YAML syntax, schema, fingerprint consistency, risk classification) and explicitly saying it does not write. This distinguishes it from sibling tools that modify or preview changes (e.g., clash.config.apply_transaction, clash.config.preview_change).
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 for validating a config before applying, and the 'Does NOT write' clause indicates safety. However, it does not explicitly mention when not to use it or name alternative tools like clash.config.audit or clash.config.preview_change, which could provide similar checks.
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?
Explicitly declares read-only nature, no modifications, and describes output structure (versioned report with findings and proposedActions). Mentions limitation of recommendations based on structural evidence only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph with clear statements: version, purpose, output, non-modification, and constraint. Efficient but could be slightly more structured.
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?
Fully explains the tool for a no-parameter, no-output-schema scenario. Covers purpose, behavior, output, and limitations, making it easy for an agent to decide to invoke it.
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?
No parameters exist, so the description does not need to explain parameters. Schema coverage is 100% (empty schema), and the description provides full context for the tool's function.
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?
Clearly states it is a read-only DNS configuration diagnosis tool, lists specific checks, and distinguishes from sibling tools like clash.optimize.rules or clash.optimize.proxy_groups.
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?
States it does not modify DNS configuration and describes its recommendations, but does not explicitly specify when to use it versus other optimization or runtime 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?
With no annotations, the description carries full burden. It explicitly states 'Read-only' and 'Does NOT execute any action or modify configuration', clearly disclosing non-destructive behavior. It doesn't cover auth needs or rate limits, but for this tool those are unlikely critical.
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 long, front-loads the key identity ('Read-only execution plan builder'), and every sentence adds value without redundancy. It is maximally concise.
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 tool has 2 parameters (both with schema descriptions) and no output schema, the description adequately explains what it returns (executable/blocked actions and the 8-step protocol). It could be slightly more detailed about the output structure, but it is largely complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters already described sufficiently. The description adds marginal context by stating the tool 'checks each action' but does not materially improve understanding beyond the schema definitions. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool as a 'Read-only execution plan builder' and specifies its exact function: checking proposed actions against capability gates and returning executable/blocked status. It distinguishes itself from sibling optimizer tools (e.g., verify_baseline, dns) by being a planning, non-executing tool.
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 the tool requires a baselineVerification from verify_baseline and proposedActions, indicating when to use it. However, it does not explicitly state when not to use it or mention alternatives among siblings, so it lacks full usage 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?
With no annotations provided, the description fully discloses behavioral traits: it is read-only, does not carry a GitHub token, does not execute push/login/write operations, and does not read private repo content. It also explains the diagnostic process layer-by-layer (DNS/TCP/TLS/HTTP/rule_match), providing complete transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of three sentences, each sentence adding essential information: version/read-only nature, what endpoints are probed, and exclusions. No unnecessary words; highly efficient and front-loaded with key details.
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 tool has no output schema, but the description explains that it 'reports failures layer-by-layer' which is sufficient context for a diagnostic tool. It covers the input parameters and behavioral constraints comprehensively. A slight improvement would be to mention the output format more explicitly, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the two parameters (skipProbes, probeBudgetMs), so the description does not need to add much. The description implies the behavior of skipProbes and budget by mentioning 'network probes' and 'local facts', but does not explicitly describe the parameters. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a 'Read-only GitHub service network reachability diagnosis' and specifies the endpoints (github.com, api.github.com, codeload.github.com) and the layers checked (DNS/TCP/TLS/HTTP/rule_match). This distinguishes it from sibling tools like clash.optimize.diagnose_network or clash.optimize.openai which target different services.
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 states what the tool does (diagnose GitHub reachability) and what it does NOT do (carry token, write operations, read private repo). However, it does not explicitly guide when to use this tool versus related siblings like clash.optimize.dns or clash.optimize.rules. The context is adequate but lacks explicit when-to-use/alternatives.
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 fully discloses read-only nature, scope (rule coverage + probes), and reporting (layer-by-layer). Also clarifies limitations. No annotation 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 dense paragraph front-loaded with purpose. Every sentence adds value: version, read-only, specific services, layer-by-layer reporting, and explicit exclusions. No waste.
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?
No output schema, but description covers purpose, behavior, and limitations sufficiently for a diagnostic tool. Parameter details are in schema. Minor gap: no mention of result format or pagination, but given 2 params and no nested objects, it's adequate.
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 covers both parameters with descriptions (100% coverage). The tool description adds no additional parameter context. Baseline 3 is appropriate as schema does the heavy lifting.
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 ('diagnoses') and resource ('streaming service network reachability'), lists exact services (Netflix, Disney+, Prime Video), and distinguishes from siblings by targeting streaming optimization.
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 what the tool does NOT do (unlock, bypass DRM, modify account) and clarifies that DRM/region issues are not network failures. Provides clear context for when to use, though lacks direct sibling differentiation.
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 full burden and discloses capability-gating, rejection of ambiguous matches and drift, and two-phase preview/nonce execution. It does not detail consequences of successful removal or potential rollback.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, densely packed with key information: capability, fingerprint method, section targeting, rejection conditions, and execution flow. No filler, though a slightly more structured ordering could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers usage context well but lacks mention of return values or output behavior. Given no output schema, this is a minor gap for a mutation 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?
Schema coverage is 100%, so baseline 3. The description adds value by explaining the role of ruleFingerprints (from clash.rules.inspect), the two-phase flow with confirmed and confirmNonce, and optional uid/targetProfileUid. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it removes rules by unique fingerprint from a specific section (prepend/append/delete) of the Rules owner, distinguishing it from clash.rules.add and clash.rules.inspect.
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 mentions capability-gated access, ambiguous match rejection, and a two-phase preview/nonce execution, providing context for when to use. However, it does not explicitly compare to alternatives or state when not to use.
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?
No annotations are provided. The description implies a read-only operation ('Get'), but does not explicitly state safety, idempotency, or any side effects. For a getter, the behavioral disclosure is adequate but minimal.
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 concise sentence that efficiently communicates the tool's purpose and output. Every word adds value with no redundancy or extraneous information.
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 lists the returned items sufficiently for a simple getter. However, it lacks detail on the output format (e.g., whether it is a string, object, or dictionary). With no output schema, a slightly more explicit structure would be helpful, but the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters. According to guidelines, 0 parameters defaults to a baseline of 4. The description correctly adds no parameter info as 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 retrieves Verge config directories and lists specific items (config root, profiles dir, executable path, unix socket). This is a specific verb-resource combination that distinguishes it from siblings, which deal with settings, profiles, runtime, etc.
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 implicitly indicates use when these directory paths are needed. No explicit exclusions or alternatives, but given its unique purpose among siblings (no other tool gets directories), the context is clear.
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?
No annotations provided, so description carries full burden. It discloses capability-gating, protected fields (explicitly listed as NEVER modifiable), two-phase execution, and failure mode. Could mention permissions beyond capability, but overall transparent.
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 concise sentences; front-loaded with purpose, then specific constraints and process. No extraneous 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?
No output schema, but description omits return values (e.g., what preview returns, execution result). Parameter info is good, but missing expected response format reduces completeness for an agent.
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 coverage is 100%, but description adds meaning by explaining that 'patch' only accepts allowlist fields, 'confirmed' must be true, and 'confirmNonce' comes from preview. This enriches schema beyond raw 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?
Description clearly states the tool updates Profile metadata (non-sensitive) via authenticated native adapter, specifying the action and resource. It distinguishes from sibling tools focused on listing, activation, and other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains two-phase process (preview then confirmed with nonce) and failure condition. Does not explicitly compare with sibling profile tools like activate or refresh, but provides sufficient context for appropriate invocation.
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 fully discloses behavioral traits: nonce-based confirmation, allowlist of function names, Tauri accelerator syntax, rejection of reserved combos and duplicates, and required capability. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with front-loaded purpose and detailed constraints. It is relatively long but each sentence provides necessary information. Could be slightly tightened without losing clarity.
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 complex tool with 5 parameters, nested objects, and no output schema, the description covers the process, constraints, and required capability well. It could mention return structure (e.g., success/failure indication) for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds context about the two-step workflow and constraints beyond schema, but does not significantly enhance understanding of individual parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Modify' and resource 'Clash Verge hotkey mapping', distinguishing it from sibling tools like configure_theme or configure_layout which target other preference areas.
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 explains the two-step confirmation process, allowlist restrictions, Tauri syntax requirement, and rejection conditions. While it implies hotkey context, it does not explicitly contrast with alternative tools for similar modifiable settings.
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, description thoroughly covers mutation behavior: two-phase commit (preview returns diff, confirm=true applies), authentication and capability requirements, validation against real enums, platform-specific unsupported feature (tray_event on Linux), and immediate effect of env_type. Could mention idempotency or partial updates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose first, then preview/confirm, authentication, validation, platform notes. Dense but each sentence serves a purpose. Minor redundancy like 'v1.1-C:' prefix could be removed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers major aspects: what it modifies, how to apply, authentication, validation, platform specifics. Lacks description of the diff structure output and failure behavior of ownerFingerprint. Good differentiation from sibling tools by specifying 'basic preferences'.
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 coverage is 100%, but description adds value by listing all fields and providing context (validated against real enums, platform restrictions, immediate effect, ownerFingerprint for drift detection). Enhances understanding beyond 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?
Clearly states verb 'Modify' and resource 'Clash Verge Basic UI preferences' with explicit list of fields (language, theme_mode, tray_event, env_type, start_page). Differentiated from sibling tools like configure_theme and configure_layout.
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?
Describes preview mode vs confirm mode, tray_event limitation on Linux, and immediate effect of env_type. However, lacks explicit guidance on when to use set_basic versus the more specific preference tools (configure_theme, etc.).
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 provided, the description fully discloses behavioral traits: read-only nature, no login credentials carried, and clarification that HTTP 401/403 are not network failures. This provides excellent transparency beyond what structured fields would convey.
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-loads the core purpose, and includes necessary clarifications in a well-structured format. Every sentence adds value without 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 there is no output schema, the description adequately describes what the tool does and reports (layer-by-layer failures). It mentions domains, probes, and clarifies non-failure cases. Minor gaps: no details on return format or error handling, but sufficient for understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents both parameters (skipProbes, probeBudgetMs) adequately. The tool description adds no additional parameter meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: read-only YouTube service network reachability diagnosis. It specifies the domains checked (googlevideo.com, ytimg.com), probes (web and API endpoints), and outcome (layer-by-layer failure reporting). This differentiates it from sibling tools like clash.optimize.diagnose_network or clash.optimize.openai.
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 implicitly indicates usage for diagnosing YouTube connectivity issues. It explicitly lists exclusions (does not promise unlock, modify account state, read history, etc.), providing clear boundaries. However, it does not explicitly compare to sibling tools or state 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fully compensates by disclosing behavior: remote require light confirmation, local NOT_APPLICABLE, fail-closed to BLOCKED when adapter unavailable/unauthenticated, and clarifies it is a Verge subscription refresh.
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?
Four sentences, front-loaded with purpose, each sentence adds value: purpose, local behavior, remote+fail behavior, disambiguation. No redundancy or 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?
Covers key scenarios (local, remote, fail-closed) and disambiguates from Mihomo refresh. Lacks details on success/error response format or typical effects, but no output schema exists to rely on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; description adds minimal new meaning beyond schema. The mention of 'light confirmation' for the confirmed param repeats schema info. No additional parameter insights.
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 clearly states action (refresh), target (remote subscription Profile via Clash Verge Adapter), and distinguishes from related sibling tools like Mihomo Provider refresh. Includes edge cases for local profiles (returns NOT_APPLICABLE).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use for remote subscription profiles, not local; remote require confirmation. Does not explicitly list when not to use compared to sibling refresh tools (e.g., clash.runtime.refresh_proxy_provider), but the differentiation Verge vs Mihomo is noted.
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 explicitly states 'Read-only' and that provider URLs and credentials are never returned, giving clear safety and behavioral guarantees. No annotations are present, so the description fully handles transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, highly concise, and front-loaded with the key attribute 'Read-only'. Every phrase adds value without unnecessary 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?
The description explains the tool's purpose and output type (names and summaries) but omits output structure details like pagination or summary format. Given no output schema, a bit more detail would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the parameters. The description does not add further semantic context about limit, cursor, or filter beyond what the schema provides.
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 rule provider names and safe runtime summaries, explicitly noting it is read-only and for use with refresh_rule_provider. This distinguishes it from sibling tools like list_proxy_providers.
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: use this to get provider names/summaries before calling refresh_rule_provider. However, it does not explicitly mention when not to use or compare to similar listing 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?
Given no annotations, the description discloses the two-step confirmation process and inclusion of port listening verification. It does not detail failure modes or permissions, but provides meaningful behavioral context beyond the 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?
Two concise sentences: first defines purpose and scope, second provides critical usage guidance. No unnecessary words, efficiently packed with information.
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 no output schema, the description covers purpose, workflow, and a behavioral hint (verification). Could elaborate on what 'port listening verification' entails or side effects, but overall adequate.
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 coverage is 100%, baseline 3. Description adds value by explaining the strong confirmation workflow and the role of confirmNonce, which is not fully captured in the schema's 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?
Description clearly states it configures proxy ports in config.yaml with a specific owner (verge_clash_base). The verb 'Configure' is specific and distinguishes it from siblings like configure_tun or configure_dns_override.
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 describes the strong confirmation workflow: call first without confirmed to get nonce, then with confirmed and nonce. Mentions port listening verification, guiding the agent on the expected usage pattern.
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 immediate effects, preview mode returning a Diff, and the need for confirmation, which is transparent for a configuration tool with no annotations. It could detail error behavior but covers key traits.
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 brief yet comprehensive, front-loading the purpose and constraints, with no unnecessary 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?
The description covers parameter constraints, preview/apply flow, and capability requirements, compensating for the lack of output schema with a clear statement about the return value.
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 100% schema coverage, the description adds value by explaining the menu_order constraint, immediate behavior, and output format, going beyond the schema's basic 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 'Modify Clash Verge Layout preferences' and lists specific fields, which distinguishes it from sibling tools like configure_theme and configure_hotkeys.
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 explains the preview vs apply mode and the required capability (settings.verge-preferences-write), providing clear usage context, though it does not explicitly mention when not to use it or contrast with alternatives.
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 highlights read-only nature and lists returned data (DNS/TUN/rules summary, fingerprint, paginated rules). Without annotations, this provides solid transparency, though could mention that no modifications occur.
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 cover action, defaults, return values, and read-only flag. No unnecessary words, perfectly 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 is complete for a simple inspection tool: explains input defaults, output summary, and pagination. Missing output schema is compensated by description. Could briefly mention error handling, but not essential.
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 schema descriptions already cover all parameters thoroughly. The tool description adds practical context (default uid, pagination for limit/cursor) that enhances understanding beyond the schema alone.
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 inspects a Merge file by uid, specifying default behavior (active profile's merge) and output summary. This distinctly differentiates it from siblings like clash.profiles.inspect or clash.rules.inspect.
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 mentioning defaults and read-only nature, but does not explicitly state when to use this tool vs alternatives. Sibling names help, but lack of explicit guidance prevents a 5.
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?
No annotations are provided, so the description fully carries the burden of behavioral disclosure. It explicitly states the tool is read-only, what is returned (names and safe summaries), and crucially what is NOT returned (subscription URLs and credentials). This is excellent transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence. It front-loads the read-only nature, then states the output purpose, and closes with a security note. Every word earns its place; no 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 list tool with a fully documented input schema, the description covers purpose, behavioral traits, and a sibling linkage (refresh_proxy_provider). No output schema exists, but the description adequately describes the return content. Complete and self-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 input schema already has 100% coverage with descriptions for all three parameters (limit, cursor, filter). The tool description adds no extra meaning or usage context beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists proxy provider names and runtime summaries. It explicitly tags the tool as read-only and notes its utility with refresh_proxy_provider. Among siblings like list_proxy_groups and list_rule_providers, this one is uniquely about proxy providers, so purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a precursor to refresh_proxy_provider, offering clear context. However, it does not explicitly contrast with alternative list tools (e.g., list_rule_providers) or state when not to use it. The privacy disclaimer about sensitive data not being returned is helpful.
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?
Despite no annotations, the description discloses key behavioral traits: the per-provider lock prevents concurrent refresh, and it 'Does NOT modify persistent config.' This adds value beyond the input schema. However, it could mention error behaviors or return values, though the lack of output schema reduces the need.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences covering the action, lock behavior, confirmation, and side effects. Every sentence is necessary and well-structured, with no redundant 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 simple refresh tool with two required parameters and no output schema, the description covers all essential aspects: action, parameters (confirmation), concurrency control, and persistence behavior. It is fully adequate for an agent to understand how to use 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?
Schema coverage is 100% with descriptions for both parameters. The description adds meaning by calling the confirmation 'light' and explaining that the lock prevents concurrent refresh, which provides context beyond the schema's field 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 'Refresh a proxy provider by name.' This is a specific verb+resource pair that directly communicates the tool's action and distinguishes it from sibling tools like clash.runtime.refresh_rule_provider, which refreshes rule providers instead.
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: 'Per-provider lock prevents concurrent refresh. Light confirmation required.' This tells the agent when to use it (for proxy providers) and that a confirmation parameter must be true. It does not explicitly state when not to use it, but the sibling distinction is implied.
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 full burden. It discloses color format requirements, font_family restrictions, the preview-to-apply workflow, and what fields are excluded. It does not cover error handling or side effects, but covers the main behavioral traits effectively.
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, well-organized paragraph. Every sentence adds value: field list, constraints, exclusions, workflow, capability. No fluff or repetition.
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 mentions 'structured Diff' but does not detail the output format, and there is no output schema. For a mutation tool with preview, more detail on the Diff structure would improve completeness. Still, it covers essential usage aspects.
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 coverage is 100%, but the description adds crucial context: null restores default state, font_family rejects dangerous characters, and explicitly states what is not opened. This goes beyond schema patterns to guide correct usage.
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 modifies Clash Verge Theme preferences, listing all specific fields (primary_color, secondary_color, etc.). It distinguishes from siblings by noting that 'css_injection and background image paths are NOT opened' and identifies the required capability.
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 explains the two-phase flow (preview then confirm) and the required capability. However, it does not explicitly compare with other preferences tools like configure_layout or set_basic, so the agent lacks guidance on when to choose this tool over alternatives.
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 provided, the description fully discloses the read-only nature, classification behavior, critical regression detection requiring rollback, and the caveat that config write success does not equal optimization success.
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 front-loaded with purpose. Every sentence adds value, and there is no redundant information.
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 explains the classification outcomes and critical regression behavior. Although no output schema is present, it covers the essential return state. It could benefit from specifying the exact result structure.
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 coverage is 100% with descriptions for both params. The description adds value by specifying constraints (same targets, sample counts, timeouts) and implying the arrays must match in structure, though it does not detail the object fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a read-only before/after probe comparison tool that classifies outcomes into four categories. It distinguishes itself from sibling tools by explicitly noting it does NOT execute probes or modify configuration.
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 when having before and after probes, and states what it does not do. However, it lacks explicit guidance on when to use this tool versus other optimization tools like diagnose_network or dns.
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 provided, the description fully covers behavioral traits: it is read-only, performs specific checks, returns a versioned report with findings and proposedActions, and does not modify rules. It also clearly states a limitation (static order analysis cannot prove real traffic hits), providing honest expectations.
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 but packed with essential information: version label, purpose, list of checks, output type, and a key limitation. Every sentence adds value, and the most important information (read-only, diagnosis) 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?
Given the tool's simplicity (no parameters, no output schema in structured data), the description covers what it does and its limitations. It mentions the report contains 'findings and proposedActions,' which gives an idea of the output. It could be slightly more detailed on the report structure, but it is adequate for an agent to understand when to use it.
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 no parameter information is needed. The description adds meaning by explaining the tool's function and what it diagnoses, which is sufficient. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a read-only rules configuration diagnosis tool. It lists specific checks: duplicate rules, invalid proxy references, MATCH position, rule shadowing, and rule count. It distinguishes itself from sibling modification tools by emphasizing it does NOT modify rules, and from other diagnosis tools by focusing on rules specifically.
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 the tool is for diagnosis and does not modify rules, indicating when to use it. It also notes the limitation that static analysis cannot prove real traffic hits, suggesting complementary use with runtime verification. However, it does not explicitly differentiate from siblings like clash.rules.inspect or other optimize tools, but the context is clear enough.
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?
No annotations provided, so description carries full burden. It warns about changing active network configuration, explains the confirmation mechanism and nonce requirement. 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?
Two sentences, front-loaded with purpose, zero waste. Efficiently communicates the two-step process and rationale.
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 4 parameters and two-step process without output schema, description explains the entire flow and parameter roles. Lacks return value details but given no output schema, the description is adequate.
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 coverage is 100%, baseline 3. Description adds value beyond schema by explaining the role of confirmed (preview vs execution) and confirmNonce as one-time nonce, and timeoutMs clamping. Does not repeat 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 'Activate a Profile through Clash Verge itself' with a specific verb and resource. It distinguishes from siblings like list, inspect, etc., which do not activate.
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 describes the two-step confirmation process: first call with confirmed=false to receive a nonce, then retry with confirmed=true and confirmNonce. Explains why (network configuration change). No explicit when-not, but sufficient.
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?
Declares read-only nature and describes return values: 'ruleset fingerprint, paginated rules with per-rule fingerprints, and MATCH position'. No annotation coverage, but description adequately covers behavioral traits.
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?
Four concise sentences with no redundancy. Front-loaded with purpose, then key details, then alternative tool reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, read-only, pagination, source options, section behavior, and alternative tool. Lacks exact return format details but mentions key return elements. Adequate given no output schema.
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?
Adds context beyond schema for 'source' (explains 'rules' source and Verge template), 'section' (which parts), and 'targetProfileUid' (defaults to active, supports inactive). Schema coverage is 100%, but description enhances understanding.
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 clearly states the verb 'inspect' and the resource 'rules' from multiple sources (profile, merge, rules, runtime). It distinguishes from sibling tools like clash.config.get_effective for runtime rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use alternative: 'For runtime rules use clash.config.get_effective with section="rules"'. Also explains source='rules' behavior and section parameter usage.
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 is highly transparent: it declares read-only behavior, what it reads from (Adapter memory and verge.yaml), what it does not do (write, trigger refresh, etc.), and that sensitive fields are excluded. No annotations are present, so the description carries full burden and excels.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is clear and well-structured, though it includes a version number ('v1.1-A') which is not essential. It front-loads the main purpose and then adds detail, making it easy to parse.
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 no parameters and no output schema, the description fully covers what the tool does, what it returns, and what it excludes. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100%. The description adds meaning by explaining what the tool inspects and returns, which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a read-only inspection tool for Clash Verge UI preferences, listing the categories (Basic, Theme, Layout, Hotkeys). It distinguishes itself from sibling tools by emphasizing read-only and no side effects.
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 explicitly states that it does not require write capability and does not trigger GUI refresh or persistence, providing clear context. However, it does not explicitly mention alternative tools for writing or other inspection variants, though the sibling list implies them.
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?
Discloses the entire sequence: snapshot creation, file writing, reload attempt, health checks, and automatic rollback on failure. No contradictions with missing 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?
Single sentence that front-loads the main action and efficiently lists all steps without 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?
Covers all major aspects of the apply transaction—snapshot, write, reload, health checks, rollback—despite no output schema.
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?
Adds meaningful context beyond the schema: confirmed must be true, workspaceId must come from create_workspace and be validated.
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?
Clearly states it applies a validated workspace's changes to the persistent config file, distinguishing it from sibling tools like preview_change, validate_change, and rollback by describing the full apply action.
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 mentions that light confirmation is required (confirmed=true) and that the workspace must be validated, but could be more explicit about prerequisite steps like validate_change.
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 fully discloses behavior: reads merge file or profile, records fingerprints, no file writes, and auto-expires after 5 minutes. This is excellent transparency for a zero-parameter 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?
Three concise sentences, front-loaded with purpose. Every sentence adds value with no redundancy. Highly efficient.
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 no inputs or output schema, the description covers purpose, behavior, and limitations (auto-expire, no writes). It is complete and leaves no ambiguity.
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?
No parameters exist, so baseline is 4. The description adds no parameter information, but none is needed. Schema coverage is 100% (empty).
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 creates a config workspace for previewing/validating changes, specifies what it reads, and notes that no files are written. This is a specific verb+resource with clear scope, distinguishing it from siblings that write or apply 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 explicitly says 'for previewing and validating changes' and notes 'no files are written', providing clear context for when to use. It implies not to use when wanting to persist changes, but does not name alternative tools explicitly.
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 fully covers behavioral traits: read-only, no configuration modification, safe probe targets only (no arbitrary URLs), and return structure (facts, probes, findings, recommendations, proposedActions).
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: first defines purpose and scope, second describes output and constraints. No wasted words, front-loaded with version ID and key safety traits.
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 2 optional parameters, no annotations, no output schema, the description adequately covers behavior, constraints, output structure, and safety. It is sufficient for an agent to select and invoke 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?
Parameter descriptions in schema already explain skipProbes and probeBudgetMs. Description adds value by clarifying that probeBudgetMs is the 'total' budget (default 30000, max 60000) and that probes are 'predefined safe targets', but this is moderate added value over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool performs a read-only network diagnosis, listing specific components checked (Controller, Adapter, DNS, etc.) and output format (versioned report). It distinguishes from sibling optimization tools by emphasizing diagnosis vs. optimization.
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?
Description explicitly says it's read-only, does not modify configuration, and uses safe probe targets. However, it does not directly compare to alternatives like clash.doctor or other optimize tools; usage context is implied but not explicit.
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 explicitly states the tool is read-only and does not modify configuration, which is critical given no annotations. It also discloses the output is a versioned report with findings and proposed actions, providing full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences with no unnecessary words. The version tag adds minor context but does not detract.
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?
Despite having no output schema, the description sufficiently explains what the tool does, what it checks, and what it returns. It is complete for a zero-parameter read-only 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?
There are no parameters, so the baseline is 4. The description adds no parameter information, which is acceptable as 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 it is a read-only diagnosis tool for health-check configuration, listing specific checks and output format. It distinguishes itself from siblings by explicitly stating it does not modify configuration.
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 indicates it is for diagnosing health-check configuration and notes it is read-only, implying it should be used instead of mutation tools. However, it does not explicitly state when to use this tool over other optimize siblings (e.g., diagnose_network, dns).
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?
Description fully discloses read-only behavior, the exact checks performed, and the return structure (versioned report with findings and proposedActions). Also clarifies that node names are not used for geographic inference. No annotations are provided, so the description carries full burden and meets it excellently.
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?
Description is a single paragraph with three sentences, each adding essential information (purpose, checks, disclaimers). No wasted words; front-loaded with the main 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 has no parameters and no output schema, the description provides complete context: what the tool does, what it checks, and what it returns. The disclaimer about node names adds necessary context for an optimization 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?
Input schema has zero parameters, and schema description coverage is 100% (no parameters to document). The description does not need to add parameter info; it correctly focuses on behavior.
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 clearly states it is a read-only diagnosis for proxy groups, listing specific checks (empty groups, invalid references, selection validity, etc.) and the output format. It distinguishes from sibling tools by focusing on proxy groups optimization.
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 notes the tool is read-only and does not modify proxy groups, providing clear usage context. While it does not name alternative tools, the purpose is well-defined and self-contained.
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 fully bears the transparency burden. It explicitly states 'Does NOT modify any configuration' and 'Read-only' upfront. It also enumerates the specific conditions checked for drift (Profile, run mode, etc.), providing complete behavioral insight.
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 sentences, front-loaded with the core purpose, and every sentence adds value: read-only intent, drift comparison details, protocol step, and safety note. No wasted words.
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?
Despite having a nested object parameter and no output schema, the description covers return values (matched=true/false with details), the specific aspects checked, and the action on drift. This is complete for a verification tool, requiring no further elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description merely restates the parameter purpose as 'The baselineFingerprint from the original optimizer report.' It does not add significant meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Read-only baseline drift verification' tool that re-collects the current baseline fingerprint and compares it to the original. It specifies exactly what it does, with a specific verb and resource, and implicitly distinguishes from other optimize tools by focusing on drift detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit protocol step: 'Per v1.0-D protocol step 1: if drift is detected, re-diagnose instead of executing proposedActions.' This provides clear when-to-use and when-not-to-use guidance, and the mention of 're-diagnose' gives actionable context without needing sibling comparison.
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?
Despite no annotations, description discloses that it returns detection, feature flags, and pending transactions, and implies it is a safe read operation by mandating it before writes.
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 with purpose front-loaded and 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?
Complete for a simple read tool with no params; explains necessity and return content, adequate despite missing output schema.
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?
Zero parameters and 100% schema coverage; baseline 4 as no parameter info needed beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get environment capabilities' and specifies it must be called before write tools, distinguishing it from siblings that are write operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'MUST be called before any write tools', providing clear when-to-use instruction with no ambiguity.
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:

[![clash-control-mcp MCP server](https://glama.ai/mcp/servers/huaqing0/clash-control-mcp/badges/card.svg)](https://glama.ai/mcp/servers/huaqing0/clash-control-mcp)

Score Badge

Copy to your README.md:

[![clash-control-mcp MCP server](https://glama.ai/mcp/servers/huaqing0/clash-control-mcp/badges/score.svg)](https://glama.ai/mcp/servers/huaqing0/clash-control-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/huaqing0/clash-control-mcp'

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