agent_task_upsert

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

No annotations, so the description carries the full behavioral burden. It does add real context the schema lacks — that verify_cmd must be run before ticking, and that the item is session-scoped — but it says nothing about update semantics (overwrite vs. merge of omitted fields), required permissions, or error behavior for a mutation tool with 9 params.

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?

Front-loads the create/update distinction and the trigger in a compact block. One sentence — 'This productizes the vibe goal-file checklist' — is internal jargon that earns no place and costs clarity, but the rest is tight.

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 9-parameter, no-annotation, no-output-schema mutation tool, the usage and routing story is complete but the mutation contract is not: what an update does to unset fields, whether status transitions are validated, and whether subtask creation requires an existing parent are all unstated.

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 coverage is 100%, so the schema already documents task_id, parent_task_id, title, and the rest; the baseline of 3 applies. The description's gloss on verify_cmd ('names HOW the item is proven done') adds intent but not syntax, and its create-vs-update rule repeats the task_id schema text.

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 pair and resource ('Create or update one checklist item in a session's task tree') and immediately disambiguates the two modes via 'Omit task_id to create; pass task_id to update.' It also names the sibling goal_add and the condition that distinguishes them, so an agent can route without opening schemas.

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?

Explicit when-to-use ('call at the START of a tracked piece of work'), when-not ('ignore unrelated casual chat'), and the alternative for the cross-session case ('use goal_add on the board instead'). This is a full routing rule, not an implication.

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