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

Beyond the readOnlyHint annotation, the description adds that the output is a set of page images in order, and that it exposes rendering quality issues. It also discloses the availability precondition. This is useful behavioral context, though it does not detail response format or page-count behavior.

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?

The description is a single substantive sentence followed by a necessary availability condition. Every clause earns its place, and the inspection-purpose is front-loaded before the workflow instruction.

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 simple 2-parameter, read-only visual inspection tool, the description gives the output type, ordering, the availability gate, and the recommended follow-up action. It lacks explicit return-value details, but the absence of an output schema makes the current level mostly sufficient.

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 50%, with guest_token documented but deck_id not. The tool description provides no additional meaning for either parameter, such as clarifying that deck_id must refer to a submitted deck. The precondition indirectly implies which deck to pass, but that is not enough to compensate for the gap.

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 clear verb and resource: the tool returns the deck's rendered pages as images, page 1 first. It also frames the purpose as visual QA (checking overlap, clipping, spacing), which distinguishes it from sibling tools like submit_deck and create_deck.

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 says the tool is 'available once the deck has been submitted' and prescribes a follow-up workflow: inspect the images, fix the file, then call submit_deck again. It does not explicitly list when not to use it, but the precondition and workflow give clear enough context.

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