Server Quality Checklist

Tool Scores

• wb_todo_doneB
  3.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the behavioral disclosure burden. It does disclose that this is a write operation requiring confirm:true and that id uses prefix matching. However, it does not explain side effects such as whether completion is reversible, what state changes occur, or what response is returned.

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

  Conciseness4/5

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

  The description is compact and front-loaded with the core action, then adds the CLI mapping and required confirmation. It wastes no words, though repeating parameter details from the schema is slightly redundant.

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

  Completeness3/5

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

  For a simple two-parameter tool with no output schema, the description is mostly sufficient for calling it correctly: id and confirm are covered. It lacks usage distinction from siblings and any return/result information, but the low complexity keeps the gap moderate.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents both id and confirm. The description only restates these details ('待办 id（前缀匹配）' and 'confirm:true') without adding deeper meaning, so it stays at the baseline.

  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 '完成待办' (complete todo) with a specific resource and references the CLI equivalent 'todo done'. It does not explicitly compare itself to sibling todo tools like wb_todo_edit or wb_todo_del, but the verb and resource are unambiguous.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to choose this tool over alternatives such as wb_todo_edit or wb_todo_del. It gives a CLI mapping and a confirmation requirement, but no contextual conditions or exclusions.

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

• wb_dev_task_createB
  3.3/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose that this is a write operation and that confirm:true is required, which is important safety-relevant behavior. However, it does not describe side effects on linked todo items, whether the operation is reversible, permissions needed, or what the response will be.

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

  Conciseness5/5

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

  The description is compact, front-loaded with the core purpose, and includes the CLI mapping, required parameters, and the confirm gate in a single efficiently structured string. Every sentence earns its place.

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

  Completeness3/5

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

  For a mutating tool with no annotations and no output schema, this description covers purpose, required parameters, and the confirm gate, making it minimally viable. But it lacks usage guidance and any explanation of return values or expected side effects, so an agent may still be uncertain about the full invocation context.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description restates title and bugs parameters and adds the confirm safety requirement, but it does not add meaning beyond what the input schema already provides. It is acceptable but not additive.

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

  Purpose4/5

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

  The description clearly states a specific verb and resource: 新建开发任务 (create development task). It does not read as a tautology or vague operation. However, it does not explicitly differentiate this tool from sibling tools like wb_dev_task, wb_dev_task_stage, or wb_dev_task_item.

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

  Usage Guidelines2/5

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

  The description provides no explicit guidance on when to use this tool versus alternatives. The parenthetical '(S0 需求汇总自动生成)' hints at an automation context, but does not clearly state when an agent should choose this tool or when it should not. The CLI mapping is informative but not usage guidance.

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

• wb_dev_task_itemB
  3.3/5.0
  Behavior3/5

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

  No annotations are provided, so the description must disclose behavior itself. It explicitly labels the operation as a '写操作' (write operation) and states that confirm:true is required, which is useful safety information. However, it does not describe reversibility, side effects, permissions, or success/failure behavior beyond the schema's confirm note.

  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 short and front-loaded with the core purpose, but it duplicates the parameter documentation that already exists in the schema and includes a CLI mapping that adds little for an AI agent. It is compact, but not every sentence earns its place.

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

  Completeness3/5

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

  For a write operation with no annotations and no output schema, the description covers the purpose, required confirmation, and key parameters. It is adequate for basic invocation, but it omits guidance on expected outcomes, error cases, or what 'S4/S7' refers to, leaving some context incomplete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameters. The description mostly restates the same parameter labels and meanings (id, key, index, status, note) without adding new format, default, or dependency details. Baseline 3 applies because the schema carries the load.

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

  Purpose4/5

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

  The description states a specific action ('S4 条目 / S7 清单打勾' – checking off an item in a dev task checklist) and identifies the target resource as a dev-task item. It is more informative than the bare tool name, though the S4/S7 abbreviations are domain-specific and not explained.

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

  Usage Guidelines3/5

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

  The description gives contextual usage clues ('S4/S7 checklist item') and a CLI equivalent, but it does not explicitly state when to use this tool versus sibling tools such as wb_dev_task_create or wb_dev_task_stage. There are no exclusions or alternative-routing hints.

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

