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

The description goes beyond the annotations by explaining that only provided attributes are changed, that a before/after diff is returned per touched attribute, and the all-or-nothing rejection behavior for blocked_by. The destructiveHint is true but the description clarifies the partial-update nature so the agent knows it is not a full overwrite. It doesn't mention permissions or rate limits, but the key behavioral traits for a mutation are disclosed.

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?

Four sentences, each earning its place: purpose, partial-update semantics, return value, and dependency-specific behavior. Front-loaded with the main action and scope.

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?

The description covers the critical aspects: piece types, partial update, return value, and the nuance of blocked_by. With no output schema, the description explains the return briefly. However, it doesn't mention that some attributes are type-specific (Epic-only for_errors, Task-only task_type_code) which is in the schema but could be highlighted. Still, the schema covers it, so the description is sufficient for correct invocation.

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 all 12 parameters thoroughly. The description adds the concept of additive blocked_by links and that they are refused if already linked, which is not in the schema's description. For the other parameters, the description doesn't add 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.

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

The description states a specific verb (Update) and resource (Task/Story/Epic/Recurent piece) and identifies the key (relative_id). It distinguishes itself from CreatePieceTool and the read siblings by naming the exact piece types and the update semantics.

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?

The description makes clear that it updates existing pieces and that only passed attributes change, implying partial-update semantics. It also points to ManageBlockerLinksTool for removal of blocking links, which is a clear alternative for that sub-operation. However, it does not explicitly say when to prefer this over ManageBlockerLinksTool for adding links (though the schema for blocked_by explains it).

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