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

No annotations exist, so the description carries the full burden. It adds one useful behavioral fact — group mode returns the fastest few nodes — but says nothing about the probe being a slow network operation bounded by timeout, whether it blocks, whether it mutates config, or what failures look like.

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

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

A single sentence, front-loaded with the verb 测延迟, then the two mode branches. No filler, no repetition of schema fields.

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

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

All parameters are optional, so the call is cheap, and the group-mode return ('fastest few') is hinted at. With no output schema, however, the single-node result shape, units, and failure/timeout reporting are left entirely undefined.

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

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

Schema coverage is 100% with per-parameter descriptions for url, name, group, and timeout, so the baseline would be 3. The description goes beyond the schema by establishing that name and group are mode selectors (single node vs whole group), a mutually-exclusive semantic the schema never states.

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

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

The description states a specific verb+resource (测延迟 / latency test) and clarifies the two operating modes keyed on name vs group. No sibling tool (list_proxies, switch_proxy, get_connections, etc.) performs latency probing, so it is naturally distinguishable, though it never explicitly contrasts itself with them.

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

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

It gives concrete routing guidance for its own modes: pass name to test a single node, pass group to test an entire group. That tells the agent which parameter to reach for in which scenario, but it offers no exclusions, prerequisites, or conditions under which the tool should not be used.

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

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

With no annotations, the description carries the full behavioral burden. It conveys that this is a non-mutating view operation ('查看') and lists which config domains are surfaced, but says nothing about return format, whether values reflect live/active state, or whether any permissions are needed.

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

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

A single compact sentence, front-loaded with the verb and resource, followed immediately by the scope of the returned config. No filler or redundancy.

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

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

For a zero-parameter read tool with no output schema, the description usefully enumerates the configuration areas returned, which stands in for a return-value spec. It is nearly complete; the only gap is that '等' (etc.) leaves the exact field set open-ended.

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

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

The tool takes zero parameters, so the baseline is 4. Nothing in the description needs to compensate for undocumented inputs, and the listed config categories act as an informal picture of what the call yields.

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

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

States a specific verb ('查看' / view) and resource ('内核运行配置' / kernel runtime config), then enumerates the configuration areas covered (运行模式, TUN, 混合端口, 局域网共享). This clearly separates it from siblings like get_rules, get_connections, and get_version, though it never names an alternative explicitly.

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

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

Usage is only implied: an agent can infer this is the read path for configuration that pairs with the sibling setters (set_mode, set_tun, toggle_system_proxy). There is no explicit statement of when to call it, when not to, or which sibling to prefer for related data.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It does disclose two useful traits: results are ordered by download volume, and the closeId mode both terminates a connection and suppresses the list. It is silent on permissions required to close a connection, whether the close is immediate/reversible, and rate or refresh considerations.

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

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

One compact sentence front-loads the primary purpose (view connections and traffic stats) and appends the secondary mode (closeId) as a modifier. No padding or repetition; a 5 is withheld only because the dual-purpose nature could be structured slightly more explicitly.

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

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

With no annotations and no output schema, the description should carry more weight. It covers purpose, ordering, and the destructive closeId branch adequately, but says little about what the 'traffic statistics and details' payload contains or what happens on close, leaving gaps for a connection-management tool.

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

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

Schema description coverage is 100% and both parameters (limit, closeId) are documented in the schema itself, so the baseline of 3 applies. The description reinforces closeId's side effect and the list ordering, but adds no syntax, units, or format detail beyond the schema.

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

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

The description states a specific verb and resource: view traffic statistics and details for all current connections, with an explicit ordering (by download volume). That is far more informative than the bare name get_connections. It does not need to differentiate from siblings since none of them (get_configs, list_proxies, set_mode, etc.) deal with live connections, but it also makes no explicit contrast.

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

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

Usage is implied rather than spelled out: the description notes that passing closeId closes the specified connection, which signals the tool's second mode of use. There is no statement of when NOT to use it, no prerequisites, and no reference to any alternative tool for connection handling.

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

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

No annotations are provided, so the description carries the full behavioral burden. '查看' (view) implies a read-only operation, which is some value, but the description says nothing about return shape, ordering, pagination behavior, permissions, or what happens with large rule sets. It largely restates what the schema already shows.

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

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