• wb_noteB
  3.4/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the behavioral transparency burden. It does disclose that the domain contains write operations and that confirm is required, which is safety-relevant. It does not describe side effects, reversibility, or output behavior, but the explicit write/confirm warning provides meaningful value.

  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 short and front-loaded with the domain and command family, followed by the confirm requirement. The parenthetical '（本域含写操作）' is mostly redundant with the preceding sentence, so it is not perfectly economical, but overall every other part earns its place.

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

  Completeness3/5

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

  For a generic command-family dispatcher with no annotations and no output schema, the description provides the core scope and the confirm gate, which is essential for safe invocation. However, it does not enumerate the full set of note subcommands or clarify the relationship with wb_note_add/wb_note_edit, leaving some context missing.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents command, args, and confirm thoroughly. The description adds only the high-level note-domain context and the confirm requirement, which is already in the schema. This meets the baseline but does not add extra parameter-level detail.

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

  Purpose4/5

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

  The description states a specific resource ('笔记域/note 命令族') and the operations it covers ('笔记列表/新增/编辑'), so an agent can tell it is the note-domain command tool. It does not explicitly contrast itself with the sibling tools wb_note_add and wb_note_edit, which slightly weakens 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 Guidelines3/5

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

  The description implies usage for note list/add/edit operations and gives a clear operational rule: write operations require confirm. However, it does not explain when to prefer wb_note over the more specific wb_note_add/wb_note_edit siblings, nor does it list exclusions or alternatives explicitly.

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

• wb_todo_editB
  3.4/5.0
  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 that this is a write operation and requires confirm:true, but it does not describe what actually happens to the todo item, whether unspecified fields are preserved, whether changes are reversible, or what response the agent can expect. For a mutating tool, this is a meaningful 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 compact and front-loaded with the core purpose, followed by the minimum-argument requirement and the safety flag. The parameter enumeration is somewhat redundant with the schema, but the overall length is justified and easy to scan.

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

  Completeness3/5

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

  The description covers all seven parameters, the required id, and the confirmation safety gate, making it sufficient for a basic call. However, there is no output schema, no annotation safety profile, and no statement about return behavior or side effects, so an agent still lacks a full picture of what happens after the edit.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents every parameter, including enums and the date pattern. The description repeats the parameter list without adding substantial new meaning beyond marking id as a prefix and reiterating the confirm requirement. Baseline 3 is appropriate because the schema carries the heavy lifting.

  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 operation as '编辑待办字段' (edit todo fields), identifying both the verb and the resource. It also adds a useful constraint about passing at least one field to change. However, it does not explicitly differentiate itself from sibling tools like wb_todo_done or wb_todo_tag, though the edit verb makes the distinction mostly inferable.

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

  Usage Guidelines4/5

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

  The description provides concrete invocation context: at least one editable field must be provided, and the write operation requires confirm:true. It does not explicitly name when to use this tool versus siblings, but the conditions for calling it are clear and actionable.

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

• wb_dev_taskA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the safety disclosure burden. It does disclose that the domain contains write operations, that writes require confirm, and that concurrent checking is serialized — useful traits not in the schema. It still omits the effect of writeback on existing state, return format, and any permission/error behavior, so it is only partially transparent.

  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 compact: it fronts the domain purpose, then adds the two most important operational constraints (confirm requirement and serial queue). Minor redundancy exists in the final parenthetical '本域含写操作' which restates the write-operation warning.

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

  Completeness3/5

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

  The description plus a well-covered schema is usable for basic invocation of dev-task commands. However, no output schema exists and the description does not explain return behavior, enumerate the full allowed command set, or clarify how the generic tool relates to the specialized wb_dev_task_* siblings, leaving gaps for a complex multi-command domain.

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

  Parameters4/5

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

  Schema description coverage is 100%, so the baseline is 3, but the description adds real parameter meaning: it enumerates the dev-task command family (list/show/create/stage/item), which the schema explicitly refers to as the source of allowed first words. It also reinforces the write/confirm relationship for the confirm parameter.

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

  Purpose4/5

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

  The description clearly identifies the tool as the dev-task command family/domain and lists representative subcommands (list/show/create/stage/item), which is more specific than a tautology. However, it does not distinguish the generic wb_dev_task wrapper from the sibling specialized tools wb_dev_task_create, wb_dev_task_stage, and wb_dev_task_item.

  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?

  It implies usage context: this tool is for dev-task pipeline commands, and warns that writes require confirm. But it gives no explicit when-to-use vs alternatives, no exclusions, and no guidance about preferring the specialized sibling tools for create/stage/item.

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

