e-worker-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation5/5
Each tool has a clearly distinct purpose: read-only queries, preview dry-runs, and apply mutations are separated with explicit _preview and _apply suffixes. Resource-specific operations (todo, time, file, db, diagnose) are well compartmentalized, leaving no ambiguity between tools.
Naming Consistency4/5Most tools follow a resource_action or resource_action_preview/apply pattern in snake_case (e.g., todo_list, todo_create_apply, db_export). However, a few outliers like safety_policy, report_daily, report_weekly, diagnose_report, and diagnose_collect deviate from the verb_noun convention, making the set slightly inconsistent.
Tool Count3/5At 25 tools, the server covers multiple domains (todos, time logging, reports, diagnostics, file management, DB import/export), which explains the large count. While each tool serves a purpose, the set feels heavy and may overwhelm agents; it sits at the top of the 'borderline' range for tool count.
Completeness4/5The tool surface covers core workflows: todo lifecycle (create, update, transition, list, get), time logging, daily/weekly reports, file operations, diagnostics, and DB import/export. Minor gaps exist, such as no update/delete for time logs, no explicit todo delete (though archived status may suffice), and diagnostic suggestions are not executable within the server.
Average 3.9/5 across 25 of 25 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It does not state whether this is a read-only operation, whether it mutates data, or what side effects (if any) occur. The description only states the output content, not the operation's behavior or safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that front-loads the essential purpose and output contents. It is concise and to the point, with no wasted words, earning high marks for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema covers the return format, the description lacks crucial context for the 'day' parameter and does not provide usage guidance or alternative comparisons. For a simple one-parameter tool, the absence of parameter semantics and usage context makes the description incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'day' with 0% coverage, and the description does not explain its meaning or effect. Although the description mentions '当日' (current day), it does not clarify how the 'day' parameter interacts with this default, leaving the parameter ambiguous. The description fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a daily report with specific content: completed items categorized by work/study and total work minutes. The verb '生成' (generate) and resource '日报' (daily report) are specific, and the scope distinguishes it from the sibling tool report_weekly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies daily reporting use through '当日' (current day), but it does not explicitly state when to use this tool versus alternatives like report_weekly or time_list. There are no clear exclusions or alternative comparisons, leaving usage context only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It describes the report content but does not explain side effects, permissions, or whether the operation is read-only. The term 'generate' could imply creation but no mutation is clarified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the tool's purpose and output structure. Every element (weekly report, daily grouping, category summary, total minutes) earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The high-level output structure is covered and an output schema exists, but the description lacks essential parameter context and usage scope. It does not address how the weekly range is determined or what start_day means.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention start_day at all. The agent receives no guidance on the parameter's format, meaning, or default behavior, leaving invocation ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a weekly report with specific aggregations (per-day completion count, category summary, total work minutes). The 'weekly' scope distinguishes it from the sibling tool report_daily.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for weekly reporting but does not provide explicit guidance on when to choose it over report_daily or how to handle the start_day parameter. No alternatives 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?
No annotations are provided, so the description must carry the full burden. It only notes the action is an 'actual update' and mentions a prerequisite, but does not disclose permissions, reversibility, side effects, failure modes, or postconditions. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one sentence that front-loads the core action and the key prerequisite (preview and adjudication). No redundant words, and it is well-structured for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, is a write operation, and has no annotations or schema descriptions, the description is far too minimal. It omits parameter usage, return value semantics, and contextual guidance about the adjudication process, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameter or explain what fields can be updated. The schema lists 7 parameters with names and types, but the description adds no semantic meaning, leaving the agent without guidance on how to fill them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool performs an actual update ('实际更新事项') and explicitly distinguishes it from preview tools by requiring a prior preview and adjudication. The verb and resource are specific enough to identify the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says '需先 preview 且通过裁决' (must first preview and pass adjudication), which tells the agent when this tool should be used versus alternatives like todo_update_preview. It also implies it is the apply step in a two-phase update flow.
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 burden of behavioral disclosure. It adds a prerequisite and a constraint on duration_minutes, but it does not disclose the actual side effects of applying (e.g., creating a record, irreversibility, permission needs). This is a modest addition but 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is front-loaded with the core purpose and prerequisite. However, it is arguably too terse, omitting details that would fit without bloat. It is concise but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not fully shown), which reduces the need to explain return values. Yet the description leaves out parameter semantics for three of four params and gives limited behavioral context. For an apply-type operation following preview, the description provides the essential workflow link but lacks depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains only duration_minutes must be a positive integer, but gives no semantics for item_id, date, or note. This is insufficient for a 4-parameter tool with zero schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource, '实际记录工时' (actually record work hours), and explicitly frames it as the apply step after preview. This clearly distinguishes it from sibling time_log_preview by indicating it is the final recording action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states a prerequisite: '需先 preview 且通过裁决' (must preview first and pass adjudication), giving clear context on when to use this tool relative to the preview tool. However, it does not mention when not to use it or alternatives beyond the implied preview step.
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 clearly states the tool is read-only ('只读操作') and refuses to overwrite existing paths ('拒绝覆盖已存在路径'), which are important behavioral traits. However, it does not mention error behavior, path handling, or output structure, so it falls short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose and then adds two key behavioral constraints. Every word contributes meaning, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple export tool with an output schema, the description covers the essential purpose and key constraints. However, it lacks parameter semantics and usage guidance, which are important for an agent to use the tool correctly. Given the tool's simplicity, the gaps are not critical, but they prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and no enums. The description only implies that 'format' supports JSON/CSV by mentioning those formats, but it does not explain the 'path' parameter, its default, or the exact allowed values. This leaves significant ambiguity for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: '导出数据库为 JSON/CSV' (Export database to JSON/CSV). It also distinguishes the tool from siblings like db_import_apply and file_scan by explicitly framing it as an export operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions the tool is read-only and refuses to overwrite existing paths, but these are constraints rather than usage guidance. There are no explicit exclusions or alternative tool references.
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 burden of behavior disclosure. It indicates a read operation via '查询' and states the return value (total minutes), but it does not explicitly confirm side-effect-free behavior or mention any required permissions or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the action, filter criteria, and output. It is front-loaded and contains no unnecessary words, earning a perfect score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three optional parameters and an output schema, so the description does not need to detail return structure. It covers what the tool does and its primary filtering dimensions, which is sufficient for a simple query tool, though it lacks any caveats or usage boundaries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the schema has no descriptions, the description compensates by explaining that parameters item_id and the date range (date_from/date_to) serve as filters. It does not cover parameter formats or detailed semantics, but it provides essential meaning for an agent to use the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries work time records with a specific verb (查询) and resource (工时记录). It also mentions filtering capabilities, making its purpose clear even without comparing to sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying time records with optional filters by item_id and date range. However, it does not explicitly contrast with sibling tools like report_daily or todo_list, nor does it state when to prefer this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly discloses the key non-destructive behavior (no database write), which is the most critical trait for a dry-run tool. It does not elaborate on what 'impact' means (e.g., validation results, conflicting entries), but the core safe-operation point is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, highly concise sentence that immediately communicates the tool's purpose and side-effect-free nature. It is front-loaded and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which covers return values), the description provides no usage context beyond dry-run status. With zero parameter coverage and no annotations, the agent lacks critical details about required inputs, potential constraints, and what 'impact' the preview displays. The description is too thin for reliable invocation in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameter or add meaning beyond the parameter names. It does not clarify value formats (e.g., date format, duration_minutes units) or how 'note' is used. The agent must guess from param titles, which is insufficient for a 4-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to preview the impact of recording work hours, specifically as a dry-run that does not write to the database. This distinguishes it from the sibling tool 'time_log_apply' which presumably performs the actual write.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'dry-run，不写库' implies this tool should be used to check effects before actually applying changes, and the sibling set includes 'time_log_apply', making the alternative clear. However, it does not explicitly say 'use this before applying' or provide conditions for when to choose this over other preview tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It mentions the sort order and filter capabilities, which adds some context, but it does not explicitly state that this is a read-only operation, describe pagination behavior, or mention any side effects. The word '查询' implies query, but not fully explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that leads with the main purpose and follows with key behaviors. Every phrase adds value with no unnecessary words, making it appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six optional parameters and an output schema, so return values are likely covered elsewhere. However, the description omits details about pagination (limit/offset), how filters behave (exact vs. partial match), and any potential side effects. It is acceptable for a simple list tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 clarifies the meaning of four parameters (status, category, keyword, tag) as combinable filters, but it does not explain limit and offset, which are also parameters. Partial compensation but not complete for all six parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries a todo item list (查询事项列表) and specifies supported filters (status/category/keyword/tag) plus sort order (creation time descending). This distinguishes it from sibling tools like todo_get which retrieves a single item, and time_list which queries time logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing todos with combined filters, but it does not explicitly mention alternatives or when not to use this tool. For example, it does not direct users to todo_get for single-item retrieval or note any exclusions, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 explicitly states '只读' (read-only), which is the critical safety trait, and describes the return payload. However, it does not mention edge cases such as pattern filtering behavior, recursion depth, or error handling, preventing a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the tool's purpose and output. Every word contributes value, with no redundancy or filler. It is appropriately sized for a relatively simple scanner tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core scan and return metadata well, but it omits any mention of the pattern parameter, usage context relative to siblings, and edge cases. The presence of an output schema reduces the need to explain return values, but the lack of parameter and usage information makes it incomplete for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description only vaguely references the directory via '扫描目录', which hints at the 'path' parameter. The 'pattern' parameter with its default '*' is completely omitted, and no details are given about how it affects results. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (read-only directory scan) and explicitly lists the returned metadata fields (name/path/size/mtime/extension) plus the subdirectory list. This clearly distinguishes it from sibling tools like file_organize_apply or file_clean_apply, which modify or organize files rather than merely scan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The read-only nature implies usage for inspection, but the description does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or when-not-to-use guidance. Usage context is implied but not clearly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool performs a real status change, requires a prior preview and adjudication, and automatically writes completed_at when transitioning to done. However, it omits information about error handling, permissions, or what happens if the prerequisite is not met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a single sentence with a parenthetical to convey both purpose and key constraints. Every phrase adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with only two parameters and an output schema exists, so return values are covered. Still, the description leaves gaps about what counts as a valid 'new_status' (beyond 'done') and what '裁决' entails, which are important for correct use in the context of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the bare parameter names. It adds some meaning by mentioning the value 'done' for new_status and its side effect, but it does not explain item_id or enumerate valid statuses, leaving significant ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it actually transitions a todo item's status, using the verb '流转' (transition) with the resource '事项状态' (todo status). It also distinguishes from sibling preview tools by explicitly noting the need to preview first and pass adjudication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '需先 preview 且通过裁决' provides clear guidance that this tool should only be used after running a preview and obtaining approval, effectively signaling when to use it versus alternatives. It does not explicitly name alternative tools, but the context makes the usage order clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It states the tool performs a dry-run preview, which implies no data modification, and it checks for id conflicts and whether a database clear is needed. These are meaningful behavioral traits beyond a simple 'preview' label, but it does not explicitly say 'does not modify data' or mention any auth/rate-limit constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately communicates the tool's core function and key aspects. Every phrase adds value, with no fluff or repetition. It is appropriately concise for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema (so return values are covered externally), and the description effectively summarizes its purpose and key checks. However, it lacks explicit usage guidance and parameter semantics, which would make it fully self-contained. Given the tool's low complexity and the presence of an output schema, the description is mostly complete but has a minor gap in contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the three parameters (path, merge, format). The description mentions '来源文件' (source file) which maps to 'path' but does not explain how 'merge' or 'format' affect the preview output, nor does it clarify any parameter-specific behavior. The description focuses on outputs, not inputs, leaving parameter semantics largely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '预览导入影响' (preview import impact). It enumerates specific outputs: source file, number of records to import, id conflict detection, and whether database clearing is needed (dry-run). This distinguishes it from db_import_apply, which executes the import, and from other preview tools by mentioning import-specific impact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the term 'dry-run' and its role as a preview tool, suggesting it should be used before db_import_apply. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The guidance is inferred rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the key behavioral trait: files are moved to .trash/ and never physically deleted. This is valuable safety context, though it doesn't mention permissions, reversibility, or edge-case 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence efficiently conveys the operation, prerequisite, and safety behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple apply-step tool, covering purpose, prerequisite, and safety. However, the absence of parameter semantics and reliance on sibling context leaves some gaps, especially since no annotations are provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no details about 'path' or 'pattern'. The parameter names are self-explanatory in context, but the description doesn't specify how they interact or what formats are expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: applying cleanup by moving files to .trash/ rather than physically deleting. It distinguishes itself from preview tools by explicitly saying '实际清理' (actual cleanup) and mentioning the prerequisite of preview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: after preview and after passing adjudication ('需先 preview 且通过裁决'). This effectively tells the agent to use the preview sibling first, though it doesn't explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses a critical behavioral trait: files are moved to .trash/ rather than deleted. It also implies no actual changes via 'dry-run'. However, it does not describe recursion, permissions, or the exact output format, though the output schema may cover return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the core purpose and safety behavior without redundancy or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the dry-run and trash behavior but omits details about scan scope (e.g., recursive), pattern semantics, and what the 'impact' consists of. Since an output schema exists, return values are not required, but the description is minimal for a tool with no annotations and two unannotated parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only parameter names (path, pattern) with no descriptions, and the tool description does not explain their formats or semantics. The only hint is 'matching files', suggesting pattern is a match criterion, but glob/regex syntax and the meaning of path remain unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool previews the impact of cleaning matching files, using the verb 'preview' and explicitly noting the dry-run behavior. It distinguishes itself from the sibling file_clean_apply by mentioning files are moved to .trash/ instead of deleted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The dry-run keyword provides clear context that this is a non-destructive preview, implying it should be used before applying cleanup. However, it does not explicitly mention the sibling file_clean_apply or state when not to use it, so it lacks explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses an important behavioral constraint (whitelist/blacklist check and preview requirement), which adds context beyond basic creation. However, it does not describe side effects, failure modes, or authorization details, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loading the core action and critical precondition. Every word earns its place, and the required category note is included without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 params, no annotations, no output schema reliance because description doesn't mention it), the description provides the essential workflow context (preview first) and category constraint, but lacks details on other parameters and the exact relationship to the preview output. It is adequate but not complete for a tool with this parameter count.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds the allowed values for category ('work/study') which is helpful, but the other six parameters (due, tags, notes, priority, metadata) receive no explanation. For a tool with 7 parameters, this is insufficient semantic enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function ('实际创建事项' = actually create todo item) and distinguishes it from the sibling preview tool (todo_create_preview). It also names the required category field, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the precondition: must first preview and pass whitelist/blacklist arbitration. This gives clear when-to-use guidance and separates it from the preview step. The sibling list confirms the preview/apply pattern, but the description itself provides the key usage rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral trait: dry-run and no database write ('不写库'), which is essential since no annotations are provided. However, it does not elaborate on what the 'impact list' contains or any validation behavior, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the purpose, includes the dry-run note, and gives the follow-up call—no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core workflow and non-destructive nature, but with 7 parameters and no schema descriptions, it leaves parameter semantics entirely unexplained. The existence of an output schema mitigates return-value documentation, yet the overall context is incomplete for a new user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about parameters such as title, category, due, tags, notes, metadata, or priority. It neither explains required fields nor value constraints, failing to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb '预览' (preview) with a clear resource ('创建事项的影响' - impact of creating a todo), explicitly distinguishes from the sibling 'todo_create_apply' which executes, and establishes the preview/apply workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this tool first to display the impact list, then call 'todo_create_apply' to execute, providing clear when-to-use guidance and direction to the companion tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the operation does not write to the database, which is the most critical side-effect information. It does not elaborate on what the preview shows (e.g., diff, errors), but for a dry-run this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys purpose and key behavior without any padding. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives the essential preview/no-write info and there is an output schema, so return structure is covered. However, given 7 parameters and the presence of many sibling tools, it lacks guidance on prerequisites (e.g., item must exist) or typical usage flow with todo_update_apply. It is minimally adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no context for the parameters. While property names are self-explanatory, the description does not explain how they are used in the preview or whether they represent the fields to be changed. This fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool previews the impact of updating a todo item, explicitly noting it is a dry-run with no database write. This distinguishes it from sibling tools like todo_update_apply, which actually performs the update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The dry-run indicator implies this should be used to assess changes before applying them, providing clear context. However, it does not explicitly name alternative tools or state when not to use it, so it misses the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly states that target conflicts are skipped and no physical deletion occurs, adding safety and execution context. It also notes the preview/adjudication requirement, which is helpful for understanding side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary action followed by important conditions. Every clause adds value: execute move, preview prerequisite, conflict skip, and no deletion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with an output schema, the description covers essential preconditions and side effects, including conflict handling and deletion policy. The term 'adjudication' is domain-specific and not elaborated, but given the sibling preview tool, the context is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not elaborate on the 'path' or 'rules' parameters, and the schema provides no descriptions for them (0% coverage). The agent must infer that 'path' is the directory and 'rules' come from preview, but the description itself lacks parameter-level detail or format guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '实际执行归档移动' (actually execute archive move), which is a specific verb+resource. It distinguishes itself from siblings like file_organize_preview and file_clean_apply by emphasizing the execution step and prerequisite of preview/adjudication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage prerequisite: '需先 preview 且通过裁决' (must preview first and pass adjudication), telling the agent when this apply tool is appropriate. It does not explicitly name alternatives or exclusions, but the prerequisite context is sufficient to guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states the tool is a dry-run, meaning it will not mutate data, which is a crucial safety trait. The state machine also discloses the allowed statuses, though it doesn't detail validation rules or side effects beyond the non-mutating nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core purpose ('preview impact') and immediately followed by the state machine. There is no redundant information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required params, no nested objects) and the presence of an output schema, the description covers the essential purpose and state machine. It lacks explicit parameter semantics and usage boundaries, but the output schema presumably handles return values, making the description largely adequate for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It does not explain item_id or new_status; the state machine only hints at valid values for new_status, while item_id semantics are left entirely to inference from the name. This is insufficient compensation for the absence of schema-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool does a dry-run preview of item status transitions, using the specific verbs '预览' (preview) and 'dry-run'. The state machine inbox→todo→doing→done→archived further specifies the scope and distinguishes it from sibling tools like todo_transition_apply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'dry-run' term clearly indicates this tool is for previewing before taking action, and sibling tool names (todo_transition_apply) reinforce the intended workflow. However, it does not explicitly name alternatives or state when not to use it, leaving the guidance implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 disclosing behavior. It reveals critical safety constraints: the requirement for prior preview and adjudication, and the rejection when merge=false with a non-empty database. This adds valuable context about side effects and operation viability, though it does not detail success behavior or the meaning of 'adjudication'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action and immediately follows with critical conditions. Every word earns its place, with no redundant information or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity and presence of an output schema, the description covers the essential context: the workflow prerequisite (preview and adjudication) and a key edge-case rejection. It does not explain the return value, but the output schema exists. It could briefly mention what happens on success, but the current level is sufficient for an AI to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 explicitly explains the behavior of the 'merge' parameter (false leads to rejection if DB non-empty), which is a key semantic. However, it does not clarify 'path' or 'format', leaving those to the schema. The description adds meaningful context for the most consequential parameter but under-specifies the others.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs the actual data import ('实际导入数据'), distinguishing it from the preview sibling by explicitly mentioning the prerequisite of preview and adjudication. The verb 'import' and resource 'data' are specific, and the condition 'merge=false 且库非空会被拒绝' adds further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit preconditions: must preview first and pass adjudication before applying. It also warns about the rejection condition for merge=false with non-empty database, which serves as a clear 'when not to use' hint. However, it does not explicitly mention alternatives or when merge=true would be appropriate, leaving some room for inference.
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 clearly discloses the non-destructive nature ('dry-run，不移动文件'), which is critical. It also explains rule structure, but does not describe other potential side effects or return details beyond what the output schema likely covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, purposeful sentences. The first front-loads the core behavior and the second concisely explains rule item structure. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a dry-run preview tool with an output schema and moderate parameter complexity, this is largely complete. It covers the non-destructive behavior, rule structure, and provides enough context for an agent. The only gap is the undefined path parameter, but its name is fairly self-explanatory given the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning to the rules parameter by stating each item contains 'pattern(glob) 与 target(目标子目录)', but the required path parameter is not described at all. This is a partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with '预览按规则归档的影响清单' (preview the impact list of archiving by rules), which is a specific verb+resource. It explicitly says 'dry-run，不移动文件' (dry-run, does not move files), clearly distinguishing it from file_organize_apply and other apply tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states this is a dry-run that does not move files, implying it is safe to use before applying changes. However, it does not explicitly name the alternative file_organize_apply or provide a when-not-to-use condition, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. The word '查询' (query) implies a read-only operation, but the description does not disclose behavior on missing ids, permissions, or any side effects. It is minimal but not misleading, so a mid-range score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It provides the core purpose without unnecessary detail, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with one parameter and an output schema, the description is sufficient. It does not need to describe return values since the output schema exists. It lacks explicit prerequisites (e.g., item must exist), but that is less critical for a basic query operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explicitly says '按 id' (by id), clarifying that the required item_id parameter is the unique identifier of the todo item. This adds meaning beyond the schema's bare parameter name, though it does not explain the string format, which the schema already handles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '按 id 查询单个事项详情' clearly states the action (query details) and resource (single todo item) with a specific identifier. It differentiates from siblings like todo_list by specifying a single item lookup, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use this to fetch details for a known id. It does not explicitly name alternatives or exclusions, but the 'by id' qualifier provides clear context that this is for single-item retrieval rather than listing, which is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the operation is read-only ('只读') and does not listen or bind ports ('不监听不绑定端口'), which is critical safety information. It also lists the specific data being collected, providing clear scope and reassurance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that begins with the action and scope, then enumerates specific collected items. It is concise, with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's purpose, safety profile, and data scope, and an output schema exists to document return values. However, it does not mention the relationship to sibling tool diagnose_report or typical usage scenarios, which would improve contextual integration into the broader diagnostic workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so a baseline of 4 is appropriate. The description adds no parameter-specific details because there are none, but it does describe the data categories the tool collects, which are outputs rather than inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a read-only action ('只读采集') on a specific resource (local environment info) and enumerates the exact data points: Python/Node/Go versions, PATH, port listening list, and disk remaining capacity. This distinguishes it from sibling tools like diagnose_report, which likely focuses on generating a report rather than collecting data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for gathering environment diagnostics, but it does not explicitly state when to prefer this tool over alternatives or how it relates to diagnose_report. No exclusions or alternative tool names are mentioned, leaving the agent to infer the expected workflow from the sibling list.
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. It discloses the key non-execution behavior and manual confirmation requirement, which is crucial for an AI agent. It also describes report contents (issues and recommendations), adding context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence front-loads the verb and resource, then efficiently lists report contents and the critical caveat. Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, report-generating tool with an output schema, the description covers essential content and non-execution behavior. It omits any prerequisite (e.g., running diagnose_collect first), which is a minor gap given the sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 properties, so the baseline is 4. The description appropriately focuses on report content and behavior rather than parameter details, which are irrelevant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses explicit verb '生成' and resource '环境诊断报告' with specific content: issue list (disk, tools, contract port) and recommended actions. This clearly distinguishes it from sibling tools like diagnose_collect (collect vs. report) and report_daily/weekly (different report types).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it generates a diagnostic report and explicitly notes '不自动执行，需人工确认' (does not execute automatically, requires manual confirmation), providing clear context and a when-not. However, it does not name alternative tools like diagnose_collect or apply tools, so it misses the full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the non-destructive behavior (no DB write), describes the internal processing logic, and mentions the follow-up flow. It could elaborate on edge cases or input expectations, but the key behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single, compact sentence that front-loads the primary action, includes essential caveats, and avoids unnecessary detail. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, core behavior, and the relation to todo_create_apply. The output schema covers return values. Missing explanation of the 'category' parameter and potential input format constraints, but overall sufficient for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It clearly indicates 'text' is the meeting minutes content, but the 'category' parameter is not mentioned at all. The description partially compensates but leaves one parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool extracts draft to-dos from meeting minutes text, with specific processing steps (action word scan + date conversion). It distinguishes from sibling tools by explicitly noting it only returns drafts without writing to the database.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (extraction/preview) and when to call the alternative todo_create_apply for persisting. The 'only return drafts, don't write to DB' phrase provides clear usage guidance and names the follow-up tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the tool is read-only, which is a key behavioral trait. It also clarifies the downstream behavior (direct execution vs. preview) based on the returned policy, adding useful context beyond a simple read operation. However, it does not mention potential side effects or error behavior, though since it is read-only, this is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences. The first sentence front-loads the core purpose and fields, and the second sentence provides essential usage guidance. There is no redundancy or filler; every sentence provides valuable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description sufficiently covers the tool's role as a policy gate at session start, and it explains the auto_approve logic that connects to sibling preview/apply tools. The output schema exists, so not detailing return values is acceptable. However, it assumes the reader knows what 'domains' mean in the policy context, which could be ambiguous without broader system knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. The baseline for zero params is 4, and the description adds no unnecessary parameter information, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '只读返回当前安全策略' (read-only returns the current safety policy) and explicitly lists the fields (mode/allow_rules/deny_rules/auto_approve). This distinguishes it from sibling tools, which are action-oriented preview/apply operations, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: '会话开始时先调用本工具' (call this tool first at session start). It also explains the decision logic—auto_approve matching domains can be executed directly, while non-matching domains require preview and user confirmation—which guides when to use this tool versus relying on preview tools.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/albertm88/e-worker-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server