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

Annotations already mark it as read-only and idempotent; the description adds the critical non-recoverable behavior after expiry or restart and clarifies it may return pending status. It also provides extra context by listing operations it does not perform, which goes beyond the annotations.

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 sentences with no waste: main action first, exclusions second, and the expiry caveat last. Every sentence earns its place.

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?

Given the output schema and strong annotations, the description covers the core retrieval contract, including pending status and non-recoverability. It lacks explicit parameter semantics, but that is accounted for separately, and the remaining usage conditions are adequately specified.

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 0%, so the description should compensate, but it only says to pass the 'exact operation capability received before upload' without explaining what result_handle and result_token mean. The agent must infer their semantics from names and schema patterns, which is insufficient.

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?

Clearly names the action (Retrieve) and object (analysis result or pending status), and the phrase 'using the exact operation capability received before upload' defines the scope precisely. The negative list differentiates it from sibling analysis/OCR tools rather than merely restating the title.

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?

Describes when to use it (after upload, with the operation capability) and what it does not do (upload, analyze, call OCR, renew expiry, prove identity), which routes an agent away from the sibling tools. It does not explicitly name the alternatives, so some inference remains.

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