• wb_finA
  3.5/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the disclosure burden and does state the key behavioral trait: write operations require confirm=true ('含写操作需 confirm') and the domain contains write operations ('本域含写操作'), warning the agent about mutation risk. However, beyond the confirm gate it says nothing about return format, error behavior, or side effects, and part of the disclosure duplicates the schema's confirm parameter description. The additive context is useful but thin.

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

  Conciseness5/5

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

  One compact sentence that front-loads the most important routing fact ('财务域') before scope enumeration and the safety requirement. There is zero filler; every element earns its place.

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

  Completeness3/5

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

  For a 3-parameter dispatcher with a fully documented schema, the description covers domain identification, scope, and the confirm safety gate, which is sufficient for correct routing. It lacks example fin-domain command strings (the schema examples are todo-domain) and any hint about output format, and with no output schema or annotations those gaps are not filled elsewhere. The essentials for selecting and invoking the tool are present, but not much more.

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

  Parameters3/5

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

  Schema description coverage is 100% — command, args, and confirm each have detailed documentation including usage examples and the args-vs-command precedence rule. The description adds no parameter-level detail beyond labeling the domain, so the baseline 3 applies.

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

  Purpose4/5

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

  The description clearly identifies this as the finance-domain command family ('财务域：fin 命令族') and enumerates concrete sub-resources (账户/流水/分类/预算/目标/订阅), which tells an agent what domain it operates on and distinguishes it from sibling domain tools like wb_todo and wb_dev_task. As a command dispatcher it lacks a single action verb, but the domain label plus resource range make its purpose unambiguous enough.

  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 domain label implies finance commands should be routed here while sibling tools cover their own domains, but the description never explicitly names alternatives or states a when-not-to-use condition. The schema adds that each domain's allowed first word lives in the tool description, and 'fin 命令族' marks that boundary. This is implied routing context, not explicit guidance.

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

• wb_addA
  3.6/5.0
  Behavior3/5

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

  The description discloses an important behavioral trait: this is a write operation requiring confirm:true, which is a safety gate. It also explains that type skips AI classification, adding behavioral context. However, with no annotations provided, the description carries the full burden, and it does not mention side effects, whether the operation is reversible, or what happens on success/failure. Still, the written-operation requirement is clearly disclosed, so a 3 is appropriate.

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

  Conciseness4/5

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

  The description is compact, front-loads the main purpose, and packs useful information about parameters and the confirmation requirement into a few sentences. It is slightly dense with inline parentheses, but every sentence earns its place and there is no waste.

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

  Completeness3/5

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

  The tool is a write operation with a pass-through schema and no output schema. The description covers the core entry behavior, the confirmation gate, and the type parameter's role. It lacks explicit return-value or error-handling context, but for a simple add operation with a fully self-described schema, this is adequate. The absence of annotations raises the burden but the description handles most of it.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all three parameters. The description repeats the text and type semantics but adds the hint about prefixes like 修复/优化/闪念/日程 guiding classification, which is useful. It does not add much beyond the schema for type or confirm, so the baseline 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool's verb and resource: it performs 全类型录入 (all-type entry) and routes entries to different tables such as 待办/闪念/bug/日程/成长. It distinguishes itself from siblings like wb_todo or wb_idea_add by being the general entry point with AI-routed classification. However, it does not explicitly name sibling alternatives to differentiate from, though the purpose is clear enough.

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

  Usage Guidelines4/5

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

  The description provides explicit guidance on when to use the tool: for general entry when AI classification is desired, and when to use the type parameter to force a specific type. It also mentions the CLI equivalent, which aids discoverability. It does not explicitly say 'use wb_todo for todos' but the routing behavior is implied and the type parameter allows selecting specific tables, giving clear context for usage.

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

