GonMCPtool

by GonTwVn

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tool set has clear groupings (code editing, file operations, localization, npm, tasks), but within groups there is significant overlap. For example, codeLineInsert and insert_to_file both insert content into files, while edit_file and codeLineDelete/delete_from_file have overlapping deletion capabilities. Descriptions help clarify some differences, but an agent could easily misselect between similar tools.
Naming Consistency2/5
Naming conventions are inconsistent across the set. Some tools use camelCase (codeFileRead, npmBuild), others use snake_case (delete_from_file, insert_to_file), and some use mixed or no clear pattern (add, search_code). The task tools follow a consistent taskVerb pattern, but overall the server lacks a unified naming style.
Tool Count2/5
With 33 tools, this server feels overloaded for its apparent scope of code/file management, localization, npm, and task tracking. Many tools could be consolidated (e.g., multiple file insertion/deletion tools), leading to redundancy. A more focused set of 15-20 tools would be more appropriate and less confusing for agents.
Completeness4/5
For the domains covered, the tool set is largely complete. Code/file operations have read/write/edit capabilities, localization supports CRUD and export, npm covers install/build, and tasks offer full lifecycle management. Minor gaps exist, such as no tool for moving or copying files, but agents can work around these with existing tools.
Average 2.8/5 across 33 of 33 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but provides minimal information. It doesn't indicate whether this is a read-only operation, what permissions are required, whether it searches across multiple files or languages by default, what format the results are in, or any performance characteristics. The single sentence offers almost no behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese sentence that directly states the tool's function. There's no wasted language or unnecessary elaboration. However, this conciseness comes at the cost of completeness, as it omits important contextual information that would help an agent use the tool effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a tool with 4 parameters (2 required), no annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. It doesn't explain what the tool returns, how results are structured, what happens when no matches are found, or provide any context about the localization system being searched. For a search tool with multiple parameters and no structured documentation, this single-sentence description leaves critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 4 parameters, the description provides no information about any parameters. It mentions '特定文字' (specific text) which vaguely relates to 'searchText', but doesn't explain the filePath, language, or limit parameters at all. The description fails to compensate for the complete lack of schema documentation, leaving most parameters semantically undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '搜尋包含特定文字的翻譯項目' (Search for translation items containing specific text) clearly states the tool's purpose as searching translation items. However, it doesn't specify what type of translation items (localization files, database entries, etc.) or distinguish it from sibling tools like 'localizationFindLongValues' or 'localizationFindMissing' that also search localization data. The purpose is understandable but lacks specificity about the resource being searched.
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. With multiple sibling localization tools (localizationFindLongValues, localizationFindMissing, localizationGetByKey, search_code), there's no indication of when this text-based search is preferred over other search methods or what context triggers its use. The description is purely functional without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions '搜索' (search) which implies a read operation, but doesn't disclose behavioral traits such as whether it's paginated, what permissions are needed, or what the return format looks like. The description is minimal and lacks critical operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese, making it appropriately concise. However, it's under-specified rather than truly well-structured, as it lacks necessary details for a tool with complex parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (1 parameter with nested object, 0% schema coverage, no output schema, and no annotations), the description is incomplete. It doesn't explain the search behavior, result format, or error handling, leaving significant gaps for an AI agent to understand how to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions '條件' (conditions) which hints at the 'filter' parameter, but doesn't explain the semantics of nested properties like 'status', 'tags', or 'dueDateFrom'. 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '根據條件搜索任務' (Search tasks based on conditions) states the basic purpose but is vague. It doesn't specify what kind of tasks or what system it operates on, and doesn't distinguish from sibling tools like 'taskGetAll' or 'taskGetById'. It's better than a tautology but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'taskGetAll' (which might retrieve all tasks without filtering) or 'taskGetById' (for specific tasks). The description implies filtering but doesn't clarify context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'create, edit, and write' functions but doesn't clarify permissions needed, whether files are overwritten or appended, error handling, or output format. For a mutation tool with 5 parameters and no annotations, this is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that front-loads the core functionality. It avoids unnecessary words, though it could be more specific. Every word contributes to stating the purpose, earning its place without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations, no output schema, and 0% schema coverage), the description is incomplete. It doesn't explain parameters, behavioral traits, or usage context, making it inadequate for an agent to reliably invoke this file-writing tool among many siblings.
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 by explaining parameters. It adds no information about the 5 parameters (filePath, content, mode, createDirs, prettify), their meanings, or how they interact. This leaves critical semantics undocumented, failing to address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides '建立、編輯與寫入功能' (create, edit, and write functions) for files, which gives a general purpose. However, it doesn't specify what types of files or distinguish it from sibling tools like 'edit_file', 'insert_to_file', or 'delete_from_file' that also modify files. The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With multiple file-modification siblings (e.g., 'edit_file', 'insert_to_file', 'delete_from_file'), the description offers no context on appropriate use cases, prerequisites, or exclusions, leaving the agent to guess based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action ('delete') without any information about permissions required, whether deletion is permanent or reversible, side effects (e.g., if related data like task steps are also deleted), error handling, or response format. This is inadequate for a destructive operation with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that directly states the tool's purpose. There is no wasted verbiage or unnecessary elaboration, making it front-loaded and efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature (deletion), lack of annotations, no output schema, and incomplete parameter documentation (0% schema coverage with no compensation in the description), the description is severely inadequate. It doesn't address critical aspects like safety, permissions, or what happens post-deletion, leaving the agent with insufficient context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning the single parameter 'id' is undocumented in the schema. The description adds no information about this parameter beyond implying it's for a 'specified ID'—it doesn't explain the ID format, source, or validation rules. With low schema coverage, the description fails to compensate for the documentation gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('刪除' meaning 'delete') and the resource ('任務' meaning 'task'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from other task-related siblings like 'taskStepDelete' or 'localizationDelete', which would require mentioning it's for deleting entire tasks rather than task steps or localization entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid task ID), exclusions, or comparisons to sibling tools like 'taskStepDelete' for partial deletions or 'taskUpdate' for modifications instead of removal.
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. The description only states it's a 'simple addition calculation tool,' which implies a read-only mathematical operation without side effects. However, it doesn't specify whether it handles integer/decimal numbers, error conditions (e.g., overflow), performance characteristics, or output format. For a tool with no annotation coverage, this leaves significant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase ('簡單的加法計算工具'), which is appropriately concise and front-loaded with the core function. There's no wasted text, and it efficiently communicates the basic purpose without unnecessary elaboration. However, it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no nested objects, no output schema) and lack of annotations, the description is incomplete. It doesn't explain the return value (e.g., sum as a number), error handling, or how it fits with the sibling tools (e.g., whether it's for mathematical operations within code contexts). For a basic tool, more context about behavior and integration would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters (a and b) with 0% description coverage, so the schema provides no semantic information. The description doesn't mention parameters at all, failing to compensate for the schema gap. However, since there are only 2 parameters and the tool's purpose is clearly addition, the parameters can be inferred as the two numbers to add. This provides minimal but adequate semantic context, aligning with the baseline for low parameter count.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '簡單的加法計算工具' (simple addition calculation tool) clearly states the tool's function as performing addition, which is a specific verb (addition) on unspecified resources (numbers). However, it doesn't distinguish this mathematical operation from the many file/code/task management sibling tools, leaving the scope ambiguous. The purpose is understandable but lacks precision about what kind of addition this is (mathematical vs. other types).
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. With sibling tools focused on code editing, file operations, localization, npm tasks, and task management, there's no indication whether this tool is for mathematical calculations in a specific context (e.g., within code files) or general arithmetic. No prerequisites, exclusions, or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. '新增' (add) implies a write operation, but it doesn't disclose whether this creates new files, appends to existing ones, requires specific file formats, or has side effects. No information about permissions, error handling, or response format is included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a single sentence that directly states the tool's action. No wasted words or redundant information. The structure is front-loaded with the core purpose, though it lacks detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters (including a nested object), 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the tool's behavior, parameter meanings, or expected outcomes, leaving significant gaps for an AI agent to understand its use.
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 but adds no parameter information. It doesn't explain what 'filePath' refers to (e.g., translation file location) or what 'entry' contains (translation key and values). The two parameters remain undocumented beyond their schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '新增一個完整的翻譯項目' (Add a complete translation project) states a general purpose but lacks specificity. It mentions adding translation items but doesn't clarify what constitutes a 'complete translation project' or how it differs from sibling tools like localizationUpdate or localizationDelete. The verb+resource is present but vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like localizationUpdate or localizationDelete. The description doesn't mention prerequisites, constraints, or typical scenarios for adding translation entries versus updating existing ones. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Update' implies a mutation operation, but the description doesn't specify permissions required, whether changes are reversible, rate limits, or what the response looks like (e.g., success/failure indicators). For a mutation tool with zero annotation coverage, this is a significant gap 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 extremely concise—a single phrase in Chinese—and front-loaded with the core action. There's no wasted text, making it efficient to parse, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with 3 parameters, nested objects, and no annotations or output schema), the description is incomplete. It doesn't explain behavioral aspects, parameter meanings, or usage context, which are critical for an agent to invoke it correctly. The conciseness comes at the cost of necessary detail for this type of tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. With 0% schema description coverage and 3 parameters (including a nested 'updates' object with 4 properties), the schema alone documents structure but not meaning (e.g., what 'taskId' and 'stepId' refer to, or the purpose of fields like 'estimatedTime'). The description doesn't compensate for this lack, leaving parameters largely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '更新任務的特定步驟' (Update specific step of a task) clearly states the verb ('update') and resource ('specific step of a task'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'taskUpdate' or 'taskStepAdd', which also modify task-related data, leaving some ambiguity about its specific role.
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 doesn't mention prerequisites (e.g., needing an existing task and step), exclusions, or comparisons to siblings like 'taskUpdate' (which might update the task itself) or 'taskStepAdd' (which adds steps). This lack of context makes it hard for an agent to choose correctly.
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 burden for behavioral disclosure. It states it's an update operation, implying mutation, but doesn't cover critical aspects like required permissions, whether changes are reversible, error handling (e.g., invalid ID), or response format. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with 2 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It lacks details on parameter usage, behavioral traits, error conditions, and output expectations, making it inadequate for safe and effective use by an AI agent.
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 mentions 'task information' but doesn't specify what fields can be updated (e.g., title, status). The two parameters (id and updates) are undocumented in both schema and description, leaving their purpose unclear. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '更新現有任務信息' (Update existing task information) clearly states the verb ('update') and resource ('existing task information'), but it's vague about what specific aspects can be updated. It doesn't distinguish from sibling tools like taskStepUpdate or taskSetAllSteps, which also modify task-related data.
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 doesn't mention prerequisites (e.g., needing a valid task ID), exclusions, or comparisons to sibling tools like taskCreate (for new tasks) or taskStepUpdate (for modifying steps). The description alone offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool reads files and supports text/JSON formats, but doesn't mention error handling (e.g., what happens if the file doesn't exist or isn't in the expected format), performance characteristics, or security implications. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that efficiently conveys the core functionality. It's front-loaded with the main purpose ('讀取檔案內容') and adds essential detail about supported formats. There's no wasted verbiage, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is incomplete. It doesn't address key aspects like return values (e.g., what structure the JSON mode returns), error conditions, or how it differs from similar sibling tools. For a file-reading tool with multiple parameters and no structured documentation elsewhere, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the parameters are documented in the schema. The description mentions support for text and JSON formats, which loosely relates to the 'mode' parameter with its enum values, but doesn't explain the 'filePath' parameter (e.g., format, relative vs. absolute paths) or 'encoding' parameter (e.g., default, supported encodings). It adds minimal value beyond what the schema's enum implies.
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 as '讀取檔案內容' (read file content) with support for text and JSON formats. It specifies the verb ('讀取') and resource ('檔案內容'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'codeFileRead' or 'search_code', which might have overlapping functionality.
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. With sibling tools like 'codeFileRead' (which might be specialized for code files) and 'search_code' (which might search within files), there's no indication of when this general file reader is appropriate. It mentions supported formats but doesn't specify use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool finds and marks file paths, implying a read-only operation, but doesn't mention whether it's recursive, what 'allowed directories' means, performance characteristics, error handling, or output format. For a tool with 2 parameters and no annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence in Chinese that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded with the core purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'allowed directories' are, how patterns work, what the output looks like, or any behavioral details like recursion depth or error conditions. For a file search tool with undocumented parameters, more context is needed.
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 for undocumented parameters. It mentions '檔名模式' (filename pattern) which maps to 'filePattern', and implies directory filtering but doesn't explain 'excludeDirs' or provide examples of patterns. The description adds minimal semantic context beyond the bare parameter names, failing to fully compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '在允許的目錄中找尋所有符合檔名模式的檔案並標示其檔案路徑' translates to 'find all files matching a filename pattern in allowed directories and mark their file paths'. This specifies the verb (find), resource (files), and scope (allowed directories). However, it doesn't explicitly differentiate from sibling tools like 'search_code' or 'fileRead', which might have overlapping functionality.
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 mentions 'allowed directories' but doesn't specify what these are or how they differ from other file-related tools in the sibling list. There's no mention of prerequisites, limitations, or comparison to tools like 'search_code' or 'fileRead'.
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 states it's a deletion operation, implying it's destructive, but doesn't disclose critical behavioral traits like whether the deletion is permanent, requires specific permissions, affects other data, or has side effects. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks information on behavioral risks, parameter meanings, expected outcomes, or error handling, which are essential for safe and effective use.
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, but it only mentions '指定Key' (specified key) implicitly, without explaining the 'filePath' parameter or providing any details on parameter formats, constraints, or examples. This leaves both parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('刪除' meaning 'delete') and the resource ('指定Key的翻譯項目' meaning 'translation item for specified key'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'localizationDelete' vs 'delete_from_file' or 'codeLineDelete', though the 'localization' context helps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'localizationUpdate' or 'delete_from_file'. The description only states what it does, leaving the agent to infer usage from the tool name and context with other localization 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool exports translations but doesn't clarify whether this is a read-only operation, if it modifies data, what permissions are needed, or how the export is delivered (e.g., file creation vs. data return). For a tool with two parameters and no annotation coverage, this leaves significant 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 directly states the tool's function without unnecessary words. It's appropriately sized for a simple export operation and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters with 0% schema coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain parameter meanings, behavioral traits (e.g., file system impact), or return values, leaving the agent with inadequate context 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?
The schema has 0% description coverage, so parameters 'filePath' and 'language' are undocumented in the schema. The description mentions 'specific language' (hinting at the 'language' parameter) but doesn't explain 'filePath' at all (e.g., whether it's an input or output path). It adds minimal value beyond the schema, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('export') and resource ('translations for a specific language') with the output format ('JSON format'), making the purpose understandable. However, it doesn't differentiate from sibling tools like localizationGetByKey or localizationSearch, which might also retrieve translation data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like localizationGetByKey (which retrieves by key) or localizationSearch (which searches translations). There's no mention of prerequisites, exclusions, or specific scenarios where exporting to JSON is preferred over other methods.
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 states the tool finds items but doesn't describe what 'finds' entails—whether it returns a list, modifies data, requires specific permissions, has rate limits, or what happens on errors. For a tool with 4 parameters and no annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every part contributing to understanding the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain parameters, return values, error conditions, or behavioral traits. For a tool that likely interacts with localization files and has multiple configuration options, this leaves too many gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the 4 parameters have descriptions in the schema. The tool description doesn't explain any parameters—it doesn't mention 'filePath', 'threshold', 'language', or 'limit'. The agent must guess parameter meanings from their names alone, which is inadequate given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '查找超過特定字數的翻譯項目' (Find translation items exceeding a specific character count). It specifies a verb ('查找' - find) and resource ('翻譯項目' - translation items) with a specific scope (exceeding character count). However, it doesn't explicitly differentiate from sibling tools like 'localizationFindMissing' or 'localizationSearch', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when-not-to-use scenarios, or comparisons to sibling tools like 'localizationFindMissing' (for missing translations) or 'localizationSearch' (for general searching). The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it indicates this is a 'find' operation (likely read-only), it doesn't describe what the tool actually returns (e.g., list of keys, counts, file locations), whether it has side effects, performance characteristics, or error conditions. For a tool with 3 parameters and no annotation coverage, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese sentence that directly states the tool's core function. There's zero wasted language or unnecessary elaboration. It's front-loaded with the essential purpose without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, how parameters interact, or provide any context about the localization system it operates on. For a tool that presumably scans files for missing translations, more context about expected formats, return values, and usage patterns would be needed.
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%, meaning none of the 3 parameters (filePath, language, limit) have descriptions in the schema. The tool description doesn't mention any parameters at all, failing to compensate for the complete lack of schema documentation. Users must guess what filePath refers to, what language format is expected, and what limit controls.
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: '查找有Key值但缺少特定語言翻譯的項目' (Find items that have key values but are missing specific language translations). This specifies the verb (find), resource (localization items), and scope (missing translations). However, it doesn't explicitly differentiate from sibling tools like localizationSearch or localizationGetByKey, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling localization tools (localizationSearch, localizationGetByKey, localizationFindLongValues, etc.), but the description doesn't indicate when this specific 'find missing' functionality is appropriate versus other search or retrieval operations. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read operation ('查詢' - query), suggesting it's non-destructive, but doesn't clarify permissions, rate limits, error handling, or what happens if the key is not found. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese, front-loaded with the core action. There is no wasted text, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 required parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return values, error cases, or how parameters interact, leaving the agent with insufficient information to use the tool effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'Key' but doesn't explain its format or purpose, and ignores 'filePath' entirely. This fails to add meaningful context beyond the bare schema, leaving key details unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('查詢' - query) and resource ('翻譯項目' - translation item), specifying it's based on a key. It distinguishes from siblings like localizationAdd (add), localizationDelete (delete), and localizationSearch (search), though not explicitly. However, it lacks specificity about what a 'translation item' entails, making it slightly vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention when to choose this over localizationSearch (which might search broadly) or localizationFindMissing (which finds gaps), nor does it specify prerequisites or contexts for usage, leaving the agent with no direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's an update operation but doesn't mention permissions needed, whether changes are reversible, potential side effects, or response format. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before 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 in Chinese that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain parameter meanings, behavioral traits, or what to expect upon execution, leaving significant gaps for an AI agent.
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 parameters are undocumented in the schema. The description doesn't explain what 'filePath', 'key', or 'updateData' represent or how they should be used. It fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '更新現有翻譯項目的內容' clearly states the action (update) and target (existing translation items). It's specific about what the tool does, though it doesn't explicitly differentiate from sibling tools like 'localizationAdd' or 'localizationDelete'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'localizationAdd' (for new items) or 'localizationDelete' (for removal). It doesn't mention prerequisites, context, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool executes an npm build command, implying it's a mutation operation that may modify files or produce output, but it doesn't disclose critical behaviors such as whether it requires specific permissions, what happens on failure, if it's idempotent, or any side effects like creating directories. This is a significant gap for a tool with potential destructive effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly. Every word earns its place by conveying the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a build tool with 2 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on parameters, behavioral traits, expected outputs, error handling, and usage context. This makes it inadequate for an agent to reliably invoke the tool without additional assumptions or trial-and-error.
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 2 parameters (path and options) with 0% description coverage, meaning no details are provided in the schema. The description adds no information about these parameters—it doesn't explain what 'path' refers to (e.g., project directory path) or what 'options' might include (e.g., npm build flags). This fails to compensate for the low schema coverage, leaving parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('執行npm build命令構建專案' translates to 'execute npm build command to build project'), specifying the verb (execute npm build) and resource (project). It distinguishes from siblings like npmInstall, which installs dependencies rather than building. However, it doesn't specify what type of project or build output is expected, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for building projects with npm, but it doesn't mention prerequisites (e.g., needing npm installed, a package.json file), when not to use it, or compare it to other build tools in the sibling list. This leaves the agent with minimal context for decision-making.
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. While '執行npm install命令' implies it runs a system command with potential side effects (installing dependencies), it doesn't disclose critical behavioral traits like whether it modifies files, requires internet access, has rate limits, or what happens on failure. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that directly states the tool's function. There's no wasted language or unnecessary elaboration, making it front-loaded and efficient. Every word serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of running npm install (which can modify files, require network access, and have various outcomes), the description is incomplete. With no annotations, no output schema, and 0% parameter coverage, it fails to provide sufficient context for safe and effective use. The description doesn't cover return values, error conditions, or behavioral implications.
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 description provides no information about the two parameters ('path' and 'options'), and schema description coverage is 0%. The description doesn't compensate for this gap by explaining what these parameters mean, their expected formats, or how they affect the installation process. This leaves parameters completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('執行npm install命令') and resource ('安裝依賴'), making the purpose understandable. It doesn't explicitly distinguish from sibling tools like 'npmBuild', but the verb 'install' versus 'build' provides implicit differentiation. The description is specific about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'npmBuild' or other dependency management approaches. It states what the tool does but offers no context about prerequisites, when it's appropriate, or what scenarios it's designed for.
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 burden for behavioral disclosure. While 'search' implies a read-only operation, the description doesn't specify important behavioral aspects: what 'allowed directories' means (permissions? configuration?), whether this is a recursive search, what the output format looks like, or any performance considerations. For a search tool with 6 parameters and no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence in Chinese that efficiently conveys the core purpose. Every word serves a purpose: 'search' (action), 'code' (target), 'containing specific text' (criteria), 'within allowed directories' (scope). There's no wasted verbiage 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?
For a search tool with 6 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what parameters do, what the search returns, how results are formatted, or any constraints. While conciseness is good, the description lacks essential information needed for an agent to effectively use this tool, especially given the complexity implied by multiple parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 6 parameters, the description provides no information about any parameters. It mentions 'specific text' which loosely corresponds to 'searchText', but doesn't explain the other 5 parameters at all. The description fails to compensate for the complete lack of schema documentation, leaving most parameters completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('search') and target ('code containing specific text'), making the purpose understandable. It specifies 'within allowed directories' which adds useful scope information. However, it doesn't explicitly differentiate this from sibling tools like 'find_files' or 'localizationSearch' which might also search code or files.
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 minimal guidance on when to use this tool. It mentions 'within allowed directories' which gives some context about scope, but offers no explicit comparison to alternatives like 'find_files' (which might search file names rather than content) or 'localizationSearch' (which might search localization strings). No guidance on when NOT to use this tool is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While '創建' implies a write/mutation operation, the description doesn't address permissions, side effects, error conditions, or what happens on success. For a creation tool with 6 parameters and no annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before 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 - just 8 Chinese characters plus punctuation. It's front-loaded with the core purpose and adds one clarifying detail about steps. Every word earns its place with zero waste 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?
For a creation tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what gets created, what the response looks like, error conditions, or parameter semantics. While concise, it leaves too many contextual gaps for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 6 parameters (3 required), the description provides no parameter information beyond the generic mention of '可以包含多個步驟' (can contain multiple steps). This only hints at the 'steps' parameter but doesn't explain any of the other 5 parameters (title, description, tags, dueDate, priority) or their formats/constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('創建' meaning 'create') and resource ('任務' meaning 'task'), making the purpose immediately understandable. It also adds useful context about supporting multiple steps, which distinguishes it from simpler creation tools. However, it doesn't explicitly differentiate from sibling tools like 'taskUpdate' or 'taskStepAdd'.
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 about when to use this tool versus alternatives. With multiple sibling task-related tools (taskUpdate, taskDelete, taskStepAdd, etc.), there's no indication of when this creation tool is appropriate versus when to modify existing tasks or use other task operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states a read operation ('獲取' - get) but doesn't disclose behavioral traits such as whether it's paginated, sorted, or includes metadata. For a list operation with zero annotation coverage, this is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('獲取所有任務列表') with no wasted words. It's appropriately sized for a simple tool, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation) but lack of annotations and output schema, the description is incomplete. It doesn't explain what 'all tasks' includes (e.g., status, fields returned) or behavioral aspects like performance implications. For a tool in a context with sibling alternatives, more guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any parameters, aligning with the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '獲取所有任務列表' (Get all task list) states a clear verb ('獲取' - get) and resource ('任務列表' - task list), but it's vague about scope and doesn't distinguish from sibling tools like taskGetById or taskSearch. It specifies '所有' (all) which implies no filtering, but lacks precision about what 'all' encompasses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like taskGetById (for specific tasks) or taskSearch (for filtered searches). The description implies it retrieves all tasks, but doesn't clarify use cases or exclusions, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While '設定' implies a write/mutation operation, the description doesn't disclose important behavioral traits like whether this requires specific permissions, whether the operation is reversible, what happens to partially completed steps, or how this affects task status. For a mutation tool with zero annotation coverage, this represents significant gaps in behavioral 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 extremely concise - a single sentence that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. The structure is front-loaded with the core functionality immediately apparent.
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 this is a mutation tool with no annotations, 0% schema description coverage, no output schema, and multiple sibling tools handling similar operations, the description is incomplete. It doesn't address key contextual questions about when to use this tool, what the parameters mean, what the behavior entails, or what the expected outcome is. The conciseness comes at the expense of necessary contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 2 parameters (taskId and completed), the description provides no parameter semantics beyond what's implied by the tool name. The description doesn't explain what format taskId should be in, what 'completed' means in context (marking all steps as done/undone), or any constraints on these parameters. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('設定' meaning 'set') and resource ('某個任務所有步驟的完成狀態' meaning 'completion status of all steps for a task'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like taskStepUpdate or taskUpdate, which handle individual steps or task properties respectively.
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 several sibling task-related tools (taskStepUpdate, taskUpdate, taskStepAdd, taskStepDelete) that handle similar operations, but the description offers no context about when this bulk step completion tool is preferred over individual step updates or other task modifications.
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 burden for behavioral disclosure. '添加' (add) implies a write/mutation operation, but the description doesn't disclose permissions needed, whether steps are appended or inserted at specific positions, what happens on duplicate orders, or error conditions. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase in Chinese that directly states the tool's purpose. There's no wasted language, repetition, or unnecessary elaboration. It's appropriately sized for a straightforward tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 4 parameters (0% schema coverage), no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, error conditions, or important behavioral aspects like how 'order' affects step sequencing. The agent lacks critical information for proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It mentions '新步驟' (new steps) which hints at the 'description' parameter but doesn't clarify what 'taskId', 'order', or 'estimatedTime' represent. The description adds minimal value beyond what's inferable from parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '為任務添加新步驟' (add new steps to a task) clearly states the verb ('添加' - add) and resource ('任務步驟' - task steps). It distinguishes from siblings like taskCreate (creates entire tasks) and taskStepUpdate (updates existing steps). However, it doesn't specify whether this adds single or multiple steps, which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., task must exist), when to use taskStepUpdate instead for modifications, or how it differs from taskSetAllSteps (which presumably replaces all steps). The agent must infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that the tool reads files and displays line numbers, but doesn't disclose behavioral traits such as error handling (e.g., if the file doesn't exist), performance characteristics, or output format details. The advice about not modifying minor issues adds some context, but overall, the description lacks comprehensive behavioral disclosure for a read operation 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 concise and front-loaded, stating the core purpose in the first sentence. The second sentence adds useful guidance without redundancy. However, the inclusion of parenthetical advice slightly reduces structural clarity, but overall, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a read operation with 1 parameter), no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain the return values (e.g., what '顯示行號' entails), error conditions, or parameter details, leaving significant gaps for an AI agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the tool description doesn't mention any parameters. It fails to explain what 'filePath' represents (e.g., absolute path, relative path, file format expectations) or provide any semantic context beyond what the bare schema offers. This is insufficient compensation for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '讀取程式碼檔案並顯示行號' (read code file and display line numbers). It specifies the resource (code files) and verb (read with line numbers), but doesn't explicitly differentiate from sibling 'fileRead' which might serve a similar function without line numbers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance: '用於確認檔案實際行數以便編輯操作' (for confirming actual line counts for editing operations) and advises not to modify minor issues like indentation unless they affect compilation. However, it doesn't explicitly state when to use this tool versus alternatives like 'fileRead' or 'search_code', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While '刪除' implies a destructive operation, it doesn't specify permissions required, whether changes are reversible, error handling, or side effects. The dryRun parameter hints at preview capability, but this isn't explained in the description itself.
Agents need to know what a tool does to the world before 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 with no wasted words. It's appropriately brief and front-loaded with the core action, though this conciseness comes at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive file operation with 3 parameters (2 required), no annotations, and no output schema, the description is insufficient. It lacks details on behavior, error cases, permissions, and doesn't explain the relationship with sibling tools, leaving significant gaps for the agent to navigate.
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 mentions '特定內容' (specific content), which loosely relates to the 'selector' parameter, but adds minimal value beyond what's in the schema. With 33% schema description coverage (only 'dryRun' has a description), the description doesn't adequately compensate for the undocumented 'path' and 'selector' parameters, though it hints at their purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '從檔案中刪除特定內容' clearly states the action (delete) and target (specific content from a file), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'codeLineDelete' or 'edit_file', which appear to have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'codeLineDelete' or 'edit_file'. There's no mention of prerequisites, context, or comparison with sibling tools, leaving the agent with insufficient information to choose appropriately.
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. The description mentions '精確的編輯' (precise editing) and text replacement, but doesn't disclose critical behavioral traits: whether this is a destructive operation, what permissions are required, how errors are handled, or what the output looks like. For a file modification tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose in a single sentence: '對檔案進行精確的編輯，可以替換特定文字內容'. There's no wasted text or unnecessary elaboration. However, it could be slightly more structured by explicitly mentioning the parameters or usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a file editing tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the tool's behavior beyond basic functionality, doesn't provide usage guidance among similar tools, and leaves critical aspects like error handling, permissions, and output format undocumented. For a mutation tool in this context, the description should do more to compensate for the lack of structured metadata.
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% (1 of 3 parameters has a description in the schema). The description adds some value by implying the tool operates on text content ('替換特定文字內容'), which aligns with the 'edits' parameter. However, it doesn't explain the 'path' parameter or the 'dryRun' option beyond what the schema provides. The description partially compensates for the low schema coverage but doesn't fully address the parameter semantics gap.
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: '對檔案進行精確的編輯，可以替換特定文字內容' (perform precise editing on files, can replace specific text content). It specifies the verb ('edit') and resource ('files') with the specific operation of text replacement. However, it doesn't explicitly distinguish this tool from sibling tools like 'delete_from_file' or 'insert_to_file' that also modify files.
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. With multiple sibling tools that modify files (e.g., 'delete_from_file', 'insert_to_file', 'fileWrite'), there's no indication of when text replacement is appropriate versus other editing operations. The description only states what the tool does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool inserts content but doesn't mention whether this modifies files permanently, requires specific permissions, handles errors, or what happens if the position is invalid. The 'dryRun' parameter suggests preview capability, but this isn't explained in the description itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence in Chinese that directly states the tool's function. It's front-loaded with the core action and contains no unnecessary words or redundant information. Every part of the sentence contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a file modification tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the mutation behavior, error conditions, position format (line number vs. character offset), or what the tool returns. The presence of a 'dryRun' parameter suggests important behavioral nuances that aren't addressed in the 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?
Schema description coverage is 50% (only 'content' and 'dryRun' have descriptions). The description mentions '特定位置' (specific position) which aligns with the 'position' parameter, and '新內容' (new content) which aligns with 'content'. However, it doesn't explain what 'path' represents or provide additional context about parameter formats, constraints, or interactions beyond what's minimally implied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('插入新內容' - insert new content) and target resource ('在檔案的特定位置' - at a specific position in a file). It distinguishes from obvious siblings like 'delete_from_file' and 'edit_file' by specifying insertion rather than deletion or general editing. However, it doesn't explicitly differentiate from 'codeLineInsert' which might be a more specific sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'edit_file', 'codeLineInsert', or 'fileWrite'. There's no mention of prerequisites, constraints, or typical use cases. The agent must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While '獲取' (get) implies a read operation, the description doesn't specify whether this requires authentication, has rate limits, returns real-time vs cached data, or what format the analysis report takes. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before 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 Chinese phrase that directly states the tool's purpose. There's zero wasted language - every character earns its place. The structure is front-loaded with the core functionality immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent complexity (providing analysis reports) and the absence of both annotations and output schema, the description is insufficient. It doesn't explain what constitutes a 'status analysis report', what data it includes, whether it's aggregated or detailed, or what format it returns. For an analysis tool with no structured output documentation, the description should provide more context about the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to compensate for any parameter gaps. The baseline for 0 parameters with complete schema coverage is 4, as there's no parameter information to add beyond what's already structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '獲取任務狀態分析報告' (Get task status analysis report) states a clear purpose with a specific verb ('獲取' - get) and resource ('任務狀態分析報告' - task status analysis report). However, it doesn't distinguish itself from sibling tools like 'taskGenerateReport' or 'taskGetAll' - the agent must infer this is specifically about status analysis rather than general reporting or retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple task-related siblings (taskGenerateReport, taskGetAll, taskGetById, taskSearch), there's no indication of when this status analysis report is appropriate versus other task operations. The agent receives no usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool generates a Markdown report but doesn't describe where the report is saved (e.g., to a file or returned as output), what data sources it uses, whether it requires specific permissions, or any side effects. This leaves significant gaps for a tool that likely accesses and processes task data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose in a single sentence. It efficiently communicates the main function and optional feature without unnecessary details, though it could be slightly more structured by explicitly separating the primary action from the optional parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (generating reports with date filtering), no annotations, no output schema, and incomplete parameter documentation (67% coverage), the description is insufficient. It doesn't explain the output format, how the report is delivered, or behavioral aspects like error handling, making it inadequate for safe and effective use by an AI 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?
The schema description coverage is 67% (2 out of 3 parameters have descriptions). The description adds minimal value beyond the schema by mentioning date filtering, which aligns with the schema's startDate and endDate parameters. However, it doesn't explain the outputPath parameter or provide additional context like format constraints or default behaviors, resulting in an adequate but not enhanced baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '生成任務進度Markdown報告' (generate task progress Markdown report) with optional date filtering. It specifies both the verb (generate) and resource (task progress report), though it doesn't explicitly distinguish it from sibling tools like taskAnalyze or taskGetAll, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions optional date filtering but doesn't specify scenarios where this is preferable over other task-related tools like taskSearch or taskGetAll, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While '刪除' (delete) implies a destructive mutation, it doesn't disclose behavioral traits like whether deletion is permanent/reversible, permission requirements, error conditions (e.g., invalid IDs), or what happens to task structure after step removal. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese with zero wasted words. It's appropriately sized for a simple deletion operation and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It lacks essential context like behavioral details, parameter meanings, error handling, and output expectations, leaving significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies parameters for identifying a task and step ('任務的特定步驟'), but doesn't specify what 'taskId' and 'stepId' represent (e.g., format, source). The description adds minimal value beyond the schema's parameter names, failing to fully address the coverage gap.
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 '刪除任務的特定步驟' (Delete a specific step of a task) clearly states the verb ('刪除' - delete) and resource ('任務的特定步驟' - specific step of a task). It distinguishes from sibling tools like 'taskDelete' (deletes entire tasks) and 'taskStepAdd' (adds steps), but doesn't explicitly mention this differentiation in the description itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing task/step), exclusions, or comparisons to similar tools like 'taskDelete' or 'taskStepUpdate'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. The description only states what the tool does ('get by ID') without disclosing behavioral traits like: what happens if the ID doesn't exist (error vs null return), authentication requirements, rate limits, or response format. For a read operation with no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's purpose. There's zero wasted language, and it's appropriately sized for a simple retrieval tool. The structure is front-loaded with the core functionality.
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 this is a read operation with 1 parameter, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain error conditions, response format, or parameter details. For a tool that likely returns structured task data, more context about what information is returned would be helpful.
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% (no parameter descriptions in schema), and the description doesn't provide any parameter information beyond what's implied by 'by ID'. It doesn't explain what format the ID should be (string format, length constraints, etc.), where to find task IDs, or provide examples. With 1 parameter and 0% schema coverage, the description should compensate more.
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 '根據ID獲取特定任務' (Get specific task by ID) clearly states the verb ('獲取' - get/retrieve) and resource ('任務' - task) with the specific mechanism (by ID). It distinguishes from siblings like taskGetAll (get all tasks) and taskSearch (search tasks). However, it doesn't explicitly mention what 'task' refers to in this context.
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 you have a specific task ID and want to retrieve that single task. It distinguishes from taskGetAll (get all tasks without filtering) and taskSearch (search with criteria). However, it doesn't provide explicit guidance about when NOT to use this tool or mention alternatives like taskSearch if you don't have the exact ID.
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 that this is a destructive operation (deletes lines) and mentions a prerequisite (codeFileRead). However, it doesn't cover important behavioral aspects like error handling, what happens if lines don't exist, whether changes are saved immediately, or permission requirements. The description adds some context but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise but could be better structured. The first sentence about prerequisites is front-loaded and important. The second sentence mixes the core purpose with implementation details about formatting. While not excessively wordy, the structure could be clearer by separating purpose from behavioral notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficient. It mentions prerequisites and gives a hint about formatting behavior, but doesn't explain what the tool returns, error conditions, or the full implications of deleting code lines. The description should do more given the complexity and lack of structured documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 3 parameters, the description provides no information about what 'filePath', 'startLine', or 'endLine' mean or how they should be formatted. The baseline would be 1 for complete lack of parameter information, but it gets a 2 because the description implies line-based deletion (giving some context about the parameters' purpose), though not enough to compensate for the coverage gap.
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: '刪除程式碼檔案指定範圍的行' (delete specified lines from a code file). It specifies the resource (code file) and action (delete lines within a range). However, it doesn't explicitly differentiate from sibling tools like 'delete_from_file' or 'codeLineInsert', which reduces it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: '每次使用前、使用後必須先使用(codeFileRead)' (must use codeFileRead before and after each use). It also mentions an alternative approach for minor formatting issues ('提醒User就好了' - just remind the user). This gives clear when-to-use and prerequisite instructions.
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 effectively describes the tool's behavior: it inserts content at a specified line, shifts existing content down, and has specific prerequisites (using codeFileRead before/after). It also mentions handling of formatting issues (indentation) and user notification. While it doesn't cover all potential behavioral aspects like error handling or performance, it provides substantial operational context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with two main ideas (prerequisites and core functionality), but it's not optimally structured. The prerequisite information comes first, which is good for front-loading, but the formatting advice is somewhat buried. The text could be more streamlined while maintaining clarity.
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 complexity of a code modification tool with 4 parameters, no annotations, and no output schema, the description provides moderate contextual completeness. It covers behavioral aspects and usage guidelines well but leaves parameters largely unexplained. For a mutation tool without annotations or output schema, more detail about parameters and expected outcomes would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the 4 parameters have descriptions in the schema. The tool description doesn't explain any parameters beyond implying 'lineNumber' and 'content' through the phrase '指定行插入內容' (insert content at specified line). It doesn't mention 'filePath' or 'indentToMatch' at all. With 4 parameters and 0% schema coverage, the description fails to compensate adequately for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '在程式碼檔案指定行插入內容，原內容將向下移動' (insert content at a specified line in a code file, with original content moving down). This specifies the verb (insert), resource (code file), and behavior (line insertion with shifting). However, it doesn't explicitly distinguish this tool from similar siblings like 'insert_to_file' or 'edit_file'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: '每次使用前、使用後必須先使用(codeFileRead)' (must use codeFileRead before and after each use). It also gives context about when not to modify formatting: '如果不影響編譯器的話，不需要針對縮排等小問題修改。提醒User就好了' (if it doesn't affect the compiler, don't modify indentation or minor issues; just remind the user). This clearly defines prerequisites and limitations.
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:

[![GonMCPtool MCP server](https://glama.ai/mcp/servers/GonTwVn/GonMCPtool/badges/card.svg)](https://glama.ai/mcp/servers/GonTwVn/GonMCPtool)

Score Badge

Copy to your README.md:

[![GonMCPtool MCP server](https://glama.ai/mcp/servers/GonTwVn/GonMCPtool/badges/score.svg)](https://glama.ai/mcp/servers/GonTwVn/GonMCPtool)

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/GonTwVn/GonMCPtool'

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