iKuai MCP Server

by gxxHuang

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation1/5
With 229 tools, many have overlapping purposes such as multiple get/list monitoring tools (get_line_monitoring, get_terminal_list, get_load_monitoring) and numerous log retrieval functions. Duplicate tools like get_ddns_config and get_dynamic_dns_config further confuse selection, making it nearly impossible for an agent to reliably distinguish between them.
Naming Consistency3/5
The majority of tools follow a verb_noun pattern (list_*, get_*, add_*, delete_*, set_*, toggle_*), but the choice between get_ and list_ is inconsistent (list_wan_configs vs get_wan_status). Outliers like kick_pppoe_user, wake_on_lan, subnet_calculator, and change_admin_password deviate from the pattern, though overall naming remains readable.
Tool Count1/5
229 tools is drastically excessive for an MCP server. Even for a comprehensive router management system, this volume overwhelms agents and violates the principle of a well-scoped toolset, far exceeding the 3-15 tool sweet spot.
Completeness4/5
The toolset thoroughly covers router domains: interfaces, VPN, DHCP, DNS, routing, NAT, firewall, QoS, logs, and system utilities. However, many resources lack update/modify operations (e.g., VLAN, DHCP static bindings, IP groups), and the presence of duplicates suggests minor workflow gaps.
Average 3.2/5 across 229 of 229 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 18 commits in the last 12 weeks
- Last stable release on July 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'configure DMZ host' and gives no information about side effects (e.g., exposing an internal IP to the WAN), requirements, or whether the operation is a toggle or full update. This is a potentially destructive network change with zero disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single brief sentence, which is concise in length but severely under-specified. It lacks any structure that would help the agent parse key information, and it simply restates the tool name in Chinese rather than providing a useful summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this tool modifies network configuration, has three undocumented params, and relies entirely on the description for context, a one-line restatement of the name is completely inadequate. It fails to provide the information needed to invoke the tool safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has three parameters (enabled, interface, internal_ip) with no descriptions and 0% schema coverage. The description does not compensate by explaining any of these parameters, leaving the agent without any semantic understanding of what values are expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '配置 DMZ 主机' (Configure DMZ host) states a verb and resource, but it is essentially a literal restatement of the tool name 'set_dmz'. It does not clarify what specific aspects of the DMZ host are configured (e.g., enable/disable, which interface, which IP), nor does it differentiate from other configuration tools beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as checking the current config via get_dmz_config, nor does it explain under what conditions a user might need to set a DMZ host.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without explaining side effects, required permissions, how the limit is applied (e.g., per MAC or IP), or whether it overwrites existing rules. This is a serious gap 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but not in a useful way. A single phrase that merely restates the tool name wastes the opportunity to add value and is under-specified for a tool with six parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (six parameters, no annotations, no parameter descriptions), the description is completely inadequate. It does not address return values, error conditions, or interaction with existing connection limit rules, making it nearly impossible for an agent to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining any of the six parameters. The agent must infer the meaning of 'mac', 'ip_addr', 'time_range', and 'max_connections' solely from their names, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '添加连接数限制' translates directly to 'Add connection limit', which is a restatement of the tool name 'add_connection_limit'. It provides no additional context about scope, behavior, or how it differs from other 'add_*' sibling tools, making it essentially tautological.
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 guidance is provided. The description does not indicate when to use this tool versus related tools like 'delete_connection_limit' or 'list_connection_limits', nor does it mention any prerequisites or context for adding a connection limit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'add custom URL library' with no details about side effects, idempotency, required permissions, error behavior, or what happens on duplicate libraries. This is a significant gap 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than concise. It consists of a single phrase that adds no value beyond the tool name. It is not appropriately sized for a meaningful tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and no schema descriptions, the description is grossly incomplete. It does not explain return values, expected input formats, or how this tool fits into the broader workflow. The output schema exists but the description does not leverage it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the parameters (name, comment, domains). The agent cannot infer what these fields mean, their formats, or how they relate to each other from the description alone. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '添加自定义网址库' is a direct translation/restatement of the tool name 'add_custom_url_library'. It repeats the name without adding any specific detail about the resource or action beyond what the name already communicates. There is no distinction from sibling tools like 'add_url_blacklist' or 'add_domain_blacklist'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclusions. The agent is left without any information about when this tool should be preferred over similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It simply states the action without mentioning side effects, requirements, or implications such as whether the mapping is persistent, whether it affects existing mappings, or if it requires specific network conditions. This is a significant gap for an add operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise in length, but it does not earn its place: it merely restates the tool name. This is under-specification rather than effective conciseness, similar to the 'process' calibration example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, no annotations, and a minimal description, yet the description fails to provide any operational context. While an output schema exists, the description is far from complete for an agent to invoke the tool correctly. It leaves all aspects of configuration, constraints, and expectations unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameter meanings or relationships. It does neither—there is no mention of any parameter, and the required fields (name, internal_ip, internal_port, external_port) are completely unaddressed. The agent is left to guess what values to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "添加端口映射" is a direct translation of the tool name 'add_port_mapping', essentially restating the title without adding specificity. It does not distinguish this tool from sibling tools like add_port_forwarding_rule or provide any detail about what a port mapping entails.
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. There is no mention of prerequisites, suitable scenarios, or exclusions. The agent is left without any contextual hints to choose between this and similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states '添加 VPN 账号' without revealing any behavioral traits such as whether the operation is idempotent, requires specific permissions, overwrites existing accounts, or affects VPN server configuration. This leaves the agent blind to the tool's 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. A single phrase that merely repeats the tool name does not earn its place; it offers no substantive information. The lack of any additional structure or detail makes it inadequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters (three required) and no annotations, the description is severely incomplete. It does not explain what the parameters do, what the return value represents (despite an output schema existing), or any contextual details such as supported VPN types or usage scenarios. This is insufficient for an AI agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema includes five parameters (comment, ip_type, password, username, vpn_type) with zero schema description coverage. The description does not mention any of these parameters or their meaning, failing to compensate for the lack of schema descriptions. Parameter names are somewhat self-explanatory, but the description adds no value beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '添加 VPN 账号' is a direct translation of the tool name 'add_vpn_account', essentially restating the name without adding any specific detail about what the tool does. It does not differentiate the tool from other 'add_*' operations like add_pppoe_account or add_admin_account, nor does it mention the VPN types or context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, constraints, or exclusions, leaving the agent without usage context. The name implies adding VPN accounts, but there is no explicit instruction or differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for disclosing the destructive nature of a delete operation. It gives no information about irreversibility, required permissions, or side effects, leaving the agent unaware of the operation's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but under-specified rather than concise. While it is a single sentence, it omits all operational details, making it more of a placeholder than an informative description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete tool with one parameter and no annotations, the description should at least state what a DDNS record is and that the operation removes it. The minimal phrase provides no context, leaving the tool's behavior entirely ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (record_id) with zero description coverage, and the description does not mention it at all. The agent cannot infer what record_id represents or how to obtain it, as the description adds no semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除 DDNS' is a direct translation of the tool name 'delete_ddns', essentially restating the name without adding specificity. It fails to clarify what DDNS refers to or distinguish it from similar delete tools, making it a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like delete_acl_rule or delete_static_route. The description provides no context about prerequisites, such as whether a DDNS configuration must exist, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits. It does not mention whether the deletion is permanent, whether confirmation is needed, or what consequences occur. The description simply repeats the action without adding useful 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than good conciseness. It omits essential information about the tool's scope and parameters, so the single sentence does not 'earn its place' as a complete explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with one parameter and no annotations, the description is incomplete. It does not explain the relationship to domain blacklisting, what the deletion affects, or any expected return values. An output schema exists but the description does not leverage it or add complementary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the rule_id parameter at all. It fails to clarify what rule_id refers to, how to find it, or its significance, leaving the sole parameter semantically unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says '删除禁止娱乐网站' (Delete prohibited entertainment websites), which specifies a verb and a resource, but the resource is misleadingly specific. The tool name indicates it deletes domain blacklist entries generally, not just entertainment websites. It does not distinguish from similar tools like delete_url_blacklist, and the narrowed wording creates confusion about the actual scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no indication of how to obtain the required rule_id. It merely states a single action without any contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It only says 'delete' without mentioning whether the deletion is permanent, what happens to associated data, or whether specific permissions are required. This is a significant gap 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse (8 characters). While concise, it is under-specified and fails to provide essential information. This is not effective conciseness but rather a lack of specification, similar to the 'Process' example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation, the description is woefully incomplete. It lacks prerequisites (e.g., rule must exist), scope clarification (black vs. white list), and any mention of return value or error handling. Despite the low complexity, the description does not enable correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter, rule_id, but the description does not mention it at all. Schema description coverage is 0%, so the description fails to compensate. The parameter name is self-explanatory, but no context is added about where to find the rule_id or how it relates to the list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete URL black/white list' which is ambiguous—'黑白名单' can mean both blacklist and whitelist, yet the tool name is specifically 'delete_url_blacklist'. It does not distinguish from sibling tools like delete_domain_blacklist or explain whether it affects both lists. The verb and resource are present but the scope is unclear and potentially misleading.
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. There is no mention of how it relates to list_url_blacklist or add_url_blacklist, nor any exclusions or prerequisites. The description simply states the action without any contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only says 'delete', which is already in the tool name. It does not explain whether deletion is immediate, whether it requires confirmation, what happens if the rule_id does not exist, or any side effects. This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise in length, but it is under-specified—it merely repeats the tool name. It does not earn its place by adding any useful information, making it an under-specification rather than a model of conciseness.
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?
While an output schema exists (so return values need not be explained), the description is still incomplete for a delete operation. It lacks context about what an ACL rule is, how to find the rule_id, and what the consequences of deletion are. The surrounding sibling tools (list_acl_rules, add_acl_rule, toggle_acl_rule) are not referenced, leaving the description insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, rule_id, and the description does not mention it at all. Schema description coverage is 0%, so the description was expected to compensate by explaining what rule_id refers to or how to obtain valid values. It provides no such meaning, leaving the parameter semantics entirely to the schema's property name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除 ACL 规则' directly restates the tool name 'delete_acl_rule' in Chinese, making it a tautology. It states the action (delete) and resource (ACL rule), but adds no new information beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like add_acl_rule or toggle_acl_rule. The description does not mention prerequisites, such as how to obtain a rule_id via list_acl_rules, nor any conditions under which deletion is appropriate.
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 provided, the description carries the full burden of behavioral disclosure. It merely states 'Add DDNS' without explaining side effects, required permissions, validation behavior, or the structure of the created resource. This is insufficient for a mutation tool with 6 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It fails to use the available space to convey necessary information, making the tool effectively undocumented.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 6 parameters (4 required), no annotations, and an output schema that is not described. The description adds no context about error handling, success indicators, or how this DDNS addition fits into the broader network configuration. It is wholly inadequate for a create operation in a complex system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no descriptions for the 6 parameters. The description offers no parameter explanations, making it impossible for an agent to know what 'provider', 'interface', or 'enabled' mean or how they relate to DDNS configuration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '添加 DDNS' is a direct Chinese translation of the tool name 'add_ddns', restating the name without adding any detail. It does not specify what DDNS means or what resource is being added, failing to distinguish it from siblings like get_ddns_config or delete_ddns.
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 such as get_ddns_config or delete_ddns. There is no mention of prerequisites, use cases, or exclusion scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior, but it only states the action of adding. It doesn't mention side effects, required domain_groups, scheduling parameters (weekdays/time_range), or whether it replaces existing entries. This is essentially a restatement of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase that is under-specified. It does not waste words, but it also fails to provide necessary information, making it more of a placeholder than a concise, informative description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters (1 required), no annotation context, and an output schema not shown, the description is severely incomplete. It provides almost no guidance for correct usage, leaving the agent to guess parameter meanings and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain any of the 5 parameters, including the required domain_groups. There is no semantics added beyond property names and defaults, so the agent cannot understand how to properly invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '添加禁止娱乐网站' translates to 'Add prohibited entertainment website', which conveys adding a blacklist entry for entertainment sites. However, it doesn't explicitly mention 'domain blacklist' or domain_groups, and could be confused with the sibling add_url_blacklist. It's specific enough to indicate an add operation on a blacklist for entertainment websites, but lacks precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like add_url_blacklist or list_domain_blacklist. The description provides no context for selection or exclusions.
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 available, the description must disclose behavioral traits itself. It only states the generic action 'add' and does not mention side effects, permissions, idempotency, or interaction with existing rules. The mutation nature is implied but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-line description is short but under-specified rather than concise. It amounts to a restatement of the tool name and lacks structure or essential details. For a tool with 5 parameters, this brevity is insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for a tool with 5 parameters, no annotations, and no explanatory schema text. It provides no context on parameter roles, expected outcomes, or usage scenarios, leaving an AI agent without the necessary information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description was expected to compensate by explaining the 5 parameters. It does not mention any parameter names or meanings, leaving fields like 'src_addr' and 'interface' ambiguous. The description adds zero semantic value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '添加域名分流规则' is a direct translation of the tool name add_domain_forwarding_rule, restating the action and resource without adding any new information. It fails to distinguish itself further from sibling tools beyond what the name already implies.
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 such as list_domain_forwarding_rules or delete_domain_forwarding_rule. The description lacks context about prerequisites, scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits. It only says 'Add ACL rule', which implies mutation but provides no details about side effects, required permissions, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification for a tool with 11 parameters. It is not an example of concise writing adding value; rather, it is an absence of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of annotations, the description is grossly incomplete. It provides no context for the rule structure, parameter meaning, or usage, making it insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 11 parameters, but the description does not explain any of them. With 0% schema description coverage, the description adds no value beyond the bare schema, leaving the agent to guess parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Add ACL rule' which is a clear verb+resource, distinguishing it from siblings like delete_acl_rule and list_acl_rules. However, it lacks any additional context about the rule's scope or behavior, so it does not fully achieve the highest level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool, what prerequisites are needed, or how it compares to alternatives such as toggle_acl_rule or list_acl_rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral details. With no annotations provided, it fails to disclose expected side effects, permission requirements, or behavior on duplicate usernames, leaving the agent to guess.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is concise but lacks substance. It repeats the tool name and provides no added value, so it fails to earn its place as a meaningful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that creates an admin account with four parameters and no annotations, this description is severely incomplete. It lacks any detail about the operation's effect, prerequisites, return values, or error conditions, making it inadequate for reliable invocation.
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 covers all four parameters with descriptions, so the baseline is 3. The description does not add any parameter-level information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '添加管理员账号' (Add administrator account) restates the tool's name without any additional detail. It does identify the action and resource but offers nothing beyond what the name already conveys, making it essentially a tautology.
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 like list_admin_accounts or change_admin_password. The description only states the action, with no context on prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the basic add operation without mentioning effects such as whether it overwrites existing rules, requires specific permissions, or has any side effects. This is a significant omission 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse (a single short phrase), but this is under-specification rather than appropriate conciseness. It omits essential context, making it insufficient for an agent to understand the tool's usage. Every word is functional, but the content is too sparse to earn a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, output schema, many sibling tools), the description is completely inadequate. It does not explain the tool's role within the broader API, the meaning of its parameters, or expected behavior, leaving an agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description does not explain any of the five parameters (ip_addr, upload_kbps, download_kbps, etc.). The description adds no meaning beyond the schema's bare parameter names and types, failing to compensate for the lack of documentation.
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 '添加 IP 限速' (Add IP speed limit) clearly states the action (add) and the resource (IP speed limit), making the tool's purpose understandable. It distinguishes itself from siblings like add_mac_speed_limit by specifying IP, but this distinction is already inherent in the tool name, so the description adds little beyond a direct translation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. There are closely related sibling tools (add_mac_speed_limit, delete_ip_speed_limit, list_ip_speed_limits) that could benefit from usage context, but none is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it does not. It only says 'add' without explaining potential side effects, required permissions, or behavior on duplicate names or invalid input. This is a significant transparency gap 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is structurally concise, but it is under-specified. It provides no additional detail or context, making it more of a near-tautology than a helpful summary. The brevity does not add value beyond restating the tool's name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and no annotations, the description is far from complete. It does not explain the expected input format, the purpose of the group, or any behavioral nuances. While an output schema exists, the description still needs to set context for the operation, which it fails to do.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the parameters (name, comment, mac_list). It does not explain the format of 'mac_list' or the meaning of 'comment', leaving the agent to guess. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: adding a MAC address group. It uses a specific verb ('add') and resource ('MAC group'), making the primary purpose unambiguous. However, it does not differentiate from sibling tools like 'add_ip_group' or 'add_mac_access_control', so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, intended use cases, or scenarios where another tool would be more appropriate. It only states the bare action, leaving the agent without context for selection.
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 disclosure. It only states the delete action, omitting irreversibility, side effects, or permission requirements, offering no useful behavioral insight beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single terse sentence, which is concise but not effective. It is under-specified and does not earn its place by adding value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with one unannotated integer parameter and no behavioral disclosure, the description is critically incomplete. It does not clarify the meaning of group_id, the deletion scope, or any consequences, leaving the agent without adequate context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the group_id parameter at all. With schema description coverage at 0%, the description fails to compensate by explaining what group_id signifies or how it relates to the deletion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除自定义网址库' is a direct translation of the tool name 'delete_custom_url_library', providing no additional information. It is a tautology that restates the name without distinguishing from sibling tools beyond the verb itself.
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 gives no guidance on when to use this tool, what prerequisites are needed, or alternative tools. It simply states the action with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose behavioral traits. It only says 'delete' without explaining consequences, reversibility, or required permissions, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but severely under-specified. It is a minimal translation of the tool name, closer to the 'Process' example than to a helpful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description lacks essential context about when to use the tool, what rule_id refers to, and behavioral implications. The description is inadequate for a simple but destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema shows one required parameter (rule_id) with 0% description coverage. The description does not mention the parameter or add any meaning beyond the schema, failing to compensate for low coverage.
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 '删除 IP 限速' translates to 'Delete IP speed limit', clearly indicating the verb and resource. However, it does not distinguish this tool from siblings like delete_mac_speed_limit, so it misses the higher bar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description provides zero context for usage.
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 the full burden of disclosing behavioral traits. It only says 'delete', which implies a destructive action, but it does not mention irreversibility, impact on active rules, or any required permissions. The description adds no behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (four Chinese characters), but this is under-specification rather than conciseness. It fails to provide any useful structure or elaborated meaning, essentially duplicating the tool name in another language.
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?
Given the simple delete operation, the description still does not explain what rule_id refers to, what happens after deletion, or whether there are any side effects. The presence of an output schema is not leveraged, and the description remains inadequate for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, rule_id, with no textual description (0% schema description coverage). The description does not mention rule_id or explain how to identify the MAC speed limit rule to delete. Since the description was expected to compensate for the missing parameter details, this is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除 MAC 限速' translates directly to 'Delete MAC speed limit', which is a tautological restatement of the tool name. It does not add any distinguishing information beyond what the name already conveys, nor does it differentiate the tool from similar siblings like delete_ip_speed_limit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when this tool should be used versus alternatives. The description does not mention any context, prerequisites, or exclusions. An agent would have no basis for selecting this tool over related delete operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to disclose that this is a security-sensitive mutation, that the old password is required for verification, or that confirm must be set to true. Zero 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is a case of under-specification rather than conciseness. The single sentence does not earn its place because it simply restates the tool name in another language and omits critical context. Structure is absent.
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?
Given that this is a security-sensitive account management operation with no annotations, the description is severely incomplete. While an output schema exists and parameters are documented, the description fails to provide any context about the operation's impact, prerequisites, or confirmation requirements. The agent cannot understand the tool's purpose or behavior beyond the name.
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% since each parameter (old_password, new_password, confirm) has a description. The tool description itself adds no parameter semantics, but the baseline of 3 applies because the schema fully documents the parameters. The confirm parameter's 'must be set to True' is present in the schema, not the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '修改管理员密码' is a direct translation of the tool name 'change_admin_password' and provides no additional information. It restates the name, making it a tautology rather than a distinct purpose statement. It does not distinguish the tool from sibling tools like add_admin_account.
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 offers no guidance on when to use this tool versus alternatives. It does not mention scenarios, prerequisites, or exclusions. The agent is left to infer usage solely from the name.
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 only states 'Delete MAC access control' without mentioning permanence, side effects, permissions, or reversibility. The destructive nature is implied but not explicitly addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and under-specified. While it is concise in word count, the single sentence merely repeats the tool name and adds no value. It does not earn its place because it offers no useful information beyond the identifier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with one parameter and an output schema, the description is incomplete. It lacks detail on expected return values, error conditions, and any prerequisites. The minimal description leaves the agent without sufficient context to invoke the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% as the description makes no reference to parameters. The sole parameter 'rule_id' is left undocumented, and there is no explanation of how to obtain it (e.g., from list_mac_access_control). The parameter name is self-explanatory but insufficiently contextualized.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除 MAC 访问控制' (Delete MAC access control) is a direct restatement of the tool name itself. It provides a verb and resource but adds no additional specificity or distinction from sibling tools like delete_acl_rule. This is a tautology.
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. There is no mention of how it relates to list_mac_access_control or add_mac_access_control, nor any prerequisites or exclusions. The description is purely declarative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that the SSID is modified but gives no indication of side effects, radio band behavior, persistence, or whether clients will be disconnected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and lacks any structured detail beyond a single phrase. It is not verbose, but it is so minimal that it provides little value over the tool name itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and an output schema, this description is inadequate. It does not clarify the radio parameter, the effects of changing the SSID, or what the output represents, making it insufficient for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'ssid' or 'radio' parameters. The meaning of 'radio' and its default '2g' are left entirely to the schema, which lacks descriptions.
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 '修改 Wi-Fi SSID' clearly identifies the action (modify) and resource (Wi-Fi SSID), which distinguishes it from sibling tools like set_wifi_password or toggle_wifi. It is specific and unambiguous, though it does not elaborate on the meaning or scope beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. The description is only a verb phrase with no context, prerequisites, exclusions, or mention of related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description fails to mention that this tool likely performs a network speed measurement, which may consume bandwidth, take time to complete, or require specific permissions. It also does not indicate whether the operation is read-only or potentially disruptive, leaving the agent with no behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, consisting of only five Chinese characters. While concise in word count, it is under-specified rather than effectively concise; it omits essential context and detail, so it fails to earn its place as a useful description.
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 one optional parameter and an output schema present, the tool is not highly complex, but the description is insufficient for an AI agent to understand the tool's role, behavior, or expected results. It lacks information about the test duration, metrics returned, and whether the tool is suitable for recurring diagnostics, leaving the agent guessing in a context with many similar diagnostic tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a 100% description coverage for the single 'interface' parameter, including its default value 'wan2'. The tool description adds no additional parameter meaning, so the baseline of 3 is appropriate since the schema handles the semantic burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '执行线路测速' translates to 'Execute line speed test', which essentially restates the tool name 'speed_test' with only minimal added context ('line'). It does not specify what metrics are tested (upload/download/latency), the scope of the test, or how it differs from the sibling 'iperf_test', making it closer to a tautology than a clear purpose statement.
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 guidance is provided. The description does not indicate when to use this tool versus other diagnostic siblings like ping_test, traceroute, or iperf_test, nor does it mention any prerequisites, frequency, or scenarios where speed_test is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It fails to mention whether existing bindings are overwritten, input validation rules, side effects, or required permissions. The phrase '添加 ARP 绑定' reveals nothing about behavior beyond the operation itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It merely restates the tool name in natural language and does not earn its place by adding value. A good concise description would include key usage or parameter hints within one or two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter mutation tool with no annotations, the description is completely inadequate. It does not mention expected return values, error conditions, side effects, or the relationship to other ARP binding tools. The presence of an output schema does not excuse the lack of contextual information about the operation's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. However, it provides no additional meaning for the ip, mac, or comment parameters. The schema already lists names and types; the description does not clarify formats, constraints, or purpose of the comment field.
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 '添加 ARP 绑定' clearly states the action (add) and the resource (ARP binding). It distinguishes from sibling tools like list_arp_bindings and delete_arp_binding by focusing on the add operation. However, it does not elaborate on what an ARP binding entails or why it is used.
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 such as add_dhcp_static_binding or add_mac_access_control. There is no mention of prerequisites, scenarios, or exclusions. It simply states the operation without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'add' without describing side effects, duplicate handling, authorization needs, or how the mode parameter affects behavior. This is severely lacking 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is superficially concise, but it is under-specified and omits critical details. This is not effective conciseness; it is an incomplete stub.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no annotations, and a one-line description, the tool is far from contextually complete. The existence of an output schema does not compensate for missing parameter semantics, usage guidelines, or behavioral expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no information about any of the 6 parameters (url, mode, week, comment, enabled, time_range). The description fails to compensate for the undocumented schema, leaving agents without essential parameter semantics.
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 the specific verb '添加' (add) and the resource '网址黑白名单' (URL black/white list), clearly indicating an add operation. This differentiates it from sibling tools like list_url_blacklist and delete_url_blacklist, though it does not explicitly explain how the black/white mode is selected.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites, constraints, or black/white selection context. The single sentence provides no usage direction.
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?
The description adds no behavioral context beyond the readOnlyHint annotation. It does not describe what data is returned, whether the operation is a simple read, or any scope limitations. The annotation covers the read-only nature, but the description offers no additional insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but it is not effectively concise; it sacrifices clarity for brevity. While it is front-loaded, it is under-specified and provides minimal informational value.
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?
Given the tool has no parameters and an output schema exists, the description should at least clearly state the tool's purpose. The current description is ambiguous and does not equip an agent to understand what this tool does, despite the simplicity of the 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, so there is no parameter meaning to explain. The baseline score of 4 applies as the absence of parameters eliminates the need for additional documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取总账管理' loosely translates to 'get general ledger management', which is vague and does not clearly convey that the tool retrieves a billing summary. It fails to specify whether it returns a summary, a report, or a management interface, and does not differentiate from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 or how it differs from alternatives. There is no mention of use cases, prerequisites, or exclusions, leaving the agent without context for selection.
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 full responsibility for behavioral disclosure. It only says 'configure SNMP' without mentioning side effects, whether it enables/disables SNMP, or any impact on monitoring. This is insufficient for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, almost terse. It lacks structured information and does not earn its place as a helpful specification; it is under-specified rather than concise.
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?
Given the tool's simplicity, a short description could suffice, but without annotations, parameter explanations, or usage context, it is incomplete. The presence of an output schema does not compensate for the lack of behavioral and parameter information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning for the parameters 'enabled' and 'community'. It does not mention what these parameters control or how they relate to SNMP configuration, leaving the agent without any semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '配置 SNMP' means 'Configure SNMP', which identifies the resource and action but is vague. It does not specify what aspects are configured (e.g., enable/disable, community string), nor does it explicitly distinguish from sibling get_snmp_config.
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. The sibling get_snmp_config implies a get/set pair, but the description does not state any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description only restates the action implied by the name. It does not disclose that the deletion is permanent, may disrupt traffic, or any other behavioral consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It omits essential context about the operation's effects and parameter source.
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?
Although the tool is simple and an output schema exists, the description lacks enough context for an agent to use it confidently. It doesn't mention that the rule must already exist, how to find the rule_id, or any side effects, so the description is not complete for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single required integer rule_id with no description, and schema description coverage is 0%. The tool description does not explain what rule_id references or how to obtain it, leaving the parameter entirely unsupported.
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 indicates deleting a port forwarding/diversion rule, matching the tool's name and distinguishing it from add/list counterparts. It is specific enough, but it doesn't explicitly differentiate from similar delete tools like delete_port_mapping.
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 guidance is provided. The description does not mention when to use this tool versus alternatives, nor does it indicate that rule_id should be obtained from list_port_forwarding_rules first.
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?
The readOnlyHint annotation indicates a safe read operation, but the description itself adds no behavioral context beyond the verb 'get'. It does not describe what records are returned, how they are scoped, or any side effects. With annotations present, the lack of additional disclosure is a missed opportunity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but provides no substantive information; it is under-specified rather than concise. It is simply the name translated, so it does not earn its place as a helpful explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, the description still fails to convey what 'optimization records' refers to in the router domain. It lacks any domain context, and with sibling tools like get_ap_optimization and get_system_overview, agents cannot confidently select this tool. The presence of an output schema is insufficient without a meaningful description.
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 accepts zero parameters, so the schema fully covers parameter semantics (100% coverage, no required fields). According to the rubric, zero parameters warrant a baseline of 4. The description correctly offers no irrelevant parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取优化记录' literally translates to 'get optimization records', which is a direct restatement of the tool name. It identifies the resource but does not specify what kind of optimization (e.g., AP, WiFi, performance) or distinguish it from sibling tools like get_ap_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?
There is no guidance on when to use this tool versus alternatives. Among dozens of sibling getters, no context is provided to indicate the appropriate use case or scenarios to avoid.
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?
The readOnlyHint annotation is present and the description simply says 'get', which is consistent. However, the description adds no behavioral context beyond the annotation, such as what settings are returned or any dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it merely restates the tool name. It is under-specified and does not earn its place by adding useful information.
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?
Given the presence of a closely related sibling (get_upnp_status), this description is insufficient to disambiguate. There is no mention of what constitutes 'settings' versus 'status', and the output schema is not referenced. The tool description should provide more context, but it provides almost none.
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 doesn't need to explain parameters, and the baseline for 0-param tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a direct translation of the tool name (get_upnp_settings = 获取 UPnP 设置), which is a tautology. It names a verb and resource but does nothing to distinguish it from the similar sibling get_upnp_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 like get_upnp_status. The absence of any explanatory text leaves the agent to guess 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral details. It only says 'kick offline' but fails to explain side effects, irreversibility, permission requirements, or impact on the user's session. This is inadequate for a mutating action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It omits critical information while not adding any explanatory value beyond the tool name.
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?
Even though the tool has a single parameter, the description is incomplete: it lacks information about expected input, output, errors, or relation to PPPoE online users. The presence of an output schema is not enough to compensate for the missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'username' has no schema description and the description does not clarify what format or type of username is expected (e.g., PPPoE account name, session ID). With 0% schema coverage, the description fails to compensate.
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 (kick offline) and the target (specified user), aligning exactly with the tool name kick_pppoe_user. It is specific and distinct from sibling tools like list_pppoe_online_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, prerequisites (e.g., listing online users first), or how it differs from other user-management tools. Users are left to infer the intended context.
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 behavior. It simply states 'set' without explaining effects such as whether existing sessions are disrupted, whether the change requires a reboot, or how force_https affects the ports. This is a critical gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although brief, the description is under-specified and merely repeats the tool name. It fails to provide any additional context, making it an unjustified one-liner rather than a concise informative summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that modifies ports and has an output schema, this description is far too sparse. It omits the purpose of the ports, the implications of force_https, and any potential side effects, leaving an agent without sufficient information to decide whether and how to invoke it.
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 thoroughly describes all three parameters (http_port, https_port, force_https) with defaults and descriptions, achieving 100% coverage. The description adds no parameter-level information, so the schema's documentation carries the full weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '设置 Web 管理端口' is a direct translation of the tool name 'set_web_ports', adding only the word 'management'. It restates the name without clarifying what the web ports control (e.g., the router's admin interface), making it essentially a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description neither mentions conditions for use nor distinguishes it from similar setter tools like set_dns_config or set_snmp.
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?
There are no annotations to cover safety or behavior, so the description must carry the burden. It only implies a write operation by using 'add' but does not disclose side effects, permission requirements, or whether duplicates are handled. This is insufficient for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, but this is under-specification rather than effective conciseness. It lacks any structure or front-loaded information that would help an agent invoke the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no annotations, and an output schema), the description is severely incomplete. It provides no context about expected behavior, return values, or how this rule integrates with protocol control.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 8 parameters with zero description coverage, and the tool description mentions none of them. It does nothing to clarify the meaning of 'action', 'prio', 'week', or other parameters, leaving the agent to guess from names alone.
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 (add) and the resource (application protocol control rule). It is specific enough to distinguish from sibling tools like add_acl_rule or add_port_mapping, though it lacks details on what the rule contains.
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 for when to use this tool, prerequisites, or alternatives. The description is a standalone phrase without any context for usage decisions.
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 provided, the description carries the full burden of behavioral disclosure. It merely states the action without mentioning side effects, permission requirements, reversibility, or what happens on duplicate MAC entries. This is insufficient for a write operation with no safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is front-loaded but severely under-specified. It does not earn its place because it provides no value beyond what the tool name implies. Under-specification is not conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 5-parameter write tool with no annotations and zero schema-description coverage. The description is completely inadequate to guide an agent on correct invocation, parameter semantics, or side effects. An output schema exists, but it cannot compensate for the lack of behavioral and parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about any of the 5 parameters. The schema shows defaults like action: 'drop' and time_range: '00:00-23:59', but their meaning, allowed values, and behavior are undocumented. The description entirely fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '添加 MAC 访问控制' translates to 'Add MAC access control', which clearly states the action (add) and the resource (MAC access control). It distinguishes itself from sibling tools like list_mac_access_control and delete_mac_access_control via the verb, though it lacks explicit scope or additional context.
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 such as add_acl_rule or add_mac_group. The description gives no context about prerequisites, use cases, or situations where a different tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it merely restates the tool's name. It does not disclose side effects, constraints (e.g., valid ranges for upload_kbps/download_kbps), whether it overwrites existing limits, or any operational impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, but this is under-specification rather than effective conciseness. It lacks structure or front-loaded information, providing only a minimal phrase that adds no value over the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters, no annotations, and a non-trivial schema, the description is profoundly incomplete. It does not address return values, error scenarios, prerequisites, or interactions with existing MAC speed limits, making it insufficient for safe and correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 6 parameters with 0% description coverage. The description does not explain any parameter beyond its bare name, leaving the agent without guidance on units, valid values, or the meaning of optional fields like time_range, enabled, and comment.
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 '添加 MAC 限速' (Add MAC speed limit) clearly states a specific action (add) on a specific resource (MAC speed limit), distinguishing it from sibling tools like list_mac_speed_limits and delete_mac_speed_limit. The intent 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 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 such as add_ip_speed_limit or add_connection_limit. It does not mention prerequisites, exclusions, or any context for choosing this tool.
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 the full burden of disclosing behavioral traits. It only indicates the action of adding a rule, with no mention of side effects, persistence, default interface behavior, or validation. This is insufficient for a mutation tool with eight parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is concise in length but under-specified in content. It essentially restates the tool name without adding meaningful detail, making it an ineffective summary rather than a valuable addition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, all optional with defaults) and lack of annotations, the description is grossly incomplete. It does not cover purpose, usage, parameter semantics, or expected behavior, leaving the agent with almost no operational context. The presence of an output schema does not compensate for the missing input-side information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description offers zero parameter information. With schema description coverage at 0%, all responsibility falls on the description, but it does not explain the meaning of 'src_addr', 'dst_addr', 'protocol', or how they relate to the rule. The parameter names are self-evident to a human, but an AI agent receives no guidance on values or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('add') and a resource ('port diversion rule'), which clearly communicates that this tool adds a rule related to ports. It is distinguishable from domain-based forwarding rules and static routes. However, the term '分流' (diversion) does not exactly match the tool name's 'forwarding', creating minor ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as add_port_mapping or add_domain_forwarding_rule. It lacks any context about prerequisites, typical scenarios, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, but it merely restates the add operation. It does not reveal potential side effects, validation requirements, or whether existing routes are affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It essentially translates the tool name and adds no additional value beyond what the name already conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with six parameters and no annotations, the description is completely inadequate. It does not explain task context, route prerequisites, return values, or any operational behavior, making it impossible for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter semantics. The six parameters (destination, netmask, gateway, metric, comment, interface) are left entirely unexplained, with no format or default-value context beyond raw schema types.
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 'Add static route' clearly identifies the action (add) and resource (static route), distinguishing it from sibling tools like list_static_routes and delete_static_route. However, it lacks detail about what a static route entails or how this operation fits into routing configuration.
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. It does not mention prerequisites, nor does it reference sibling tools such as delete_static_route or get_routing_table.
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 disclose behavioral traits. It only states 'delete', which is already evident from the tool name. It does not mention irreversibility, impact on firewall settings, or authorization requirements. The deletion's permanence and potential side effects are left undisclosed.
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 exceptionally concise, consisting of a single short sentence. It is free of fluff and gets to the point, but the brevity comes at the cost of essential details. It does not waste words, yet it could have achieved more with the same length.
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?
Given the tool's simple schema, the description is insufficiently complete. There is no output schema explanation, and the description fails to explain the deletion's impact, required permissions, or even that it targets a single rule. For a destructive operation, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, rule_id, with no description coverage (0%). The tool description does not mention or explain rule_id at all. The agent is left without any context about what rule_id refers to, how to obtain it, or its format, greatly increasing the risk of incorrect invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除应用协议控制' translates to 'Delete application protocol control', which provides a verb (delete) and a resource (application protocol control). However, it is vague and essentially paraphrases the tool name without clarifying that it deletes a specific rule by ID. It lacks specificity, making it hard to distinguish from related operations like toggle_app_protocol_rule.
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. There is no mention of prerequisites, target use cases, or exclusions. Any context about needing a rule_id from list_app_protocol_rules is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does not mention whether the deletion is permanent, what side effects occur (e.g., impact on interfaces or settings), whether confirmation is needed, or any safety warnings. This is a mutation tool with zero transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two words), with no wasted prose. However, it is under-specified rather than appropriately concise, bordering on a tautology. It lacks any structural detail that would aid comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and an output schema, the description is minimally viable but leaves critical gaps. It does not explain what a VLAN is, what happens when deleted, or any constraints. The output schema exists, so return values are covered, but the operational context is severely lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention vlan_id at all. The parameter name is somewhat self-explanatory, but the description fails to compensate for the lack of schema documentation, leaving the user to infer the meaning and expected format.
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 '删除 VLAN' clearly states the action (delete) and the resource (VLAN), which distinguishes it from sibling tools like add_vlan and list_vlan_configs. It is specific but lacks any additional context about what a VLAN entails in this system.
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. There is no mention of prerequisites, exclusions, or conditions under which deleting a VLAN might be appropriate. The description simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only says 'delete VPN account' and does not mention whether deletion is permanent, requires specific permissions, disconnects active sessions, or has other side effects. This is a significant gap for a destructive operation.
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 phrase '删除 VPN 账号' with no redundant words. It is concise and to the point, though it is also under-specified in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two required parameters, no annotations, and is a destructive operation, the one-line description is grossly insufficient. It lacks parameter explanations, usage context, and behavioral warnings, making it inadequate for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage) for the two required parameters (user_id and vpn_type), and the description does not explain their meaning or acceptable values. The agent must guess that user_id identifies the account and vpn_type specifies the VPN protocol, with no guidance.
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 '删除 VPN 账号' clearly states the action (delete) and resource (VPN account), and distinguishes from sibling tools like delete_pppoe_account. However, it essentially restates the tool name without adding specific scope or differentiating details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention, for example, that delete_pppoe_account should be used for PPPoE accounts, or any prerequisites or conditions for deleting VPN accounts.
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?
The annotations declare readOnlyHint=true, which already indicates a safe read operation. The description adds nothing beyond the verb 'list', with no mention of return format, pagination, or other behavioral traits. It does not contradict annotations, but provides no extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is just a restatement of the tool name. It does not earn its place by adding any information, making it an under-specification rather than a concise, value-adding description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters, read-only, output schema present), but the description leaves the concept of 'time plans' undefined. It doesn't explain what a time plan is, how it relates to other features, or any detail about the listing behavior. The minimal description is not contextually 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 and an empty schema. With 0 parameters, the baseline is 4, and there is nothing to explain. The description need not add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出时间计划' is a direct translation of the tool name 'list_time_plans', providing no additional information. It merely restates the name without specifying scope, filtering, or differentiating from other list tools, making it a tautology.
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 gives no guidance on when to use this tool versus alternatives. There is no indication of intended scenarios, preconditions, or exclusions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. '添加 VLAN' implies a mutation (creating a resource) but does not mention side effects, required permissions, duplicate handling, or reversibility. This is a significant gap for a write operation.
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, short sentence that directly states the action. It is concise and front-loaded, with no unnecessary words. However, it is so brief that it sacrifices useful context, so it doesn't earn a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with five parameters (three required), no annotations, and no behavioral details, the description is drastically incomplete. The output schema exists but doesn't compensate for the lack of usage context. This description provides almost no actionable guidance for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has five parameters with zero description coverage. The description adds no meaning beyond what parameter names (vlan_id, name, interface, ip, comment) already suggest. It fails to clarify the purpose of fields like 'interface' or 'ip' in the VLAN creation context, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '添加 VLAN' (Add VLAN) uses a specific verb and resource, clearly indicating a create operation. It distinguishes itself from sibling tools like list_vlan_configs and delete_vlan since 'add' is unique among them, but it lacks any additional scope or detail that would push it to a 5.
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. There is no mention of prerequisites, exclusions, or context such as 'use this to create a new VLAN before configuring DHCP.' It simply states the action without any situational 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?
The readOnlyHint annotation already communicates that this is a read-only operation, but the description adds no further behavioral context. It does not mention what data is returned, any limitations, or system effects, so the description contributes nothing beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it carries minimal informational value beyond the tool name. It is not necessarily bloated, but it also does not earn its place by adding meaningful detail, making it borderline adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and an output schema, the description is too vague to be complete. It fails to specify the source, type, or scope of the messages, and the presence of many sibling notification tools means the agent cannot reliably infer which messages are meant.
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 zero parameters, the schema is trivially complete and the description need not explain any inputs. The baseline score of 4 is appropriate because there is no parameter information to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取消息通知' is essentially a Chinese translation of the tool name 'get_messages', providing no additional specificity about what kind of messages or notifications are retrieved. It does not distinguish this tool from sibling tools such as get_notifications or get_realtime_notices, making it a tautological restatement.
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 gives no indication of when to use this tool versus the many related sibling tools for notifications or messages. There is no mention of context, alternatives, or exclusions, leaving the agent without guidance for tool selection.
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?
Annotations already declare readOnlyHint=true, and the description adds no behavioral context such as return format, default filtering, or the effect of vpn_type. It does not contradict the annotations, but it contributes nothing beyond the tool's name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and free of filler, but it is under-specified; it essentially restates the tool's purpose without adding supplementary information. It is concise but lacks substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and a single optional parameter, the description does not explain vpn_type semantics or how VPN accounts differ from VPN clients/servers. The context is too incomplete for an agent to use the tool with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter vpn_type has 0% schema description coverage, and the description does not explain its meaning, accepted values, or default behavior. The description fails to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '列出 VPN 账号' (List VPN accounts) with a clear verb and resource. It is distinguishable from siblings like list_vpn_clients and list_vpn_servers by naming the specific resource 'accounts', though it doesn't explicitly contrast with those tools.
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 such as list_vpn_clients, list_vpn_servers, or get_pptp_server_config. The description offers no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It says 'modify' but does not explain whether changes are immediately applied, if they require a reboot, whether existing connections are affected, or the nature of the output. This is a significant gap for a configuration-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and front-loaded with the main action. However, it lacks any additional structure or elaboration that would help the agent understand the tool, and it provides only the bare minimum of information.
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?
Given that this is a configuration modification tool with no annotations and 0% schema description coverage, the description is inadequate. It does not mention effects, parameter roles, or how this relates to other DNS tools. The presence of an output schema partially explains return values, but the description still leaves too many gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%: none of the three parameters (primary_dns, enable_cache, secondary_dns) have descriptions. The tool description also fails to mention or explain any parameters, leaving their semantics entirely ambiguous. It does not compensate for the schema gap at all.
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 '修改 DNS 配置' clearly states the verb (modify) and resource (DNS configuration), making the tool's purpose understandable. However, it does not differentiate from sibling tools like get_dns_config or get_multi_line_dns beyond the obvious read/write distinction, and there is no scoping detail (e.g., which DNS settings are affected).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no context about when modification is appropriate. It merely states what it does, leaving the agent without direction for tool selection.
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?
The annotation readOnlyHint=true already communicates that this is a safe, non-mutating operation. The description adds no behavioral detail beyond that, such as what inputs are accepted, how the calculation is performed, or any limitations. It fails to add context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase with no wasted words, but it is under-specified. It merely restates the tool's name in Chinese and does not earn its place by adding substantive information. It is more a label than a functional description.
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?
While the tool is simple and has rich structured context (annotations, full schema coverage, output schema), the description alone is too sparse to fully guide an agent. It omits details such as the type of subnet calculation performed, the mask format, or expected outputs. The combination of description and schema still leaves gaps for correct invocation.
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%, with 'ip' documented as 'IP 地址' and 'mask' as '子网掩码'. The description '子网换算工具' adds no additional meaning to the parameters, but the schema already provides adequate baseline documentation. The mask format (e.g., CIDR vs dotted decimal) remains ambiguous, though the schema baseline of 3 applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '子网换算工具' states the tool performs subnet conversion, but it is essentially a translation of the tool name. It does not specify what the conversion produces (e.g., network address, broadcast, usable IP range) or distinguish it from other network utilities, leaving the purpose somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no context, and no exclusions. It simply names the operation without explaining scenarios where it would be appropriate or inappropriate.
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 present, so the description carries the full burden of behavioral disclosure. It only states 'enable/disable' without explaining effects on existing VPN connections, whether the change is persistent, or what happens to clients. This is a minimal mutation disclosure with no additional detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler words, which is structurally efficient. However, it is under-specified rather than effectively concise, so it does not earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no parameter descriptions, and an ambiguous 'VPN server' resource, the description is inadequate for correct invocation. It does not address which VPN type to target, when toggling is appropriate, or what the output schema contains, making it minimally useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no information about the vpn_type or enabled parameters. vpn_type is a required string with no accepted values or enum guidance, and enabled's boolean semantics are not described, leaving the agent without necessary parameter context.
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 '启用/禁用 VPN 服务端' clearly states a specific action (enable/disable) and resource (VPN server). However, it does not differentiate among VPN protocol types or distinguish itself from sibling tools like toggle_pppoe_server, so it falls short of a 5.
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 or guidance is provided. The description does not explain when to use this tool versus alternatives, mention prerequisites, or clarify what vpn_type should be. Sibling tools such as list_vpn_servers and toggle_pppoe_server exist but are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it offers none. It does not state whether group names must be unique, what happens on duplicate names, or what the response contains. This is a critical gap for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is concise, but it is under-specified. It lacks essential information about the operation, making it insufficient for correct usage despite being front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, and an output schema, the description is far from complete. It only provides the basic purpose without operational details, failure handling, or parameter context, making it inadequate for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate by explaining parameters. It does not mention 'name', 'comment', 'ip_list', or 'ip_type', leaving all parameters undocumented and the tool difficult to invoke correctly.
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 (add) and the resource (IP address group), distinguishing it from sibling tools like 'delete_ip_group' and 'list_ip_groups'. It is specific and unambiguous, conveying the core purpose effectively.
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 creating an IP group but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The context needed for selecting this tool over others is not provided.
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 provided, the description carries the full burden of behavioral disclosure. It only states the action 'delete' without mentioning irreversibility, side effects, or whether the rule must exist. This is minimal disclosure that adds no value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It merely restates the tool name in Chinese and fails to provide any additional useful information.
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?
This is a simple tool with one parameter and an output schema, but the description is too sparse. It lacks operational context such as the need to list rules first, any prerequisites, or how deletion affects routing. The missing annotations and minimal description leave significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter rule_id with zero description coverage. The description does not explain how to obtain rule_id or its meaning beyond the parameter name itself. The agent would have to infer from context that rule_id comes from listing domain forwarding rules.
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 indicates a delete operation on domain forwarding rules. The verb and resource are specific, and the action distinguishes it from list/add siblings. However, it lacks any additional scope detail that would earn a top score.
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, prerequisites, or alternatives. Related tools like list_domain_forwarding_rules and add_domain_forwarding_rule are not mentioned, leaving the agent without context on how this tool fits into the workflow.
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 carry the full burden of behavioral disclosure. It only indicates a delete operation, but fails to mention consequences (e.g., whether the deletion is irreversible), prerequisites, or side effects. This is minimal disclosure at best.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (four Chinese characters), but this is under-specification rather than effective conciseness. It lacks essential information and does not earn its place as a meaningful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with one parameter, the description is insufficient. Even though an output schema exists, the lack of annotations, parameter explanations, and usage guidance leaves significant gaps. The description is barely above a tautology.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required integer parameter 'rule_id', but with 0% schema description coverage. The description does not explain what 'rule_id' refers to, though the name implies it is the identifier of the port mapping. The description adds no meaning beyond what the parameter name already suggests.
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 (delete) and resource (port mapping), making the purpose unambiguous. However, it does not differentiate from similar sibling tools like delete_port_forwarding_rule, which may cause confusion.
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 such as delete_port_forwarding_rule or delete_acl_rule. The description merely states the action without any contextual cues or exclusions.
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?
The description adds no behavioral context beyond the readOnlyHint annotation. It simply states 'get', which is consistent with the annotation, but does not provide any additional details about side effects, permissions, or output behavior.
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 short phrase, making it very concise and front-loaded. However, it is so minimal that it amounts to a restatement of the tool name, so it does not quite achieve a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks contextual completeness. It does not explain what the cross-layer3 service configuration is, when to retrieve it, or how it relates to sibling configuration tools. Although an output schema exists, the description itself gives no reason to select this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. The description does not need to explain parameter semantics, and no additional parameter details are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取跨三层服务配置' is a direct translation of the tool name, restating 'get_cross_layer3_config' without providing any additional explanatory context. It does not clarify what 'cross-layer3' refers to or distinguish this tool from the many other get_*_config tools.
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 offers no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, leaving the agent without situational guidance.
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?
The description adds nothing beyond the readOnlyHint annotation. It does not mention what packages are returned, whether any filtering or grouping is applied, or any side effects. While it does not contradict the annotation, it provides no extra 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, but the brevity comes at the cost of clarity. It is front-loaded and has no wasted words, yet it fails to convey the necessary meaning of 'packages' or the tool's 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?
With an output schema present, return values need not be described. However, the meaning of 'packages' is unspecified, and there is no context about what packages are available or what the list represents. For a simple 0-param list tool, more resource context is needed for full 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 coverage is 100%, so there are no parameter semantics to explain. The baseline for 0 params is 4, and the description does not need to address parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出套餐' (List packages) is essentially a restatement of the tool name in another language. It provides no additional detail about what kind of packages are listed or how this differs from other list tools, making the purpose ambiguous.
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 gives no guidance on when to use this tool, what prerequisites exist, or how it relates to sibling list tools such as list_vpn_clients or list_wan_configs. It is a bare command with no contextual usage instructions.
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?
The description adds no behavioral information beyond the readOnlyHint annotation. It does not describe what a port group is, whether system defaults are included, or any special behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is concise, but it repeats the tool name without adding value, so it does not fully earn 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?
Given the tool's simplicity (0 params, readOnlyHint, output schema present), the description is minimally sufficient but lacks any contextual nuance about port groups or their role.
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 zero parameters, so there is nothing to explain. The description does not need to compensate as the baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出端口分组' (List port groups) is a direct restatement of the tool name. It clearly identifies the action and resource but provides no additional meaning beyond the name, making it effectively a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus other group-listing tools or alternative approaches. The description does not mention any specific use cases, exclusions, or context.
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?
The description only says 'list', which is consistent with readOnlyHint=true, but it adds no behavioral context such as pagination, filtering, or that it returns all rules. No additional transparency beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short phrase), but it adds no information beyond the tool name. It is not verbose but does not earn its place as a useful addition.
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 parameters and an output schema, the description is minimal. It doesn't explain what up/down separation rules are or when to use this tool, but the name and output schema may compensate partially. Still, it lacks context about the resource or usage.
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 in the schema, and the description doesn't mention any. With 0 parameters, the baseline is 4, and no further parameter info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出上下行分离规则' is a direct translation of the tool name, providing no new information. It restates the name without specifying scope or distinguishing it from sibling 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 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. Many sibling list tools exist, but no criteria or exclusions are given.
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 full responsibility for disclosing behavior, but it only states the action. It does not mention that this is a mutation, whether it overwrites existing names, if it is idempotent, what happens if the MAC is not found, or any required permissions. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is appropriately front-loaded for a simple tool. However, it under-specifies by repeating what the tool name already implies, and it could be rephrased or expanded to add value 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?
Given the low complexity, a short description could suffice, but this one lacks essential context: no usage guidelines, no behavioral transparency, and no parameter semantics. The output schema exists but is not summarized, and there is no mention of success/failure responses or side effects. The tool is minimally complete but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not compensate by explaining the parameters. The names 'mac' and 'name' are self-explanatory to a technical user, but the description does not clarify that 'mac' identifies the device and 'name' is the new value to set. It also does not describe any format constraints (e.g., MAC address format, name length).
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 (set) and resource (terminal name), matching the tool name without being a full tautology. It distinguishes from siblings like list_device_names and set_hostname by implying a per-terminal (MAC-based) name. However, it could explicitly mention the target is identified by MAC to differentiate from hostname setting.
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 guidance is provided. The description does not indicate when to use this tool, prerequisites (e.g., existing terminal), or how it relates to alternatives like list_device_names. There is no mention of whether it should be used before or after adding a device, or any context about device name management.
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 provided, the description carries the full burden of behavioral disclosure. It merely says 'delete connection limit' without stating that the operation is permanent, requires elevated permissions, or what side effects occur. This is insufficient for a destructive tool.
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, short sentence with no redundant words. It is concise and easy to parse, though the brevity sacrifices important contextual details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with no annotations and an output schema, the description should provide more context about side effects, permissions, and relationship to sibling tools. It lacks this, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention rule_id or its role. The parameter name is self-explanatory in context, but the description adds no semantic value 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 the action (delete) and the resource (connection limit), making it specific enough. It distinguishes itself from other delete tools by naming the unique resource, though it is essentially a translation of the tool name and adds little extra nuance.
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 about when to use this tool versus alternatives, such as list_connection_limits or add_connection_limit. There is no mention of prerequisites, context, or whether the rule_id must come from a list operation.
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. However, it only says 'delete', implying a destructive action, but does not state irreversibility, potential impact on network clients, or required permissions. The lack of any behavioral disclosure beyond the action itself is a significant gap for a delete operation.
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 concise phrase that is easy to parse and front-loads the key action. There is no redundancy or fluff. However, it is so minimal that it sacrifices informative content, but for conciseness alone, it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete. It does not explain how to obtain record_id, what happens when the binding is deleted, or any prerequisites or side effects. Even though an output schema exists, the tool's purpose and operational context are underspecified. A simple list or reference to the related list tool would significantly improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, record_id (integer), with no description and 0% schema description coverage. The tool description does not mention record_id at all, so it does not compensate for the missing schema documentation. The agent is left to infer that record_id identifies the binding to delete, which is not explicitly stated.
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 '删除 DHCP 静态分配' clearly states the action (delete) and the resource (DHCP static binding). It distinguishes from siblings like add_dhcp_static_binding and list_dhcp_static_bindings. However, it is essentially a translation of the tool name and lacks any additional context, so it is clear but not exceptional.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool or when not to. It does not mention how record_id should be obtained (e.g., from list_dhcp_static_bindings) or any prerequisites. No alternatives are discussed, and the single sentence provides no contextual usage information.
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 provided, the description must disclose behavioral traits. It only states 'delete', which implies destructiveness, but gives no information about irreversibility, failure conditions, or side effects. The agent is left unaware of potential consequences or errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, which is good. However, it is under-specified for a tool with parameters and potential side effects. While it conveys the core purpose efficiently, it lacks substance that could be added without significant length, making it less appropriately sized than a fully helpful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a delete operation with 2 parameters and an output schema, but the description is minimal. It doesn't explain how group_id and ip_type are used, what happens after deletion, or any constraints. The description is insufficiently complete for an agent to understand the full context of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention either parameter (group_id, ip_type). The agent cannot infer what ip_type represents (e.g., IPv4 vs IPv6) or that group_id is the identifier of the group to delete. The description adds no value beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除 IP 地址分组' clearly states the action (delete) and the resource (IP address group). This distinguishes it from sibling tools like list_ip_groups and add_ip_group, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 vs alternatives or any prerequisites. For example, it doesn't mention whether the group must be empty or if deletion is disallowed when the group is in use by other rules. The description only states the action with no exclusions or contextual conditions.
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 provided, the description carries the full burden of behavioral disclosure. It only states the deletion action, but does not disclose side effects (e.g., whether the group must be empty), irreversibility, impact on associated rules, or required permissions. This is a significant gap for a destructive operation.
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 efficiently conveys the core action. It contains no wasted words. It earns a 4 for brevity, though it could be improved with a second sentence for usage context.
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?
Given the simplicity of the tool (one parameter, no annotations, no output schema details), the description is not complete. It fails to explain the permanence of deletion, prerequisites, or what constitutes a successful deletion. The provided output schema exists but is not described, leaving return behavior unknown.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single required integer group_id with no description (schema_description_coverage = 0%). The description 'Delete MAC address group' does not explain what group_id refers to or how to obtain it. While the parameter is somewhat self-explanatory, the description adds no explicit meaning beyond the schema field name.
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 '删除 MAC 地址分组' clearly states the action (delete) and the resource (MAC address group). It distinguishes itself from sibling tools like add_mac_group and list_mac_groups by specifying the delete operation. However, it lacks additional scope qualifiers (e.g., permanent deletion) that could elevate it to a 5.
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, prerequisites, or alternatives. It does not mention that the group must exist or that deletion is irreversible, nor does it reference sibling tools like list_mac_groups for finding the group_id. Usage context is only implied by the tool name.
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 present, the description carries the full burden of behavioral disclosure. It simply states 'modify' without explaining whether the change takes effect immediately, requires a reboot, or has side effects. This is a significant gap for a write operation.
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, short phrase with no wasted words, making it highly concise and front-loaded. However, its brevity borders on under-specification, though it still serves as a clear, efficient statement of the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool, a short description might be acceptable, but this one lacks any behavioral details or parameter constraints. The presence of an output schema reduces the need to explain return values, but the description still feels incomplete without usage context or effect information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description does not elaborate on the 'hostname' parameter. While the parameter name is somewhat self-explanatory, the description does not provide validation rules, allowed formats, or length constraints, which is necessary when the schema lacks descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '修改路由器主机名' clearly states that the tool modifies the router hostname, using a specific verb and resource. It distinguishes itself from siblings by explicitly targeting the hostname, which is a unique resource among the listed tools. However, it lacks any explicit comparison to alternatives.
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 other configuration tools. There is no mention of prerequisites, conditions, or when not to use it. The user is left without any contextual direction.
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, and the description does not disclose any behavioral traits such as irreversibility, permissions required, or side effects. For a deletion operation, this lack of transparency is a notable gap.
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 concise sentence with no wasted words. However, it is overly terse, and while structure is clean, the lack of additional context limits its value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only one parameter, but the description provides no explanation of expected behavior, return values, or prerequisites. Despite the output schema existing, the description itself is incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single parameter 'route_id' with no description, and the tool description adds no meaning to it. With 0% schema description coverage, the agent has no hint about what route_id represents or how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除静态路由' translates to 'delete static route', which clearly states the action (delete) and the resource (static route). It distinguishes from sibling tools like add_static_route and list_static_routes by the verb and object.
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 or how it compares to alternatives. The description only states the action, leaving the agent to infer appropriate 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation correctly indicates a safe read operation, and the description does not contradict it. However, the description adds no behavioral context beyond what the annotation provides, such as what the config contains or any prerequisites, though the simplicity of a zero-parameter getter mitigates this gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with no verbose wording, but it is under-specified: it merely restates the tool name without earning its place by adding value. It is not excessively long, but it could be more informative without losing brevity.
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 zero-parameter getter with an output schema (shown as present in context), the description is sufficient to invoke the tool correctly. The read-only annotation and empty input schema cover the operational aspects, and the tool name disambiguates from siblings, though the description itself does not.
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 of 4 is appropriate. There are no parameter descriptions needed, and the empty schema fully covers the input surface without additional explanation required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取 PPTP 客户端配置' translates to 'Get PPTP client configuration', which is a direct restatement of the tool name get_pptp_client_config. It provides no additional specificity or differentiation from sibling tools like get_l2tp_client_config or get_openvpn_client_config, making it a tautology.
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 gives no guidance on when to use this tool versus alternatives. It does not mention that this is for PPTP only, nor does it exclude other VPN protocol config tools, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates that this is a safe read operation. The description adds no extra behavioral context about return values or side effects. Given the annotation coverage, a score of 3 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 extremely concise, being a single short phrase. It has no wasted words, but it also carries minimal substance. It is appropriately sized for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (zero params, read-only) and has an output schema, so the description does not need to explain return values. However, it provides no context about what the reboot schedule is for or how it relates to other reboot tools, making it minimally sufficient.
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 100% and the description need not explain any inputs. Per the rubric, 0 params gives a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取重启计划' is a direct Chinese translation of the tool name 'get_reboot_schedule', adding no new information beyond the name itself. It does state a verb and resource, but since it merely restates the name, it qualifies as a tautology.
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 offers no guidance on when to use this tool or how it differs from alternatives. It does not mention related tools like 'reboot_router' or 'get_system_overview', leaving the agent without context for selection.
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 the full burden of behavioral disclosure. It only states the core action and does not disclose whether the toggle is reversible, idempotent, requires specific permissions, or has side effects on existing rules. This is a significant gap 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 concise sentence that front-loads the action. Every word serves a purpose, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 2 parameters and an output schema, but the description fails to provide essential context such as the effect of setting enable to true/false, the scope of rule_id, or any operational implications. It is a minimal description that leaves gaps for an AI agent trying to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond the parameter names. While 'rule_id' and 'enable' are somewhat self-explanatory, the description does not explain how they relate to the toggling operation or the expected values.
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 (启用/禁用) and resource (应用协议控制), clearly indicating an enable/disable action. However, it doesn't explicitly mention 'rule' and lacks differentiation from sibling toggle tools like toggle_acl_rule, though the resource context differs.
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 such as list_app_protocol_rules, add_app_protocol_rule, or delete_app_protocol_rule. The description simply states the action without context on prerequisites or relationships to other operations.
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 present, so the description carries the full burden. It only states 'add' without disclosing side effects, required permissions, or behavior on duplicate usernames. This is insufficient for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no redundancy. It is front-loaded and to the point, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, an output schema, and no annotations, the description is far too incomplete. It provides no context about how parameters relate, what values are valid, or any operational requirements, though the output schema may partially mitigate return-value concerns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the 6 parameters (username, password, comment, ip_type, upload_kbps, download_kbps). The agent cannot infer parameter meaning beyond raw schema names and defaults.
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 '添加 PPPoE 账号' translates to 'Add PPPoE account', which clearly states the action (add) and resource (PPPoE account). It distinguishes from sibling tools like list_pppoe_accounts and delete_pppoe_account.
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 about when to use this tool versus alternatives. It does not mention that this tool is for creating new accounts, nor does it reference related list/delete operations or any prerequisites.
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 the full burden of behavioral disclosure. It merely states 'Delete ARP binding' without revealing effects such as irreversibility, required permissions, or error behavior when the binding does not exist.
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 extremely concise with no redundant words. However, it offers little beyond a direct translation of the tool name, so while it is well-structured, it provides minimal added value.
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?
Given the low complexity (one parameter) but the complete absence of annotations and parameter descriptions, the description is too sparse. It does not mention prerequisites (e.g., obtaining binding_id), what happens on failure, or any other contextual details needed for reliable invocation. The presence of an output schema mitigates some concerns but does not compensate for the lack of guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the binding_id parameter beyond implying it identifies the target. The parameter name is somewhat self-explanatory, but the description adds no additional meaning or usage context for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (ARP binding), which directly conveys the tool's purpose. It distinguishes itself from sibling tools like add_arp_binding and list_arp_bindings by specifying the delete operation.
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 or how it relates to alternatives. It does not mention that the binding_id should come from list_arp_bindings or that deletion is permanent, leaving the agent without explicit instructions.
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?
The readOnlyHint annotation already indicates a safe read operation, and the description adds only the MAC-specific scoping. It does not disclose how the tool behaves when no MAC is available, whether it fetches historical data or real-time, or any rate limits or permissions needed. The description goes barely beyond the annotation and name.
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 short sentence, front-loaded with the core action and scope. It is concise with no wasted words. However, it may be under-specified for such a vague action word 'audit', but as far as structure and brevity, it is efficient.
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?
Given the complexity of the tool family and the empty parameter schema, the description is insufficient. It does not explain how the MAC is passed, what the output (despite having an output schema) represents, or how this tool differs in invocation from get_traffic_audit_by_user. The description leaves critical invocation context unexplained.
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 is empty, so there are no parameters to document. Although the description mentions 'by MAC', it does not explain how the MAC is specified, which could confuse an agent. With zero parameters, a baseline of 4 would apply, but the missing clarification about the MAC mechanism reduces the score.
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 '按 MAC 审计终端流量' clearly states the tool audits terminal traffic by MAC address, which is a specific verb+resource. It distinguishes from the sibling get_traffic_audit_by_user by indicating the MAC-based scoping. However, it lacks clarity about what 'audit' entails (retrieve logs vs. trigger audit) and how the MAC is provided given the empty parameter schema.
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 get_traffic_audit_by_user or get_terminal_log. There is no mention of prerequisites, typical scenarios, or explicitly contrasting with sibling tools. The context signal of many siblings makes the lack of usage guidance more noticeable.
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 the full burden of disclosing behavior. It merely states 'Execute Ping test' without mentioning ICMP echo requests, timeouts, potential network impact, or result interpretation. This minimal disclosure is insufficient for a network 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, well-structured and front-loaded. It is concise with no wasted words, though it is minimal in substance.
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?
Given the tool's diagnostic purpose, the description is too thin. It does not explain expected output, success criteria, or how to interpret results, even though an output schema exists. More context is needed for the agent to use it effectively.
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% description coverage, with all three parameters (target, count, interface) already described. The description adds no additional parameter semantics, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '执行 Ping 测试' (Execute Ping test) clearly states a specific action on a specific resource. It identifies the tool as a network diagnostic function, though it does not explicitly differentiate it from similar tools like traceroute or speed_test.
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 ping_test versus alternatives such as traceroute or speed_test. No context, exclusions, or references to sibling tools are given, leaving the agent to 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, and the description does not disclose potential side effects of disabling IPv6 (e.g., loss of IPv6 connectivity) or whether the change is reversible. For a mutation tool, this is a significant transparency gap.
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 extremely concise—a single phrase—and immediately front-loaded. It is efficient and avoids wasted words, though it might under-specify scope in exchange for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating toggle with no annotations and no parameter descriptions, the one-line description leaves important context unaddressed: global vs. interface scope, reversibility, or relationship to IPv6 WAN/LAN configuration tools. The presence of an output schema does not compensate for these missing behavioral 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?
The single 'enabled' boolean is not directly described, but the description's enable/disable phrasing implicitly conveys that true enables and false disables. This adds some meaning beyond the bare schema type, though it does not explicitly label the parameter.
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: enable/disable IPv6. It is specific enough to distinguish from sibling IPv6 configuration tools, though it does not explicitly state the scope (e.g., global vs. per-interface).
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, prerequisites, or conditions. The description only names the action without any contextual usage direction.
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 the full burden of behavioral disclosure. It does not mention whether the change disrupts connected clients, requires authentication, or has any side effects. The bare statement 'modify password' leaves operational impact undisclosed.
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 extremely concise, using a single short phrase to convey the core purpose. It could benefit from additional structure, but it is not verbose or redundant. The brevity itself is not a drawback, though it sacrifices completeness.
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?
Given the mutating nature of the tool and the lack of annotations, the description should provide more context about the impact of changing the password, the role of the radio parameter, and any return values or expected outcomes. The presence of an output schema mitigates the need to explain returns, but the absence of usage context and parameter details leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only adds the constraint 'at least 8 characters' for the password parameter. The 'radio' parameter (with default '2g') is not explained at all, leaving the agent to guess its meaning and allowed values. This incomplete compensation for schema gaps warrants a low score.
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 'modify Wi-Fi password' with an explicit resource. This distinguishes it from sibling tools like set_wifi_ssid or toggle_wifi, which handle different aspects of Wi-Fi configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any prerequisites or context such as requiring double-band support. The description simply states the action without elaborating on 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?
The readOnlyHint annotation already communicates that this is a safe read operation, so the description does not need to restate that. However, it adds no additional behavioral context, such as what data is returned, retention period, or any special conditions, leaving the agent without deeper insight beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short phrase) and front-loaded, but it is so minimal that it essentially duplicates the tool name. It under-specifies rather than providing efficient useful structure, landing between a perfectly concise summary and an unhelpful tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and an output schema, so the description need not explain return values. However, among many sibling log retrieval tools, the description lacks any clarification of what constitutes a 'wireless terminal log' versus a general terminal log, leaving contextual ambiguity that is not resolved by other structured fields.
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 zero parameters and 100% schema coverage, the schema is trivially complete. The description does not need to explain parameters. The baseline of 4 is appropriate because there are no parameter semantics to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取无线终端日志' is a literal translation of the tool name, clearly stating the verb (get) and resource (wireless terminal log). However, it does not distinguish this from sibling tools like get_terminal_log, leaving ambiguity about what specifically makes this wireless-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 provides no guidance on when to use this tool versus alternatives such as get_terminal_log or get_arp_log. There is no mention of context, prerequisites, or scenarios where this tool is preferred, so the agent gets no decision-support information.
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?
The description adds no behavioral details beyond the readOnlyHint annotation. It does not disclose expected runtime, output characteristics, or any side effects, leaving the agent without insight into how scanning works or what it returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, making it extremely concise. However, it is essentially a literal restatement of the tool name, providing minimal informative value. It is not verbose but is under-specified, warranting a mid-range score.
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 simplicity (no parameters, read-only, output schema present), the one-line description might be minimally sufficient. However, it fails to explain what 'channels' refers to or how this tool relates to other wireless diagnostic tools, leaving some ambiguity for an AI 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?
The tool has zero parameters, so parameter semantics are not applicable. The baseline score of 4 is appropriate because there are no parameter details to document or clarify.
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 '扫描周边信道' explicitly states the action (scan) and the target (surrounding channels), clearly conveying the tool's purpose. It distinguishes itself from sibling tools by using the unique 'scan' verb, though it does not explicitly clarify that these are wireless channels.
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. The description lacks any indication of when to use this tool versus alternatives like get_wireless_monitoring or ping_test, nor does it mention prerequisites or exclusions.
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. It only states 'delete' without disclosing consequences, permissions, irreversibility, or effects on related data. The verb itself implies destruction but adds no additional context.
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 short sentence with no redundancy or wasted words. It is appropriately concise, though it lacks supporting details that would be useful for a destructive tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, but the description is minimal. For a delete operation, more context about side effects or prerequisites would improve completeness, but it is not severely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the user_id parameter. The parameter name suggests it identifies the account, but no further meaning is provided 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 '删除 PPPoE 账号' means 'Delete PPPoE account', which is a specific verb+resource statement. It clearly distinguishes from sibling tools like add_pppoe_account and list_pppoe_accounts.
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 or which alternatives might be more appropriate. The description only states the action without any context for selection.
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 disclosure, but it only states the action. It does not mention side effects (e.g., impact on active FTP sessions), permission requirements, or the result of toggling.
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 clause with no waste. It is concise but could benefit from a bit more context, though it is not under-specified to the point of confusion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle tool, the description is complete enough to convey the core action, but it lacks details about the output, possible errors, or operational impact. With no annotations and no output schema details, the agent is left guessing about the tool's behavior beyond the basic toggle.
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 fully documents both parameters (port and enabled). The description adds no extra parameter insight, but the baseline of 3 applies because the 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 '启用/禁用 FTP 服务' clearly states the action (enable/disable) and the resource (FTP service). It is specific and distinguishes this tool from siblings like enable_ssh or enable_telnet.
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 gives no guidance on when to use this tool versus alternatives, prerequisites, or exclusions. It only states the basic function, leaving the agent without contextual direction.
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?
The description adds no behavior beyond the readOnlyHint annotation; it simply restates the tool name. It does not mention what the ARP log contains, whether it is historical or current, or any output 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 extremely concise with zero wasted words, but it is terse to the point of providing minimal semantic value. It is front-loaded and readable.
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 no-argument getter with an output schema, the description is adequate but thin. It does not explain the nature of the ARP log (e.g., event history vs. current table), leaving some ambiguity for the 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?
The tool has zero parameters and an empty schema, so parameter descriptions are not needed. The baseline of 4 applies because there is no parameter complexity to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: '获取 ARP 日志' ('Get ARP log'). It identifies the specific ARP log among many sibling log tools, though it does not add scope details or explicit differentiation from similar get_*_log tools.
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 instead of alternatives like list_arp_bindings or get_connection_table. There are no usage conditions, prerequisites, or exclusions.
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?
The readOnlyHint annotation already signals that this is a safe read operation. The description adds no additional behavioral context, such as what the status encompasses, whether it can be null, or any side effects. It merely restates the operation without enriching transparency beyond the annotation.
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 short sentence that directly states the purpose, with no filler or redundancy. It is appropriately concise for a simple getter, though it lacks elaboration that could be helpful in other dimensions.
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?
As a 0-parameter, read-only getter with an output schema, a brief description is acceptable. However, the description does not clarify what 'binding status' entails or when to use this tool, and the presence of many sibling getters suggests that more context could 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?
The tool accepts zero parameters, and the schema is empty with 100% coverage. The baseline for 0-parameter tools is 4, and the description appropriately does not need to explain parameter details. It adds no extra parameter information, but none is required.
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 '获取云服务绑定状态' (Get cloud service binding status) clearly states a specific verb and resource. It distinguishes itself from many other getter tools in the sibling list by focusing on cloud service binding, but it does not explicitly differentiate from similar status getters like get_registration_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are no context cues, prerequisites, or exclusion statements, leaving the agent without direction on selecting this over similar getter tools.
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?
The annotation readOnlyHint: true already signals a safe read operation. The description merely repeats the resource ('kernel parameter settings') without adding behavioral details such as scope, sample output, or any special conditions. It adds no transparency beyond the annotation, except reinforcing that it is a getter.
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 extremely concise, consisting of a single phrase. It is front-loaded and not verbose. However, it is very sparse, providing only the bare resource name; while this is efficient, it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists, and readOnlyHint is set, the description is adequate at a basic level. Yet 'kernel parameter settings' is vague and could be misinterpreted without further detail on what 'kernel' refers to in this router context. The output schema likely fills the gap, but the description itself leaves room for 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?
The tool has zero parameters, and the schema confirms this with an empty properties object. The description does not need to explain parameters. Per the rules, zero parameters yields a baseline of 4, and the description adds no confusion.
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 '获取内核参数设置' (Get kernel parameter settings) uses a specific verb and resource, clearly indicating the tool retrieves kernel settings. It does not explicitly differentiate itself from the many other get_* sibling tools, but the subject is distinct enough to be understood.
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 guidance is provided. The description does not state when this tool should be used versus alternatives, nor does it mention any prerequisites, intended scenarios, or exclusions. The agent is left to infer its purpose 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'get' which matches the readOnlyHint annotation, so there is no contradiction. However, it discloses no additional behavioral traits such as filtering, ordering, pagination, or whether the list is sorted or limited. With annotations present, the bar is lower, but the description adds no value beyond the annotation.
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 immediately conveys the operation. It is front-loaded and contains no filler, earning a perfect score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters, but the description is too sparse to be actionable in a rich context with many sibling tools. It doesn't clarify what type of notifications are returned, how they are generated, or whether they are system alerts or user messages, making it incomplete for effective selection.
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, and the schema coverage is 100%, so the description need not explain parameters. The baseline of 4 is appropriate since no parameter information is needed.
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 (获取/get) and the resource (消息通知列表/message notification list), making the tool's purpose clear. However, it does not differentiate from sibling tools like get_notification_log or get_messages, which also relate to notifications.
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. The description offers no context, prerequisites, or examples, leaving the agent to 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the readOnlyHint annotation. It does not disclose what 'config' includes, whether the operation is safe beyond read-only, or any side effects. Since annotations already cover the read-only nature, the description contributes no additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and to the point, but it essentially restates the tool name in another language. It is concise but adds little structural value; a single sentence that merely translates the name does not earn its place as meaningful content.
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 zero-parameter getter with an output schema and readOnly annotation, the simple description is sufficient. The output schema covers return details and the annotation covers safety, so the description does not need to elaborate further. It is complete for the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not required to explain parameter semantics. The empty schema already defines the absence of parameters, and with no parameters, the baseline score is 4.
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 retrieves OpenVPN server configuration, using the verb '获取' (get) and specifying the resource 'OpenVPN 服务端配置' (OpenVPN server config). It is not a mere tautology since it names the specific protocol and server side, distinguishing it from client config tools, though it does not explicitly contrast with siblings.
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 such as get_openvpn_client_config or other server config getters. The usage is implied only by the name; there is no mention of scenarios, prerequisites, or exclusions.
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?
The readOnlyHint annotation already identifies this as a read-only operation, but the description adds no further behavioral context such as return format, what 'faststart' refers to, or whether any prerequisites exist.
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 extremely concise, consisting of a short phrase with no fluff. However, it lacks sentence structure and additional detail, though for a zero-parameter tool this is acceptable.
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 zero-parameter schema and existing output schema, the description is minimally adequate. Yet the unexplained 'faststart' qualifier and the similarly named sibling tool leave ambiguity about the exact scope.
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 the schema provides complete coverage. The description is not required to elaborate on parameters.
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 retrieves cloud service registration/binding status, using a specific verb and resource. However, it does not differentiate from the sibling 'get_cloud_binding_status', which appears to serve a similar purpose.
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 guidance is provided; the description does not indicate when to use this tool over alternatives like 'get_cloud_binding_status' or any other context.
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?
The description adds no behavioral context beyond the readOnlyHint annotation. It does not disclose output format, pagination, ordering, or any other operational details. While it does not contradict the annotation, it provides no additional transparency about the tool's 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?
The description is a single, short sentence that conveys the core action without any unnecessary words. It is front-loaded and concise, though somewhat minimal, it earns its place as a clear, non-redundant statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and an output schema, the description fails to provide enough context. It does not clarify what 'periodic notices' are or differentiate from other notice list tools, leaving the agent without a full understanding of when this tool is relevant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema description coverage is 100% (everything is documented). The description does not need to explain parameters, and the baseline score of 4 is appropriate since no parameter guidance is required.
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 a specific verb and resource: 'List periodic notices'. It distinguishes the action from mutation tools but does not differentiate it from sibling tools like 'list_realtime_notices' or 'list_expiry_notices', relying solely on the name for disambiguation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or situations where 'list_periodic_notices' would be preferred over similar list tools, leaving the agent without direction for tool selection.
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 discloses the key behavioral impact (network outage for 1-2 minutes) via an explicit warning. However, it does not explain the 'confirm' parameter's role, whether the reboot is immediate, or other side effects, and there are no annotations to fill in those 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?
The description is extremely concise, consisting of a clear action and a warning, with no filler words. It is front-loaded and every element serves a purpose, making it highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, the description covers the main purpose and side effect but omits crucial context about the 'confirm' parameter and what happens when it's false. Given the output schema exists, return values are not required, but the confirm semantics are a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a 'confirm' boolean with default false and no property description, and the description does not mention it at all. With schema description coverage at 0%, the description fails to compensate, leaving parameter semantics entirely unexplained.
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 '重启路由器' (restart router), a specific verb and resource, and adds a warning about a 1-2 minute network outage, which provides valuable context. It is clearly distinguishable from the sibling tool 'restart_ap' by specifying 'router'.
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, nor any prerequisites or exclusions. The description merely states the action and its side effect, leaving the agent to infer appropriate usage.
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 the full burden of behavioral disclosure. 'Restart specified AP' only states the action without warning that restarting an AP will disrupt connectivity for associated clients or that the operation may take time. Important behavioral context is missing.
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 immediately conveys the action. It is appropriately sized for a simple one-parameter tool and avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a potentially disruptive operation like restarting an AP, the description is incomplete. It lacks usage guidance, behavioral impact information, and parameter explanation. While an output schema exists, the description still needs to provide operational context to be fully useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single integer parameter ap_id with 0% description coverage. The tool description merely mentions 'specified AP' but does not explain how to obtain the ap_id, what values are valid, or its format. The description provides minimal semantic value 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 'Restart specified AP' clearly states the action (restart) and the target resource (an access point). It is specific and easily distinguishes this tool from sibling tools like 'upgrade_ap_firmware' or 'get_ap_group_config', which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, side effects, or situations where a different tool (e.g., reboot_router) would be more appropriate. The context is entirely implicit.
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?
There are no annotations, so the description carries full responsibility for behavioral disclosure. It only states the action without explaining side effects, whether it affects 2.4GHz/5GHz radios, persistence, or client impact. This is a significant gap for a mutating toggle operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It is front-loaded and appropriately sized for the action it describes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating toggle with no annotations and minimal parameter description, the description is too sparse. It lacks usage context, parameter semantics, and behavioral details, though the output schema may cover return values. This is insufficient for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the 'enabled' or 'radio' parameters. The 'radio' parameter with a default of '2g' is especially ambiguous, leaving the agent without guidance on valid values or meaning.
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 ('启用/禁用' - enable/disable) and resource (Wi-Fi), clearly stating the tool's function. It distinguishes from sibling tools like set_wifi_ssid, set_wifi_password, and get_wifi_basic_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 implies the tool is used when you want to enable or disable Wi-Fi, but it does not explicitly state when to use it versus alternatives, nor does it provide exclusions or prerequisites. Usage is inferable only from the action itself.
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 the full burden of behavioral disclosure. It only states the tool's action without revealing potential side effects, privileges required, output behavior, or any limitations. The description is essentially a restatement of the tool name and adds no transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, directly stating the action. It is appropriately sized and front-loaded, with no wasted words. However, it is extremely brief, which slightly limits its value but does not affect efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which reduces the need to explain return values), the description is minimal and does not provide context about when to use the tool, what the output means, or any operational details. For a network diagnostic tool with two parameters, this level of description is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% coverage with descriptions for both parameters: 'target' as target IP or domain and 'interface' as outgoing interface. The description adds no additional meaning beyond the schema, 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 '执行 Traceroute 路由追踪' clearly states the tool's function: execute a traceroute. The verb '执行' (execute) plus the specific resource 'traceroute' distinguishes it from sibling diagnostic tools like ping_test, iperf_test, and speed_test. The purpose is unambiguous and 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 provides no guidance on when to use this tool versus alternatives. It does not mention use cases, prerequisites, or exclusions, leaving the agent without context for selecting this tool over other network diagnostics like ping_test or iperf_test.
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 carries the full burden of behavioral disclosure. It does warn about a critical side effect ('AP 会重启' – AP will restart), which is useful. However, it doesn't mention the confirm parameter's role or other potential impacts like service disruption or failure 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 extremely concise, with a single sentence and a warning emoji. Every token is useful, and it avoids redundancy. It is well-structured for quick comprehension, though it sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the existence of an output schema, the description lacks essential context: no parameter semantics, no usage guidance, and minimal behavioral detail. For a destructive operation with a confirmation flag, this is inadequate for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the parameters (ap_id, version, confirm). It does not add any meaning beyond the bare schema, failing to guide the agent on how to fill them correctly.
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 ('升级 AP 固件' = upgrade AP firmware) with a specific verb and resource. This distinguishes it from related tools like restart_ap and start_firmware_upgrade, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like restart_ap or get_ap_firmware_versions. The warning about reboot implies context, but no explicit when-to-use or when-not-to-use instructions are provided.
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 present, so the description carries the full burden of behavioral disclosure. It does not mention how the tool handles existing bindings, validation of IP/MAC formats, whether it overwrites, or any side effects on current DHCP leases. This is a significant gap 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, front-loaded sentence that conveys the essential purpose without unnecessary words. It is appropriately sized and easy to parse.
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 is simple and the purpose is clear, the description omits parameter details and usage context. An output schema exists but is not provided, and the agent must infer MAC/IP formats and error conditions elsewhere. It is minimally adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters with no descriptions, and the description does not explain expected formats (e.g., IP/MAC syntax) or the optional 'comment' parameter. With schema description coverage at 0%, the description fails to compensate, leaving parameter semantics ambiguous.
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 ('add') and the resource ('DHCP static allocation'), with a clarifying parenthetical '(IP-MAC binding)' that leaves no ambiguity. It distinguishes itself from sibling tools like 'list_dhcp_static_bindings' and 'delete_dhcp_static_binding' by specifying the creation operation.
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, nor any prerequisites or exclusions. The description is purely definitional and does not help an agent decide when to invoke it.
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?
The readOnlyHint annotation already declares the operation is read-only. The description adds no behavioral context beyond the name, such as what the log contains, time range, or pagination 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?
The description is a single, clear phrase with no wasted words. It is appropriately sized for a simple tool and front-loaded with the core 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?
Given the simple nature (no parameters, read-only, output schema exists), the description is minimally sufficient but lacks any contextual details about the log's contents or use cases. It could be more complete by mentioning what the log tracks or when to access 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, and the schema coverage is 100%. Per the rubric, a baseline of 4 is appropriate when no parameters exist, and the description doesn't need to explain parameter details.
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 retrieves DDNS logs, with a specific verb and resource. It distinguishes from siblings like get_ddns_config by the word 'log', though the differentiation is mostly inherent in the tool name itself.
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 gives no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, scenarios, or alternatives, leaving the agent without context for selection.
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 readOnlyHint annotation already signals a safe read operation, and the description adds no additional behavioral context such as data scope, refresh rate, or dependencies. It does not contradict the annotation, but it also adds no value beyond it.
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 short sentence with no wasted words. It is appropriately concise for a simple status retriever, though it could benefit from a bit more context about what diversion monitoring covers.
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?
Given the many sibling monitoring tools and the lack of explanation of what 'diversion monitoring' entails, the description is too terse to fully contextualize the tool. The empty schema and output schema reduce some burden, but the description does not help an agent decide when to use this tool over similar ones.
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 the empty schema fully covers parameter semantics. The description adds nothing, but none is needed since there is nothing to clarify.
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 retrieves the status of diversion monitoring, using a specific verb and resource. It does not elaborate on what 'diversion' refers to, but it is sufficiently specific to distinguish from many siblings, though it lacks explicit differentiation from similar monitoring tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus other monitoring tools like get_line_monitoring or get_policy_monitoring. The description provides no context, prerequisites, or exclusions, leaving the agent to guess the appropriate scenario.
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?
The description adds no behavioral information beyond the readOnlyHint annotation. It simply restates the operation in Chinese. No mention of authentication, response format, or side effects (though none expected).
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, succinct phrase that is easy to parse. It is appropriately sized for a trivial getter.
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 parameterless getter with an output schema, the description is minimally sufficient. However, it lacks contextual guidance (e.g., that it returns the router's own firmware, not AP firmware), which is a small gap given the sibling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description appropriately mentions nothing about parameters. The empty schema covers everything, so the description adds no parameter semantics, but none are needed.
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 retrieves the current firmware version, matching the tool name. However, it does not explicitly distinguish this from the sibling tool 'get_ap_firmware_versions', which could cause ambiguity about scope (router vs AP).
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 about when to use this tool versus alternatives. The description gives no context for selecting it over related firmware 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?
The description is consistent with the readOnlyHint annotation, confirming a safe read-only operation. However, it adds no extra behavioral context beyond what the annotation already provides, such as scope of returned data or network impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single phrase—but it basically mirrors the tool name in Chinese. While it is not overly verbose, it misses the opportunity to add useful context like return value specifics or how it differs from similar getters.
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 simplicity (no parameters, output schema provided), the description is minimally sufficient. However, it does not clarify what specific 'IPv6 LAN settings' are included or how this relates to sibling tools, leaving some ambiguity 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?
This tool has no parameters, and the input schema is fully covered. The description does not need to explain parameter semantics; the baseline for zero-parameter tools is 4, and the description does not introduce any ambiguity.
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 ('获取' meaning 'get') and the resource ('IPv6 内网设置' meaning 'IPv6 LAN settings'). It is specific and the term '内网' distinguishes it from WAN-related siblings, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like get_ipv6_config or get_ipv6_wan_config. The description does not mention any prerequisites, exclusions, or scenarios for use.
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?
The readOnlyHint annotation already indicates a safe read operation, so the description does not need to restate that. However, it adds no additional behavioral context such as data volume, time range limits, or performance considerations. The description is essentially a tautology of the tool name, providing no extra transparency.
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, short sentence that states the purpose without unnecessary fluff. It is structured in a front-loaded manner, with the verb and resource immediately clear. Although minimal, it earns its place by conveying the core function.
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 read-only getter with one optional parameter and an output schema, a detailed description is not strictly required. However, the description lacks any usage context or links to sibling tools, so completeness is moderate. The output schema already handles return value expectations, and the parameter schema handles input, leaving this description as the only missing piece for full contextual clarity.
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 for the single 'datetype' parameter, including a description of allowed granularities. The description does not add any parameter information beyond the schema, which is acceptable given the high schema coverage. The default value and description in the schema provide the necessary semantics.
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 retrieves memory historical usage data (获取内存历史使用数据), which is a specific verb+resource combination. It does not explicitly differentiate from sibling monitoring tools, but the focus on memory history 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case: when you need memory history data. However, it provides no explicit guidance on when to use this tool versus alternatives like get_load_monitoring or get_system_overview, nor any exclusions. The purpose statement itself carries the implied usage.
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?
The description merely restates the tool's name in Chinese and adds no behavioral context beyond what the readOnlyHint annotation already conveys. It doesn't disclose return format, log retention, or any other operational details.
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, compact phrase with no unnecessary words. It is appropriately sized for the tool's simplicity and front-loads the core 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 zero-parameter read-only tool with an output schema, the description is minimally adequate. However, it doesn't clarify what the push notification log contains or when to use this over sibling log/notification tools, leaving some contextual 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?
The tool has zero parameters, so the schema covers all input requirements (100% coverage). The baseline for zero parameters is 4, and the description doesn't need to explain anything further.
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 '获取推送通知日志' (Get push notification logs) clearly states a specific verb and resource. The inclusion of 'log' differentiates it from similar sibling tools like get_notifications, though it doesn't explicitly call out that distinction.
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 such as get_notifications, get_messages, or get_warnings. The description simply names the resource without explaining the intended use case or exclusions.
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?
The description adds no behavioral detail beyond the tool's name itself, making it essentially a tautology. The annotation readOnlyHint=true covers safety, but the description does not disclose what kind of warnings are returned, whether it's a snapshot or streaming, or any other behavioral traits. No contradiction with annotations, but no added value.
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 short phrase, which is maximally concise and front-loaded. It contains no unnecessary words or repetition, and every character earns its place for such a simple tool.
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 simplicity (no parameters) and presence of an output schema, the description is minimally adequate but lacks contextual differentiation from sibling tools. It does not clarify the scope or source of warnings, which could be important for the agent to choose it correctly. The output schema fills in return value details, so the description's completeness is just below 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 tool has zero parameters, and the schema is empty with 100% coverage. The description correctly omits parameter details since none exist. This aligns with the baseline of 4 for a zero-parameter tool.
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 '获取告警信息' (get warning information) clearly states the tool's action and resource. However, it does not distinguish from sibling tools like get_notifications, get_system_event_log, or get_messages, which could also relate to warnings in different contexts. Thus it is clear but not sibling-differentiated.
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. There is no mention of prerequisites, typical scenarios, or exclusions. Given the large number of sibling get_* tools, explicit usage guidelines are absent.
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?
The description adds no behavioral information beyond what the readOnlyHint annotation already provides. It does not mention output format, pagination, or any other traits, so it fails to add value beyond the structured metadata.
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 short sentence, which is concise and front-loaded with the essential verb and resource. It is efficient with no wasted words, though it is minimal and offers no additional context.
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 (no parameters, output schema present, read-only annotation), the description sufficiently conveys the core purpose. However, it would be more complete if it clarified what qualifies as a 'custom protocol' to differentiate from sibling tools.
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 the input schema is empty, so the schema fully documents the input. A baseline of 4 is appropriate since no parameter explanation is necessary.
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') and the resource ('custom protocols'), so the primary purpose is evident. However, it does not distinguish from the sibling tool 'list_advanced_custom_protocols' or clarify the scope, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as 'list_advanced_custom_protocols' or 'list_protocol_groups'. The description merely states the action without any contextual cues for selection.
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?
The description simply restates the operation and adds no behavioral context beyond the readOnlyHint annotation. It does not mention scope, pagination, filters, or any side effects. Since annotations already declare it safe, the description fails to add any extra useful behavior information.
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 phrase with no redundant words. It is front-loaded and does not waste any space, making it highly 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?
The tool is simple with no parameters and an output schema, so the description need not explain return values. However, the phrase "expiry notices" is somewhat ambiguous, especially given the existence of a similarly named sibling tool. The description is minimally sufficient but lacks clarity about what constitutes an "expiry notice."
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 captures all needed input. The description doesn't need to compensate for any parameter documentation gaps; the baseline for zero parameters is 4.
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 "列出到期通知" translates to "List expiry notices," providing a clear verb and resource. However, it does not distinguish from the similar sibling tool "list_dial_user_expiry_notices," so it lacks sibling differentiation.
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 relative to other list_* tools. There are no context signals, exclusions, or alternative tool references. The description is a bare phrase with no usage context.
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?
The readOnlyHint annotation already indicates a safe read operation, but the description adds no additional behavioral context. It does not state that all protocol forwarding rules are returned, whether any filtering or pagination applies, or what the output contains. Beyond the annotation, the description provides zero 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, front-loaded sentence that directly states the tool's function. It is appropriately concise for a zero-parameter read-only list operation, with no filler or redundant 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?
Given the tool's simplicity (no parameters, read-only, output schema exists), the description is minimally adequate. However, it does not clarify the exact scope of 'protocol diversion rules' or distinguish them from closely related forwarding rule types, leaving some ambiguity in a crowded sibling context. The presence of an output schema partially compensates for missing return-value details.
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 fully covers all inputs (vacuously). Baseline for 0 params is 4; the description does not need to explain any parameter details. No additional parameter semantics are required.
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) and the resource (protocol diversion/forwarding rules), making the tool's purpose obvious. It distinguishes from sibling tools that list port or domain forwarding rules by specifying 'protocol', though it does not explicitly contrast with those alternatives.
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 guidance is provided. The description does not indicate when to use this tool over the many sibling list tools (e.g., list_app_protocol_rules, list_port_forwarding_rules), nor does it mention any prerequisites or intended scenarios.
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?
Descriptions carries full burden since no annotations exist. It only states the core action without disclosing behavioral traits such as whether existing SSH sessions are affected, whether a service restart occurs, or if special permissions are needed. This is minimal for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase with zero wasted words. It is perfectly concise and structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple enable/disable operation with a fully documented schema and an output schema, the minimal description is mostly adequate. However, the lack of behavioral transparency and usage guidance leaves gaps for an agent needing to assess side effects or prerequisites.
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% (both 'enabled' and 'port' have descriptions). The description adds no extra parameter meaning, so the baseline of 3 is appropriate—the schema handles 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 clearly states the action: '启用/禁用 SSH 服务' (enable/disable SSH service). This specifies the verb and resource precisely, and distinguishes it from sibling tools like enable_telnet or enable_ftp.
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 guidance is provided. The description does not mention when to use this tool versus alternatives, preconditions, or situations where SSH should not be toggled. The context is entirely implied by the tool name.
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 readOnlyHint annotation indicates a safe read operation, but the description adds no extra behavioral details (e.g., data scope, pagination, or permissions). It neither contradicts the annotation nor provides meaningful additional context.
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 extremely concise with no wasted words, but it is a fragment rather than a complete sentence. It earns a high score for brevity but lacks a structured explanation.
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 zero-parameter read-only getter with an output schema, the description is minimally viable. It lacks any usage context or clarification about what 'connection table' refers to, but the output schema may compensate for return value details.
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. With 0 params, the baseline is 4, and the description need not add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear 'get' operation for the connection/flow table, distinguishing it from sibling tools like get_routing_table and list_connection_limits. However, the phrasing '获取流表/连接查看' is terse and could be more explicit about what the table contains (e.g., active sessions or NAT entries).
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 vs alternatives. Among the many get_* and list_* siblings, there is no context or comparison to help an agent select this tool selectively.
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?
The description only restates the tool's function and adds no behavioral details beyond what the readOnlyHint annotation already provides. It doesn't mention return format, potential errors, or any other operational characteristics, offering zero extra 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 short phrase with no filler words or unnecessary information. It is extremely concise and front-loaded, making it easy to parse and understand at a glance.
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 parameterless getter with an output schema present, the description is adequate. It identifies the resource clearly, and the output schema covers return values. However, it could mention what '透传配置' includes or whether any special states exist, but given the low complexity, this is minor.
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 is 4. The description doesn't need to explain parameters, and no additional meaning is required. The schema confirms no parameters exist, and the description aligns with this.
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 '获取 IPTV 透传配置' (get IPTV passthrough configuration) clearly states the action (get) and the resource (IPTV passthrough config). It is more specific than the tool name alone by adding '透传' (passthrough), but it doesn't explicitly differentiate from other get_* config tools in the sibling list, so it's 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as get_ipv6_config or get_dns_config. It provides no context on use cases, prerequisites, or exclusions, making it hard for an agent to decide when to select this tool.
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?
The description adds no behavioral context beyond what the readOnlyHint annotation already states. It does not disclose what the config content represents, whether it requires authentication, or any caveats about sensitive data. The annotation covers read-only safety, but the description contributes no extra 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, concise sentence with no unnecessary words. 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?
For a simple no-parameter read-only getter with an output schema and readOnly annotation, the description is minimally sufficient. However, it could benefit from noting that this returns client config as opposed to server config, or that it may contain sensitive keys. Given the low complexity, the current level is fairly 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, so the baseline is 4. The description adds no parameter semantics, but none are needed. The schema is trivially complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取 OpenVPN 客户端配置' clearly states the verb (get) and resource (OpenVPN client configuration). It distinguishes from sibling tools by explicitly naming OpenVPN, although it essentially restates the tool name without additional detail.
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 like get_pptp_client_config or get_openvpn_server_config. The description lacks any mention of context, prerequisites, 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?
The description aligns with the readOnlyHint annotation, confirming a safe read operation. No additional behavioral traits are disclosed, but due to the simple getter nature with zero parameters, the annotation suffices. The description adds no extra context beyond the action.
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 extremely concise, a single phrase that front-loads the action and object without waste. However, it is so terse that it reads more like a translation of the tool name than an explanatory description, losing an opportunity to add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and an output schema available, the description's minimalism is acceptable. Yet it lacks any context about the nature of the security advanced settings or when to use them, which would help the agent differentiate this getter from many similar siblings. It is a minimum-viable description.
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 takes zero parameters, so there are no parameter semantics to explain. The baseline of 4 applies since the description is not burdened with parameter documentation.
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 '获取安全中心高级设置' translates to 'Get security center advanced settings.' It clearly states the action (get) and the resource (security center advanced settings), distinguishing it from siblings by its specific focus. However, it does not elaborate on what 'advanced settings' includes, so it is clear but not detailed.
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 or which alternatives might be more appropriate. The description is a bare statement without context, prerequisites, or comparison to related tools.
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?
The readOnlyHint annotation already indicates this is a safe read operation. The description adds no additional behavioral context such as what the configuration includes, whether authorization is needed, or any side effects. It is effectively a restatement of the tool name.
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 front-loads the core purpose. It contains no unnecessary words or filler.
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), the existing output schema, and the read-only annotation, the description is mostly complete. It adequately conveys the tool's purpose, though it omits usage context and any details about the expected output, but the output schema covers the return representation.
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 fully covers all parameter semantics. The baseline score of 4 applies because there is nothing for the description to add 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's function: getting the tcpdump/package capture tool configuration. It uses a specific verb and resource, distinguishing it from other configuration getters, though it does not explicitly name alternatives or add extra distinguishing context.
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 alternative tools. It only states the action without any context about scenarios, prerequisites, or exclusions.
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?
The description adds no behavioral context beyond the readOnlyHint annotation. It merely restates the tool's purpose without mentioning output format, filtering, pagination, or any other 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?
The description is a single short, front-loaded phrase that conveys the essential purpose. It is appropriately concise with 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 zero-parameter read-only log retrieval tool with an output schema present, the description is reasonably complete. It clearly states what records are returned, though it could benefit from a bit more context about what 'terminal' refers to, but the sibling tools and output schema reduce the need.
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 the schema description coverage is 100% (empty schema). With no parameters to explain, the description does not need to add parameter information; the baseline for 0 params is 4.
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 retrieves terminal online/offline records. It has a specific verb and resource, but it does not explicitly differentiate from sibling log tools like get_auth_log or get_wireless_terminal_log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description only states what it does without any contextual cues about appropriate scenarios or exclusions.
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 provided, the description carries the full burden of behavioral disclosure. It only states the action without revealing that the test runs for a specified duration, requires a reachable iPerf server, or returns throughput metrics.
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, concise sentence that is front-loaded with the action, containing no extraneous content.
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 schema documents parameters and an output schema exists, but the description omits context about execution behavior, such as blocking nature, network requirements, or result interpretation. This leaves some gaps for a diagnostic 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?
The input schema covers 100% of parameters with descriptions. The tool description adds no additional parameter semantics 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 '执行 iPerf 吞吐测试' (Execute iPerf throughput test) clearly states the verb and resource, identifying this as an iPerf-specific throughput test. It distinguishes from sibling tools like ping_test and speed_test by specifying the iPerf protocol.
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 like speed_test or ping_test. The description lacks context about use cases, prerequisites, or exclusions.
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?
The readOnlyHint annotation already indicates this is a safe read operation. The description adds no behavioral traits beyond the tool's purpose—no mention of pagination, scope, or output behavior. It is essentially a restatement of the tool name and contributes nothing beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and front-loaded. However, it merely restates the tool name in Chinese, adding no new information. It is not bloated but also does not earn its place substantively, making it average for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with no parameters and an output schema, the description is minimally viable. It tells the agent it lists connection limits but lacks additional context about the scope (e.g., all rules), possible interactions with other tools, or edge cases. The presence of an output schema mitigates some gaps, but the description alone is thin.
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 for parameter semantics is 4. The description does not need to explain parameters, and the lack of filters in the description implies the tool lists all connection limits without any input constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists connection limit rules ('列出连接数限制规则'), using a specific verb ('list') and a specific resource ('connection limit rules'). It distinguishes from sibling tools like add_connection_limit and delete_connection_limit by the listing action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or reference to sibling add/delete tools, leaving the agent without usage context.
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?
The description adds no behavioral context beyond the readOnlyHint annotation, which already signals a safe read operation. It does not describe the response format, the effect of ip_type, or any edge cases, so it relies entirely on the annotation for safety 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 concise phrase that states the tool's purpose without unnecessary words. It is appropriately front-loaded and easy to parse, though it is minimal.
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 low complexity (one optional parameter), the readOnlyHint annotation, and the presence of an output schema, the description is minimally sufficient but adds no context about the contents or behavior of the black/white list. It does not mention the ip_type filter or any usage notes, so it is not fully contextual.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the ip_type parameter with a description ('v4' or 'v6'), so the description's lack of parameter detail is acceptable. The parameter is optional and has a default, and the description contributes nothing further, yielding a baseline score.
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 '列出 DHCP 黑白名单' clearly states a list operation on the DHCP black/white list with a specific verb and resource. It distinguishes from sibling tools like list_wireless_blackwhite_list by explicitly scoping to DHCP.
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. The description simply states the action and does not mention any conditions, prerequisites, or exclusions relative to other list 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?
The readOnlyHint annotation already indicates this is a safe read operation. The description adds no additional behavioral context such as pagination, ordering, or return format. It is consistent with the annotation but does not go beyond it.
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, short phrase that is efficient and front-loaded. It is not verbose, but it also adds no information beyond the tool name itself. For such a simple tool, this is acceptable, though slightly under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema provided, the description does not need to explain return values. However, the tool is part of a large family of domain-related list operations, and the description does not help the agent understand where domain groups fit or which sibling to choose. It is minimally sufficient but not fully 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, and the schema confirms this with an empty object. There are no parameter semantics to explain, and the baseline of 4 applies for zero-parameter tools. The description does not need to add parameter details.
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 '列出域名分组' translates to 'List domain groups', which clearly states the action (list) and resource (domain groups). It distinguishes from sibling tools like list_ip_groups and list_mac_groups by naming the specific resource. However, it does not elaborate on what a domain group is or its purpose, so it is clear but not fully precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention context like 'use this to view domain groups for ACL rules' or differentiate from list_domain_blacklist or list_domain_forwarding_rules. There is no implied usage beyond the literal action.
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 readOnlyHint annotation already discloses that this is a safe read operation, so the description does not need to restate that. The description adds minimal context with 'tab: 关键字替换', but it does not describe other behavioral traits such as whether all items are returned, pagination, or the structure of the results. It is consistent with the annotation and adds a little context, so a score of 3 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 very brief and front-loaded with the verb. The parenthetical '(tab: 关键字替换)' adds a small UI context but is somewhat cryptic. It is concise overall, but the parenthetical could be considered less essential. Still, it earns its place as a navigational hint.
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 simplicity of the tool (0 params, read-only, output schema exists), a short description might suffice. However, the description does not explain what 'URL keyword replacement' means, nor does it provide any domain context or alternative usage. Since there is an output schema, return values are covered, but the overall context is minimal and the description is in Chinese, which might reduce clarity for non-Chinese agents.
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 input schema is complete and there is nothing for the description to explain about parameters. The baseline for 0-parameter tools is 4, and the description does not need to add anything here.
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 '列出 URL 关键字替换' clearly states the action (list) and the resource (URL keyword replacement). It is specific enough to know it lists URL keyword replacement rules. However, it does not explicitly distinguish itself from similar sibling tools like list_url_params_replace, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions. This is a simple list command, but usage guidance is completely absent.
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?
The readOnlyHint annotation already covers safety, but the description adds no behavioral context—no mention of output details, pagination, or constraints. It does not contradict annotations, but it also does not provide any extra behavioral insight, so a low score is warranted.
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, short sentence with no wasted words. It is minimal but not verbose, achieving perfect conciseness.
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 zero-parameter list tool with an existing output schema and read-only annotation, the description covers the essential purpose. It lacks usage differentiation, but that is already penalized in the guidelines dimension, so the completeness score reflects the tool's overall adequacy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%. With no parameters to describe, the description has no additional burden, and the baseline of 4 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 tool lists wireless black/white lists, identifying a specific verb and resource. However, it merely restates the tool name with no additional differentiation from similar list tools like list_dhcp_blackwhite_list, so it does not fully reach the 5-level of distinguishing from siblings.
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 about when to use this tool versus alternatives, such as list_dhcp_blackwhite_list. The description offers no context on prerequisites, use cases, or exclusion criteria, leaving the agent without direction.
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 the full burden. It discloses the toggle action but does not mention side effects, reversibility, prerequisites, or impact on traffic. This is a significant gap 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 clear sentence with no redundancy or waste. It is appropriately front-loaded with the action and resource.
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?
Given the tool's simplicity, the description is incomplete. It does not explain what 'smart flow control' does, which interface to use, or what happens upon enabling/disabling. The presence of an output schema mitigates return-value concerns, but the description still lacks critical context for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the parameters. The description mentions '某条线路' but does not map it to the 'interface' parameter or clarify possible values. The 'enabled' boolean is self-evident, but the interface parameter remains ambiguous.
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 (enable/disable) and the resource (smart flow control for a specific line). This distinguishes it from sibling getter tools like get_flow_control_lines and other setter tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you want to enable or disable smart flow control on a line) but does not explicitly state alternatives or when-not-to-use. No exclusions are mentioned, so it provides clear context but lacks direct guidance on alternative tools.
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?
There are no annotations to provide safety or side-effect information, so the description carries the full burden. It only says 'enable/disable ACL rule' and does not disclose whether the rule must exist, whether it is idempotent, or what happens if the rule is already in the desired state. This is a significant gap for a mutating operation without any 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one short phrase—and gets straight to the point. It avoids unnecessary words, but it is so terse that it borders on under-specification. For a simple toggle operation, this level of brevity is mostly appropriate, earning a slight reduction for missing essential context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two simple parameters and an output schema, so the description need not explain return values. However, it lacks behavioral details like error conditions or state transitions. For a straightforward toggle, the description is minimally viable but not complete enough to fully guide an agent without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the description must compensate for two parameters (rule_id and enable). It only states the overall purpose and does not explain that 'enable' is a boolean controlling the action or that 'rule_id' identifies the rule. The description adds minimal value beyond the schema's property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: enabling/disabling an ACL rule. It uses a specific verb ('toggle') and a specific resource ('ACL rule'), which distinguishes it from sibling tools like delete_acl_rule or add_acl_rule. Even though it's a short phrase, it precisely conveys the tool's function.
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 gives no explicit when-to-use guidance or alternatives. However, the tool's purpose is self-evident: you use it when you need to enable or disable an existing ACL rule. It doesn't mention exclusions or compare with other toggle tools (e.g., toggle_vpn_server), but the action is simple enough that the implied usage might suffice.
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 disclosure, but it only says 'send network wake-up packet'. It does not disclose whether this is a mutation, what side effects occur, whether it requires the target to be powered off, or any rate/access 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 is a single, short sentence that conveys the core purpose with no wasted words. It is front-loaded and appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has low complexity, schema covers parameters, and an output schema exists, so return values need not be described. However, the description lacks usage guidelines and behavioral transparency, which are important for a network-mutating action, leaving a moderate 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?
Schema description coverage is 100%, with clear descriptions for both 'mac' and 'interface'. The tool description adds no additional parameter meaning, so the baseline of 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?
The description clearly states the action: '发送网络唤醒包' (send network wake-up packet), which is a specific verb+resource. It unambiguously differentiates this tool from all siblings, none of which perform Wake-on-LAN.
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 vs alternatives, nor are there prerequisites or exclusions. The description simply states the action without context, leaving the agent to infer usage.
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 readOnlyHint annotation already signals a safe read operation, and the description's 'get' wording is consistent. No extra behavioral context is added, but it does not contradict the annotation and adequately describes the primary 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?
The description is a single, concise phrase that is front-loaded with the action and resource. Every word earns its place, and there is no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and has an output schema, so the description covers the basic function. However, the existence of the sibling 'get_ddns_config' creates ambiguity that is not addressed, making the description incomplete for tool disambiguation.
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 zero parameters, so the description does not need to explain parameter usage. The baseline for no-parameter tools is 4, and the description does not need to compensate for missing schema details.
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 '获取' (get) and identifies the resource '动态域名 (DDNS) 配置', making the tool's purpose clear. However, it does not distinguish itself from the sibling tool 'get_ddns_config', which appears to have the same purpose.
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. There is no mention of the similarly named 'get_ddns_config' or related DNS/DHCP tools, leaving the agent without selection criteria.
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 is consistent with the readOnlyHint annotation (read operation), so there is no contradiction. However, it adds no additional behavioral context beyond the annotation—no information about what the configuration contains, return format, or caveats. With annotations covering the safety profile, this is adequate but not enhanced.
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 phrase, front-loaded with the action verb. It is appropriately sized for a zero-parameter getter with no unnecessary 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?
Given the simplicity of the tool (no parameters, read-only, output schema exists), the description is minimally sufficient. However, it lacks any contextual information about what '内网穿透配置' includes, when this tool is relevant, or how the output is structured, leaving some ambiguity for an agent operating in a large sibling set.
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 the input schema confirms this with an empty properties object. The description adds no parameter information, but there is nothing to elaborate on, so the baseline of 4 for zero parameters applies.
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 verb 'get' and the resource 'intranet penetration configuration', which aligns with the tool name. However, it doesn't add extra scope or explicitly distinguish itself from the many sibling get_*_config tools, so it's clear but not strongly differentiated.
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 guidance is provided. The description does not mention when to use this tool over alternatives, any prerequisites, or exclusions. Usage is only implied by the 'get' verb, which is insufficient for an agent deciding between this and similar config getters.
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?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds no extra behavioral context (e.g., return format, side effects), but given the simplicity of the tool, the annotation is sufficient. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase, front-loaded with the key action and resource. No wasted words, perfectly sized for the simplicity of the tool.
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 zero-parameter read-only tool with an output schema, the description is minimally adequate. However, it does not clarify the exact scope of 'total config' or point users to more specific alternatives, leaving slight ambiguity about what the output contains.
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 provides complete coverage. The description does not need to explain parameter semantics; the baseline for zero parameters is 4.
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 it retrieves the overall IPv6 configuration, distinguishing it from more specific IPv6 tools like get_ipv6_wan_config and get_ipv6_lan_config. The verb '获取' (get) and resource 'IPv6 总配置' make the purpose clear.
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. The sibling list implies there are more specific IPv6 config tools, but the description does not mention them or provide any 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?
The annotation readOnlyHint=true already discloses that this is a safe read operation. The description adds no further behavioral context (e.g., whether it queries live data, required permissions, or response structure). Since annotations cover the primary safety profile, a neutral score is appropriate, but the description adds zero value beyond the annotation.
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, efficiently worded sentence that directly states the purpose. There is no fluff, repetition, or unnecessary detail. Every word 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?
The tool is a simple getter with no parameters and an output schema, so the description doesn't need to explain return values. However, it lacks contextual completeness in differentiating this from other IPv6 getter tools. Given the sibling list, an agent might struggle to know exactly what 'line detail' means versus 'config' or 'WAN/LAN config'. The description is adequate but not rich enough to fully resolve 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?
The tool has zero parameters and the schema coverage is 100%, so the baseline for this dimension is 4. The description correctly includes no parameter explanations because there are none. It does not add any extra semantic detail, but none is needed.
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 '获取 IPv6 线路详情' clearly states the tool's function: retrieving IPv6 line details. It uses a specific verb and resource, and the tool name itself distinguishes it from siblings like get_ipv6_config, get_ipv6_wan_config, and get_ipv6_lan_config. However, it does not explicitly contrast with these alternatives, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings. Given the existence of several IPv6-related getters, an agent needs more context to confidently choose this specific tool. No exclusions or alternative references are provided.
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 readOnlyHint annotation already indicates a safe read operation. The description adds that it returns a 'list', which is a minor behavioral detail. No other traits (e.g., pagination, ordering, real-time vs cached) are disclosed, but for a simple getter the bar is lower.
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: a single sentence with no filler or redundancy. It is front-loaded with the action and resource, effectively using the space.
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 zero-parameter, read-only nature and presence of an output schema, the description is minimally complete for invocation. However, it lacks clarity on what 'downlink switches' means and offers no guidance on when to use this tool versus other device-listing tools, so it is adequate but has gaps.
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 is 4. The description does not need to explain any parameters, and the empty schema provides complete coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('获取...列表' = get list) with a specific resource ('下联交换机设备' = downlink switch devices). It distinguishes itself from sibling tools like get_ap_devices or get_camera_devices by the resource type, though it does not explicitly mention alternatives or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No context, prerequisites, or exclusions are provided. The description only states what it does, not when to choose 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 annotation readOnlyHint=true already communicates the read-only nature, so the description need not restate it. The description adds no extra behavioral context (e.g., what data is returned, whether it requires authentication), but it does not contradict the annotation.
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 short sentence with no unnecessary words. It is concise and front-loaded, conveying the purpose efficiently.
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 presence of an output schema, readOnlyHint annotation, and zero parameters, the description does not need to explain return values or parameter details. However, it is minimal and does not elaborate on what 'protocol control' means or when this configuration is relevant, leaving some room for interpretation.
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 provides no parameter semantics. The description does not need to explain parameters, and the baseline of 4 applies since no parameters exist.
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 indicates this tool retrieves protocol control configuration, with a specific verb and resource. However, it does not differentiate this tool from the many other get_* siblings, so it is clear but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any mention of exclusions or prerequisites. The description only states what the tool does, not when it should be invoked.
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?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds the 'current' qualifier, implying a real-time snapshot, but offers no additional behavioral context such as output format or potential performance implications.
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, front-loaded with the essential purpose. It contains no filler or repetition, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and an output schema present, the description is sufficiently complete. It conveys the core functionality without needing to explain return values or elaborate on the ip_type filter since the schema covers that.
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 one optional parameter (ip_type) with a clear description ('v4' or 'v6'), achieving 100% schema description coverage. The tool description does not add any extra meaning beyond what the schema already provides, so a baseline 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 identifies the action (view) and resource (current routing table). It is specific enough to distinguish from other network tools, though it does not explicitly differentiate from sibling tools like list_static_routes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it shows the live/current routing table as opposed to static route configuration, nor does it reference any sibling 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?
The annotation readOnlyHint=true already indicates a safe read operation, so the description's burden is lowered. The description adds the L7 scope constraint, but it does not disclose any additional behavioral characteristics (e.g., pagination, sorting, or return format). This is adequate but not rich, matching the baseline of a simple read-only list 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, front-loaded sentence with no redundant words. It conveys the essential purpose efficiently and contains no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (zero params, read-only, output schema exists), so the description is mostly sufficient. However, the close sibling 'list_custom_protocols' creates ambiguity that the description does not address, and it lacks any contextual detail about what makes these protocols 'advanced' or how they differ from other list tools.
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 zero parameters, so the baseline is 4. The description does not need to explain parameter semantics since there are none, and the schema coverage is trivially 100%.
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') and the resource ('advanced custom protocols') with an L7 scope qualifier. However, it does not explicitly differentiate this from the closely named sibling tool 'list_custom_protocols', which is implied by the name but not stated in the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 such as list_custom_protocols or list_protocol_groups. There is no mention of scenarios, exclusions, or prerequisites, leaving the agent without sufficient context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a non-mutating operation, and the description 'list' is consistent with that. However, the description adds no additional behavioral details such as whether all bindings are returned, pagination limits, or output format. With annotations covering the main safety aspect, a baseline score of 3 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 extremely concise, using a single short phrase. While it is slightly redundant ('list ARP binding list'), it is appropriately sized for a simple no-parameter list operation and does not waste 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 has no parameters, a readOnlyHint, and an output schema, the description is minimally sufficient for correct invocation. It does not explain the exact scope of bindings or return structure, but the output schema covers return values and the operation is straightforward. The missing usage guidance is captured in dimension 2.
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 zero parameters and 100% coverage, so no parameter explanation is needed. The description adds nothing about parameters, but none exist. Baseline for 0 params is 4.
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 '列出 ARP 绑定列表' clearly states the action (list) and the resource (ARP bindings), which matches the tool name. It distinguishes from sibling mutation tools like add_arp_binding and delete_arp_binding by indicating a read-only listing operation, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 related list tools such as list_ipv6_neighbors or list_dhcp_static_bindings. There is no mention of context, prerequisites, or alternatives, leaving the agent without selection criteria.
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 readOnlyHint annotation already declares a read-only operation, and the description adds the tab context as minor behavioral context. No mention of pagination, sorting, or data scope, but the output schema likely covers return values. The description is consistent with the annotation, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Chinese, efficiently stating the tool's purpose. It is front-loaded and contains no filler, though it is minimal and could be slightly more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with no parameters, an output schema, and a readOnlyHint, the description is adequately complete. It clearly identifies the resource, and the surrounding sibling context confirms it is one of many CRUD operations. It could mention that it returns the full list or any sorting, but these are likely in the 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?
With zero parameters, there is no need for the description to explain parameter semantics. The input schema is empty, and the baseline of 4 applies because there is nothing to compensate for.
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 the specific verb '列出' (list) with the resource '自定义网址库' (custom URL library), clearly indicating a list operation. It distinguishes from sibling tools like add_custom_url_library and delete_custom_url_library by the verb, though it does not explicitly mention alternatives.
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. The only additional context is the tab name '自定义网址库', which hints at a UI location but does not explain use cases, prerequisites, 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?
The readOnlyHint annotation already indicates this is a safe read-only operation. The description adds the IP version scope but does not disclose additional behavioral traits such as default filtering behavior when ip_type is omitted, pagination, or output format. Given the annotation, this is acceptable but could be richer.
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 with no fluff. It is appropriately sized for a simple list operation.
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 tool with one optional parameter, readOnlyHint, and an output schema, the description covers the basic purpose but leaves the ip_type parameter semantics ambiguous. It does not clarify whether the parameter filters by IP version or what values are accepted, which is a notable gap. Still, with the output schema present, it is quite complete overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single parameter ip_type with no description, and schema description coverage is 0%. The description's parenthetical 'IPv4/IPv6' hints at the parameter's possible values but does not explicitly name the parameter or explain how to use it. This is insufficient compensation for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '列出' (list) and a specific resource 'IP 地址分组' (IP address groups), with the parenthetical 'IPv4/IPv6' indicating the IP version scope. This clearly distinguishes it from sibling list tools like list_mac_groups or list_domain_groups.
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, nor any prerequisites or exclusions. It simply states the function without any context about 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely restates the operation implied by the tool name and adds no behavioral detail beyond the readOnlyHint annotation. No information is provided about output structure, potential side effects, or operational constraints.
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, short sentence with no filler or redundant phrasing. It is appropriately sized for a simple zero-parameter list operation.
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 read-only list tool with no parameters and an output schema, the description sufficiently conveys the tool's function. The output schema covers return-value details, and the operation is simple enough that no further context is necessary.
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 is empty, so the baseline for zero-parameter tools is 4. There are no parameter semantics to explain, and the description has no additional burden in this area.
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 '列出' (list) and a clear resource 'IPv6 邻居列表' (IPv6 neighbor list), making the tool's basic purpose understandable. However, it does not explicitly differentiate this from sibling tools such as list_ipv6_static_bindings or get_ipv6_config, so it falls short of full sibling distinction.
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. There is no mention of use cases, exclusions, or contrasting sibling tools, leaving the agent without selection 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?
The readOnlyHint annotation already indicates this is a safe read operation, and the description's 'list' verb is consistent with that. However, the description adds no behavioral context beyond the name, such as what data is returned or any limitations. With annotations covering the safety profile, this is acceptable but not enriched.
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, short, front-loaded sentence with no wasted words. It is appropriately sized for a simple read-only list operation.
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 low complexity (0 parameters, read-only, output schema exists), the description is minimally viable. However, it lacks any clarification of what 'static assignments' means in this context (e.g., DHCPv6 vs. prefix delegation), and does not mention related tools. The output schema covers return structure, but usage context is still thin.
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 fully covers them (100% coverage by virtue of being empty). The description adds no parameter details, but none are needed. Baseline for 0 parameters is 4.
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 '列出 IPv6 前缀静态分配' clearly states a list operation for IPv6 prefix static assignments, which is specific and distinguishable from siblings like list_dhcp_static_bindings. However, it does not explicitly differentiate from similar IPv6-related list tools, preventing a higher score.
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 such as list_ipv6_neighbors or list_dhcp_static_bindings. There is no mention of context, prerequisites, or exclusion criteria, leaving the agent without direction.
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 simply states 'list protocol groups', which aligns with the readOnlyHint annotation. It adds no additional behavioral context such as pagination, filtering, or the meaning of protocol groups. However, given the annotation already indicates a safe read operation, the description is not misleading.
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, short phrase that directly states the operation. It is concise but borders on tautological, repeating the tool name without elaboration.
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 parameterless, read-only listing tool with an output schema, the description is minimally adequate. It conveys the basic operation but lacks context about what protocol groups are or how they relate to other tools.
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 empty schema covers everything. Per the rubric, the baseline is 4; the description adds no parameter semantics but doesn't need to.
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 Chinese description '列出协议分组' translates to 'list protocol groups', clearly indicating a read-only listing operation. However, it does not differentiate itself from sibling tools like list_custom_protocols or list_port_groups, which also list protocol-related entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or exclusions, leaving the agent without context on when to invoke 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 readOnlyHint annotation already indicates a safe read operation. The description adds a minor UI context (tab location) but does not disclose other behavioral traits like whether both black and white entries are returned or how pagination works. Since annotations cover the safety profile, a 3 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a parenthetical tab reference. It is extremely concise and front-loaded with the verb and resource, containing no unnecessary 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 tool is simple with no parameters and has an output schema, so a minimal description is acceptable. However, the description says '黑白名单' (black/white list) while the tool name says 'blacklist', creating ambiguity about the exact scope. This gap in clarity affects 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 no parameters, and the schema is empty with 100% coverage. The description does not need to explain parameter semantics, and the baseline for 0 params is 4.
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 lists the URL black/white list with a specific verb ('列出' = list) and resource ('网址黑白名单' = URL black/white list). It is distinguishable from related siblings like list_domain_blacklist, though it doesn't explicitly differentiate itself.
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 only a UI tab reference ('tab: 网址黑白名单') and no guidance on when to use this tool versus alternatives such as list_domain_blacklist or delete_url_blacklist. No exclusions or alternative recommendations are given.
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 disclosure. It only states the toggle action but fails to disclose effects such as whether disabling drops existing PPPoE sessions, whether a restart is required, or whether the change persists across reboots. For a state-changing operation, this is a notable gap.
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 short phrase that directly states the action and resource. It is appropriately sized for a simple toggle function with one parameter, containing no wasted words or redundant information.
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?
Although the tool is simple (one boolean parameter), it controls a server that may have active users, as evidenced by sibling tools like list_pppoe_online_users and kick_pppoe_user. The description provides no consequences, prerequisites, or impact information, making it incomplete for a potentially disruptive network 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 description's "启用/禁用" aligns with the single boolean parameter `enabled`, implying true enables and false disables. However, schema description coverage is 0%, and the description does not elaborate on the parameter's meaning beyond what the parameter name already suggests, nor does it mention any nuances or consequences of setting it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: "启用/禁用 PPPoE 服务端" (enable/disable PPPoE server). It clearly identifies the target operation and distinguishes itself from sibling toggle tools like toggle_vpn_server and toggle_acl_rule by mentioning the specific resource (PPPoE).
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 (when to change the PPPoE server state) but provides no explicit context, alternatives, or exclusions. It does not mention checking current state with get_pppoe_server_config or warn about disconnecting active users, leaving the usage guidance implicit rather than explicit.
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 provided, the description carries the full burden of behavioral disclosure. It only states the basic action (enable/disable) without revealing side effects, whether active Telnet sessions are terminated, persistence across reboots, or required permissions. For a state-changing tool, this lack of transparency is a significant gap.
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 phrase 'Enable/Disable Telnet Service' with no filler or redundant words. It is front-loaded with the key action and resource, making it immediately clear. Every word 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?
Given the low complexity (one boolean parameter) and the presence of an output schema, the description covers the core function and the schema clarifies the parameter. However, with no annotations and no mention of operational context (such as service availability or security implications), the description is only minimally sufficient. It's enough to understand what the tool does but omits surrounding details that could affect invocation.
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 documents the 'enabled' boolean with descriptions for True (Enable) and False (Disable), giving 100% schema coverage. The tool description merely restates this mapping without adding new meaning. It doesn't explain edge cases like idempotency or the effect of setting the same value twice, so it meets the baseline but adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Enable/Disable Telnet Service' clearly uses a specific verb and resource, directly stating the tool's action. It distinguishes itself from siblings like enable_ssh and enable_ftp by explicitly naming Telnet, leaving no ambiguity about which service it controls.
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 through its action statement—use this tool when you need to turn Telnet on or off. However, it provides no explicit comparison to alternatives, no mention of prerequisites, and no guidance on when not to use it. The usage is self-evident from the name and description, but no extra context is given.
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 annotation readOnlyHint=true already indicates a read-only operation, and the description aligns with that. No additional behavioral details such as data freshness, required context, or relationship to AP optimization records are disclosed; however, the simple getter nature makes this acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that clearly states the tool's action. It contains no redundant words or irrelevant details, making it highly 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 zero-parameter schema, presence of an output schema, and read-only annotation, the description provides sufficient context for basic usage. The term 'AP optimization status' is slightly vague but still understandable; it would be improved by a brief mention of what the status includes or how it relates to other optimization tools.
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 zero parameters, so the description is not expected to explain parameter meaning. The baseline score of 4 applies because there is no parameter complexity to address.
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 '获取 AP 优化状态' specifies the verb (get) and resource (AP optimization status), making the tool's purpose clear. It is specific enough to distinguish from sibling getters like get_optimization_records or get_wireless_monitoring, though it does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are many related getter tools in the sibling list, but no context or exclusions are offered.
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 is consistent with the readOnlyHint annotation. It adds no behavioral context beyond what the annotation already conveys—no mention of data volume, performance, or any side-effect-free assurance. Since annotations are present, this is acceptable but not enhanced.
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 clear sentence, perfectly concise and front-loaded. Every word earns its place, with no filler or redundant content.
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, a read-only annotation, and an output schema, the minimal description is largely sufficient. However, it could benefit from a brief explanation of what 'version snapshots' refer to (e.g., firmware backups), but this is not critical for a parameterless list 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, so the description does not need to explain parameter meanings. The baseline for 0 params is 4, and the description is adequate for a parameterless operation.
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 (get) and the resource (version snapshot list), and it's a read-only operation consistent with the tool name. It does not explicitly differentiate from sibling tools, but the resource is unique enough to avoid confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description is just a short statement of function, with no mention of use cases, prerequisites, or situations where another tool should be preferred.
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 readOnlyHint annotation already indicates a safe read operation. The description adds minimal context beyond that, only specifying the data source (app protocol traffic history). It does not disclose any additional behavioral traits such as time ranges, aggregation, or limitations, but also does not contradict the annotation.
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 phrase with no wasted words. It is front-loaded with the verb and resource, making it easily scannable.
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, an output schema, and a readOnlyHint, the short description is mostly sufficient. However, it could benefit from elaborating what 'behavior insight' entails or the scope of the historical data, making it slightly incomplete but still adequate for a simple read 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, so the schema fully covers parameter semantics (100% coverage). The description is not required to explain parameters; baseline of 4 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 (获取/get) and the resource (行为洞察/behavioral insight based on application protocol traffic historical data). It distinguishes from other get_* tools by specifying the data type, though 'behavior insight' remains somewhat vague.
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. The description does not reference any sibling tools or conditions for use, leaving the agent without direction on selecting this tool over similar log/audit getters.
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?
The readOnlyHint annotation already indicates a safe read operation. The description adds no extra behavioral context, such as whether logs are real-time or historical, any time-range limitations, or how results are structured. It merely restates the purpose, contributing no transparency beyond the annotation.
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 phrase that is front-loaded with the key information. No wasted words and perfectly sized for a simple no-parameter getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, read-only, has output schema), so the description is minimally adequate. However, it lacks usage context or any mention of how it fits among the many log retrieval siblings, making it incomplete for an agent deciding between get_im_log and similar tools.
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 already fully defines the input space. The description does not need to add parameter semantics, and the baseline of 4 applies since no parameters 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 '获取 IM 上下线记录' clearly states the tool retrieves IM online/offline records. It uses a specific verb (获取/get) and a specific resource (IM online/offline logs), distinguishing it from sibling tools like get_arp_log and get_url_browsing_log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. With many sibling get_* log tools, the description does not explain the intended scenario (e.g., monitoring IM connectivity) or exclusions, leaving the agent without decision support.
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 readOnlyHint annotation is consistent with the get operation. The description adds no extra behavioral details (e.g., no side effects, no return format), but with the annotation providing safety, the lack of additional context is not misleading. The bar is lower given annotations, so a neutral 3 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded with the action and resource. Every word is essential, and there is no redundancy or filler.
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 zero-parameter read-only getter with an output schema, the description is mostly sufficient. However, it does not explain what 'multi-line DNS' means or how it differs from standard DNS, which would help an agent fully contextualize the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully documents all inputs. With 0 params, the baseline is 4, and the description does not need to add parameter detail.
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 '获取多线路 DNS 配置' translates to 'Get multi-line DNS configuration', clearly stating the action (get) and resource (multi-line DNS configuration). It distinguishes from siblings like get_dns_config by the 'multi-line' qualifier, though it does not explicitly compare them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_dns_config. The description only states what the tool does without any context for selection 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?
The description does not add behavioral context beyond the readOnlyHint annotation. Since the annotation already declares this as a safe read operation, the minimal description meets the baseline but provides no additional transparency about return format or scope.
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, clear sentence with no wasted words. It directly states the action and target, making it optimally 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 simplicity of the tool (no parameters) and the presence of an output schema, the description is largely complete. However, it could clarify what constitutes 'peripheral devices' (e.g., USB, printers), leaving slight 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?
The tool has zero parameters and the schema is fully covered. With no parameters to document, the description does not need to add parameter semantics; the empty schema is self-explanatory.
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 gets a list of peripheral devices. It uses a specific verb ('get') and resource ('peripheral devices'), but does not differentiate from siblings like get_camera_devices or get_managed_switches, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No context is provided about scenarios where this tool is appropriate or not, and no alternatives are mentioned.
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?
The description adds no behavioral context beyond the readOnlyHint annotation. It doesn't describe return format, conditions, or any side effects, though read-only is already declared.
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 phrase with no wasted words, front-loaded with the core action.
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 zero-parameter getter with an output schema and readOnlyHint, the description is minimally sufficient, but it lacks any context about what the port mirror config contains or 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 input schema has zero parameters, so the description doesn't need to explain parameter meanings. The '100% schema coverage' baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取端口镜像配置' uses a specific verb (获取/get) and resource (端口镜像配置/port mirror config), clearly identifying the tool's function and distinguishing it from the many other get_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs alternatives, nor any exclusions or prerequisites. The description simply states the action without contextual usage rules.
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 readOnlyHint annotation already marks this as read-only, and the description's '获取' (get) is consistent. It adds the navigation context that this is under Smart Flow Control, but does not disclose what the returned data looks like or any side effects (though none expected). Minimal added 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?
A single short sentence in Chinese, efficiently conveys the resource and its location. No fluff, appropriately sized for a simple getter.
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 an output schema present, the description is mostly sufficient. It names the settings and the navigation path, but could benefit from explaining what the settings are used for (e.g., which domains get priority in flow control). Still, for a simple getter, it covers the essentials.
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 already covers everything. The description adds nothing about parameters because none exist, aligning with the baseline 4 for no-parameter tools.
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 (获取/get) and names the resource (优先域名设置/priority domain settings), with a parenthetical navigation path (智能流控 → 优先域名) that adds context. It is clear but does not explicitly distinguish from sibling getters beyond the resource name.
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, nor any exclusions or prerequisites. The only implied usage is that it retrieves priority domain settings, which is largely self-evident from the name.
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?
The description adds no behavioral context beyond the readOnlyHint annotation. It doesn't mention any side effects, permissions, or constraints such as whether SD-WAN must be configured or what aspects of status are returned, so the annotation remains the only safety-related 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, direct phrase with no unnecessary words. It is front-loaded and appropriately sized for a tool with no parameters and a clear purpose, though it lacks additional detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and adequately identifies the tool's function, but it lacks usage context and differentiation from similar status tools. The readOnlyHint and output schema help, but the description alone does not provide enough information for an agent to confidently choose this tool over alternatives in all situations.
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 zero parameters in the input schema, the baseline is 4. The description adds no parameter information, but none is needed. The schema fully documents that there are no parameters, so no further explanation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取 SD-WAN 智能组网状态' precisely states the tool retrieves SD-WAN intelligent networking status, providing a specific verb-resource mapping. It distinguishes this from sibling tools like get_wan_status and get_system_overview by explicitly mentioning SD-WAN.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description says nothing about use cases, prerequisites, or when not to use it, leaving the agent without contextual decision support.
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 readOnlyHint annotation already indicates a safe read operation. The description adds no further behavioral context, such as what data is audited, time ranges, or any side effects. Since annotations cover the safety profile, the description adds minimal value but does not conflict.
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 immediately conveys the tool's function. It is appropriately sized with no unnecessary filler.
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 zero-parameter schema and the presence of an output schema, the description is adequate for understanding the tool's basic purpose. However, it omits any context about what 'account' refers to or how this relates to the MAC-based sibling, though output schema handles return details.
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 zero parameters, and schema coverage is 100%. The description contains no parameter information, but with no parameters to document, the baseline 4 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 tool audits terminal traffic by account, using a specific verb and resource. The 'by account' qualifier distinguishes it from the sibling get_traffic_audit_by_mac, though it does not explicitly name the alternative.
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 the similar get_traffic_audit_by_mac. It simply states what the tool does, with no exclusions or alternative references, so the agent receives no usage direction.
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 annotation readOnlyHint=true already declares the tool's safety profile, and the description is consistent with it, describing a read operation. However, the description adds no extra behavioral context such as authentication requirements, rate limits, or return format beyond what annotations and output schema already provide. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence: '获取网址浏览记录.' It is front-loaded and contains no filler or redundancy. For a simple getter with no parameters, this is appropriately sized.
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 (zero parameters, read-only), the description is nearly complete. The output schema exists to describe return values, and the annotation covers safety. However, the lack of any usage guidance or context about what 'browsing log' includes prevents it from being a perfect 5.
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 0 parameters, and the schema coverage is 100% vacuously. Per the calibration rules, a 0-parameter tool receives a baseline of 4. The description does not need to explain parameters that do not exist, and it does not add any misleading information.
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 retrieves URL browsing records, using a specific verb and resource. It is unambiguous and directly maps to the tool name, but it does not differentiate from sibling log-retrieving tools like get_im_log or get_terminal_log beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description is a simple declarative statement with no mention of context, prerequisites, or exclusions. It leaves the agent without information about when to prefer this tool over similar log retrieval 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?
The readOnlyHint annotation already indicates this is a safe read operation. The description adds that the status is 'real-time' and lists returned fields, but does not disclose potential latency, snapshot semantics, or any side effects. This adds some behavioral context but is not extensive.
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, concise sentence that front-loads the core purpose and key output fields. No filler or 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 no parameters, a readOnlyHint, and an output schema, the description covers the essential purpose and key fields. However, the term 'AC 状态' is somewhat domain-specific and could benefit from clarification, though the output schema can fill in details.
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, which meets the baseline of 4. The description provides no parameter details, but none are needed. It clarifies the output scope instead, which is helpful.
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 tool's function: retrieving real-time WAN port status with a list of key attributes (IP, rate, connection count, AC status). It is specific and uses an action verb, but does not explicitly distinguish it from sibling status/getter tools like get_system_overview or get_wan_pppoe_log.
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 name and description imply it is for WAN monitoring, there is no mention of context or exclusions, leaving the selection decision to the agent.
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 readOnlyHint annotation already indicates this is a safe read operation, and the description's 'List' verb is consistent. However, the description adds no extra behavioral context such as response format, pagination, or specific data fields, which would be useful for a list operation. The annotation carries the safety information, so this is adequate but not enhanced.
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 immediately states the purpose. The parenthetical tab reference is brief and does not clutter the description. 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 simplicity of a zero-parameter list with an output schema, the description is mostly complete. However, it does not provide any context about what the blacklist contains or how it relates to sibling tools like list_url_blacklist, which could help the agent choose correctly. Still, the tool is straightforward, and the lack of depth is acceptable, so a 4 is appropriate.
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 the schema confirms this (coverage 100%). With no parameters to explain, the description is not required to add parameter-level detail. This matches the baseline of 4 for zero-parameter tools.
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') and the resource ('prohibited entertainment websites'), which aligns with the tool name. It is specific enough to be understood, but it does not explicitly differentiate from the sibling tool list_url_blacklist, which could also involve entertainment content. The tab reference adds some context but does not resolve potential ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_url_blacklist or add/delete_domain_blacklist. The description does not mention any exclusions or preferred usage contexts, leaving the agent to infer 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already declares this as a safe read operation, and the description '列出' is consistent. No additional behavioral context is provided, such as pagination or ordering, but given the tool's simplicity, this does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no filler. It is efficiently front-loaded and every word 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 the tool's zero-parameter, read-only nature and the presence of an output schema, the description conveys the core functionality. However, it does not elaborate on the scope of rules returned or any default behavior, so it is slightly under-complete compared to a fully self-contained description.
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 input schema is empty. Per baseline, a no-parameter tool earns a 4; there is no parameter-related information the description could add 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 '列出端口分流规则' (List port forwarding rules) clearly identifies the tool as listing a specific resource. However, it does not explicitly distinguish it from similar siblings like list_port_mappings or list_nat_rules, so it lacks separate differentiation.
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 offers no guidance on when to use this tool versus alternatives. It simply states the action, with no mention of prerequisites, use cases, or when to choose other list 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?
The readOnlyHint annotation already indicates this is a safe read operation, so the description's main contribution is clarifying that it lists DNAT rules specifically. It does not add details about pagination, ordering, or other behavioral traits, but the annotation covers the safety profile.
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 communicates the exact action and target resource with no unnecessary words or filler.
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 list operation with no parameters and an output schema provided, the description is mostly sufficient. However, the lack of differentiation from similar sibling tools like list_nat_rules and list_port_forwarding_rules introduces some ambiguity, preventing a perfect completeness score.
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?
This tool has zero parameters and the input schema is empty, so there are no parameter semantics to explain. The baseline of 4 applies as there is nothing for the description to add 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 uses the specific verb '列出' (list) and identifies the resource as '端口映射 (DNAT) 规则' (port mapping/DNAT rules), clearly stating what the tool does. However, it does not explicitly differentiate itself from sibling tools like list_nat_rules or list_port_forwarding_rules, which may overlap in scope.
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 offers no guidance on when to use this tool versus alternatives such as list_nat_rules or list_port_forwarding_rules. There is no mention of preferred contexts, exclusions, or conditions that would help an agent choose this tool.
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 readOnlyHint=true, the annotation covers the safety profile, but the description adds no extra value. It fails to clarify whether 'PPPoE accounts' means configured accounts or active sessions, which is a meaningful behavioral trait given the existence of list_pppoe_online_users. No additional context about response format or filtering is provided.
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 phrase '列出 PPPoE 账号' that immediately conveys the purpose. It is appropriately sized for a tool with no parameters and simple functionality, with no wasted 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 tool is simple and has an output schema, but the description lacks a crucial distinction between accounts and online users. Without stating that this lists configured PPPoE accounts (as opposed to current sessions), it is not fully complete for disambiguating from list_pppoe_online_users. The minimal text is functional but leaves a subtle 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?
The tool has zero parameters, so the description has no duty to explain parameter semantics. The baseline of 4 applies because the empty schema fully documents the parameter requirements and there is nothing for the description to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action (list) and resource (PPPoE accounts), distinguishing it from sibling tools like list_pppoe_online_users. It is specific and unambiguous about the core operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention the distinction from list_pppoe_online_users or specify that it returns configured accounts rather than online sessions. Usage is only implied by the tool name, not the description.
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 annotation readOnlyHint=true already indicates a safe read operation. The description adds the 'online' status which implies a live snapshot, but nothing else about pagination, rate limits, or data recency. Given the annotation coverage, this is acceptable but not rich.
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 clear sentence that is front-loaded and contains no filler. Every word is meaningful for a tool with no parameters.
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 params, read-only, output schema present), the description is nearly complete for the operation. However, it could have noted that this lists only PPPoE online users, contrasting with list_pppoe_accounts for configured accounts, to improve 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 zero parameters, and the schema has 100% coverage (vacuously). The baseline for 0 params is 4. No additional parameter semantics are needed, and the description does not need to compensate.
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 lists current online accounts. The verb 'list' and resource 'online accounts' make the purpose specific. However, it does not explicitly distinguish from sibling tool list_pppoe_accounts, which lists configured (not necessarily online) accounts, so it misses 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No context is given about when this is preferred over list_pppoe_accounts or how it relates to kick_pppoe_user for managing online users.
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?
The description adds no behavioral context beyond the readOnlyHint annotation. It does not disclose any special behaviors such as pagination, filtering, or response structure, and does not contradict the annotation. Since the annotation already indicates read-only, the description contributes little extra 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 short sentence with no redundant words. It is front-loaded and directly states the purpose, earning its place without unnecessary detail.
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 is a simple, parameterless list operation with an output schema and read-only annotation, the description is minimally viable. However, it does not differentiate from similar tools like list_proxy_dial_online, and lacks contextual clues about the nature of 'proxy dial accounts' beyond the name.
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 is 4. The description need not explain parameters, as the schema is empty. No additional parameter meaning is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出代拨账号' clearly states the tool lists proxy dial accounts, using a specific verb (list) and a specific resource (proxy dial accounts). It distinguishes from siblings like list_proxy_dial_online by focusing on accounts rather than online status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling list tools, there is no mention of preferred scenarios or exclusions, leaving the agent to 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, and the description's 'list' verb is consistent with a read-only operation. However, the description adds no extra behavioral context such as auth requirements, pagination, or potential side effects. With annotations covering the safety profile, a neutral score 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Chinese that directly states the tool's purpose without waste. It is front-loaded and appropriately sized for a simple no-parameter list operation.
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 (no parameters, read-only, output schema present), the description is sufficient for an agent to understand the core function. However, it does not explain what 'task management' refers to, but this is likely clear from the context of the system and output schema. It is complete enough for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is complete with an empty object. The baseline for 0 parameters is 4, and the description does not need to explain parameters further since none exist. No additional parameter semantics are required.
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 lists tasks within the task management module. It uses a specific verb (list) and resource (tasks), and is not a tautology. However, it does not differentiate from other list tools by specifying scope or context, though no sibling tool appears directly related to tasks.
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, or when not to use it. The description offers no context about suitable scenarios, prerequisites, or exclusions, leaving the agent without direction in selecting this tool among many similar list_* 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?
The readOnlyHint annotation already indicates a safe read operation, and the description consistently says 'get'. No additional behavioral details such as log recency, ordering, or filtering are disclosed, but the output schema likely covers return structure. This is adequate but not enhanced beyond the annotation.
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 short phrase, extremely concise and front-loaded. It communicates the essential purpose without unnecessary filler.
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 no-parameter read-only log retrieval tool with an output schema, the description is minimally sufficient. The purpose is clear, but it could benefit from a brief note on what the log contains to differentiate it from other log tools.
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 the input schema is empty with 100% coverage. The description adds no parameter details because none exist, so the baseline of 4 for a zero-parameter tool applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving the administrator operation log. The verb '获取' (get) and specific resource '管理员操作日志' distinguish it from sibling log tools like get_auth_log or get_system_event_log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 other log-related siblings. The one-line description does not mention scenarios, prerequisites, or alternatives, leaving the agent without selection criteria.
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 annotation readOnlyHint=true already covers the read-only nature, and the description adds minimal behavioral context beyond the literal meaning of '下联' (downstream). It does not mention pagination, filtering, or any side effects, but it also does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the tool's purpose. There is no wasted wording or 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?
Given the tool's low complexity (no parameters, output schema present, read-only annotation), the description is complete enough. The output schema covers return value details, and the annotation covers safety, so the description only needs to state the core function.
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 an empty input schema, so there is nothing for the description to explain. With 0 parameters, the baseline is 4, and the description adds no parameter-level meaning but none is needed.
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 retrieves a list of downstream camera devices (获取下联摄像头设备列表) with a specific verb and resource. However, it does not explicitly differentiate from broader sibling tools like get_peripheral_devices, so it lacks explicit sibling differentiation.
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 about when to use this tool versus alternatives such as get_peripheral_devices or get_ap_devices. The description only states the basic function without any context, preconditions, 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?
Annotations declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the detail that it reads via the multi-line DNS interface, which is useful context but does not describe return format or other behavioral aspects.
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 front-loads the purpose and includes the technical detail about the multi-line DNS interface. 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?
Given the tool has no parameters, an output schema exists, and the read-only annotation is present, the description is sufficient. It clearly identifies the resource and the underlying interface, making it complete for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is effectively 100%. The baseline for zero params is 4, and the description adds no need for parameter explanation. No additional semantics are required.
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 gets 'DNS acceleration service configuration' (获取 DNS 加速服务配置), a specific resource. The verb+resource combination is specific, though it does not explicitly distinguish from the similar sibling get_multi_line_dns.
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 get_multi_line_dns or set_dns_config. There is no mention of context, exclusions, or alternative tools.
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?
The description adds no behavioral information beyond the readOnlyHint annotation. It only restates the tool's name in Chinese and does not disclose any additional side effects, output format, or context about the health check configuration.
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 phrase with no wasted words. 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's simplicity (no params, read-only, output schema exists), the minimal description is mostly sufficient. However, it does not elaborate on what 'health check config' includes, which could be ambiguous without additional 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?
The tool has zero parameters, so no parameter documentation is needed. The description contributes nothing relevant to parameters, which is acceptable given 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 '获取健康检测配置' (Get health check configuration) clearly states a specific verb+resource. It is distinct from sibling getters and unambiguously identifies what the tool retrieves.
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. There is no mention of context, prerequisites, or exclusions, leaving the agent without decision support.
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?
The description adds no behavioral context beyond the readOnlyHint annotation. It does not mention that it retrieves current settings, that there are no side effects, or any other operational details. For a trivial getter with annotations, this is below the bar for meaningful added value.
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 with no wasted words. It conveys the essential purpose in the most efficient manner possible.
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 zero-parameter, read-only tool with an output schema, the description is mostly complete. It could add a note about returning the current active configuration, but the context signals (0 params, readOnlyHint, output schema) already cover most operational needs.
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 is 4. The description correctly avoids adding parameter information that would be irrelevant, and the schema already confirms no parameters 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 states a specific verb ('get') and resource ('IGMP proxy config'), clearly distinguishing itself from sibling getters like get_udp_proxy_config and get_iptv_config. The resource is specific enough to avoid ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply states what it does without naming alternatives or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the read-only nature. The description adds no additional behavioral context such as return format, side effects, or dependencies, but it does not contradict the annotation either. Given the low bar set by the annotation, a score of 3 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, extremely concise and front-loaded. It contains no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter with an existing output schema, the description sufficiently identifies the tool's purpose. There are no additional parameters to clarify, and the return structure is presumably covered by the output schema, making the description complete for its 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 description does not need to explain parameter meanings. The schema is fully documented with no properties, and the baseline for zero params is 4.
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 '获取 IPv6 外网设置' clearly states the tool retrieves IPv6 WAN settings, using a specific verb and resource. It distinguishes from sibling tools like get_ipv6_lan_config by specifying '外网' (WAN). However, it does not explicitly contrast with alternatives, so it is not a perfect 5.
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 such as get_ipv6_config or get_ipv6_lan_config. There is no mention of context, prerequisites, or exclusions, offering zero usage direction.
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?
The readOnlyHint annotation already covers the safety profile, but the description adds no additional behavioral context such as edge cases, configuration state, or side effects. It is a bare restatement of the tool's function without disclosing anything beyond the annotation.
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 phrase that directly conveys the tool's purpose with no filler or redundancy. It is appropriately sized for a simple parameterless getter.
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, a readOnlyHint, and an output schema, the description is mostly sufficient for selection and invocation. It lacks a bit of context about what 'Mesh 快连配置' includes, but the output schema likely covers the return 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?
The tool has zero parameters, so the description has no parameter burden to explain. The baseline for a parameterless tool is 4, and there is no missing parameter information to penalize.
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 (获取/get) and a clearly named resource ('Mesh 快连配置' / Mesh quick-connect configuration), making the tool's purpose immediately obvious. It is unique among the sibling tools, so there is no confusion with other configuration getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It only states what the tool does, leaving the agent to infer usage context from the name and sibling list.
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?
The readOnlyHint annotation already declares this is a safe read operation. The description adds no additional behavioral context—no mention of return structure, authentication needs, or side effects. It essentially restates the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded phrase that efficiently states the tool's purpose. No superfluous words 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?
For a zero-parameter read-only configuration getter with an output schema, the description is minimally sufficient. However, it does not explain what the self-service password management config encompasses, though the output schema likely fills that 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?
The tool accepts zero parameters, so the empty schema fully covers the parameter space. The description need not explain parameters; the baseline of 4 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 uses a specific verb (获取/get) and identifies the exact resource (自助密码管理配置/self-service password management configuration). It clearly distinguishes this tool from sibling tools, none of which target the same feature.
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 vs alternatives, no prerequisites, and no exclusions. It merely names the operation, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond what the readOnlyHint annotation already conveys. It does not describe the returned data structure, any side effects, or performance implications. Since annotations already cover safety, the description fails to provide additional contextual behavior such as whether the configuration is from the active or standby unit or if any restrictions apply.
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 phrase that directly states the tool's purpose without any filler or redundant content. It is appropriately sized for a zero-parameter read operation, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters) and the availability of an output schema, the description is sufficiently complete for an agent to understand what it does. The readOnlyHint and schema provide additional context, so the minimal description meets the needs of this simple getter. However, it does not proactively mention related tools or configuration aspects, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% by default. Per the rubric, a 0-parameter tool receives a baseline score of 4. The description doesn't need to elaborate on parameters because there are none, and the schema already confirms this.
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) and the resource '双机热备 (VRRP) 配置' (dual-machine hot standby VRRP configuration), which is a specific and distinct resource among sibling tools. It adds semantic value by explaining the Chinese term and acronym, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, complementary tools, or scenarios for which this tool is appropriate or inappropriate. For a simple getter, some context about typical use cases or relationships to other network configuration tools would be helpful.
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?
The annotation readOnlyHint=true already declares the read-only nature. The description adds no additional behavioral context, such as log size limits, time range, or output format. It does not go beyond what the annotation already provides, and no extra safety or side-effect information is 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?
The description is a single, clear sentence with no filler or redundancy. It is concise and front-loaded, immediately stating the tool's purpose.
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 a zero-parameter input schema, a readOnlyHint annotation, and an existing output schema (not shown), the description is sufficient for basic invocation. However, it is very terse and could benefit from mentioning that it retrieves PPPoE dial logs for the WAN interface specifically, which the name already implies but the description conveys in a minimal way. Overall, adequate for a simple getter.
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 fully covers the input. The description does not need to explain parameters. With no params, the baseline is 4, and there is nothing missing in parameter semantics.
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 (get) and resource (WAN dial-up/PPPoE log), using a specific verb and noun phrase. It distinguishes this tool from sibling log retrieval tools like get_arp_log and get_auth_log by specifying the WAN PPPoE log type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions. For a simple log getter, usage is implied, but the lack of explicit guidance, especially given the many sibling log tools, leaves the agent without clear selection criteria.
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?
Annotations already mark readOnlyHint: true, and the description adds no additional behavioral context such as pagination, filtering, or output specifics. It essentially restates the tool name without disclosing any traits beyond what annotations already 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 a single short phrase with no redundancy. It is appropriately sized for a parameterless listing tool, and every word 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 the tool's simplicity (0 params, read-only, output schema exists), the description is largely sufficient. The output schema covers return structure, and the description clearly states the resource. Minor gap: no elaboration on what constitutes an 'internet code' versus a 'coupon', but this is not critical.
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 accepts zero parameters, and schema coverage is 100% (no params). Per rubric, baseline is 4 since there are no parameter details to explain.
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 internet codes/coupons, using a specific verb ('列出' = list) and a precise resource. It is distinguishable from all sibling tools, none of which mention coupons or internet codes.
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 guidance is provided. The description does not specify when to use this tool versus other list_* tools, nor does it mention any exclusions, prerequisites, or 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 readOnlyHint=true already present in annotations, the description adds no additional behavioral context. It does not disclose anything about pagination, ordering, or what the returned list contains beyond what the name and annotation imply. The description is essentially a restatement of the tool name.
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 is front-loaded with the verb and object. It contains no redundant or unnecessary wording, achieving maximum efficiency.
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 list operation with no parameters, read-only annotation, and an output schema, the description is sufficient to convey the core function. It could be enhanced with a note about the absence of filters or the scope (all static bindings), but overall it is complete enough for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100% (vacuously). Per the rubric, 0 params yields a baseline of 4, and there is no need for parameter explanation since 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 '列出 DHCP 静态分配（IP-MAC 绑定）' clearly states the tool lists DHCP static bindings (IP-MAC bindings). It uses a specific verb (list) and resource (static bindings), which distinguishes it from sibling tools like list_dhcp_servers and list_dhcp_leases.
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 explicit guidance on when to use this tool versus alternatives. It does not mention when a user would choose this over list_dhcp_leases or list_dhcp_servers, nor does it offer any exclusions or conditions.
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?
The readOnlyHint annotation already indicates a safe read operation. The description adds no further behavioral context (e.g., pagination, scope, or limitations) but does not contradict the annotation.
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, short sentence with no wasted words, appropriately sized for a simple list operation.
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 list tool with zero parameters, read-only annotation, and an output schema, the description is adequate. It could mention what the rules contain or any filtering scope, but the basic purpose is fully covered.
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 the schema coverage is 100% (vacuously). The description adds no parameter details, but with no parameters, this is acceptable and the baseline 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 the action (list) and resource (domain forwarding rules), directly distinguishing it from sibling tools like list_app_protocol_rules and list_port_forwarding_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It merely restates the function without context, exclusions, or mention of related 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?
The description is consistent with the readOnlyHint annotation, and the verb 'list' matches a read operation. However, it adds no additional behavioral context beyond what the annotation already provides, such as pagination or response format.
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 short and direct phrase in Chinese, '列出多线负载规则', which translates to 'List multi-line load balancing rules'. Every word is necessary, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only list operation with an output schema, the description is fully sufficient. The tool's complexity is low, and no further context is needed beyond the clear purpose provided.
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 there is no need for the description to explain parameter meanings. The baseline for zero parameters is 4.
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) and the resource (multi-line load balancing rules). It distinguishes this tool from sibling tools by the specific resource type, though it does not provide any explicit differentiation beyond the name.
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. The description only states the action without any context about prerequisites, filtering, or related tools.
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?
The description adds no behavioral context beyond the readOnlyHint annotation. It simply restates the tool's function without disclosing any additional traits such as pagination, return format, or data source.
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 short phrase, minimum viable to convey the purpose with 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 zero-parameter list tool with an output schema, the description is adequate in context. It clearly identifies the resource, and the output schema covers return values, though it does not elaborate on the nature of 'real-time notices'.
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 description does not need to explain parameter semantics. The baseline of 4 applies as the schema vacuously covers all parameters.
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 real-time notifications, providing a specific verb and resource. It distinguishes itself from sibling tools like list_periodic_notices and list_expiry_notices via the 'realtime' qualifier.
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. The description does not mention any exclusions, prerequisites, or relationship to other notice-listing 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?
Annotations declare readOnlyHint=true, and the description's verb '列出' is consistent. The additional mention of 'tab: 参数替换' gives a small UI-oriented context but does not disclose return format, pagination, or other behavioral details. This is acceptable given the simple list nature, but not rich.
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 phrase that gets straight to the point: the action and the resource. There is no wasted wording, and it is appropriately sized for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, a basic output schema, and simple list semantics, the description is adequate but minimal. It does not clarify what 'URL 参数替换' encompasses or what the output represents, leaving some ambiguity. Given the low complexity, this is a minimum viable description.
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 zero properties and schema coverage is 100%, so there are no parameters to document. The description identifies the resource being listed, which is sufficient context for a parameterless tool. Baseline for 0 params is 4, and the description does not detract.
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 the verb '列出' (list) and names the resource 'URL 参数替换' (URL parameter replacement), clearly indicating a listing tool for this specific feature. However, it does not distinguish itself from sibling tools like list_url_blacklist or list_url_redirects, so it earns a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to list URL parameter replacement rules, but provides no explicit guidance on when to use it over alternatives or any exclusions. For a simple list operation the context is understandable, but the lack of any alternative mention keeps it at a 3.
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?
The readOnlyHint annotation already indicates a safe read operation. The description adds no extra behavioral context beyond confirming it lists statuses—no mention of output structure, pagination, or other behavioral traits. It does not contradict the annotation, but also fails to add meaningful transparency beyond the structured hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It communicates the purpose directly and efficiently.
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, readOnly annotation, and an output schema), the description sufficiently covers the necessary information. It clearly states the scope ('all VPN server statuses') without requiring further elaboration, though it could optionally mention that it covers different VPN types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the baseline of 4 applies. The description correctly implies no parameters are needed, and there is no additional parameter information to add.
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 'List all VPN server statuses' uses a specific verb (list) and resource (VPN server statuses), clearly distinguishing it from sibling tools like get_pptp_server_config (configuration retrieval) and toggle_vpn_server (state change). It is unambiguous and directly states what the tool does.
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 gives no guidance on when to use this tool versus alternatives such as get_pptp_server_config or list_vpn_clients. There is no mention of appropriate contexts, exclusions, or relationships to sibling tools.
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 the full disclosure burden. It states the toggle action but does not mention security implications, persistence, authentication requirements, or impact on existing admin sessions—important for a WAN-exposure control.
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 short, front-loaded sentence with parenthetical clarification. No redundant content.
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 one-boolean setter with an output schema, the description and schema are largely sufficient. It lacks only security/usage context, which keeps it from being a 5.
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?
Input schema is fully self-descriptive (100% coverage) with a clear boolean 'enabled' explanation. The description adds no further parameter detail, so the 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 uses a clear verb (开启/关闭) and specific resource (外网 Web 访问), with parenthetical clarification that this controls access to the router admin UI from the WAN. This meaningfully distinguishes it from sibling tools like set_web_ports and get_remote_access_config.
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 intended use is implied: toggling external web access. However, there is no explicit guidance on when to choose this over related tools, nor any mention of prerequisites or security caveats.
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?
The annotation readOnlyHint=true already informs the agent that this is a safe read operation. The description merely repeats the 'get' semantics without adding any additional behavioral context (e.g., no mention of what configuration exactly is returned, but the output schema covers that). No contradiction occurs, but the description adds no value beyond the annotation.
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 precisely conveys the tool's purpose without any filler or redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters), the readOnlyHint annotation, and the presence of an output schema, the description is fully adequate. The agent knows it is a read-only getter with no inputs, and the output schema will define the return structure, so no additional contextual documentation is necessary.
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 input schema is trivially complete. The baseline for 0 parameters is 4, and the description does not need to elaborate on any parameter semantics.
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 ('获取' = get/retrieve) and the specific resource ('DMZ 主机配置' = DMZ host configuration). It is specific and distinguishes itself from sibling tools like set_dmz, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. While it is implicitly the read counterpart to set_dmz, the description does not mention this relationship or any other usage context, leaving the agent to infer usage from the name and sibling list.
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?
Annotations declare readOnlyHint=true, but the description adds no additional behavioral context. It does not mention return format, side effects (none expected), or any special conditions. The description contributes nothing beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that directly states the tool's function. No wasted words, front-loaded, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, read-only hint provided, output schema exists), the description is sufficient. The agent can understand what the tool does without needing more detail; the output schema covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema is fully covering. The description doesn't need to explain parameter meanings. Baseline 4 for 0 params 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 '获取 PPTP 服务端配置' clearly states the action (get) and the resource (PPTP server configuration). It is specific and distinguishes this tool from sibling tools like get_pptp_client_config and get_l2tp_server_config by naming 'server' and 'PPTP'.
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 gives no guidance on when to use this tool versus alternatives, no context about prerequisites, and no exclusions. It simply restates the purpose. There is no explicit or implied usage direction beyond the name itself.
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?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds value by disclosing the scope ('all online devices') and the fields returned (IP/MAC/hostname/traffic/connections). However, it does not disclose pagination behavior, default limits, or whether the list reflects real-time data, which would be useful 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 a single, information-dense sentence. It is front-loaded with the verb and resource ('获取终端监控列表') followed by the key return fields. Every word earns its place with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description is sufficiently complete. It clearly indicates the scope (all online devices) and the returned fields, while the schema covers pagination and IP version parameters. No critical context is missing for a list-reading 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?
Schema description coverage is 100% (limit, offset, ip_type all have descriptions). The tool description adds no information about parameters beyond what the schema already states. Per the rubric, high schema coverage earns a baseline of 3, and the description does not compensate with additional semantic detail.
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: '获取终端监控列表' (get terminal monitoring list), and specifies the exact data returned: '所有在线设备 IP/MAC/主机名/流量/连接数' (all online devices IP/MAC/hostname/traffic/connection count). This distinguishes it from siblings like get_terminal_log or get_arp_log by emphasizing it's a monitoring list of current online devices with traffic stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It simply states what it does without mentioning exclusions, prerequisites, or comparative use cases. For example, it does not clarify whether to use this over get_terminal_log for historical logs or get_connection_table for connection details.
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?
Annotations declare readOnlyHint=true, so the read-only nature is known. The description adds the context that it returns current assignments, which is slightly useful. It does not disclose pagination, sorting, or any additional behavioral traits, but the output schema likely covers return structure.
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 conveys the core function. There is minor redundancy with 'list' appearing as both verb and noun (列出...列表), but it is still compact 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?
For a simple read-only list tool with one optional parameter and an output schema, the description is largely sufficient. It would benefit from explicitly mentioning the ip_type parameter or noting that it only returns dynamic leases, but the schema and the parenthetical cover the essential context.
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% description coverage for the single optional parameter ip_type, which is fully described as "v4" or "v6". The tool description adds no parameter-specific meaning, but since the schema already documents the parameter clearly, the baseline of 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?
The description clearly states the tool lists DHCP leases (currently assigned IPs), using a specific verb and resource. The parenthetical 'currently assigned IP' distinguishes it from related tools like list_dhcp_static_bindings, making sibling differentiation 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?
Usage is implied: if you need to see current DHCP leases, use this tool. However, there is no explicit when-to-use vs alternatives, no exclusions, and no guidance on when not to use it. The description states what it does but not how it fits among siblings.
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?
The annotation readOnlyHint=true already discloses this is a safe read operation. The description adds no behavioral context beyond that—no mention of pagination, result size, ordering, or any caveats. Since the description provides no additional transparency beyond the annotation, it falls short of the 'credit for adding context' standard.
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, compact sentence with no redundant words. It efficiently states the tool's function without any fluff, earning every character it uses. This is ideal for a simple no-parameter list operation.
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 low complexity (no parameters, read-only, output schema exists), the description is minimally viable. However, it lacks any context about what IP speed limit rules are, how they relate to other speed-limit tools, or any specific usage scenarios. The presence of an output schema means return values need not be described, but a brief note on when to use this versus list_mac_speed_limits 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?
The tool has zero parameters, and the schema is empty. The baseline for 0 parameters is 4, and the description does not need to explain parameter semantics because none exist. It correctly reports the function without unnecessary detail.
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 simply states 'List IP speed limit rules' (列出 IP 限速规则), which is a specific verb+resource action. It clearly distinguishes from sibling tools like list_mac_speed_limits (which lists MAC speed limits) and add_ip_speed_limit/delete_ip_speed_limit (which modify rules). The 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It implies usage (when you need to view IP speed limits) but does not mention exclusions or contrast with related tools such as list_mac_speed_limits. For a simple read-only list tool, this implied usage is minimally adequate but lacks explicit 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?
The description prominently discloses a critical behavioral consequence—router reboot and network disconnection—which is especially important given no annotations are provided. However, it omits other behavioral details such as upgrade duration, failure modes, or whether the process is irreversible.
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 with clear action followed by a prominent warning. It is excessively concise with zero filler or redundant information.
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?
Although an output schema exists, the description lacks essential context for a high-stakes operation like firmware upgrade: no prerequisites, no mention of the confirm parameter's role, no expected duration, and no post-conditions. The user is left with only the warning, making the description insufficient for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'confirm', has no schema description and is not mentioned in the tool description. The warning implies caution but does not explain how the boolean controls the upgrade initiation. At 0% schema coverage, the description fails to compensate for this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Start firmware upgrade' with a specific verb and resource, and the warning about reboot/network loss distinguishes it from sibling tools like 'upgrade_ap_firmware' or read-only queries. It unambiguously identifies what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for the router's own firmware upgrade via the warning about reboot and network disconnect, but it does not explicitly mention when to use it versus alternative upgrade tools (e.g., AP firmware upgrade) or provide any when-not-to-use guidance. Usage is implied rather than stated.
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, yet the description only says 'enable/disable' without disclosing potential side effects (e.g., locking out users, requiring admin privileges, or persistence across reboots). For a toggle that changes security posture, this is insufficient 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, compact phrase with no filler. It is immediately understandable and front-loaded with the verb-action and target resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and an output schema exists, so return values are covered. However, the description omits any caution about the impact of disabling web authentication, which is relevant for a toggle tool. It is minimally complete but lacks safety 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?
With 0% schema description coverage, the description compensates by making the boolean parameter self-explanatory: 'enabled' corresponds to enabling or disabling web authentication. No ambiguity remains for a one-parameter 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 action (enable/disable) and the resource (web authentication). It distinguishes itself from siblings like get_web_auth_config (read-only) and toggle_vpn_server (different feature).
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 phrase '启用/禁用' implies a binary switch action but gives no explicit guidance on when to use this tool versus running get_web_auth_config first or versus similar toggle tools. Usage context is only implied by the name and sibling list.
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?
Annotations declare readOnlyHint=true, so the agent knows this is a safe read. The description adds no behavioral detail beyond the literal read-only fetch (e.g., no mention of what versions are returned or whether it can be called without APs present), but it does not contradict the annotation. With the annotation already covering safety, the minimal description is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded Chinese sentence that conveys the tool's purpose with no filler. Every word earns its place; no restructuring is needed.
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 zero-parameter read-only getter with an output schema, this description is adequately complete. It could have clarified whether the list refers to current firmware versions on AP devices or available firmware versions, but the low complexity and presence of an output schema reduce the need for extra 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?
The tool has zero parameters and 100% schema coverage (empty object), so there are no parameter semantics the description needs to add. The baseline of 4 applies for a zero-parameter 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 uses a specific verb ('获取' / get) and resource ('AP 固件版本列表'), clearly indicating a list/read operation. It differentiates from sibling mutation tools like restart_ap and upgrade_ap_firmware.
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 about when to use this tool versus alternatives such as get_ap_group_config or upgrade_ap_firmware. The sibling list also offers no explicit context, leaving the agent to 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description simply repeats the read-only nature implied by the get verb and the readOnlyHint annotation. It adds no additional behavioral context, such as what the configuration contains or under what conditions it might be unavailable.
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 phrase that uses minimal words to convey the tool's purpose. No extraneous content exists.
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 no-parameter, read-only getter with an output schema, the description is nearly sufficient. It names the exact resource and operation, though it could benefit from clarifying what an 'AP group' is, but the output schema likely covers the return 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?
With zero parameters, the description is not required to explain parameter semantics. The input schema is empty, and the description doesn't add or need parameter details; score reflects 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 '获取 AP 分组配置' translates to 'Get AP group configuration,' clearly stating the specific verb (get) and resource (AP group config). This uniquely identifies the tool among siblings, as no other sibling tool targets AP group configuration.
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 no explicit when-to-use guidance or alternatives. However, the verb 'get' and the resource name imply the tool is used to fetch the current AP group configuration, so usage is implied rather than explicit.
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 readOnlyHint annotation already signals the safe read-only nature, and the description adds no extra behavioral context such as authentication requirements or response details. It does not contradict annotations, but it provides no additional transparency beyond what the annotation already conveys.
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 is front-loaded with the action and target. Every word contributes meaning, with no filler or 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?
For a simple getter with no parameters and an output schema available, the description fully covers what the tool returns. It does not need to explain return values, and no further context is necessary given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no parameter meanings to explain. The baseline of 4 is appropriate because there is no schema-coverage gap to compensate for.
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 fetches the dynamic DNS (DDNS) configuration, using a specific verb (获取/get) plus resource (动态域名配置). This distinguishes it from siblings like add_ddns, delete_ddns, and get_ddns_log, which have different actions or targets.
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 relative to others, nor any exclusions or alternatives. The name itself implies its purpose, but the description offers no explicit or implicit usage context beyond that.
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 annotation readOnlyHint=true already communicates the safe read-only nature. The description simply says 'get' which aligns with that, but adds no extra behavioral context such as whether logs are paginated, time-bounded, or limited to certain DHCP events. Given the annotation covers the safety profile, this is adequate but not enriched.
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 phrase with no wasted words. It's precisely sized for a no-parameter getter tool, delivering maximum clarity with minimal characters.
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?
With an output schema present, return values are already documented. The description is minimal but sufficient for a simple getter with no parameters, though it could arguably clarify whether 'DHCP log' refers to server logs or client lease logs. Overall, the contextual need is low and the description meets 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 input schema has zero parameters, so schema coverage is vacuously 100%. With no parameters, the description doesn't need to explain any parameter semantics, earning a baseline score of 4 per the guidelines.
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 '获取 DHCP 日志' (Get DHCP logs) clearly states the action and resource, distinguishing it from sibling log tools like get_arp_log and get_auth_log. It's a specific verb+resource pair that leaves no ambiguity about what the tool does.
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. The description doesn't mention what DHCP logs contain, whether to use it for troubleshooting, or how it relates to sibling DHCP tools like list_dhcp_leases. It's purely a bare statement with no contextual direction.
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 adds a navigation path but no additional behavioral traits. Annotations already declare readOnlyHint=true, so the read-only nature is known. There is no contradiction, but the description provides minimal extra context beyond the annotation.
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 concise sentence with the navigational hint. No redundant information, front-loaded with the core purpose. Ideal for a simple getter.
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 params, read-only, has output schema), the description is sufficient to understand its purpose. However, it lacks any usage context or relationship to sibling tools, which would make it more 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 and the schema is empty with 100% coverage, so there are no parameter semantics to explain. The description correctly says nothing about parameters, meeting the baseline for parameterless 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?
Description clearly states it retrieves flow control strategy settings, using the specific verb '获取' (get) and resource '流控策略设置' (flow control strategy settings). It distinguishes from sibling tools like get_flow_control_lines and set_flow_control_line by focusing on the strategy settings level.
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. It does not mention exclusions or contrast with similar getter tools, 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?
The readOnlyHint annotation already indicates a safe read operation. The description adds no additional behavioral context such as authentication requirements or output details, but it does not contradict the annotation either.
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 directly states the tool's purpose without any superfluous wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple parameterless getter, and an output schema is present. The description sufficiently conveys the tool's function, though it lacks explicit sibling differentiation that would make it more 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 takes zero parameters, and the schema has 100% coverage (vacuously). The description correctly implies no configuration is needed, so the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取 IPSec VPN 客户端配置' clearly states the action (get) and the resource (IPSec VPN client configuration), distinguishing it from sibling tools like get_pptp_client_config by naming the specific protocol.
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. There are multiple VPN client config getters (PPTP, L2TP, OpenVPN, IKEv2, WireGuard), but the description does not explain selection criteria or 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?
The description is consistent with the readOnlyHint annotation but adds no additional behavioral context (e.g., authentication, response shape, or side effects). Since the annotation already covers safety, the description neither contradicts nor enriches it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused phrase with no redundancy or filler. It is appropriately sized for a simple getter with no parameters.
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 params, readOnlyHint, output schema present), the one-line description is mostly sufficient for an agent to select and invoke the tool. However, it omits any contextual hints about what the configuration contains or when it is relevant, though the output schema may cover return values.
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 0 parameters, so there is nothing to explain. The baseline for 0-param tools is 4, and the description does not need to compensate for any schema gaps.
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 '获取 L2TP 客户端配置' clearly states the action (get) and resource (L2TP client configuration), unambiguously distinguishing it from siblings like get_l2tp_server_config and other VPN client config getters.
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 such as get_l2tp_server_config or the other get_*_client_config tools. It relies entirely on the tool name, which is not explicit usage guidance.
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 readOnlyHint annotation already confirms this is a safe read operation, lowering the bar. The description adds the component list but no deeper behavioral context (e.g., snapshot vs. aggregated data, performance implications, or how it relates to historical tools), so it meets the bar only partially.
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 Chinese sentence that begins with the verb+object and compresses all key output domains into a compact colon-separated list. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, no-parameter overview with an output schema, the description is nearly complete: it names the tool's scope, and the annotation covers the safety profile. The main gap is the absence of sibling differentiation, but the low complexity and presence of an output schema keep this from being a major omission.
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 zero parameters and 100% schema coverage, the baseline is 4. The description's component list informs the agent of what data will be returned, compensating for the lack of parameters worth documenting. No additional parameter-level detail 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 clear verb+resource pattern ('获取系统概览' / get system overview) and enumerates six concrete components (CPU, memory, traffic, version, uptime, online users). This distinguishes it from more specific sibling tools like get_memory_history or get_firmware_version, which cover only individual aspects.
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 the many more specific sibling tools (e.g., get_memory_history, get_terminal_list, get_firmware_version, get_wan_status). No exclusions, preconditions, or alternative recommendations are given.
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 readOnlyHint annotation already indicates a safe read operation. The description adds the module path (Smart Flow Control) but does not disclose return format, pagination, or other behavioral details. With the annotation covering safety, the added context is minimal but non-contradictory.
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 one short phrase with no wasted words. It includes a useful UI path, making it efficient and 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 there are no parameters, an output schema exists, and the readOnlyHint is present, the description is nearly complete for a simple getter. It lacks an explanation of what 'terminal independent speed limits' means, but the output schema likely covers the return 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?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters since none exist, and the schema coverage is 100% (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 the tool retrieves terminal independent speed limits, using a specific verb ('获取' = get) and a specific resource. It distinguishes from sibling tools like 'list_ip_speed_limits' and 'list_mac_speed_limits' by naming a distinct configuration category.
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 such as other speed limit getters. The UI path '智能流控 → 终端独立限速' gives navigation context but no explicit usage conditions or exclusions.
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?
The description is a literal translation of the tool name and adds no behavioral context beyond what the readOnlyHint annotation already provides. With annotations present, the bar is lower, but the description still fails to disclose what 'advanced settings' include, any prerequisites, or return characteristics beyond relying on the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise phrase with no unnecessary words. It is front-loaded and immediately communicates the tool's purpose. Perfectly sized for a parameterless getter.
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 params, readOnlyHint, output schema present), the description is nearly complete. However, it does not clarify what distinguishes 'advanced' from 'basic' Wi-Fi settings, leaving the agent to rely on the sibling tool name and output schema. Slight gap in contextual clarity.
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 zero parameters, so there is nothing to describe. The rule for 0 params is baseline 4, and the description correctly provides no irrelevant parameter information. Schema coverage is 100% vacuously, so no compensation 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 '获取 Wi-Fi 高级设置' translates to 'Get Wi-Fi advanced settings', which is a specific verb+resource statement. It clearly identifies the tool as a read operation for advanced Wi-Fi settings and implicitly distinguishes it from siblings like get_wifi_basic_settings by specifying 'advanced'.
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 no explicit guidance on when to use this tool versus alternatives. However, the name and description imply usage when advanced Wi-Fi settings are needed, which is sufficient for a simple getter. No exclusions or alternative tool references are given.
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 adds no behavioral detail beyond the readOnlyHint annotation. It does not describe return format, authentication needs, or any side effects, but the annotation already conveys that this is a safe read operation. No contradiction exists.
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 with no redundant information. It is appropriately sized for a simple getter tool and avoids any 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?
Given the tool's simplicity (no parameters, output schema exists, read-only annotation), the description is adequate. It could be slightly more explicit about the scope of the configuration, but the name and description together sufficiently convey the tool's purpose.
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?
This tool has zero parameters, so the schema covers everything. Per the rubric, a baseline of 4 applies when there are no parameters, and the description has no need to add parameter details.
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 '获取 WireGuard 客户端配置' clearly states the tool retrieves WireGuard client configuration. It uses a specific verb and resource, and the protocol name distinguishes it from sibling VPN client config getters such as PPTP, L2TP, OpenVPN, IPsec, and IKEv2.
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 alternative VPN client config tools. It simply states what it does without context on selection criteria or exclusions, so the usage guidance is minimal.
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?
The description adds no behavioral context beyond the name and the readOnlyHint annotation. It does not mention pagination, filtering, or return format. Since readOnlyHint=true is already present, the description does not contradict annotations but also provides no additional 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 one short clause, no filler, and appropriately sized for a simple list operation.
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 zero-parameter read-only list tool with an output schema, the description is sufficient. It clearly identifies the tool's purpose with no missing required information.
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 the input schema is empty. Schema coverage is 100% (vacuously). Baseline for 0 parameters is 4, and the description doesn't need to explain any parameter semantics.
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 'List ACL access control rules' (列出 ACL 访问控制规则), using a specific verb 'list' and resource 'ACL rules'. It distinguishes from sibling tools like add_acl_rule, delete_acl_rule, and toggle_acl_rule.
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. It simply states the action without mentioning exclusions or alternatives. The naming convention and sibling tools imply it's the read-only list operation for ACL rules, so usage is somewhat implied.
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 `readOnlyHint` annotation already covers the safety profile, and the description adds the L7 ACL scope clarification. However, it does not disclose any additional behavioral traits such as pagination, sorting, or default response size, which would be useful for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose without any fluff or redundancy. It is appropriately 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's simplicity (no parameters, read-only annotation, output schema present), the description is largely adequate. However, it lacks a brief note distinguishing it from similar list tools, which would make it fully complete for an agent choosing between options.
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 is 4. The description does not need to add parameter semantics, and the empty schema confirms the absence of inputs.
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 application protocol control rules (L7 ACL) with a specific verb ('list') and resource. It distinguishes from siblings like `list_acl_rules` by specifying the L7 ACL scope.
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. It does not mention exclusions or alternatives, such as `list_acl_rules` for L3/L4 ACLs, leaving the agent to infer usage from the name.
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 readOnlyHint annotation already declares the safe read nature. The description adds the scope (terminal names/remarks) but does not disclose any additional behavior such as pagination, ordering, or lack of filtering. This meets the lower bar given the annotation coverage.
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 short phrase that immediately conveys the tool's purpose. Every word is informative and there is no filler or redundant content.
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 is a parameterless read-only list operation with an output schema and readOnlyHint annotation, the brief description is largely sufficient. It could have named sibling tools for differentiation, but that is not critical for invoking such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters and the schema is empty, so the baseline for parameter semantics is 4. The description adds no parameter information, but none is needed because there are no parameters to document.
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 ('列出' / list) and a specific resource ('终端名称/备注' / terminal names/remarks). It distinguishes itself from sibling tools like get_terminal_list (which likely returns full terminal information) and set_device_name (which writes a device name).
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 about when to use this tool instead of alternatives such as get_terminal_list or set_device_name. The description only states what it does, not when it should be preferred.
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 aligns with the readOnlyHint annotation, simply stating it lists configuration. It adds no additional behavioral context (e.g., whether it returns global or per-interface settings), but the annotation already covers the read-only safety profile, so this is adequate for a trivial list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, to-the-point sentence with no wasted words. It is front-loaded with the key information and appropriately sized for such 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 has zero parameters, an output schema, and a read-only annotation, the description is mostly sufficient. However, it could clarify the exact scope of 'DHCP servers' (e.g., whether it covers multiple server instances or just the main config) and mention that it reads the current configuration. Despite this minor ambiguity, the minimal complexity makes it 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 tool has zero parameters, and schema coverage is 100% by default. There is nothing for the description to explain about parameters, so the baseline of 4 applies. No additional parameter context is needed or provided.
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 '列出 DHCP 服务端配置' clearly states the tool lists DHCP server configuration, using a specific verb (list) and resource (DHCP server configuration). This distinguishes it from sibling tools like list_dhcp_leases and list_dhcp_static_bindings, which target different aspects of DHCP.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention related tools or clarify the scope of 'DHCP servers' compared to leases or static bindings, leaving the agent to rely on the tool name alone for 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?
The readOnlyHint annotation already indicates this is a safe read-only operation. The description does not add further behavioral context such as pagination, rate limits, or data freshness. However, for a simple list operation with no parameters, the annotation and description together provide sufficient 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, concise sentence that immediately states the action and target. There is no redundant or extraneous information, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema present, read-only), the description is adequate for understanding its function. It could benefit from clarifying what a 'dial user expiry notice' is, but the output schema likely covers the return structure. Overall, the description is mostly 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 input schema has zero parameters, making parameter semantics irrelevant. The description adds no parameter information, but none is needed. The baseline for zero-parameter tools 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 the tool lists dial-up user expiry notices, using the specific verb 'list' and the resource 'dial user expiry notices'. This distinguishes it from general expiry notice lists such as list_expiry_notices, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The only information is the operation itself, without context about when it is appropriate. No alternatives are named or conditions for selection.
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 readOnlyHint annotation already indicates a safe read operation. The description adds no further behavioral details, such as sorting, pagination, or scope, but it does not contradict the annotation.
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, efficient sentence that says exactly what the tool does with 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?
With no parameters, an existing output schema, and a simple list operation, the description is sufficiently complete. It could be enhanced with usage context, but is not inadequate.
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 there is nothing to explain. The baseline of 4 applies because the description does not need to elaborate on parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'list' and names the resource 'MAC access control rules', making the purpose immediately clear. It distinguishes from sibling tools such as list_acl_rules and add_mac_access_control.
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, nor are any exclusions or prerequisites mentioned. The context signal from sibling tools is not leveraged in the description.
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 annotation readOnlyHint=true already discloses the read-only nature. The description adds no further behavioral context, such as pagination, ordering, or filtering. It is consistent with the annotation but does not enrich beyond it.
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 phrase, efficiently stating the tool's function without any filler or redundancies.
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) and the presence of an output schema, the description is adequate. A minor gap is not specifying whether it lists all NAT rule types, but this is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema coverage is vacuously 100%. The baseline for 0 params is 4, and no parameter semantics are needed beyond that.
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 '列出 NAT 规则' translates to 'List NAT rules', clearly specifying the action (list) and resource (NAT rules). This distinguishes it from sibling list tools like list_acl_rules and list_static_routes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only states the function, with no mention of use cases, prerequisites, or exclusions, making it no guidance at all.
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 readOnlyHint annotation already declares the operation as read-only, and the description's 'list' action is consistent. The description adds minimal context beyond the annotation (only the 'all' scope), without disclosing ordering, pagination, or other behavioral traits. No contradiction exists.
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 in Chinese, with no filler or redundant details. It is front-loaded and directly states the operation.
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 zero-parameter, read-only list operation with an output schema provided, the description is largely sufficient. It could benefit from noting the distinction from get_routing_table, but that gap is more related to usage guidance than 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 accepts zero parameters, so the description does not need to explain parameter meanings. The baseline of 4 applies when there are no parameters, and the schema confirms no parameters 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 uses the specific verb '列出' (list) with resource '静态路由规则' (static route rules), and the word '所有' (all) clarifies scope. This distinguishes it from sibling tools like add_static_route, delete_static_route, and get_routing_table.
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 such as get_routing_table or get_ipv6_config. No exclusions, prerequisites, or selection criteria are mentioned, leaving the agent to infer usage solely from the name.
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 readOnlyHint=true annotation already declaring the operation as read-only, the description adds minimal extra context—only that it runs a health report. It does not disclose potential time-to-complete, data scope, or any authentication requirements, but it does not contradict the annotation either.
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 phrase—'运行路由体检'—with no unnecessary words. It is appropriately sized for a zero-parameter tool and earns its place 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 zero parameters and the presence of an output schema, the description sufficiently identifies the tool's purpose. However, it does not explain what the health report contains or when to use it relative to other diagnostic tools, leaving a small gap in contextual 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?
This tool has zero parameters, so schema coverage is 100% by default. The description does not need to explain parameter semantics, and the baseline for zero-parameter tools is 4, which is appropriate here.
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 ('运行' meaning 'run') and the resource ('路由体检' meaning 'router health check'), making it specific and actionable. It distinguishes itself from sibling get_* tools by specifying a run operation rather than a simple retrieval.
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 context about when to use this tool versus alternatives, no mention of exclusions, and no reference to related tools like get_health_check_config. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the readOnlyHint annotation. It doesn't disclose what the output looks like (e.g., boolean or ) or any edge cases, relying entirely on the output 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?
A single short sentence that immediately conveys the tool's purpose with no redundant or extraneous text.
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 trivial no-parameter read-only query tool with an output schema, the description is complete. It states exactly what the tool does, and the output schema handles return value details.
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 description of parameters is unnecessary. The baseline for 0 parameters is 4, and the description doesn't need to compensate for any missing schema info.
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 queries whether CPU temperature detection is supported, using a specific verb ('查询') and resource ('CPU温度检测支持'). This clearly differentiates it from the many other get_* tools in the sibling list.
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, but the purpose itself implies usage: when you need to know if CPU temperature detection is supported. The tool is unique among siblings, so no alternative is named.
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 readOnlyHint annotation already indicates this is a read-only operation, which aligns with the description. However, the description adds no extra behavioral context such as response format, authentication requirements, or any side effects. Since annotations cover the safety profile and there is no contradiction, a score of 3 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundant information. It is front-loaded with the action and resource, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read operation with an output schema, the description provides sufficient context. The tool name and description together clearly identify what is being retrieved, and the output schema covers return value details. No additional context is needed.
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 there are no parameter semantics to explain. The schema coverage is trivially complete, and the baseline for 0-parameter tools is 4, which is appropriate here.
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 ('get') and resource ('IKEv2/IPSec client configuration'), distinguishing it from sibling tools like get_ike_server_config and other protocol-specific client config getters. The verb+resource combination is 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 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 such as get_ipsec_client_config or get_ike_server_config. There is no mention of context, prerequisites, or exclusions, leaving the agent without direction for tool selection among closely related 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?
The readOnlyHint annotation already indicates this is a safe read operation. The description adds the specific metrics (CPU/memory/real-time traffic) and the 'real-time' qualifier, which is useful context. However, it does not disclose return format, pagination, or historical/current behavior beyond the real-time hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential information without waste. It is appropriately concise for a straightforward getter.
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, a readOnly annotation, and an output schema, the description fully covers what the tool does. It is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds value by specifying what data will be returned (CPU, memory, traffic), which complements 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 the tool retrieves load monitoring data including CPU, memory, and real-time traffic. It uses a specific verb ('获取' / get) and names the resource and scope, distinguishing it from siblings like get_memory_history or get_line_monitoring.
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 such as get_system_overview or get_memory_history. The description does not mention any exclusions or preferred contexts.
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 readOnlyHint annotation already indicates a safe read-only operation. The description adds no additional behavioral context, but it does not contradict the annotation either.
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 immediately conveys the tool's purpose without unnecessary 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?
Given the tool has no parameters and an output schema exists, the minimal description is sufficient for the agent to understand the operation's scope.
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 there are no parameter details to clarify. The description faces no burden in this area.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb '获取' (get) with the resource 'UDPXY 配置' and clarifies the context with '组播转 HTTP' (multicast to HTTP), distinguishing it from similar tools like get_igmp_proxy_config.
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. The description only states what it does and does not mention exclusions or alternative 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?
The annotation readOnlyHint=true already indicates a safe read operation. The description adds the scope of what is retrieved (status and mapping table) but does not disclose additional behavioral traits such as authentication requirements, data freshness, or potential 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 concise sentence that immediately states the purpose. It contains no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with an output schema, the description sufficiently communicates what is retrieved. The presence of an output schema means the description does not need to detail return values.
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 takes zero parameters, so the schema covers all parameter information. The baseline of 4 applies because no parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '获取' (get) and the specific resource 'UPnP 当前状态和映射表' (UPnP current status and mapping table). This distinguishes it from sibling tools like get_upnp_settings by explicitly scoping to status and mappings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as get_upnp_settings or list_port_mappings. The description relies entirely on the name to imply usage, providing no exclusions or 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?
Annotations declare readOnlyHint=true, and the description is consistent ('获取' = get). It adds useful context by specifying the returned data (AP count/status), but does not disclose other behavioral traits like real-time vs. cached data or response formatting. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence in Chinese that immediately conveys the purpose and key content. No wasted words, and the essential information is front-loaded.
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, a read-only annotation, and an output schema, the description sufficiently conveys the operation and expected result (AP count and online status). The tool is simple, and the description covers it adequately.
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 zero parameters, the schema already fully covers the parameter space. The description adds no parameter-specific detail but is not required to; the baseline of 4 applies for 0-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb '获取' (get) and resource '无线监控' with precise scope 'AP 数量/在线状态' (AP count/online status). This clearly distinguishes it from sibling monitoring and AP-specific tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions or name alternate tools for related tasks, leaving the agent to infer usage solely from the name.
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 annotation readOnlyHint=true already discloses the read-only nature. The description adds no additional behavioral traits such as pagination, authentication, or data freshness. It neither contradicts nor enriches the annotation, so a neutral score 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise phrase that communicates the purpose without any wasted words. It is appropriately front-loaded and minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, list-only), the description is fully adequate. The output schema covers return values, and the annotation covers safety. No further context is needed.
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 the schema is complete. With no parameters to describe, this dimension is trivially satisfied; the 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 '列出个人 API 令牌' clearly states the action (list) and the resource (personal API tokens). It is specific enough to distinguish this tool from sibling list tools like list_admin_accounts or list_vpn_accounts.
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, and there are many sibling list tools. No exclusions or contextual triggers are mentioned, so the agent must infer usage solely from the name.
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 annotation readOnlyHint=true already declares this as a read-only operation, so the agent knows it is safe to call. The description adds no additional behavioral context (e.g., return size, speed, rate limits), but it does not contradict the annotation.
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 phrase, front-loaded with the verb 'list' and the object 'custom ISP rules'. Every word is meaningful and there is no unnecessary detail.
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, an output schema exists, and the annotation covers safety, the description is sufficient for the agent to invoke the tool correctly. The tool's simplicity means no further context is required.
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 0 parameters and the schema is empty with 100% coverage, so there is no parameter information needed. The description does not need to explain any inputs, earning the baseline score 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 '列出自定义运营商规则' translates to 'List custom ISP rules', clearly stating a specific verb (list) and resource (custom ISP rules). It distinguishes the tool from siblings as no other tool mentions ISP rules.
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. The description only states the action without any context, prerequisites, 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?
The annotation readOnlyHint=true already establishes the read-only nature. The description adds minimal extra context by specifying 'all', indicating the response includes every LAN port configuration without filtering. However, no further behavioral details such as pagination, order, or potential performance implications are provided.
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 phrase in Chinese that serves its purpose without any wasted words. It is front-loaded with the verb and resource, making it highly scannable and appropriate for its simple 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 simplicity of the tool (0 parameters, read-only annotation, and an existing output schema), the description is sufficient. The output schema defines the return structure, and the read-only annotation covers safety, so the description need not elaborate further. The scope ('all') is also clearly stated.
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 the input schema is empty. Per the scoring rubric, a parameterless tool receives a baseline score of 4, as there is no parameter documentation burden. The description adds no parameter information, which is acceptable 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 '列出所有 LAN 口配置' clearly states the action (list all) and the resource (LAN port configurations), making the tool's purpose unambiguous. It distinguishes itself from related sibling tools like list_wan_configs and list_vlan_configs by specifying 'LAN'.
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. The description lacks any mention of user/workspace filtering, exclusions, or references to sibling tools like list_wan_configs. The intended context is only implied by the tool name and description.
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?
The description adds no behavioral traits beyond the readOnlyHint annotation. It simply restates the tool's purpose without mentioning any additional context such as return format, pagination, or ordering, which would be useful even for a no-parameter list 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 concise sentence with no superfluous words. It delivers the essential purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, read-only annotation), the description is sufficient. It clearly states what the tool does, and the output schema is available to explain return values, so no further detail is necessary.
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 description is not required to explain parameter semantics. Per the rubric, 0 params warrants a baseline score of 4, and the description does not need to compensate for any missing parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出 MAC 限速规则' clearly indicates a specific action: listing MAC-based speed limit rules. It distinguishes from sibling tools like list_ip_speed_limits, which target IP-based rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the tool name and description: one would use this when needing to view MAC speed limit rules. However, there is no explicit guidance about when not to use it or which alternative to choose for IP-based rules, leaving some ambiguity.
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?
Annotations provide readOnlyHint=true; the description adds the specific scope of wireless terminal VLANs, which is useful context. However, no additional behavioral traits such as return format or dependencies 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?
One short sentence accurately conveys the tool's function. No filler or unnecessary detail.
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 read-only list operation with no parameters and an output schema, the description sufficiently conveys the tool's purpose. The output schema handles return structure, and annotations cover safety.
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 the schema is empty. The description adds no parameter semantics, which is acceptable as there is nothing to document; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出无线终端 VLAN 配置' clearly states the tool lists wireless terminal VLAN configurations. It distinguishes from sibling 'list_vlan_configs' by specifying 'wireless terminal' scope.
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 guidance is provided. The description does not mention when to use this tool over alternatives like 'list_vlan_configs' or other list operations.
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?
Annotations already declare readOnlyHint=true, and the description's '获取' consistently indicates a read operation, so no contradiction. It adds modest context by enumerating the setting categories, but discloses no additional behavioral traits (e.g., auth requirements, defaults, or response granularity) beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence in Chinese with no filler; every word conveys the tool's scope and examples. Ideal length for a no-parameter getter.
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, zero params, existing output schema, and read-only annotation, the description is mostly complete. The '等' (etc.) leaves the exact setting list open, but that is not a serious gap for a basic settings getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4; the description correctly focuses on the resource rather than parameter syntax. No parameter clarification 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 ('获取' = get/retrieve) and identifies a clear resource ('设备基础设置' = device basic settings), with concrete examples (hostname/timezone/NTP). This distinguishes it from sibling getters like get_wifi_basic_settings or get_system_overview.
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 usage context is implied: use when needing hostname/timezone/NTP-level basic settings. However, it gives no explicit guidance on when not to use it or which sibling alternative to prefer, though the resource name is reasonably self-explanatory.
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?
Annotations already declare readOnlyHint=true. The description adds only a UI navigation path (Smart Flow Control → Flow Control Lines), which is useful context but does not disclose other behavioral traits like response structure or scope (e.g., that it returns all lines). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. The verb and resource are immediate, and the UI path is appended as a useful parenthetical.
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?
With zero parameters, an output schema, and a readOnly annotation, the description is mostly complete for an agent to invoke the tool correctly. It could explicitly state that it returns the entire current line configuration, but the name and UI path provide enough 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?
The tool has zero parameters, so the schema fully covers parameters. The description adds no parameter details, but none are needed. Per the rubric, a 0-parameter tool gets a baseline of 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 Chinese description uses a specific verb '获取' (get) and a clear resource '流控线路配置' (flow control line configuration), plus a UI navigation path '智能流控 → 流控线路'. This clearly differentiates it from sibling tools like set_flow_control_line that perform mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: this is a read-only getter for flow-control line settings, and sibling set_flow_control_line is for changes. However, there is no explicit guidance on when to use this tool vs alternatives, nor any exclusion conditions.
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?
Annotations already declare readOnlyHint=true, and the description adds no additional behavioral details. It is consistent and minimally transparent, but lacks insight into return format or any prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded, concise sentence that directly conveys the tool's purpose. 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?
For a zero-parameter read-only getter with an output schema, the description is complete enough. It could optionally state that it retrieves the current config, but the name and schema cover the essentials.
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, making parameter documentation unnecessary. The description adds no parameter info, but with no params this is satisfactory.
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 '获取 PPPoE 服务端配置' precisely states the action (get) and resource (PPPoE server configuration), distinguishing it from sibling config getters for other protocols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the tool name and description; it is clear this is for retrieving PPPoE server settings, but no explicit alternatives or exclusionary guidance is provided.
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 readOnlyHint annotation already signals a safe read operation, and the description adds a detailed list of return fields with value meanings (0/1 states and default ports). However, it does not disclose additional behavioral traits such as permission requirements or potential side effects (none expected for a read). With the annotation covering safety, this is adequate but not rich.
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 a one-line summary followed by a clearly structured list of return fields. Each field includes its meaning and possible values, making the description highly scannable 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?
For a simple read-only tool with no parameters and an output schema, the description covers the purpose and fully documents the return fields. It lacks explicit guidance on when to use this tool versus sibling configuration tools, a minor gap, but the description is otherwise complete for its simple scope.
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 the schema provides complete coverage (100%). The description does not need to explain parameters, and the field list it provides concerns the return value rather than parameters. Per the zero-parameter baseline, a score of 4 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 purpose with a specific verb ('获取' = get) and resource ('远程访问配置' = remote access configuration), further narrowing scope to SSH/Telnet/FTP/Web port statuses. This distinguishes it from sibling setter tools like enable_ssh or set_web_ports.
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 it is used to retrieve current remote access configuration, but it does not explicitly state when to use it versus sibling write tools (e.g., enable_ssh, set_web_ports). No alternatives or exclusions are mentioned, leaving usage context implied rather than explicit.
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 annotation readOnlyHint=true already indicates the operation is read-only, and the description's 'list' wording is consistent. The description does not add further behavioral context such as sorting or filtering, but the simplicity of the operation and the presence of an output schema mitigate the need for additional details.
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 phrase that directly communicates the tool's function without any unnecessary words 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?
For a zero-parameter, read-only list operation with an output schema, the description is adequate to convey purpose. It could explicitly mention that it returns all groups, but the simplicity of the tool makes the current description sufficient.
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 the input schema is empty, making parameter coverage 100% by definition. With no parameters to describe, the description does not need to provide additional semantics, and the baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出 MAC 地址分组' translates to 'List MAC address groups', which clearly identifies the action (list) and the resource (MAC address groups). This distinguishes it from sibling tools like add_mac_group and delete_mac_group, which handle creation and deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool or mention alternatives. However, its purpose as a listing operation is implied by its name and the presence of related add/delete siblings, so an agent can infer that it is used to view existing MAC groups.
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 adds domain context by explaining what 'network sharing controls' refers to (secondary routing/hotspot control), which goes beyond the readOnlyHint annotation. For a zero-parameter list operation, this is adequate behavioral disclosure, though it doesn't mention response format or whether all entries are returned.
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 is front-loaded with the core verb and resource, then clarifies scope in parentheses. There is zero waste and 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?
For a simple read-only list tool with no parameters and an output schema present, the description provides sufficient context. It explains what the tool lists and the domain. The only gap is lack of usage guidance, but that is already factored into the usage_guidelines score.
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 zero parameters, so the baseline is 4. The description does not need to explain parameters, and no parameter information is missing. The parenthetical clarification adds useful semantic context about what is being listed.
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 '列出' (list) and identifies the resource '网络分享控制' (network sharing controls), with a parenthetical clarification '二级路由/热点控制' that explains the domain. This clearly distinguishes it from sibling list tools like list_wan_configs or list_lan_configs.
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. There is no mention of use cases, exclusions, or relationship to other tools. The agent must infer usage solely from the name and description.
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?
Annotations declare readOnlyHint=true, so the agent knows this is a safe read operation, and the description aligns with that. However, the description adds no extra behavioral context such as pagination, sorting, or limits. The presence of an output schema covers return structure, so a score of 3 is appropriate given minimal additional value.
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, efficient phrase with no extraneous information. Every word contributes to the meaning, and it is appropriately sized for a tool with no parameters and a clear purpose.
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 is simple (no parameters) and has an output schema, so the description sufficiently explains its core purpose. However, it could briefly clarify what 'online' status entails or whether it returns the same fields as list_proxy_dial_accounts. Given the low complexity, the current description is nearly 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?
This tool has zero parameters, so parameter semantics are trivially satisfied. Baseline for 0 params is 4, and the description does not need to explain any parameter details. The schema is also fully covered.
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 online proxy-dial accounts, using the specific verb 'list' and a well-defined resource ('online accounts'). This distinguishes it from sibling tool list_proxy_dial_accounts, which likely lists all accounts, by adding the 'online' qualifier.
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 viewing currently online proxy-dial accounts, but it provides no explicit guidance on when to choose this tool over alternatives like list_proxy_dial_accounts. The sibling names give context, but the description does not state any exclusions or alternative conditions.
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 readOnlyHint annotation already communicates the safe read-only nature. The description adds the protocol list and the 'all' scoping, which is marginally useful. But it does not disclose any additional behavioral traits such as response size, sensitivity of credentials, or absence of filtering capabilities, so it remains a minimal contribution beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the verb and resource, then enumerates the supported protocols in parentheses. Every word adds value, with no redundancy or filler.
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 simple read-only list function, zero parameters, and presence of an output schema, the description is largely complete. It clearly enumerates the VPN protocol types covered. It could have added a note about using individual getters for per-protocol details, but that nuance is not necessary for a functional understanding, and the sibling names make the distinction apparent.
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 the input schema is an empty object with 100% coverage. There is nothing for the description to explain about parameters. The baseline of 4 for zero-parameter tools applies, as the description correctly avoids inventing irrelevant parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all VPN client configurations across six named protocols (PPTP/L2TP/OpenVPN/IPSec/IKEv2/WireGuard). It uses a specific verb (列出/list) and resource (VPN client configurations), and the scope ('所有/all') distinguishes it from sibling tools that fetch individual client configs or server configs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for getting a complete overview of all VPN client types, while siblings like get_pptp_client_config serve specific protocols. However, it does not explicitly state when to use this over the individual getters or mention any exclusion cases, so guidance is only implied rather than explicit.
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 readOnlyHint annotation already establishes this as a safe read operation. The description adds the specific protocol coverage, but doesn't disclose return format, limitations, or other behavioral traits. It is consistent with the annotation and adds minimal value beyond it.
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, front-loading the verb '获取' (get) and adding a parenthetical clarification. No wasted words; ideal for a simple getter.
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 zero-parameter input, the readOnlyHint annotation, and the presence of an output schema, the description sufficiently covers what the tool does and its context. No additional elaboration on outputs or prerequisites is necessary.
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 in the schema, so there are no parameter semantics to explain. The description is not required to compensate for schema gaps. The baseline of 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves ALG settings and specifies the protocol scope (FTP/TFTP/SIP/H323), using a specific verb+resource+scope structure. This distinguishes it from other getter tools in the sibling list, which target different network functions.
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 usage context or alternatives are provided. The description is definitional only; it doesn't state when to use this tool versus other configuration tools. Usage is implied by the getter nature, but there is no clear guidance.
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 adds minimal behavioral context beyond the readOnlyHint annotation, which already indicates this is a safe read operation. It does not describe return format, side effects, or any additional behavioral traits, but for a zero-parameter read-only tool, the annotation covers the main concern.
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 phrase that fully communicates the tool's purpose without unnecessary words. It is front-loaded and appropriately sized for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with an output schema, the description is complete enough. The context is clear given the sibling tool names, and no further details about return values are needed because the output schema exists.
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 zero parameters, and schema coverage is 100% (vacuously). The description does not need to explain parameters, earning a baseline of 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 the tool's function: '获取 IKEv2/IPSec 服务端配置' (get IKEv2/IPSec server configuration). It specifies a distinct resource (server config for the IKEv2/IPSec protocol) and differentiates from sibling tools like get_ikev2_client_config and get_pptp_server_config.
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 no explicit guidance on when to use this tool versus alternatives. Usage is implied by the name and description—retrieve the IKEv2/IPSec server configuration—but there is no explicit mention of alternatives 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?
The description adds no behavioral context beyond the readOnlyHint annotation. It does not contradict the annotation, but it also does not disclose any additional traits such as what the configuration includes or whether the operation is always safe beyond the annotation's indication.
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 directly states the tool's function with no wasted words. It is perfectly sized for this simple getter.
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 that the tool has no parameters, has an output schema, and is a read-only getter with a clear purpose, the minimal description is sufficient. There is no need for additional context about return values or side effects because those are covered by the output schema and readOnlyHint annotation.
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 is 4. The description is not required to explain parameter semantics because there are none, and the schema is complete with 100% 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 states the tool gets L2TP server configuration ('获取 L2TP 服务端配置'), which is a specific verb+resource. It distinguishes from sibling tools like get_l2tp_client_config (client vs server) and other VPN server config getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied from the name and description—it is for retrieving L2TP server configuration. However, there is no explicit guidance on when to use it over alternatives such as get_pptp_server_config or get_l2tp_client_config, nor any 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?
The description adds context by specifying the L7 QoS flow control domain and that it concerns execution status, which is beyond the generic readOnlyHint annotation. However, it does not disclose additional behavioral details such as data freshness, permission requirements, or response characteristics, so it provides only minimal added 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, compact sentence in Chinese that immediately states the tool's primary purpose and its specific scope. It is front-loaded and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: no parameters, a read-only hint, and an output schema. The description clearly communicates the tool's purpose and domain. Given the low complexity and supporting structured fields, it is complete for an agent to select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter information needed in the description. The schema already covers this completely (trivially), and a baseline of 4 is appropriate given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb '获取' (get) and clearly identifies the resource as '策略监控' (policy monitoring) with a specific focus on 'L7 QoS 流控策略执行状态' (L7 QoS flow control policy execution status). This distinguishes it from sibling tools like get_flow_control_strategies that likely return policy configurations rather than execution status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool over alternatives or mention any exclusions. It implies a use case—checking the execution status of L7 QoS flow control policies—but lacks explicit guidance on alternatives, leaving the agent to infer based on the resource name.
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 annotation readOnlyHint=true already indicates this is a safe read operation, and the description confirms it. No additional behavioral details are added (e.g., specific returned data, permissions, side effects), but none are necessary for such a simple getter.
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, short, front-loaded sentence with no filler words. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, read-only, output schema exists), the description is complete. It fully conveys what the tool does without needing additional details.
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 is 4. The description does not need to explain parameters 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 '获取 SNMP 服务配置' clearly states the verb (get) and the resource (SNMP service configuration), distinguishing it from sibling tools like set_snmp and other configuration getters. It is 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance is provided. The context implies this tool is for retrieving SNMP configuration, especially given the sibling set_snmp, but there is no explicit statement of when to use it over alternatives or any 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?
The readOnlyHint annotation covers the safety profile, and the description adds no extra behavioral context beyond stating the action. It does not mention any side effects, because there are none, but also provides no additional context like what exactly is returned or how the config is structured. Overall, it is neutral and does not contradict the annotation.
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 with no wasted words. It is front-loaded and directly conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with no parameters and an existing output schema, the description is complete. The output schema covers return values, and the readOnlyHint covers safety. No further elaboration is needed.
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 0 parameters, so the schema is fully covered (vacuously). The description does not need to explain parameters. 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 the action ('get') and the resource ('Web认证服务配置' = web auth service config), which is specific and distinct from siblings like toggle_web_auth. It unambiguously identifies what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: it's a getter, so use it when you need to retrieve web auth configuration. However, there is no explicit guidance on when to use it versus alternatives, nor any mention of prerequisites 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?
The annotation readOnlyHint=true already declares this as a safe read operation. The description adds no additional behavioral context beyond the fact that it lists admin accounts; it doesn't mention pagination, ordering, or authentication requirements. It does not contradict the annotation.
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 phrase, '列出管理员账号', that fully captures the tool's purpose without unnecessary 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?
Given the tool has no parameters, a read-only annotation, and an output schema exists to describe the return structure, the description is sufficient for an AI agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameter semantics to explain. The description is not required to add parameter details. Baseline for zero-param tools 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 uses the verb '列出' (list) and specifies the resource '管理员账号' (admin accounts), clearly distinguishing it from sibling tools like add_admin_account and change_admin_password which mutate admin accounts.
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 no explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions. However, the tool name and description make its use case obvious: retrieving the list of admin accounts. This is implied rather than 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?
The annotation readOnlyHint=true already informs the agent that this is a safe read operation. The description adds the UI tab context ('tab: URL 跳转') but does not disclose any additional behavioral traits such as output format, pagination, or scope. With annotations covering the safety profile, a middle score 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, front-loaded with the action and resource. Every word is useful, and there is no redundant information. It exemplifies conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—no parameters, a clear read-only purpose, and an output schema present—the description provides adequate context. There is no missing information that would impede correct selection or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no need for parameter descriptions. The baseline for zero-parameter tools is 4, and the description does not need to compensate for any schema coverage gap. The description is sufficient.
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 clear verb+resource pattern: '列出' (list) + 'URL 跳转规则' (URL redirect rules), making the tool's function unambiguous. It also adds the context 'tab: URL 跳转', which helps distinguish it from sibling list tools like list_url_blacklist and list_url_keywords.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions. However, the tool's purpose is self-evident from its name and description, and the readOnlyHint plus the specific resource make the intended use case clear. It could benefit from mentioning related tools or situations where this is the appropriate choice.
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 readOnlyHint annotation already indicates this is a safe read operation, and the description adds no additional behavioral context (e.g., pagination, default VLAN inclusion, or permission requirements). The bar is lower due to the annotation, but the description still provides minimal extra value.
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 fully conveys the tool's purpose with 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?
Given the tool has no parameters and an output schema exists to describe return values, the description is complete for this simple list operation. No additional context is needed.
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 0 parameters and schema coverage is 100%, so per the rubric the baseline is 4. The description does not need to add parameter details since there are none, and it correctly implies 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 '列出所有 VLAN 配置' clearly indicates a list operation for all VLAN configurations. The verb 'list' is specific and the resource 'VLAN configs' is well defined, distinguishing it from sibling tools like list_wan_configs and list_lan_configs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, but for a simple list operation, the usage is implied: use when you need all VLAN configurations. No exclusions or alternative tools 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?
The readOnlyHint annotation already establishes this as a safe read operation. The description adds the specific log type (PPPoE/VPN authentication records), providing useful scoping beyond the annotation. It does not detail output format or other behaviors, but an output schema exists to cover that, and the annotation covers safety.
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 short sentence that front-loads the action and resource without any filler or redundancy. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only log retrieval tool with an output schema, the description is sufficient: it names the exact purpose and scope. The sibling context shows many log tools, and this one is uniquely identified as authentication logs for PPPoE/VPN.
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?
This tool has zero parameters, so the input schema covers everything trivially (100% coverage). There is no need for parameter explanations in the description, and the baseline for zero parameters 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 the tool's action ('获取' meaning 'get') and resource ('认证日志' meaning 'authentication logs'), with a parenthetical clarifying it covers PPPoE/VPN authentication records. This specific scope distinguishes it from sibling log tools like get_arp_log or get_dhcp_log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for authentication logs specifically for PPPoE/VPN, which implies its use case. However, it does not explicitly mention alternatives or when not to use it, though the parenthetical scope offers some implicit 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?
The annotation readOnlyHint=true already covers safety, so the description only needs to add context. It adds that the data is real-time and spans all WAN/LAN interfaces, which is useful. However, it does not disclose additional behavioral traits like potential response size or latency, which is a minor gap.
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 one concise sentence, front-loaded with the action, and includes all necessary details without redundancy. It earns its place perfectly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only monitoring tool with an output schema, the description fully covers the scope (all WAN/LAN interfaces) and the nature of the data (real-time rates, connections, packet loss). No additional explanation is needed.
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 is 4. The description does not need to explain any parameter semantics, and it doesn't, which 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 specifies the verb (获取/get), the resource (线路监控/line monitoring), and the exact scope (所有 WAN/LAN 接口) with metrics (实时速率/连接数/丢包率). This distinguishes it from sibling tools like get_ipv6_line_detail or get_wan_status, which target different scopes or metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it's for real-time monitoring of all WAN/LAN interfaces. This implies when to use it, but it does not explicitly name alternatives or exclusions, so it stops short of the highest score.
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 annotation readOnlyHint=true already indicates a safe read operation. The description adds value by specifying exactly which settings will be retrieved (SSID/encryption/channel), which goes beyond the annotation. No contradictions detected.
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, clear sentence that front-loads the action ('get') and immediately specifies the resource. Every word is informative, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read operation with an output schema available, the description is complete. It tells the agent exactly what the tool returns. No prerequisites or side effects need explanation.
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 to document, so the description does not need to explain parameters. The schema already provides full coverage. A baseline of 4 is appropriate for a zero-parameter 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 uses a specific verb ('获取' = get) and clearly identifies the resource (Wi-Fi basic settings) along with key fields (SSID/encryption/channel), distinguishing it from sibling tools like get_wifi_advanced_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 implies the tool is for retrieving basic Wi-Fi settings, but it does not explicitly state when to use it versus alternatives like get_wifi_advanced_settings or set_wifi_ssid. It provides no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description is consistent (list = read-only). It adds useful context about the content of the list (status, model, client count), though it doesn't describe pagination or filtering. This is acceptable given the output schema exists.
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, front-loaded with the action, and contains no filler. It is appropriately sized for a parameterless list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with an existing output schema, the description sufficiently covers purpose and content. The listed fields give a clear idea of what to expect, and no critical gaps are apparent.
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 0 parameters, so schema coverage is trivially 100%. Baseline for 0 parameters is 4; no further parameter description is needed. The description adds nothing about parameters, which is fine.
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 'list' and resource 'AP devices' with stated fields (status/model/client count), clearly distinguishing it from AP config/action tools among siblings. It unambiguously states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are mentioned. The intended usage is implied by the tool name and description (call when you need AP device enumeration), but there is no comparative guidance against sibling tools like get_ap_group_config or get_wireless_monitoring.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds value by specifying the exact services covered (FTP/Samba/HTTP), which is useful behavioral context beyond the annotation. 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?
Single, front-loaded sentence with zero unnecessary words. Efficiently conveys the tool's purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with an output schema, the description is complete. It specifies what is listed and the service scope without needing to explain return values.
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 baseline is 4. The description correctly provides no parameter details 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?
Description clearly states the tool lists local service status for specific services (FTP/Samba/HTTP), providing a specific verb and resource scope that distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to check local service status) but provides no explicit guidance on alternatives or exclusions. Given many sibling list/get tools, the usage context is clear but not 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?
Annotations already declare readOnlyHint=true, and the description complements this by specifying exactly what data is returned (IP, access method, NIC, VLAN, rate). This adds valuable context beyond the read-only flag, though it does not cover potential behaviors like ordering or result limits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource ('List all WAN port configurations') with a parenthetical list of key details. Every word earns its place, and no space is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with an output schema, the description is fully adequate. It tells the agent exactly what the tool returns and implies no side effects. The scope of the operation is simple and clearly communicated.
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 description carries no parameter burden. It does provide useful context about the output content, which is relevant for understanding the tool's function. Baseline for 0 params is 4, and the description meets that baseline.
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 all WAN port configurations and enumerates the key fields (IP, access method, NIC, VLAN, rate). This specific verb-resource combination distinguishes it from sibling tools like list_lan_configs and get_ipv6_wan_config, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: an agent needing WAN port configuration details would use this tool. However, the description does not explicitly state when to use it over alternatives (e.g., list_lan_configs for LAN configs or get_ipv6_wan_config for IPv6-specific WAN info), nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, and the description adds useful scope context beyond that by specifying that this log covers system events such as reboots and upgrades. It does not go into pagination or retention, but the output schema covers return structure, so the additional value 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one short, front-loaded sentence with no filler. It states the core action and clarifies scope with parenthetical examples, earning its place fully.
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, an output schema exists, and read-only behavior is annotated, this one-sentence description is sufficient. It tells the agent what the tool does and what kind of events are included, leaving no critical gaps.
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 baseline 4 applies. There is no parameter information needed, and the description does not add irrelevant parameter 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 uses a specific verb+resource pattern ('获取系统事件日志') and gives concrete examples of event types (重启/升级等), which clearly distinguishes it from sibling log tools like get_auth_log or get_dhcp_log.
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 parenthetical examples (重启/升级等) provide clear context for when this tool is relevant—system-level events rather than user/auth/DHCP logs. It does not explicitly name alternatives or exclusions, but the scope is implied and clear enough for simple selection.
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:

[![ikuai-mcp-server MCP server](https://glama.ai/mcp/servers/gxxHuang/ikuai-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/gxxHuang/ikuai-mcp-server)

Score Badge

Copy to your README.md:

[![ikuai-mcp-server MCP server](https://glama.ai/mcp/servers/gxxHuang/ikuai-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/gxxHuang/ikuai-mcp-server)

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/gxxHuang/ikuai-mcp-server'

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