• wb_manageA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the safety burden: it explicitly flags that the domain contains write operations and that confirm is mandatory. It doesn't describe effects, errors, or return behavior, but the confirm gate is the most important behavioral trait.

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

  Conciseness5/5

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

  Two tight sentences front-load the command inventory and follow with the safety caveat. Every phrase earns its place; there is no filler or repetition.

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

  Completeness3/5

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

  The description plus schema is almost sufficient to construct a valid call, and the confirm gate is clear. But with no annotations and many sibling tools, the boundary between wb_manage and specialized add/done/key tools remains implicit, so an agent may struggle to decide between them.

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

  Parameters4/5

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

  The schema already covers 100% of parameters, and the command parameter description explicitly points to the tool description for allowed first words. The description supplies those command words (add/done/key), which adds meaning beyond the schema.

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

  Purpose4/5

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

  The description identifies a concrete management domain with specific sub-operations: add (all-type entry with AI classification), done (tagging), and key (API key issuance/list/revocation). It is actionable and coherent, but it doesn't explicitly distinguish wb_manage from specialized siblings like wb_add or wb_note_add.

  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?

  It states that write operations require confirm and that key operations are better performed directly in a terminal, which is useful context. However, it doesn't explain when wb_manage should be chosen over the many sibling tools that cover add/edit/done/tag operations.

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

• wb_dev_task_stageA
  3.8/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full behavioral burden, and it does disclose the critical mutation trait: '写操作须 confirm:true' flags that this is a write operation gated by a confirmation flag, and '内容写入步骤' clarifies that file content is committed into the step. It omits idempotency and error behavior, but the core write-plus-confirmation disclosure is explicit and sufficient for safe invocation.

  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 efficient: one front-loaded sentence stating purpose and mandatory usage, followed by a tight parameter listing. Every clause earns its place, and the critical safety note ('写操作须 confirm:true') is placed at the end. Minor redundancy exists because the parameter list duplicates a fully-covered schema.

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

  Completeness3/5

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

  For a 7-parameter write tool with no annotations and no output schema, the description covers what the tool does, when to call it, all parameters, and the confirmation safety gate. What is missing is any statement about the return value, success indication, or error behavior — an agent cannot tell what a successful write-back looks like since no output schema exists to fill that gap.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description enumerates all seven parameters compactly (e.g., 'status(步骤状态（缺省 done）)') and marks required ones with asterisks, but this largely mirrors what the schema already documents. The only marginal addition is clarifying that the file parameter's content gets written into the step, which the schema's own description already states.

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

  Purpose4/5

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

  The description states a specific action — 回写 (write back) a step in the nine-step development chain — and adds a mandatory-use framing ('每完成一步必须回写') plus a CLI mapping ('对应 CLI：dev-task stage'). This makes it identifiable as the stage-progression tool distinct from creation-oriented siblings like wb_dev_task_create, though it does not explicitly name sibling alternatives.

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

  Usage Guidelines4/5

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

  The parenthetical '每完成一步必须回写' gives a concrete trigger condition: invoke after each of the nine chain steps completes, which is clear contextual guidance. The CLI mapping reinforces the intended invocation path. However, it stops short of explicitly contrasting with overlapping siblings such as wb_dev_task or wb_dev_task_item, and states no exclusions.

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

• wb_schedule_addA
  3.8/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the burden. It discloses that this is a write operation and requires confirm:true as a safety gate, which is critical for agent behavior. However, it does not describe return values, failure modes, or side effects beyond creation. The disclosure of the confirm requirement is a positive, but the description could be richer.

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

  Conciseness4/5

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

  The description is concise, with a single opening sentence stating purpose and a parameter list. It front-loads the core functionality. However, the parameter list duplicates the schema, which is redundant, but the overall length is appropriate.

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

  Completeness3/5

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

  For a write operation with no output schema, the description covers the essential purpose and the confirm requirement. However, it lacks sibling differentiation and does not specify behavior when confirm is false or what the response contains. Given the complexity and the presence of many similar add tools, this is a notable gap.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameters. The description repeats the parameter list but adds minimal extra meaning, such as highlighting the natural language capability and the explicit time format. It does not compensate beyond the schema, so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool adds a schedule (新增日程) and mentions natural language or explicit time input. It also maps to the CLI command 'schedule add', making the purpose unambiguous. The resource and verb are specific, distinguishing it from generic add tools by its focus on schedules.

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

  Usage Guidelines3/5

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

  The description implies usage for schedule creation but does not explicitly state when to prefer this over sibling add tools like wb_add or wb_todo_add. It provides no exclusions or conditions. The mention of the CLI equivalent is helpful but doesn't offer selection guidance.

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

