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

Goes well beyond the annotations by disclosing the race outcome, the billing side effect ('Storage remains charged until physical cleanup succeeds'), and the blast radius ('does not delete an existing document or original'). These are exactly the side-effect and post-condition details an agent needs for a destructive-but-idempotent operation, and they are consistent with destructiveHint=true rather than contradicting it.

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?

Three short sentences, front-loaded with the action and its target, followed by the failure mode and the side-effect boundary. No filler and nothing repeated from the schema or annotations.

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 no output schema, the description carries the return-value burden and does so ('read back the saved outcome'). It also covers the key held-state and cleanup caveats; the only shortfall is not explaining the jobId's origin or any authorization requirements beyond 'owned'.

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?

The input schema has 0% description coverage, so jobId is documented only by its UUID pattern. The description supplies semantic context ('owned pending import') implying the id identifies that import job, but never says what the id is or where to obtain it, leaving a real gap for a low-coverage single-parameter schema.

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 a specific verb and resource ('Request cancellation of an owned pending import'), states the ownership scope, and adds that the call reads back the saved outcome. The clause 'does not delete an existing document or original' implicitly separates it from delete_document and shows it operates on the import job, not the document, so the agent can place it among the import siblings without opening the schema.

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?

Tells when this applies: only 'owned pending' imports, and warns that 'Completion may already have won', which signals the race with complete_document_import and that a successful call may still yield a completed job. It stops short of naming the alternative tools or explicitly stating when not to cancel.

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