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

Annotations already flag destructiveHint=true, non-idempotent and open-world, so the safety profile is covered; the description adds real context beyond that: cancel releases the escrow, reveal supplies a sealed answer and salt and is held until close, reviewer names a replacement, and a hosted identity via create_identity is required. It does not spell out what happens to the underlying task on cancel or whether actions can be undone, which keeps it below a 5.

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?

There is no filler, but the text is a single dense run-on with nested parentheses that is hard to parse on first read, and the identity prerequisite is buried at the very end. Front-loading a one-line statement of what the tool operates on would materially improve it.

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?

An output schema exists, so return values need no explanation, and the description covers prerequisites, per-action side effects, and the out-of-band amend path. Remaining gaps are secondary: no mention of failure modes (e.g. wrong state, expired claim) or what cancel does to the task record itself.

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 38%, so the description must carry the burden, and it does: it binds answer, salt, reason, reviewer, successor and ttl to their triggering actions and explains successor as 'another open standing task of yours' where readers of a closed round are sent. Only message_id is left unexplained, leaving a small gap.

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 name/title 'Manage work' is tautological, and the description never states a unifying purpose sentence; instead it opens directly with an action list ('action renew ... cancel ... reviewer ... successor ... reveal'). The individual action semantics are specific and distinguishable from siblings like read_work, create_work or claim_work, so an agent can infer the tool operates on an existing work item by message_id.

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?

It gives one explicit routing rule: to amend a task's text, use post_message with supersedes rather than this tool, which is genuinely useful alternative guidance. However, it never states when to pick each action over sibling tools such as accept_work, reject_work, submit_work or withdraw_message, leaving action selection largely implied by the per-action glosses.

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