• wb_note_addA
  3.9/5.0
  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 discloses that the tool writes to the capsules table, preserves spaces and newlines in content, auto-parses hashtags, and enforces a confirm:true safety gate. It does not describe return values or failure modes, but the key side effects of this write operation are well covered.

  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 compact and front-loaded: it states the action first, then the target, CLI mapping, parameters, and required confirm flag. Minor redundancy exists because '#标签 自动解析' appears twice and the parameter sentence largely restates the schema, but there is no significant filler.

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

  Completeness4/5

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

  For a simple two-parameter note-add tool, the description covers required content, confirm requirement, storage behavior, and tag parsing. It lacks an explicit return/error description and there is no output schema, but an agent has enough information to correctly select and invoke the tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description repeats the content and confirm semantics already present in the schema without adding new parameter-level meaning beyond what structured fields already provide.

  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 writes a note ('写笔记') and identifies the target table ('capsules 表'), making the core action and resource unambiguous. It also gives the CLI mapping 'note add', which reinforces the add semantics. However, it does not explicitly differentiate itself from siblings like wb_note_edit or wb_add.

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

  Usage Guidelines4/5

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

  The description provides clear operational context: it is a write operation, requires confirm:true, and corresponds to the CLI command 'note add'. It does not, however, name alternative tools or state when not to use it, so it lacks explicit exclusion guidance.

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

• wb_queryA
  4/5.0
  Behavior2/5

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

  With no annotations, the description must carry the full behavioral burden. It does disclose read-only safety, which is useful, but this is contradicted by the confirm parameter description stating that write commands like add/done/edit/del can be accepted with confirm=true. This internal contradiction leaves agents unable to trust whether writes are truly impossible.

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

  Conciseness5/5

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

  A single dense sentence front-loads the core purpose ('全域只读调阅'), then packs in command families, covered domains, and the doctor self-check role. There is no filler or repetition; every clause contributes actionable information.

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

  Completeness4/5

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

  For a broad tool with no output schema and no annotations, the description covers scope, command families, domains, and safety posture remarkably well. The main gap is the unresolved read-only vs. confirm/write contradiction, plus the absence of any return-format or error-behavior notes, but the rich input schema compensates for most invocation details.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3, but the main description adds meaning beyond the schema by enumerating the valid command families and the data domains they map to. This directly helps agents construct the command parameter, which the schema itself points back to via '各域允许的首词见 tool description'.

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

  Purpose5/5

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

  The description opens with '全域只读调阅' (global read-only retrieval), states the exact verb and resource scope, and lists the command families plus the 49-table AI-workbench coverage. The read-only framing clearly distinguishes it from the write-oriented sibling tools even though no sibling is named.

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

  Usage Guidelines4/5

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

  The description makes the primary usage context clear: use this tool for cross-domain read-only retrieval across the AI workbench, with doctor for environment self-checks. It does not explicitly name alternatives or say 'do not use for writes,' but the read-only scope is a strong implicit exclusion.

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

• wb_todoA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It clearly states that write operations require confirm and that this domain contains write operations, which is a critical side effect. However, it doesn't describe what happens on success/failure or further side effects of dispatched commands, leaving some ambiguity.

  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 moderately lengthy but well-structured, using clear separations for each parameter. It contains no fluff; every sentence adds value (e.g., long-text recommendation, confirm gate). It could be slightly more compact, but it remains efficient.

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

  Completeness4/5

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

  Given the sibling tools, this description sufficiently establishes the tool as a general dispatcher for the todo domain. It mentions the domain and confirm mechanism but doesn't enumerate all possible subcommands; however, the sibling list implies that specialized tools handle those, making this context adequate.

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

  Parameters5/5

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

  The description thoroughly explains all three parameters with concrete examples (e.g., command string vs. args array, confirm boolean). It adds meaning beyond the schema by clarifying precedence (args takes priority) and providing real usage examples for each parameter. Coverage is 100% with additional practical context.

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

  Purpose4/5

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

  The description clearly identifies this as a domain dispatcher for todo, capsule, idea, bug, book, and schedule commands, with operations like list/detail/complete/edit/tag. It conveys the tool's role as a general entry point for this domain, though it doesn't explicitly name a single verb like 'execute' or 'manage'.

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

  Usage Guidelines4/5

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

  The description provides practical guidance: it highlights the confirm requirement for write operations, recommends the args array for long text to avoid shell splitting, and explains the command vs. args precedence. It doesn't explicitly contrast with specialized sibling tools, but the domain scope makes the intended use clear.

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

