update_taskChange a task's title, body, status, or priority. Setting status to 'doing' starts timing; setting it to 'done' stops the clock for duration reports.
Change title, body, status or priority. 'doing' starts the clock, 'done' stops it; that is where report durations come from.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | ||
| model | No | Your model id, e.g. 'claude-opus-5'. | |
| title | No | ||
| status | No | ||
| task_id | Yes | ||
| priority | No |
Changes observed during successful MCP inspections.
v0.1.4Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose a genuinely non-obvious side effect: setting status to 'doing'/'done' starts and stops a duration clock that feeds reports. However, it omits other important behavior such as permission/auth requirements, whether omitted fields are preserved or cleared, and what happens on an invalid task_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the set of mutable fields, followed only by the non-obvious clock semantics. No filler, no restatement of the title or the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter mutation tool with no annotations and no output schema, the definition is only partially complete: it never mentions the 'model' parameter, says nothing about partial-update semantics or error behavior, and does not explain which status transitions are legal from a given state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (just 'model'), so the description must compensate; it names four updatable fields and explains the meaning of two status values. It leaves the 'model' parameter and the meaning of the 1-3 priority range unexplained, and gives no format detail for body/title beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Change') plus the exact mutable fields (title, body, status, priority) of a task, so an agent immediately knows this mutates an existing task rather than creating one. It does not explicitly name sibling alternatives like create_task or get_task, so the differentiation is left to the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the mutation verb and the fact that it edits an already-existing task, but there is no explicit 'use this when X, use create_task when Y' routing and no statement of preconditions or tasks that cannot be updated. The status-transition note is domain semantics rather than when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.