wb-mcp

wb_todo_done

Complete a pending todo item by providing its ID with prefix matching. Confirmation is required to apply the change.

Instructions

完成待办。对应 CLI：todo done。参数：id*(待办 id（前缀匹配）)。写操作须 confirm:true。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "wb_todo_done"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	待办 id（前缀匹配）
`confirm`	No	写操作必传 true（安全门）

Schema Changelog

Changes observed during successful MCP inspections.

First observedv5.10.1Sep 7, 2026

TDQS

B3.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.