• wb_idea_addA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden. It discloses that this is a write operation requiring confirm:true ('写操作须 confirm:true'), that it bypasses AI classification, and that title defaults to the first 30 characters of raw. It does not describe return behavior, but the key side-effect and safety gate 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/5

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

  The whole description is one compact, front-loaded line: purpose first, CLI mapping second, parameters and safety third. There is no filler; the CLI reference is brief and potentially useful for users familiar with the CLI.

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

  Completeness4/5

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

  For a simple three-parameter write tool with no output schema and no annotations, the description is sufficient to call it correctly: raw is required, title is optional with a defined default, and confirm must be true. The only notable omission is what the tool returns after success, which is secondary for such a direct add operation.

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

  Parameters3/5

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

  The input schema already covers all three parameters (100% coverage), so the baseline is 3. The description's parameter list largely restates the schema: raw is required, title has a default, and confirm is a safety gate. It adds no meaningful semantics beyond the schema, though the raw* marker is a useful summary.

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

  Purpose5/5

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

  The description opens with '直录 AI 点子（不经 AI 判类）', using a specific verb (直录) and resource (AI 点子), and explicitly distinguishes this tool from an AI-classification workflow. The '对应 CLI：idea add' further anchors the operation.

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

  Usage Guidelines4/5

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

  The parenthetical '不经 AI 判类' gives clear context: use this tool when an idea should be recorded directly without AI categorization, and not when classification is desired. It does not name a sibling alternative explicitly, so it stops short of full when/when-not/alternative guidance.

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

• wb_todo_delA
  4.2/5.0
  Behavior4/5

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

  没有任何注解，描述承担了行为披露责任。它明确说明了破坏性结果（不可恢复）和安全门（confirm:true），这对删除类工具至关重要。但未说明 id 前缀匹配到多个待办时的行为、返回结果或权限要求，略有不完整。

  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?

  描述极其精简，先用“不可恢复，慎用”突出关键风险，再以简短句说明 CLI 对应、参数和安全要求。每句话都有信息量，没有冗余内容。

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

  Completeness4/5

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

  作为简单的删除工具，描述覆盖了用途、不可逆性、参数和确认要求，配合完整 schema 已足够支撑调用。但没有提及 id 前缀匹配多个待办时的处理方式，也没有输出说明，在无 output schema 的情况下略显不足。

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

  Parameters3/5

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

  Schema 描述覆盖率达到 100%，id 和 confirm 的说明都已存在于输入 schema 中。描述中的“id 前缀”和“写操作须 confirm:true”基本是对 schema 信息的重复，没有提供额外语义，因此维持基线 3 分。

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

  Purpose5/5

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

  描述以明确的动词“删除”和资源“待办”开头，并附加“不可恢复”的警示，核心用途一目了然。与兄弟工具 wb_todo_done、wb_todo_edit、wb_todo_tag 相比，删除语义和不可逆性足以区分。

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

  Usage Guidelines4/5

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

  描述明确说明这是删除操作、不可恢复、需谨慎使用，并且写操作必须传 confirm:true，提供了关键使用约束。但没有显式说明何时应使用删除而非 wb_todo_done（标记完成），因此未达到满分。

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

