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

Annotations already declare destructiveHint=true and non-idempotent, so the safety bar is partly met. The description adds genuinely non-structured context: list items behave like tasks and the list name should be passed as `kind` in downstream tools — a cross-tool behavioral fact an agent could not infer. It does not restate the force/refusal semantics (those live in the schema) or explain permissions.

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 operations before the disambiguation. The compression is aggressive — 'list shows them all' and 'pass its name as kind' are dense enough to need a second read — but nothing is wasted.

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?

With six optional parameters and no output schema, the biggest operational fact — that a call should carry at most one of add/rename/remove, with `to` only paired to `rename` — is stated nowhere, though the schema hints at it. Purpose and cross-tool behavior are covered, so it is serviceable but leaves the call shape to inference.

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 83%, so the schema already explains to/add/remove/rename/project and the force escape hatch. The description adds only the 'pass its name as kind' hint, which concerns how the list identifier is reused elsewhere rather than clarifying this tool's own parameters. Baseline 3 is appropriate.

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?

Names three specific verbs (add, rename, remove) applied to a specific resource (the human's own lists such as ideas/bugs), and explicitly contrasts it with 'a heading in the backlog', which maps to the `section` sibling. The pointer 'list shows them all' further disambiguates it from the `list` tool. It loses a point only because the telegraphic phrasing ('lists of your own') takes a moment to parse.

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?

Gives a concrete trigger ('when they ask') and an explicit non-use case (don't do this for a heading in the backlog, i.e. use `section`), plus routes enumeration to `list`. No mention of when to use `add`/`tick` instead once the list exists, so it stops short of full alternative coverage.

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