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

Annotations only cover the safety/idempotency profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=false); the description adds real behavioral context beyond them: no HTML/arbitrary files/remote URLs accepted, asynchronous pending-export semantics, retry-after throttling, and same-key retry discipline.

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?

Front-loaded with the trigger ('Use when...') followed by exclusions and operational rules; four dense sentences with little waste. The clause 'This is a resume export service' is mildly redundant restatement of the name, the only dead weight.

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?

For an async export with no output schema and four required params, the description supplies the essential operational loop (submit with idempotency key, poll via status, honor retryAfterSeconds) and input restrictions. It does not say what the submission returns (e.g., an export id) or what a terminal failure looks like, which would fully close the loop.

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?

With 0% schema description coverage the description must carry the load, and it does: 'PDF and/or DOCX' maps to formats, 'exact saved version' implies expectedVersion, 'selected resume' implies resumeId, and idempotency key reuse is stated explicitly. It never names expectedVersion or explains version mismatch behavior, which is the remaining gap on a 4-required-param tool.

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 and resource ('PDF and/or DOCX rendered by Bespree from the exact saved version and template of a selected resume') and draws a boundary against host-rendered files. It stops short of naming sibling tools like get_export_status or list_resume_versions for adjacency, so sibling differentiation is only partial.

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?

Explicit when-to-use ('user wants PDF and/or DOCX rendered by Bespree from the exact saved version') and when-not ('Do not call for a file the user wants your host to create in its own layout'), plus operational guidance to reuse the idempotency key, check status for pending exports, and honor retryAfterSeconds.

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