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

Annotations are minimal (readOnlyHint: false, destructiveHint: false), so the description carries the full behavioral burden and delivers: validation of the deck against the brief, automatic repair of small slips, rendering, opening in the editor, and the two return states (ready with editor_url, or importing). This exposes side effects and asynchronous behavior that the structured fields do not.

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, each earning its place: the action, the processing pipeline, and the return contract. The core verb is front-loaded ('Send the complete deck file you wrote') before behavioral details, and there is zero filler or repetition of schema content.

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 a 5-parameter, no-output-schema, asynchronous tool, the description covers the main workflow and return contract, and correctly points to deck_status for polling. It does not disclose failure/error behavior (e.g., what happens if the deck badly fails the brief check) and leaves 'repairs small slips' vague, but the essential invocation and post-call flow are sufficiently explained.

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 80% (only deck_id lacks a description), setting the baseline at 3. The description adds some value beyond the schema—tying 'the complete deck file you wrote' to source and implying the brief-compliance constraint of source—but it does not clarify deck_id, label, guest_token, or the wait_seconds/importing relationship beyond what the schema already states.

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+resource ('Send the complete deck file') and then differentiates itself through a unique pipeline: checks against the brief, repairs slips, renders every page, opens in the editor, and returns ready/importing states. None of the siblings (create_deck, write_outline, deck_status, see_deck) claim this submit-and-import behavior, so an agent can distinguish it without opening schemas.

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?

The description gives clear usage context ('Send the complete deck file you wrote', 'checks it against the brief') implying the tool is used after authoring and after a brief exists. It also explicitly routes to the sibling deck_status with 'then poll deck_status' for the importing case. It lacks explicit when-not-to-use exclusions (e.g., don't call it before create_deck, or before the deck is complete), so it falls just short of the 5 bar.

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