• wb_vaultA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the safety burden and does so by explicitly stating 'read-only safe' and 'readonly profile'. It also discloses the backing store and index, which helps set expectations about data scope. It omits return/output details, but for a read-only lookup tool this is acceptable.

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

  Conciseness4/5

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

  The description is compact and front-loaded with the key identity and restrictions. Some incidental context (P1, dt_iy2eek, 'Liu's 5-year history') adds flavor but is not wasteful enough to drop the score.

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

  Completeness4/5

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

  For a read-only CLI-family wrapper, it covers the essential context: allowed commands, safety, data source, and a usage example. It lacks an explicit statement about not using write-oriented confirm, but the read-only framing makes that inference straightforward.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3, but the description adds the allowed first-words for the command parameter ('vault list/search/read') plus concrete invocation examples. This is meaningful beyond the generic schema text.

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

  Purpose5/5

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

  The description names a specific verb/domain ('vault list/search/read command family'), the resource (Obsidian cloud md), and labels it a read-only domain, which clearly separates it from the sibling wb-* tools. The example command chain further anchors 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 Guidelines4/5

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

  It clearly scopes usage to vault list/search/read and marks the tool as read-only, so an agent knows when it applies. It does not name sibling alternatives or explicit when-not-to-use conditions, but the command-family restriction is a clear contextual guide.

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

• wb_note_editA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden and does so responsibly: it flags that this is a write operation requiring confirm:true and notes that body edits trigger tag re-parsing. It could disclose more about overwrite behavior, but the core side-effect and safety information is present.

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

  Conciseness5/5

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

  A single compact sentence front-loads the purpose, then packs CLI mapping, parameter meanings, and safety requirements with no filler. Every clause carries useful information.

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

  Completeness4/5

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

  For a four-parameter mutation tool with no output schema, the description covers purpose, modes, parameter meaning, and confirmation. The main gap is not explicitly stating whether file and title are mutually exclusive or whether at least one of them must accompany id, but the mode phrasing makes this inferable.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3; the description adds value by mapping file to 'new body with tag reparse', title to 'only change title', and confirming the mandatory confirm:true safety gate. It still leaves id-prefix semantics mostly to the schema, but that is acceptable.

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

  Purpose5/5

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

  The description leads with a specific action and resource ('改笔记' – edit note) and names two concrete modes: replacing the body with tag re-parsing, or changing only the title. This clearly separates it from note-adding siblings like wb_note_add and read-only tools like wb_query.

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

  Usage Guidelines4/5

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

  It gives clear context: use when an existing note needs its body or title modified, with explicit mode selection. It does not explicitly name sibling alternatives or state when not to use it, but the edit-versus-add/query distinction is strongly implied.

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

• wb_todo_tagA
  4.4/5.0
  Behavior4/5

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

  The description discloses that this is a write operation requiring confirm:true, which is a key behavioral trait. It does not mention side effects beyond tag modification, but given the absence of annotations, this level of transparency 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/5

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

  The description is concise and well-structured, presenting the purpose, CLI counterpart, and parameter semantics in a single sentence plus a parameter list. No unnecessary words or repetition.

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

  Completeness4/5

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

  Given the absence of an output schema, the description sufficiently covers purpose, usage, and parameters. It does not detail error handling or return values, but for a simple tag modification tool this is not a significant gap.

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

  Parameters4/5

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

  The schema already covers all parameters with descriptions, so baseline is 3. The description adds the constraint 'at least pass add or del' and clarifies the id as a prefix, which provides extra semantic value beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: adding/removing tags on todos. It specifies the CLI counterpart and distinguishes itself from sibling tools like wb_todo and wb_todo_done by focusing specifically on tag operations.

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

  Usage Guidelines4/5

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

  It explicitly states the requirement to pass at least 'add' or 'del', and mentions that write operations require confirm:true. This provides clear guidance on when to use the tool, though it does not explicitly contrast with sibling tools.

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

• wb_archiveA
  4.6/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and handles it well: it explicitly declares the tool is read-only safe and visible in readonly profiles. It also discloses non-obvious behavior such as 'detect' falling back to material summaries when no LLM is available and 'gen' being a passthrough script.

  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 dense but well-organized, using semicolon-separated subcommand definitions and one clear usage sentence. It avoids fluff, though the opening parenthetical 'P4 · dt_mkq335' adds some domain jargon that could be trimmed without losing functional meaning.

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

  Completeness5/5

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

  For a multi-subcommand read-only tool with no output schema and no annotations, the description is remarkably complete: it covers all subcommands, their semantics, an example, the critical read-only guarantee, and a concrete situational use case. Nothing essential for selecting or invoking this tool is missing.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds meaningful value beyond the schema by specifying the valid first words for the command parameter (archive list/show/gen/detect) and giving a concrete invocation example. The args and confirm parameters are already fully documented in the schema.

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

  Purpose5/5

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

  The description clearly identifies the tool as the read-only memory archive domain and enumerates the exact command family (list/show/gen/detect). It also provides concrete examples like 'archive show 顾铭' and distinguishes itself from sibling write tools by stating '只读安全' and 'readonly profile 可见'.

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

  Usage Guidelines4/5

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

  The description gives explicit usage context: '会话开场可 archive list 查看、archive show 读取' tells the agent when to invoke the tool. It also explains each subcommand's purpose. However, it does not explicitly state when not to use this tool or name alternative sibling tools.

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