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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavior: no credits are reserved, no artwork is uploaded, workspace authentication is required, postcards default to full color while letters default to B&W, and composed previews use the first recipient. The postcard proof vs artwork distinction is a non-obvious side effect that would otherwise surprise an agent.

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 core purpose and the body-vs-PDF constraint are front-loaded, and most sentences carry actionable content. It runs long and the postcard proof paragraph is dense, plus a trailing contract URL, so it is efficient but not maximally tight.

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 11-parameter tool with an output schema, the description covers the hard parts an agent would otherwise get wrong: input mode exclusivity, color defaults by mail class, proof-vs-artwork handling, authentication, and the instruction to re-check price. Return values are covered by the output schema, so nothing critical is missing.

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 carries the load: it states that exactly one of a plain-text body or a PDF must be supplied (mutual exclusivity the schema does not encode via oneOf), enumerates the feature flags (Certified, electronic return receipt, color, duplex, coupon, bulk recipients), and explains that only the first recipient is used for composed previews. It leaves filename and the from/recipients field shape undocumented, but those follow from the 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?

Opening sentence states a specific compound verb (render/inspect and calculate price) over a specific resource (letter or small postcard PDF) and immediately delimits scope with 'without sending, reserving credits or uploading artwork'. This clearly separates it from send_letter and the quote siblings.

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?

Gives a clear when-to-use context (preview before send, recheck final price before sending) and an explicit when-not (do not send the proof, only the original artwork or body). It never names the alternative pricing/preview siblings, so an agent must infer preview_letter vs get_letter_quote on its own.

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