devbelt-mcp

by regaing

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation5/5
Each tool has a unique combination of category prefix and explicit operation, making their purposes distinct. Even similar utilities like encode_unicode and encode_utf8 are clearly differentiated by their descriptions.
Naming Consistency5/5
All tool names follow a consistent lowercase snake_case pattern with category prefixes (e.g., json_, text_, net_, misc_) and action suffixes. This predictable structure aids navigation across the large set.
Tool Count2/5
With 53 tools, the server far exceeds the 25+ threshold for a single MCP server. While each tool has a purpose, the sheer volume creates selection overhead and suggests the set should be split into focused sub-servers.
Completeness4/5
The toolset provides broad coverage of common developer utilities, including text processing, encoding, crypto, networking, and code generation. Minor gaps exist (e.g., no asymmetric encryption, no image format conversion), but core workflows are well supported.
Average 3.8/5 across 53 of 53 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 22 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only mentions regex handling. It does not state whether all occurrences are replaced, how the replace parameter behaves when omitted, or what the return value looks like. This leaves significant behavioral gaps 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and easy to parse. It wastes no words, though it could benefit from a bit more detail on replacement semantics. The structure is appropriate for the tool's simplicity.
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 lack of annotations and output schema, the description is too minimal. It fails to explain return values, whether replacement is global, or how to use the tool effectively among many siblings. The description is insufficient for an agent to understand the full tool behavior.
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 0%, so the description must compensate. It adds meaning to 'find' and 'use_regex' by explaining regex behavior, but it does not explain the 'replace' parameter or its default behavior. This is partial compensation for a 4-parameter tool, but not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool performs text find-and-replace, which is a specific verb+resource. Mentioning regex behavior helps distinguish it from sibling tools like text_filter or text_dedup. However, it does not explicitly clarify that it replaces occurrences, leaving slight ambiguity 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 exclusions, such as when to prefer regex_tool or other text manipulation tools. The only hint is the regex flag, but no context is given about suitable use cases.
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 mentions output_path can save as a .url file, but does not explain the return value, side effects (e.g., file overwriting), or behavior when output_path is omitted. Significant behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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. Every word earns its place, with no fluff or redundant content.
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 being a simple tool with only 3 parameters and no output schema, the description lacks essential context such as return behavior, usage conditions, and handling when output_path is absent. The tool is understandable but incomplete for an AI agent to invoke correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains the output_path parameter; name and url are not described beyond their self-evident names. The description adds minimal semantic value for parameters, leaving most of their meaning to be inferred.
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 generates Windows desktop shortcut (.url file content) with a specific verb and resource. It distinguishes itself from the other misc_* sibling tools (barcode, qrcode, favicon) by focusing on shortcut generation.
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 scenarios where other tools 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.
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 add value by revealing that png format returns a base64 dataURL and that output_path can save a file, plus clarifying error_level values. However, it does not mention default size/margin behavior, return format for svg, or error/edge-case handling.
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 dense sentence that front-loads the primary action and then efficiently lists the most important optional parameters. Every phrase adds value, 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?
For a QR generation tool with no output schema and no annotations, the description covers the core parameters and return type, but omits size and margin defaults, exact output structure, and any usage examples. It is adequate for basic selection but incomplete for fully autonomous invocation without relying on parameter names.
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 low (33%), so the description must compensate. It adds meaning for format (png/svg, dataURL), error_level (L/M/Q/H), and output_path (save file), which are otherwise undocumented in the schema. However, the size parameter remains completely unexplained, and the description does not clarify margin or text 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 purpose: "二维码生成" (QR code generation), with a specific verb and resource. It mentions key format options, but does not explicitly differentiate from sibling tools like misc_barcode, though the name itself distinguishes 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 given on when to use this tool versus alternatives. The description only lists configuration options, not usage context or exclusions. There is no mention of scenarios where QR code generation is appropriate or alternatives like barcode generation.
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 states the tool is a query and supports keyword filtering, but does not disclose what the output looks like, whether results are localized, how to handle unsupported topics, or any other behavioral traits. This is minimal disclosure but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence followed by a topic list. It is front-loaded with the core purpose and contains no redundant or filler content. Every element 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?
For a simple lookup tool with two parameters and no output schema, the description is adequate for basic invocation: it lists all valid topics and mentions optional filtering. However, it does not specify the return format or any constraints on keyword usage across topics, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: topic has an enum but no description, while keyword has a short description. The tool description adds the context of 'reference table query' and says keyword is an optional filter, but it mostly restates the enum values already present in the schema. It provides some extra meaning but does not fully compensate for the missing topic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries common reference tables and lists all available topic values. This specific verb+resource combination, along with the topic list, distinguishes it from sibling misc tools like barcode, qrcode, favicon, and shortcut.
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 is given on when to use this tool versus alternatives. The description only mentions that topic is optional (though schema marks it required) and keyword is an optional filter, but does not discuss scenarios, 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that code is generated but does not explain the output format (e.g., a string snippet), whether the regex must be valid, how flags are handled, or any limitations across languages. This lack of detail leaves the agent guessing 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, concise sentence that is front-loaded with the core action and lists the key language options. Every word contributes to the meaning without redundancy or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 0% parameter coverage, the description is too sparse to fully inform an agent. It omits essential context such as return value, error handling, and how the tool interacts with the parameters, leaving the agent with an incomplete understanding of how to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 lists the supported languages, which partially clarifies the 'language' parameter. It does not explain the 'pattern' or 'flags' parameters, nor does it mention that 'pattern' is required or that 'flags' has a default. The description adds minimal 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 clearly states the tool's function: generating regular expression code in multiple languages (js/java/go/php/ruby/python/cs). The verb 'generate' and the resource 'code for regular expressions' are specific, and the explicit list of languages differentiates it from sibling tools like regex_tool.
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 one needs code snippets for a regex in a specific programming language. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or compare with sibling tools such as regex_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 must carry the full burden of behavioral disclosure. It mentions the conversion behavior (first row as header) but does not disclose error handling, edge cases, or the exact format of the output (<table> code is vague). The description is minimal and leaves important behavioral traits uncovered for a pure function with no 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 is front-loaded with the core purpose, followed by input/output specifics. Every word contributes value, and there is no wasted or redundant phrasing.
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 (3 params, no output schema) and the description covers the essential transformation (CSV/JSON to HTML table) including the header-row rule. It lacks details about return format nuances and error behavior, but given the low complexity and clear core, it is reasonably complete for an agent to select and invoke the 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?
Schema description coverage is 67% (data and style have descriptions, data_type only has enum/default). The description adds meaning by clarifying that the data parameter accepts CSV or JSON arrays and that the first row of CSV is treated as a header. It does not explain the data_type parameter explicitly, but the coverage is moderate and the description provides some complementary 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 clearly states the tool generates HTML table code from CSV or JSON input, with a specific verb ('generates') and resource ('HTML table'). It does not explicitly differentiate from sibling tools like data_html_convert, but the input format and output are clearly specified.
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 primary use case (converting CSV/JSON to an HTML table) but does not explicitly mention when to use this tool over alternatives or when not to use it. There is no mention of exclusions or comparisons to sibling tools, so the guidance is only implied.
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 automated encoding handling (GBK/GB2312) and the fake_ip behavior with a caution ('谨慎使用'), but it omits critical behaviors such as redirect handling, timeouts, error responses, or the security risks of fetching arbitrary URLs (e.g., SSRF). This is insufficient for a network fetch 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 two short sentences. It leads with the tool's purpose and follows with the one important usage caution. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must convey return format and operational details. It only says 'decoded text' without specifying whether it's raw HTML or extracted content, and omits error handling, redirect policies, and rate limits. The tool's potential for misuse (fake_ip) is mentioned but not sufficiently elaborated.
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 provides descriptions only for max_chars (33% coverage). The description adds meaning to fake_ip by explaining its effect ('偽装国内 IP') and clarifies the url's purpose implicitly. It does not elaborate on url format or max_chars behavior beyond the schema, but the schema already covers max_chars.
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 directly states the tool's function: '网页抓取/内容采集' (web scraping/content collection) and '抓取 URL 返回解码后的文本' (fetch URL and return decoded text). This clearly identifies the verb, resource, and output, distinguishing it from network utility siblings like net_whois or net_url_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 gives a general use-case label and a caution for fake_ip, but does not explicitly discuss when to use this tool versus alternatives or any exclusions. No siblings are mentioned, so usage guidance is largely 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.
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 disclosing behavior. It mentions core filtering actions but is ambiguous about whether script/style content is fully removed or just tags, and does not explain edge cases like malformed HTML. The description also contradicts the schema's default value: it states '默认空格' (default space) while schema default is empty string, adding confusion.
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 that front-loads the primary action and lists options. It earns its place without fluff, though the compactness contributes to some ambiguity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description should cover defaults, edge cases, and return behavior. It addresses primary functionality but leaves gaps such as whether content inside script/style is stripped, how replacement applies, and what the output looks like. Overall, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (67%) for keep_tags and replace_with, and the description reinforces their meanings. However, the html parameter lacks a schema description and the description does not elaborate on expected format. The default value contradiction between description and schema further detracts from semantic clarity.
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 filters HTML tags, specifically removing script/style and tags, with optional keep and replace behaviors. This specific verb+resource combination distinguishes it from sibling tools like text_replace or data_html_convert.
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 HTML tag sanitization but does not explicitly state when to use this tool over alternatives like text_replace or regex_tool. No exclusions or alternative recommendations are provided, leaving usage inference 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?
With no annotations, the description carries the transparency burden. It adds useful behavioral context: ubb supports bidirectional conversion, and direction=to_html changes the input semantics of the 'html' parameter. However, it omits details about output format, lossiness, or behavior for other targets with to_html, leaving 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 one concise sentence that starts with the core purpose and then packs the necessary target/direction details. No wasted words, and it front-loads the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and no annotations. The description covers the essential operation and target list but does not describe return values, error cases, defaults (other than direction), or examples. It is adequate but leaves a moderate gap for a simple conversion 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?
Schema description coverage is only 33%, and the description partially compensates by listing target options and clarifying UBB's direction behavior. Yet much of this repeats what's already in enums, and the tool description doesn't deeply explain the meaning of each target or the direction parameter beyond what the schema shows.
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 a specific verb+resource: 'HTML 与其他代码/标记格式互转' (convert HTML to/from other code/markup formats). It distinguishes itself from sibling tools by naming the exact conversion target list (js/php/cs/jsp/asp/perl/ubb/markdown) and clarifying the unique bidirectional UBB support.
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 target options and note about UBB direction, but gives no explicit guidance on when to use this tool versus alternatives like data_html_table or text_format. It does not mention when not to use it 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?
With no annotations provided, the description carries the full burden. It discloses the core behavior: crawling a page and counting keyword occurrences/density. However, it omits potential behavioral traits such as handling of JavaScript-rendered content, rate limits, robots.txt compliance, or how 'density' is calculated. The description is transparent but not deeply revealing of edge cases.
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 (16 Chinese characters) that leads with the tool's purpose and immediately explains the action. No 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a web-crawling tool with no output schema or annotations, the description gives the essential function but lacks details on return format, error conditions, or special cases. It implicitly mentions output ('出现次数与密度') but does not specify structure. Given the tool's simplicity, it is adequate yet leaves room for improvement in operational 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?
Schema description coverage is 0%, so the description must compensate. It maps 'url' to '页面' (page) and 'keyword' to '指定关键词' (specified keyword), adding basic meaning beyond the raw schema. However, it does not clarify matching rules (e.g., case sensitivity, exact phrase) or what 'density' means numerically, leaving some ambiguity for the two 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's function: '网页关键词密度检测' (webpage keyword density detection) and specifies the action '抓取页面统计指定关键词出现次数与密度' (crawl page, count occurrences and density of specified keyword). It distinguishes itself from siblings like net_fetch and net_meta_analyze by focusing on keyword density, a unique resource+action combination.
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 implies usage (when you need keyword density for a page) but provides no explicit guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites. Sibling tools like net_meta_analyze or net_fetch are not mentioned, so the agent has no basis for comparative 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?
With no annotations, the description carries the transparency burden. It discloses the format structure (8-4-4-4-12) and that 'case' controls uppercase/lowercase, adding useful behavioral detail. However, it does not mention count behavior or output format, leaving some ambiguity for a generation 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 core use case and includes key parameter semantics without unnecessary words. Every phrase contributes 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?
For a low-complexity tool with no output schema, the description covers purpose and the main options, but it does not state whether the output is a single string or an array/list when 'count' is used. This is a notable gap for an agent invoking batch generation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for two of three parameters: format ('uuid' vs 'guid') and case ('大小写' = case). It omits 'count', though the schema provides min/max/default for it. Since schema description coverage is 0%, the description partially compensates but not fully.
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 'UUID/GUID 批量生成' (batch generate UUID/GUID), naming the exact resource and action. It also distinguishes from sibling tools by specifying the UUID format variants (8-4-4-4-12 vs guid).
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 about when to use this tool instead of alternatives, and no sibling tools or exclusions are mentioned. The description only explains what it does, not when it should be chosen.
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 behavior. It mentions encryption/decryption but does not clarify how the 'action' parameter (encrypt/decode) interacts with the input. The phrasing '输入普通 http(s) 地址或对应前缀的密文' suggests auto-detection, yet the schema requires an explicit action, creating ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary purpose. Every word is informative, 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 3 parameters (one required, two with enums), no output schema, and no annotations. The description covers the core purpose but omits how the action parameter affects behavior, what output is returned, and default behaviors. It is insufficiently complete for an agent to invoke correctly without further inference.
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 0%, so the description must compensate. It indirectly explains 'text' (URL or ciphertext) and 'engine' (via the listed prefixes), but it doesn't mention the 'action' parameter or map it to encrypt/decode. Partial compensation, but incomplete.
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: '下载地址加解密' (download URL encryption/decryption), and specifies the supported protocols (thunder, flashget, qqdl). This distinguishes it from generic crypto/encoding siblings like crypto_symmetric or encode_base64.
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 is for download URLs and inputs can be plain http(s) addresses or ciphertext with the listed prefixes. It does not explicitly name alternatives or exclusion cases, but the specific scope is evident from the 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?
With no annotations, the description carries the full burden. It discloses the operational modes (lines/chars/words) which is useful behavioral information, but it does not describe the output format, return behavior, or any constraints (e.g., size limits). The tool appears read-only, so risk is lower, but transparency is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core purpose and efficiently covers the main modes. Every word earns its place, with no redundancy or irrelevant 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?
Despite the tool's simplicity, there is no output schema and no annotations, so the description should explain what the tool returns. It only states the diff comparison and modes, leaving the output format undisclosed. This makes the description incomplete for an agent to know what result to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the 'mode' parameter with its enum options, which adds value. However, text_a and text_b are not described, though their purpose is fairly obvious from the context. The description partially compensates but not fully.
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 as text/code diff comparison (文本/代码差异比较) and lists the available modes (lines/chars/words). This specific verb+resource makes it distinct from sibling tools, none of which perform diffing.
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 when comparing two texts or code snippets but provides no explicit guidance on when to use this tool over alternatives, nor any exclusions. It does not mention any sibling tools or contextual 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?
With no annotations, the description carries the full burden. It discloses the core behavior (JS escape encoding/decoding) and the format, but does not detail edge cases, character handling, or reversibility. It is adequate for a simple tool but adds little beyond the 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is concise and free of fluff. Every word contributes meaning, specifying both the operation and the encoding style 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 simple 2-parameter schema and no output schema, the description is reasonably complete but lacks examples, explicit parameter explanations, or details about which characters are encoded. It suffices for basic usage but leaves gaps for an agent to fully anticipate behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explicitly describe the 'text' or 'action' parameters, only implicitly referencing encode/decode. The schema's enum and default provide some meaning, but the description fails to add value 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 states the tool performs escape encoding/decoding in JS escape style (%XX / %uXXXX), clearly identifying the operation (encode/decode) and a specific format that distinguishes it from sibling tools like encode_url or encode_unicode. This is a specific verb+resource with style differentiation.
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 JS escape style encoding/decoding but does not explicitly state when to use this over alternatives or provide exclusions. It mentions the style, which gives context, but lacks direct guidance on choosing between sibling encoders.
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 reveal the core steps (crawl, extract, check HTTP status) and the default limit of 20 checks, which is useful. However, it does not disclose the output format, how dead links are determined (e.g., what status codes are considered dead), or error-handling behavior. More transparency would be expected for a network analysis 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 in the format 'category: action details'. It is front-loaded with the tool's purpose and includes the most critical default behavior without unnecessary words. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a multi-step tool (crawl, extract, check) with no output schema, no annotations, and 0% parameter coverage. The description does not state what the tool returns (e.g., a list of dead links with status codes), how many results are returned, or what constitutes a dead link. For a task of this complexity, the description is incomplete and leaves the agent uncertain about the tool's behavior and result format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'limit' parameter indirectly through '默认最多检查 20 个' (default max 20), adding meaning beyond the schema's default value. However, it does not explicitly name the 'url' parameter or its expected format, though '抓取页面' implies it. The description adds some value but does not fully cover both 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's function: it detects dead links on a website by crawling a page, extracting links, and checking their HTTP status. This distinguishes it from sibling tools like net_url_status (which checks a single URL) or net_fetch (which fetches content). The verb '检测' (detect) and resource '网站死链' (website dead links) are specific.
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 use case (finding dead links on a page) but does not explicitly state when to prefer this tool over alternatives like net_url_status or net_fetch. It lacks clear 'when-not-to-use' guidance or mention of alternative tools. The context is clear enough for basic selection, but not robustly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry behavioral disclosure. It describes the core purpose (gzip check and size comparison) but does not mention that it likely makes an HTTP request, whether it is read-only, or how it handles servers without gzip. This leaves important behavioral aspects unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose, with 'Gzip' front-loaded. There is no fluff or redundancy; every word contributes to understanding.
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 one-parameter network check with no output schema and no annotations, the description covers the primary purpose but leaves out operational specifics such as return format, error handling, or network behavior. The description is adequate but not comprehensive.
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 one parameter, 'url', with no description (0% coverage). The tool description does not explicitly define the parameter or its format beyond implying the target is a server. This offers minimal additional meaning beyond the property name itself.
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 a specific action (check) and a resource (whether the server enables gzip and compression size comparison). It is distinct from sibling network tools like net_url_status or net_fetch, making it easy to identify when this tool should be used.
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 is implied by the name and description – it is for checking gzip compression on a server. However, no explicit guidance is given about when to prefer this over alternatives like net_url_status or net_fetch, nor are exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It mentions returning the 'final address', implying redirect following, which is useful context. However, it does not state whether the operation is read-only, error handling, timeouts, or what 'key response headers' means, leaving gaps in 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 Chinese sentence that immediately states purpose and return values with no redundant filler. It is 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 simplicity (one parameter, no output schema), the description covers the essential return values. It omits potential output format, error scenarios, and protocol restrictions, but for a basic status checker, it is reasonably complete and sufficient for an agent to select and invoke the 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?
Schema description coverage is 0%, so the description must compensate. The single parameter 'url' is self-explanatory from the tool name and description, but the description adds no extra semantic detail such as URL format, required scheme (http/https), or whether file URLs are supported. It meets the baseline by virtue of the parameter being the tool's core resource.
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: URL status detection, specifying return values (HTTP status code, key response headers, final address). The verb '检测' (detect) and resource 'URL' make it distinct from siblings like net_fetch or net_dead_link.
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 explicit conditions, exclusions, or comparisons with sibling tools like net_dead_link, net_fetch, or net_meta_analyze, leaving the agent to infer usage solely from the stated purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description relies entirely on its own text. It discloses irreversibility, algorithm options, and MD5's 16/32-bit output variation. However, it does not mention default settings (e.g., algorithm defaults to md5), the requirement for a key when using hmac-* algorithms, input encoding, or error behavior for invalid inputs.
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, two sentences, with key information front-loaded: the purpose, irreversibility, algorithm list, and MD5 bit option. Every sentence earns its place; no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the tool has 5 parameters. The description covers the primary use case and algorithm variants, but lacks important operational details such as the default algorithm (md5), the fact that HMAC algorithms require a key, output casing defaults, and input encoding assumptions. While the description is usable, it leaves gaps for an agent to discover at runtime.
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 60% (3 of 5 parameters have descriptions). The description complements the schema by listing algorithm choices and clarifying the bits parameter semantics ('MD5 支持 16/32 位输出'), but it does not clarify the text parameter (which has no schema description) or add meaningful detail about the key parameter beyond what the schema already states. It partially compensates but does not fully bridge the gap for undocumented 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 a specific verb (计算/calculation) and resource (哈希/hash), and explicitly notes irreversibility ('不可逆'), which distinguishes it from reversible crypto tools like crypto_symmetric. It also enumerates all supported algorithm variants, leaving no ambiguity about scope.
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 irreversibility note provides useful context, implying this is for one-way hashing rather than encryption, but there is no explicit guidance on when to prefer this tool over siblings like crypto_symmetric or the encode_* tools. 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?
No annotations are provided, so the description must fully disclose behavior. It mentions base range and large-number support but omits details like output format (case of letters for bases >10), handling of negative numbers, or whether non-integer inputs are accepted. This is a minimal disclosure for a tool with no safety annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a clarifying example. It is front-loaded with the verb and resource, and every word contributes information. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple conversion tool with no output schema and partial parameter descriptions, the description covers core usage. However, missing behavioral details (output casing, precision limits, error cases) leave some gaps, though the example mitigates 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?
Schema coverage is only 33% (only 'value' has a description), but the tool's description includes a worked example that conveys the role of all three parameters. It also reinforces the base range already present in the schema, adding meaning to from_base and to_base.
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 converts numbers between arbitrary bases (2-36) and supports large numbers, with a concrete example. This distinguishes it from encoding tools like encode_base64 or encode_url, which handle text/byte encodings.
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 description (convert between number bases), but there is no explicit 'when to use' or comparison with alternatives. The example provides practical guidance but no exclusionary 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?
With no annotations, the description carries the full burden. It adds useful context such as 'png（base64）或 svg' and 'output_path 可保存文件', indicating return format and file-saving side effect. However, it omits behavioral constraints like barcode type-specific text requirements (e.g., EAN-13 must be 13 digits) and does not fully describe the output when output_path is absent.
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 starts with the core purpose and efficiently packs in key options for type, format, and output_path. There is no waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but the description is incomplete for a tool without annotations or output schema. It misses important constraints (e.g., text format requirements for specific barcode types) and does not clarify the exact return value when output_path is not provided. Still, it covers the main functionality and key options, making it minimally viable.
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 only 20% (only text has a description). The description adds meaning for format (png is base64) and output_path (can save file), which is valuable. However, it merely repeats the enum options for type without adding deeper meaning, and does not mention height at all. It partially compensates for low schema coverage but not fully.
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 as '条形码生成' (barcode generation), which is a specific verb+resource. It also lists the supported barcode types and output formats, distinguishing it from sibling tools like misc_qrcode.
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 barcode generation but does not explicitly state when to use this tool over alternatives or provide any exclusions. It lacks guidance on when not to use it, though the clear purpose makes intended usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the core transformations, but does not mention the return format, edge-case behavior, or any side effects. For a deterministic text formatter, this is moderately transparent but leaves 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 a single, efficiently worded sentence that front-loads the core purpose and lists the key operations without wasted words. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple schema and no output schema, so the description is responsible for suggesting the return value and usage context. It lists main functions but does not explicitly state that it returns the formatted text or any limitations. Given the low complexity, the description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, with descriptions for indent and merge_lines, but none for text. The tool description indirectly explains the purpose of indent and merge_lines via the operations it lists, but it does not explicitly describe each parameter or clarify the text input beyond calling it an article. The description adds some meaning but does not fully compensate for the missing text parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '排版' (formatting) and resource '文章' (articles), explicitly listing the operations: first-line indent, paragraph merging, and cleaning blank lines/spaces. This clearly distinguishes it from sibling tools like text_filter or text_replace, which target different transformations.
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 automatically formatting Chinese articles, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. No alternative tools are named, so the guidance is only 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?
With no annotations provided, the description carries full responsibility for disclosing behavior. It mentions modes and parameters but omits critical details such as whether number ranges are inclusive, how uniqueness is enforced when count exceeds the range, or what the default password charset ('all') includes. These gaps leave significant behavioral ambiguity.
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 line that efficiently conveys the core functionality and mode-parameter mapping. Every part is informative, and the semicolon-separated structure is clean and front-loaded.
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, but without an output schema or annotations, the description should at least hint at the result format and edge-case behavior. It covers the main usage patterns but omits details like return type (e.g., single value vs. array) and constraints (e.g., min/max relationship). It is adequate for basic use but incomplete for a fully self-sufficient description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It adds value by grouping parameters by mode (e.g., min/max/count/unique for number; length/charset for password), but it does not explain the meaning of individual parameters like 'unique' or 'charset'. This is partial compensation, warranting a mid-range 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 explicitly states '随机数/密码生成' (random number/password generation), a specific verb+resource pairing. This clearly distinguishes the tool from siblings like uuid_generate (UUIDs) and crypto_hash (hashing), 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance by separating the two modes with 'type=number' and 'type=password' and listing which parameters apply to each. It does not explicitly compare against alternative tools, but the purpose is distinct enough that the guidance is practical and context-rich.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the core transformation (vertical output from top to bottom, column-based) but omits details such as column progression direction (right-to-left vs left-to-right), output format, and handling of whitespace/punctuation. This is adequate for a simple text transform but has clear 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?
A single, front-loaded sentence delivers the core function without superfluous words. The key term '文字竖排' appears first, and the rest provides necessary 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 simple with no output schema, so the description need not explain return values exhaustively. It covers purpose and key mechanics, but lacks explicit usage guidance, parameter defaults, and edge-case behavior. It is adequate for straightforward use but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must add parameter meaning. It refers to '文本' (text) and '指定列数' (specified column count), giving semantic roles to both parameters. However, it does not mention the default of 6 for cols or its range, though those are in the schema. It adds some value but does not fully compensate for missing parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: '将文本按指定列数从上到下竖排输出' (output text vertically from top to bottom by specified columns). It clearly identifies this as traditional Chinese vertical typesetting ('传统中文排版'), distinguishing it from siblings like text_flip or text_format.
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 parenthetical '传统中文排版' implies a use case, but there is no explicit statement of when to use this tool versus alternatives like text_flip or text_format. No exclusions or alternatives are named, leaving the usage context somewhat 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?
Annotations are absent, so the description carries the burden. It does disclose the bidirectional conversion capability via 'JSON↔XML' etc., but it does not mention error handling, input validation, or the exact return format. This is a moderate amount of behavioral context for a simple transformation 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, compact sentence with the action verb placed first and the list of targets following. It is entirely free of filler and every segment adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only 3 parameters, all fully described in the schema, and a straightforward output (converted text), the description provides sufficient context. It explains what formats are supported and hints at directionality, though it does not go into details about edge cases or error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant semantic value by explicitly mapping each 'target' enum value to a concrete format (XML, YAML, GET parameter string) and indicating bidirectionality, which the schema's simple '目标格式' label does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'JSON 与其他格式互转' (mutually convert JSON with other formats), and specifies the exact target formats (xml, yaml, get_params). This distinguishes it from sibling tools like json_process or text_format by naming concrete conversion 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 versus alternatives such as json_process or data_html_convert. The description only lists available targets, leaving the selection context entirely implicit.
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 transparency burden. It discloses the effects of sort (sorts results) and keep_first (when false, keeps last occurrence), which adds meaningful behavioral context. However, it does not state the output format or address edge cases like whitespace or empty lines, so it 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 exceptionally concise, consisting of two short clauses that immediately convey the main function and then the behavior of optional parameters. 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?
Given the simplicity of the tool, the description is complete enough: it states the core operation and the two configurable behaviors. The output (deduped text) is naturally implied, and the absence of an output schema means no format details are required. Minor gaps about edge cases exist but are not critical for such a straightforward text tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source of parameter meaning. It explains the semantics of sort and keep_first clearly, while text is self-evident as the line-based input. This provides significant value beyond the bare 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 performs text line deduplication (文本行去重) with a specific verb and resource, distinguishing it from sibling text tools like text_filter or text_replace. The purpose is unambiguous and directly tied to the tool 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. It does not mention use cases, prerequisites, or situations where a different tool would be appropriate. The only content is the operation and parameter behaviors, leaving usage entirely 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?
With no annotations, the description carries the full burden of behavioral disclosure. It defines the three modes and their effects, which is the core behavior. However, it omits edge-case behavior such as how line breaks are handled in 'full' mode (are they reversed in character order?), and whether 'line' mode preserves newline characters. These gaps are notable for a text transformation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose ('文本翻转/倒序') then uses semicolon-separated mode definitions. It is concise, well-structured, and contains no filler. Every word serves to clarify the tool's behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers the essential information: it defines the modes and their outputs. It does not explain return value formatting, but that is implied for a text transformation. Minor gaps like newline handling prevent a perfect score, but overall it is sufficiently complete for an AI 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters. The description compensates by explaining the meaning of each enum value for 'mode' (full, line, reverse_lines), which is the key parameter. The 'text' parameter is self-explanatory as the input string. This adds significant value beyond the schema's enum definition and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('翻转/倒序' = flip/reverse) and resource (text). It goes beyond the name by explaining three distinct modes (full, line, reverse_lines), which differentiates it from sibling text tools like text_format or text_replace. Each mode is explicitly defined, 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 choose this tool over alternatives. It explains how to use the 'mode' parameter but does not contrast with sibling tools or state use cases. For example, it does not say 'use this to reverse entire text' versus 'use text_filter for filtering'. Thus, usage context 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?
With no annotations, the description carries the behavioral burden. It discloses that image encode returns a dataURL, image decode writes to a file (with output_path required), and text mode processes strings. However, it fails to clarify how the required 'text' parameter is used in image mode, leaving ambiguity about the image source path or base64 input.
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—two compact sentences—yet conveys all key behaviors: modes, actions, and side effects. It is front-loaded with the core purpose and contains 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 tool's complexity (4 parameters, multiple modes, side effects) and lack of output schema/annotations, the description covers the main flow but omits details like the return value for decode, the ambiguity of 'text' in image mode, and the schema discrepancy where output_path is required by description but not marked required in the schema.
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 only 25% (output_path). The description adds meaning to 'mode' and 'action' enums and clarifies output_path's role, but it does not define the semantics of 'text' in image mode. This partially compensates for the low coverage but leaves a critical parameter underdocumented.
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 performs Base64 encoding/decoding, with explicit modes for text and image operations. It distinguishes itself from sibling encoding tools by specifying the Base64 algorithm and detailing mode-specific behaviors (text vs image, encode vs decode).
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 for when to use each mode: mode=text for strings, mode=image for local image conversion. It does not explicitly mention alternatives or when not to use the tool, but the mode breakdown effectively guides 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 must carry the full burden of behavioral disclosure. It only states the core function and options, but does not describe output format, error handling, limitations, or any side effects. For a generation tool, the absence of these details leaves significant ambiguity.
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 core purpose and key options without unnecessary verbosity. Every word earns its place, and it fits well within a tool description.
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 adequate for a moderate-complexity tool, covering the main inputs and outputs (entity class code). However, with no output schema and no annotations, it lacks details on the generated code's structure, possible limitations, or handling of edge cases. It is minimally sufficient but has clear 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 schema provides descriptions for most parameters (75% coverage), but the description explicitly clarifies the meaning of input_type (json/sql) and language (cs/java/go), which the schema's enum alone does not fully explain. This adds valuable context beyond the schema, especially for the undocumented input_type.
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: generating entity class code from JSON or SQL CREATE TABLE, and specifies the key options (input_type and language). This distinguishes it from sibling tools like json_convert or code_format, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (when you need entity classes from JSON/SQL) but does not explicitly mention when not to use it or alternatives. Given the unique functionality among siblings, the usage context is clear, but it lacks explicit 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 lists the core behaviors (format, compress, etc.) but omits critical details such as error handling for invalid JSON, return format for validate, or side effects on input. With no annotations provided, the description carries the full burden and only partially fulfills 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, front-loaded sentence that packs the purpose and action list without wasted words. It is highly concise while remaining informative.
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 multiple modes and no output schema, so the description should explain return values and error behavior. It covers the action options but leaves out what each action returns and how invalid input is handled, making it incomplete for a tool of this complexity.
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 covers all three parameters with descriptions, achieving 100% coverage. The tool description mainly restates the action enum values with Chinese labels, adding minimal extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool processes JSON with five explicit operations: format, compress, escape, unescape, and validate. This is a specific verb+resource combination that distinguishes it from sibling tools like json_entity or encode_escape.
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 by enumerating the available actions, implying when the tool should be used. However, it does not explicitly mention alternatives or when not to use it, so it falls short of full 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?
No annotations are provided, so the description carries the full behavioral disclosure burden. It discloses input format, target format, and the important size constraint (≤256px), but it does not describe output behavior (e.g., what happens if output_path is omitted) or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary purpose ('favicon.ico 生成'). Each sentence adds necessary information about the conversion process and input constraints, 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?
For a simple conversion tool, it covers the core transformation and input constraints, but it leaves ambiguity about the output side: output_path is optional in the schema, yet the description never clarifies whether the tool writes a file, returns base64, or uses a default path. This gap prevents a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters already documented in the schema. The description reiterates the image parameter's supported forms but adds no new semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates favicon.ico by wrapping a PNG into an ICO file, specifying the Vista+ PNG-ICO format. This distinguishes it from sibling image tools like misc_qrcode or misc_barcode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear context for when to use the tool: favicon.ico generation from a PNG. It also details accepted input forms (local path or base64), but it does not explicitly mention alternatives or exact exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It mentions the data source ('official interface') and the kind of information returned, but it does not state whether the operation is read-only, potential rate limits, or the response format. This leaves some behavioral ambiguity.
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, front-loaded sentence that immediately states the purpose and usage. There is no filler, and every word contributes to the tool's understandability.
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 low complexity (one parameter), lack of output schema, and no annotations, the description still manages to convey the core input and output expectations. It does not cover error handling or exact output structure, but for a simple query tool it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single 'domain' parameter, and the description only says 'input domain', which essentially restates the parameter name without adding constraints (e.g., format, IDN handling, subdomain usage). The description adds 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 explicitly states the tool's function: querying ICP filing information via the official MIIT interface, taking a domain as input and returning filing number, organizer, and other details. This clearly distinguishes it from sibling network tools like net_whois and net_url_status.
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: use this tool when you need ICP filing details for a domain. It doesn't explicitly mention alternatives or exclusions, but the niche purpose is well-defined and no competing sibling tool exists for this specific function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure. It specifies input formats and bidirectional conversion, but does not clarify output format specifics (e.g., whether RGB output is 'rgb(r,g,b)' or 'r,g,b'), case sensitivity, handling of invalid inputs, or alpha channel support. This is a partial disclosure but leaves important behavioral details ambiguous.
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 formats. Every word contributes essential information, 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?
For a low-complexity tool with 2 parameters and no output schema, the description is mostly complete. It covers the core conversion purpose and accepted input formats. However, it omits details like default 'from' behavior (if 'from' is omitted, defaults to hex) and precise output format, which would be helpful. Still, given the tool's simplicity, the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does illustrate the value format (HEX or RGB strings) and implies the 'from' parameter via the two directions. However, it doesn't explicitly document the 'from' parameter's default or behavior, nor does it clarify the expected exact syntax for 'value' (e.g., optional spaces). The description adds some meaning but not enough to fully compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts between HEX and RGB color formats, with specific format examples (#RRGGBB, rgb(r,g,b), r,g,b). It uses a specific verb (互转, mutual conversion) and a specific resource (color formats), distinguishing it from all sibling tools which deal with encoding, text, or network operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies clear usage: use this tool whenever you need to convert between HEX and RGB colors. It doesn't explicitly mention alternatives or when-not-to-use, but the context is unambiguous given the sibling list contains no other color-related tools, so a score of 4 is appropriate.
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 burden. It discloses that json_to_excel writes to xlsx and requires output_path, and excel_to_json reads xlsx/csv, but lacks details on file overwrite behavior, error handling, or output JSON structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. All information is structured clearly with bullet-like separation of modes, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and lack of output schema, the description adequately covers both directions and the required parameter. It does not detail output formatting or edge cases, but is sufficient for typical conversion tasks.
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 67%, so baseline is 3. The description adds the clarification that 'data' is a JSON array for json_to_excel and a file path for excel_to_json, slightly enhancing the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as 'Excel/CSV ↔ JSON 转换' with specific verbs and resources. It distinguishes itself from sibling text/json conversion tools by explicitly targeting Excel/CSV files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two sub-modes (json_to_excel and excel_to_json) and specifies when output_path is required. It does not explicitly mention alternatives or exclusions, but the directional guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the exact encoding style (encodeURIComponent) and the character transformation behavior (Chinese and special characters to %XX), which goes beyond the raw schema. Minor edge cases are not covered, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and uses a parenthetical to add the encoding style. Every word earns its place; there is no redundancy or irrelevant 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?
For a simple two-parameter tool, the description provides the essential behavioral context and the schema supplies the parameter enum/default. However, it lacks explicit guidance on how to use the action parameter and does not clarify alternatives, leaving the description adequate but not fully complete.
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 2 parameters (text, action) with 0% description coverage, and the description does not mention either parameter or explain how to select decode via the action parameter. It only describes the overall operation, leaving parameter semantics almost entirely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool does URL encode/decode, using '编码/解码' and specifies 'encodeURIComponent 风格' to distinguish from sibling encoding tools. It names the resource (URL) and the transformation behavior (Chinese and special chars to %XX), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this is for URL encoding/decoding in encodeURIComponent style, implying when to use it among the many encode_* siblings. It does not explicitly name alternatives or say when not to use it, but the context is specific and sufficient 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that the tool fetches a page and extracts specific meta tags, which is the core behavior. However, it does not mention potential failure modes (e.g., non-HTML pages), output format, or whether any side effects occur, leaving some gaps in 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 starts with the core concept ('网页 Meta 标签分析') and then provides actionable details. It is concise, with no redundant words, and every part contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description gives sufficient context: it names the resource type, the extraction targets, and the outcome (length suggestions). It does not elaborate on edge cases or output format, but this is not critical given the tool's simplicity. A higher score would require more explicit 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 only one parameter (url) with no description, and schema description coverage is 0%. The description compensates by clearly implying that the URL is the web page to be fetched and analyzed. Although it does not explicitly label the parameter or provide format constraints, the meaning is unambiguous for a single-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 explicitly states that the tool performs web page meta tag analysis, specifically fetching the page to extract title, keywords, and description and provide length suggestions. This is a specific verb-resource combination with clear scope, and it distinguishes itself from sibling tools like net_fetch or net_keyword_density by focusing on meta tags.
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 need to analyze a web page's meta tags and get length recommendations. However, it does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions or prerequisites. Usage is inferred from the purpose but not clearly articulated.
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 for behavioral disclosure. It adds a useful detail about Chinese punctuation being included in the conversion ('含中文标点：。、《》等'), but it does not disclose other behaviors such as reversibility, handling of unsupported characters, or exact character set scope, leaving some 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 a single, compact sentence that front-loads the primary purpose and then quickly details the two actions. Every word contributes value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple conversion tool with no output schema or annotations, the description provides the essential information: the purpose, the two modes, and the scope of punctuation handling. It does not describe the return value, but that is generally implied for such a tool. The description is complete enough for the tool's simplicity, though it could mention that the converted text is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It fully explains the 'action' enum values ('to_full=半角转全角；to_half=全角转半角') and the 'text' parameter is self-evident as the input string. This adequately compensates for the bare schema, though the 'text' parameter could benefit from additional constraints like length or encoding.
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 as '全角/半角互转' (full-width/half-width conversion), which is a specific verb+resource. It also distinguishes itself from sibling tools by focusing on this particular transformation, and the action explanations further clarify the two conversion directions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining the two actions (to_full and to_half), letting the user infer when to use each. However, it does not explicitly provide usage scenarios or mention alternatives, so the guidance 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?
With no annotations, the description carries the full burden and it does explain the main output behaviors (pinyin, tone, initial). However, it does not disclose edge-case behavior (e.g., non-Chinese characters), the return format, or how the separator is applied beyond the schema description.
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 and front-loaded with the primary action, followed by a compact explanation of output modes. Every phrase carries meaning and there is no 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 transliteration tool, the combination of description and input schema covers the essential behavior: the input text, the three output modes, and the separator. It could be more explicit about return formatting or edge cases, but the tool's complexity is low enough that this is not a critical 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?
Schema description coverage is only 33%, but the description compensates by explaining the meaning of each output enum value (pinyin/tone/initial). The text parameter is self-evident and the separator already has a schema description, so the description adds sufficient value for the key 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 opens with a specific verb and resource ('汉字转拼音' – convert Chinese characters to pinyin), which clearly identifies the tool's function. The output modes further disambiguate it from sibling text-processing tools, making the 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?
The description implies the tool is for converting Chinese characters to pinyin but gives no explicit guidance on when to prefer it over sibling text tools or when not to use it. No alternatives or exclusions are mentioned; the usage context is inferred from the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior on its own. It does so by listing the exact statistics returned, which is the core behavior. It does not mention edge cases or side effects, but for a counting tool, this list is sufficient and adds context beyond the basic 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 sentence that efficiently lists the metrics, with no filler. It is front-loaded with '字数统计' and immediately enumerates the results, earning its place with every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one simple parameter and no output schema. The description covers what the tool returns, which is the main requirement. It is concise and sufficient for an agent to select and invoke this tool, though it does not mention any additional behavior such as how newlines are counted, which is not critical for a basic text statistics 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 schema provides only the parameter name 'text' with a type string and no description. The tool description does not explicitly explain the parameter, but the phrase '字数统计' makes it clear that the input text is the content to be counted. Since the schema coverage is 0%, the description compensates implicitly but not explicitly.
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 performs text statistics and enumerates the specific metrics (total characters, Chinese characters, letters, digits, spaces, punctuation, lines, word count). This makes the tool's purpose obvious and distinguishes it from sibling text-processing tools like text_filter or text_replace.
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 provide usage guidance, such as when to use this tool versus other text tools. The only usage signal is the implicit one from the tool's function, so it is adequate but lacks explicit 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?
Since no annotations are provided, the description must carry the behavioral disclosure burden. It states conversion and lists all units, but does not disclose return format, error handling, or that it is a pure side-effect-free operation beyond the verb '换算'.
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 opens with a one-line purpose and then uses a dense, well-organized category/unit list. It is lengthy due to the exhaustive unit enumeration, but every item is necessary and nothing is wasted.
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 high complexity of units and no output schema, the description covers all supported categories and unit symbols plus temperature unit details. It does not explicitly explain how value/from/to relate or what the result looks like, but the schema fills the parameter relationship and return is implied for a converter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines category with an enum and describes from/to as generic strings. The description adds enormous value by listing every valid unit string for each category and explaining temperature unit abbreviations, which is essential for correct invocation.
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 performs unit conversion (单位换算) and then exhaustively lists every supported category and unit. This specific verb+resource scope distinguishes it from sibling tools like color_convert or encode_*.
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?
There is no explicit when-to-use or when-not-to-use guidance, nor any mention of alternatives. However, the tool's domain is so self-contained and the category list so complete that the intended use is implied: use when converting among the listed units.
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 burden. It discloses the regex-based and lightweight nature, plus the limitation on complex axes, which is useful. However, it does not mention error behavior, return format, or whether the tool modifies input.
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 core purpose, and every clause adds information about supported patterns or limitations. 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 simple 3-parameter tool with no annotations or output schema, the description covers the main extraction functionality and constraints. However, it omits the behavior of the 'count' action and return value format, which are important for a complete invocation picture.
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 only 33%, with only the xpath parameter having examples. The description adds supported XPath forms for xpath, but says nothing about html or the action parameter (extract vs count), leaving those semantics incomplete.
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 performs XPath extraction and enumerates supported patterns like //tag, tag, tag[@attr="value"], /text(). This specific verb+resource distinguishes it from sibling text/regex tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It notes this is a regex-based lightweight implementation and explicitly says it does not support complex axis expressions, giving a clear boundary for when to use it. It does not name specific alternatives but the limitation serves as implicit 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?
With no annotations, the description carries the burden of behavioral disclosure. It usefully reveals the mapping-table limitation, but does not state what happens to unmapped characters (e.g., left unchanged or error), nor the return format. This leaves some behavioral ambiguity.
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 compact sentence with a semicolon separation conveys tool name, both modes, and a limitation; every word is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter conversion tool, it covers purpose, modes, and the key limitation. However, it omits edge-case behavior for unmapped characters and output details, which are relevant for a text transformation tool without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions (0% coverage), but the description compensates by explaining the action enum values with their input/output semantics. The text parameter's meaning is inferable from context, though not explicitly described; the default is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '火星文转换' clearly identifies the tool as Martian text conversion and enumerates the two direction-specific actions (to_martian and to_chinese) with the mapping-table limitation, making its purpose unambiguous and distinct from sibling text tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states when to use each action: to_martian for Chinese-to-Martian and to_chinese for Martian-to-Chinese, and adds the constraint '仅支持映射表内字符' as an exclusion. It does not explicitly compare with sibling tools, so a high but not perfect score.
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. It discloses a key behavior (Chinese text is converted to pinyin first), but omits output format, spacing conventions, case sensitivity, or error handling, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary function. No wasted words; every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description adequately covers purpose, supported input types, and special Chinese handling. It lacks output format details, but the core functionality is well described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning to the 'text' parameter by specifying supported content (English, numbers, punctuation, Chinese) and implies the 'action' parameter via '加密/解密'. This is useful beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs Morse code encryption/decryption, supporting English, numbers, common punctuation, and Chinese via pinyin. This verb+resource combination is specific and distinguishes it from all 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (for Morse code conversion) without explicit alternatives. It provides clear context about supported character sets and Chinese handling, but does not state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose key derivation (SHA-256 from password, or direct key_hex) and output formats (base64 with iv/tag for GCM, iv only for CBC). However, it omits important behavioral details like GCM authentication, CBC's lack of authentication, IV reuse risks, and failure modes on decryption.
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, with three sentences that front-load the purpose and then efficiently cover algorithm choices, key derivation, and output format. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a cryptographic tool with no output schema, the description provides essential invocation details: algorithm options, key input methods, and return format. It is complete enough for basic use, but lacks safety warnings and detailed error behavior that would fully round out the 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 description adds significant meaning beyond the schema by explaining the algorithm-specific output formats and the priority of key_hex over password. This helps agents understand the relationship between parameters, though action and iv_hex are not elaborated.
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 '对称加解密' (symmetric encryption/decryption) and specifies AES via node:crypto, making the tool's purpose unambiguous. It also lists exact algorithm options and output formats, distinguishing it from sibling tools like crypto_hash and encode_*.
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: this tool is for symmetric AES encryption/decryption. However, it does not explicitly mention when not to use it or name alternatives such as crypto_hash for hashing or encode_base64 for simple encoding, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It explains the two modes and decode's support for decimal/0x-prefixed hex, but omits edge cases like handling of non-ASCII characters, invalid input, or exact output formatting for encode (e.g., whether hex uses 0x prefix).
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, contained in one sentence with a clear front-loaded purpose. Every part adds essential value: the core operation, the two modes, and the supported numeric bases for decode.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description covers the main operation, actions, and decode input formats. It lacks explicit details on the exact encoded output representation and error behavior, but given the tool's simplicity, it 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?
Schema description coverage is only 33% (format described), but the tool description adds meaning to 'action' (encode vs decode) and 'format' (output format), and clarifies decode's accepted inputs. It compensates for schema gaps, though it slightly ambiguously suggests encode outputs both decimal and hex rather than being selectable via format.
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: ASCII encoding/decoding, with explicit definitions of encode (characters to decimal and hex codes) and decode (code values to characters). It distinguishes itself from sibling encoding tools by being ASCII-specific and specifying supported bases.
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 for when to use the encode vs decode actions based on input and desired output. However, it does not explicitly compare this tool with sibling alternatives like encode_base64 or encode_utf8, lacking exclusionary 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?
Without annotations, the description carries the burden of disclosing behavior. It does explain the core transformation mechanism (%XX hex bytes) and directionality, but it omits edge cases such as handling of non-Chinese characters, hex case sensitivity, malformed input, or error behavior. This leaves some behavioral 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 a single efficient sentence that front-loads the overall purpose and then details both operations. Every word earns its place 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?
For a simple two-parameter tool with no output schema, the description covers the essential usage: what the tool does, what each action does, and the output format for encoding. It does not explicitly state that decode returns Chinese text or address error conditions, but the core functionality is sufficiently documented.
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 coverage, the description compensates by explaining the meaning of the action parameter (encode vs decode) and implicitly defining the text parameter as the Chinese text or byte string to convert. The default action is not mentioned but is present in the schema. This adds meaningful semantics beyond the raw 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's function: UTF-8 encoding and bidirectional Chinese-to-byte-string conversion, with encode producing %XX hexadecimal bytes and decode restoring Chinese. This specifically distinguishes it from sibling tools like encode_url and encode_unicode.
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 for both actions (encode/decode) and their respective inputs and outputs, implying when each should be used. It does not explicitly exclude alternatives or mention when not to use this tool, but the functionality is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well by disclosing the native implementation: it connects to whois.iana.org and recursively queries authoritative servers without relying on third-party APIs. It does not cover potential timeouts or error behavior, but the network-related behavior is adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the purpose and adds useful implementation detail in parentheses, 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 simple one-parameter network query tool, the description covers the essential purpose and implementation method. It lacks an explicit description of the return format, but this is not critical for tool invocation given the clear WHOIS semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'domain' is already fully described in the schema with an example, and the description adds no additional parameter semantics beyond implying the domain is the target of the query. Since schema coverage is 100%, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool performs WHOIS domain information queries, with a specific verb (查询) and resource (域名). It also distinguishes itself by mentioning the native implementation connecting to whois.iana.org, which sets it apart from sibling network tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for a WHOIS lookup scenario, making it obvious when to invoke this tool. However, it does not explicitly mention alternatives or exclusions, such as using net_icp for Chinese ICP filings, so it misses explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It explains what each action returns (test: match status, extract: matches and capture groups, replace: replaced text), which goes beyond the schema. It does not cover edge cases like invalid regex, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the tool's purpose and action-specific behavior without redundancy. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides a sufficient overview of the tool's functionality, including return values for each action. It does not explain every parameter in detail, but the core usage is well-covered for an agent to invoke correctly.
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 only 40%, and the description compensates partially by explaining the action parameter's values and the replacement parameter's $1 syntax. However, pattern, text, and flags lack semantic explanation beyond the schema, leaving some 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 clearly states the tool performs regex test/extract/replace operations, with specific action values and their return behavior. It distinguishes from siblings like regex_generate (generation vs. testing/extraction) and text_replace (plain vs. regex replacement).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by listing the three action modes, making clear when to use the tool for regex matching/extraction/replacement. It does not mention alternatives or exclusions, so it falls short of a 5, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It does so by explaining each action's effect (upper all caps, lower all lower, title first-letter caps, camel camelCase, snake snake_case), giving clear behavioral mapping. However, it omits edge-case handling such as non-English characters, multi-word segmentation, or default action 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 line that front-loads the tool's purpose and compactly enumerates all modes 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 tool with two parameters and no output schema, the description adequately covers the essential operation and modes. It could additionally mention the output type or segmentation rules for camel/snake cases, but the given information is sufficient for basic 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?
The input schema has no property descriptions (0% coverage), so the description compensates by defining each enum value of `action` in plain language (全大写, 全小写, 首字母大写, 驼峰, 下划线). The `text` parameter is self-evident, making the description sufficiently informative for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '英文大小写转换' (English case conversion), identifying the specific verb and resource, and lists all supported modes (upper, lower, title, camel, snake), which distinguishes it from sibling text tools like text_format or text_replace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by enumerating the conversion modes but does not explicitly state when to use this tool versus alternatives such as text_format or text_filter. No exclusions or alternative references are provided, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that different languages are handled by different backends (prettier, sql-formatter, basic indentation), which is valuable behavioral info beyond the schema. However, it doesn't clarify what the compress action does or the output format, given there are no annotations to cover this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, then a concise list of languages and backend mapping. Zero 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, but without an output schema or annotations, the description should mention what the tool returns. It doesn't specify the return value or behavior of compress vs format, leaving some ambiguity for a new 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 schema describes all parameters, and the description adds meaning by explaining the effect of the language parameter and formatter selection. It helps the agent understand how to choose languages and the compression action.
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 formats/compresses code ('代码格式化/压缩') and enumerates supported languages. It distinguishes itself by specifying language-specific formatter backends (prettier, sql-formatter, basic indentation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context by listing supported languages and explaining which formatter is used for each. However, it doesn't explicitly mention when not to use 'code_format' vs sibling tools like 'text_format' or 'code_obfuscate'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the irreversibility of obfuscation, the limited capability of beautify, and explicitly prohibits use for hiding malicious logic. This provides essential behavioral context beyond the schema, though it does not mention output format or error handling.
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 core purpose, then provides essential caveats and a prohibition. Every clause adds value, with no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema and no annotations, the description covers the main operations, their limitations, and a critical safety restriction. It is complete enough for the agent to understand purpose and constraints, though it could explicitly mention the output type (transformed code) and the fact that obfuscation is deterministic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%, only 'preset' has a description). The description compensates by explaining the 'action' parameter semantics (obfuscate vs. beautify) and their different behaviors, which is absent from the schema. 'code' is self-evident, and 'preset' already has a schema description, so the overall parameter understanding is adequate.
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 performs JS code obfuscation and beautification, with specific details: obfuscation is one-way and uses javascript-obfuscator, while beautify only restores formatting. This distinguishes it from sibling tools like code_format and encode_* by naming the exact operations and their effects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each mode: 'obfuscate' for obfuscation and 'beautify' for formatting restoration, noting that beautify does not recover obfuscated semantics. It also adds a usage restriction ('禁止用于隐藏恶意逻辑'). However, it does not explicitly compare to alternative tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior, and it does so well: it specifies that encode turns characters into \uXXXX form and decode restores them. It doesn't discuss edge cases or error handling, but for a straightforward conversion tool, this is sufficient.
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 a semicolon separating the encode and decode modes. It is front-loaded with the main purpose and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters, no output schema, no annotations), the description is largely complete: it covers purpose, modes, and direction of conversion. Missing details about output formatting for multi-character strings or invalid input are minor given the tool'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?
Schema description coverage is 0%, so the description compensates by explaining the action parameter's two enum values (encode/decode) with concrete behavior. The text parameter is left implicit, but its purpose is obvious from the context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool converts between Unicode escapes (\uXXXX) and characters, encoding and decoding. This is a specific verb and resource, and it distinguishes itself from sibling encoding tools by naming the exact Unicode escape format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains the two action modes (encode and decode) and what each does, providing clear context for usage. It does not mention alternatives or when not to use the tool, but for a simple conversion utility, the usage context is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains the sequence: connection with handshake display, ordered message sending, protocol-level ping with RTT, response collection, wait_for matching, and idle auto-close. It also mentions support for text/JSON messages. Minor gaps like return format or error behavior are not covered, but the core behavior is well 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, well-structured sentence that front-loads the main purpose ('WebSocket 完整会话测试') and uses arrows to show step order. Every phrase adds information, with no wasted words or redundancy. It is appropriately compact for the tool's moderate complexity.
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 moderate complexity, the description covers the entire workflow, satisfies parameter context, and does not need to explain return values since no output schema exists but the behavior of collecting responses is described. It is sufficiently complete for an AI agent to select and invoke the tool correctly, though it could be more explicit about the exact output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, setting a baseline of 3. The description adds value by weaving parameter behavior into the workflow narrative: '按序发送消息' clarifies messages, '协议级 ping' relates to ping, '空闲自动关闭' explains timeout, and 'wait_for' is explicitly mentioned. This gives the agent a better functional understanding than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a 'WebSocket complete session test' with a specific verb ('test') and resource ('WebSocket'), and outlines a clear sequence of actions (connect, send messages, ping, collect responses, wait_for, close). It is fully differentiated from all sibling tools, none of which handle WebSocket testing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage context by enumerating the full session workflow, making it clear when this tool is appropriate (testing a WebSocket endpoint end-to-end). It doesn't explicitly name alternatives or exclusions, but the sibling list contains no similar tools, so the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of disclosing behavior. It clearly explains the conversion directions, which is the core behavior. It doesn't mention edge cases like mixed text or unchanged characters, but for a simple text converter, the behavior is adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that front-load the purpose and explain the key action parameter. Every word earns its place; there is no redundancy 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 simple tool with two parameters and no output schema, the description covers the essential behavior and parameter semantics. It is complete for an agent to select and invoke the tool correctly without needing further 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 description adds significant meaning beyond the schema by explaining what each action enum value does (to_traditional/to_simplified). It implicitly indicates 'text' is the input to convert. Given 0% schema description coverage, this compensation is valuable, though it could be more explicit about the text parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts between Simplified and Traditional Chinese (简体/繁体互转). It specifies the exact actions and their directions, distinguishing it from sibling tools which focus on other text transformations.
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 on when to use each action (to_traditional for Simplified-to-Traditional, to_simplified for the reverse), but does not explicitly mention alternatives or when not to use the tool. It gives sufficient guidance for selecting the correct action.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/regaing/devbelt-mcp'

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