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

Annotations flag destructive/non-idempotent, and the description adds substantive behavior beyond them: an approval prerequisite, optimistic-concurrency version requirement, a restriction on which steps retry may target, the no-replay rule for completed effects, and the caveat that pause cannot stop an in-flight provider call. No annotation contradiction.

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 tight sentences, front-loaded with the operation set and followed by the constraints that actually govern invocation. Dense but every clause carries an operational constraint; no filler.

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?

No output schema and five parameters, so the description carries weight; it covers approval, versioning, retry eligibility and pause semantics. It omits what a stale version returns and the mechanics of the confirmation_token handshake beyond 'omit on first call'.

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 baseline is 3; the description still adds meaning by explaining that expected_version must be the task's current version and that step_id applies only to retry (failed idempotent local-read step), plus the first-call token flow.

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 specific verbs (pause, resume, cancel, retry) against a specific resource (a durable Operator task), and 'durable' plus 'operator' clearly separates it from pause_agent/pause_campaign and from the read-only get_operator_task/list_operator_tasks siblings.

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 the governing precondition ('after exact approval') and operation-specific conditions for retry, plus the pause limitation. It does not explicitly route the agent to a sibling (e.g., read task state via get_operator_task first), so it falls short of 5.

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