A single short sentence, front-loaded with the core action and resource. It is efficient, though arguably under-specified rather than optimally concise.

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

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

For a simple two-parameter read tool with full schema coverage and no output schema, this is minimally adequate. It lacks any note on result format or scope of the rule table, but the complexity is low enough that the gap is not severe.

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

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

Schema description coverage is 100%, so both limit (default 50) and search (case-insensitive match on type/payload/proxy) are fully documented in the schema. The description's mention of keyword filtering adds nothing beyond that, so the baseline 3 is correct.

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

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

States a specific verb+resource: viewing the kernel rules table (查看内核规则表), plus notes keyword filtering is supported. It is clear what the tool does, though it does not distinguish itself from any sibling (none of the listed siblings overlap, so no differentiation is strictly needed).

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

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

There is no explicit when-to-use, when-not-to-use, or alternative-selection guidance. The only implied usage is that one calls it to inspect rules; nothing about prerequisites or how it relates to other tools is stated.

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

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

No annotations exist, so the description carries the full disclosure burden. It usefully reveals what the call reports (kernel version plus which transport channel is in use, named pipe vs HTTP), which implies a safe, side-effect-free query, but it says nothing about permissions, latency, or failure modes when the kernel is unreachable.

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

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

A single front-loaded sentence with no filler and no repetition of the tool name. It is appropriately sized for a trivial zero-argument query, though the parenthetical enumeration of channels is the only elaboration offered.

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

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

With no output schema, the description partially compensates by naming the two pieces of information returned. For a no-parameter, read-only diagnostic tool this is nearly sufficient; only the return format (e.g., raw version string vs structured object) remains unspecified.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly adds no parameter detail because there is none to add, and the empty schema leaves no ambiguity.

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

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

The description gives a specific verb (查看) and two concrete resources: the mihomo kernel version and the active connection channel (named pipe / HTTP). That is enough for an agent to distinguish it from siblings such as get_configs, get_connections, or delay_test, though it never explicitly contrasts itself with them.

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

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

There is no statement of when to call this tool, when not to, or which sibling to prefer for adjacent diagnostic needs. The read-only diagnostic intent is only implied by 查看; the agent must infer usage from the name alone.

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

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

With no annotations, the description carries the full disclosure burden. It does useful work by spelling out the return payload (per-group selected node, full candidate list, delay overview), which signals a read-only inspection operation. However, it never explicitly states that it is non-mutating, and says nothing about latency of the call, caching, or whether delays are fetched live.

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

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

A single compact sentence with the core action front-loaded (list all proxy groups) followed by the parenthetical detail on contents. Every clause earns its place and there is no filler.

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

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

There is no output schema, so the description must describe the return shape itself, and it does so reasonably well: groups, selected node, candidate nodes, and delay overview. For a zero-parameter read tool with no annotations this is nearly sufficient; only the explicit read-only nature and live-vs-cached delay semantics are missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The description correctly avoids inventing parameter behavior.

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

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

The description gives a specific verb ("列出" / list) and resource ("所有代理组" / all proxy groups), then goes further by enumerating what each entry contains: the currently selected node, all candidate node names, and a delay overview. That level of detail makes the tool distinguishable from action-oriented siblings like switch_proxy or delay_test. It stops short of explicitly naming a sibling or contrasting scope, so it is not a 5.

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

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

Usage is only implied: an agent can infer this is the inspection call to run before switch_proxy or delay_test, but the description never states when to use it, when not to, or what alternative to prefer. No prerequisites or context conditions are given. This is the minimum viable level rather than genuine routing guidance.

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

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

No annotations are provided, so the description carries the full disclosure burden. It goes some way by defining what each mode actually does (rule-based routing vs global proxy vs direct), which is genuinely behavioral rather than a name restatement. However, it says nothing about persistence, whether the switch takes effect immediately, connection interruption, or configuration requirements.

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

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

A single line, front-loaded with the action, followed by a compact enumeration of the three values. Every token carries information; nothing is padding.

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

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

For a one-parameter enum tool the description covers the value space well, but with no annotations and no output schema it leaves out the behavioral facts an agent needs (does the change persist? does it apply live?). Adequate but with clear gaps given zero structured support.

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

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

Schema description coverage is 0%, so the description must compensate for the bare enum — and it does, translating each of rule/global/direct into its meaning for the kernel. This is exactly the value the schema lacks. It stops short of stating the parameter name explicitly or any default/fallback behavior, keeping it below a 5.

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

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

States a specific verb+resource ('切换内核运行模式' = switch kernel running mode) and immediately disambiguates the operation by defining all three mode values. An agent can see this is a mode-setter, distinct from siblings like set_tun, toggle_system_proxy, and switch_proxy, though the description never explicitly contrasts itself with them.

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

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

The description explains what each mode means but gives no guidance on when to switch modes, which sibling to use instead (e.g., set_tun vs toggle_system_proxy vs set_mode), or any preconditions. The agent must infer all usage context from the mode semantics alone.

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

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

With no annotations, the description carries the full disclosure burden. It adds a genuinely useful side-effect warning (Verge may restore its UI settings after a subscription reload), which is behavioral context beyond the schema. However, it omits permissions required, reversibility, and any indication of the response, so it only partially compensates for the absence of annotations.

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

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

Two short sentences, front-loaded with the action and followed by the caveat. No filler, though it is terse to the point of omitting useful detail.

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

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

For a single-boolean toggle with no output schema and no annotations, the definition covers the core action and one important caveat, which is minimally adequate. It leaves gaps around the parameter's meaning and operational prerequisites.

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

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

There is one boolean parameter (enable) with 0% schema description coverage. The word '开关' (toggle/switch) implies on/off semantics for the boolean, providing marginal information, but the description never names or explains the enable parameter or what true/false means.

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

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

States a specific verb (toggle/switch) and resource (TUN virtual network adapter mode), which is concrete enough for an agent to know exactly what changes. It does not explicitly contrast itself with similar siblings like set_mode or toggle_system_proxy, but the TUN-specific resource makes it distinguishable.

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

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

No guidance on when to enable vs disable TUN, nor when to prefer this over set_mode or toggle_system_proxy. The cautionary note implies a usage caveat but does not function as when/when-not guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden and it does not meet it. It never states persistence, whether the change is immediate, what happens if the node name is stale or the group is missing, or what a failure looks like. Only the bare mutation intent is conveyed.

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

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

A single front-loaded sentence with no filler, verb and target up front. It is efficient, though the terseness means information is omitted rather than compressed.

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

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

The tool is simple (two fully documented required params, flat object), so a one-line description is close to sufficient. However, with no annotations and no output schema, the description should have covered at least the post-switch effect and error conditions; those gaps keep it at minimum viable.

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

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

Schema description coverage is 100%; both 'group' and 'name' are documented in the schema, including the important constraint that the name must appear in the group's 'all' list. The description adds no format, casing, or naming detail beyond what the schema already supplies, so the baseline 3 is correct.

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

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

States a specific verb (切换/switch) and resource (某个代理组的当前选中节点), so the agent knows exactly what state is being modified. It does not name any sibling such as list_proxies or delay_test, so differentiation is left to inference.

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

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

Usage is implied: you call this to change which node a proxy group currently uses. There is no explicit when-to-use/when-not guidance, no mention of prerequisites (e.g. obtaining valid group and node names first) and no reference to alternatives, so an agent must infer the workflow.

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

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

With no annotations, the description carries the full burden and does disclose the important side effect (writes the registry and notifies applications), which is genuinely valuable. It omits other behavioral facts such as whether elevation is required, whether the change is reversible, and what is returned.

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

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

Two tight sentences that front-load the action and its mechanism, then the parameter default. No filler.

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

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

For a two-parameter, zero-annotation mutation tool with no output schema, the description covers the core mechanics and the key default, but leaves permission requirements, platform constraints, and result/feedback behavior unstated.

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

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

Schema coverage is 50%: 'port' is documented in the schema, and the description compensates for the undocumented 'enable' parameter by explaining the flip-on-omission default. The one remaining gap is that it doesn't state the default port behavior in the description itself, but the schema covers that.

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

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

States a specific verb and resource: toggling the Windows system proxy, and notes the mechanism (registry edit plus notifying apps). It is clearly distinct from siblings like set_tun or set_mode, though it never names an alternative explicitly.

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

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

Gives one useful conditional: omitting 'enable' flips the current state. However, it offers no guidance on when to prefer this over set_tun/switch_proxy, nor any prerequisites such as requiring Windows or elevated permissions.

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