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

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds value beyond that: it discloses the breadth of the returned payload, flags that default_configuration is a prefilled job payload consumable by price_job, and states the commercial/regional context (Australian printing and delivery, AUD, GST-inclusive).

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 intent is front-loaded in the opening clause, but the tool has an output schema, so the long mid-sentence enumeration of every returned field largely duplicates structured data and crowds out the two genuinely useful signals (call before asking the customer, and the price_job handoff). The Australia/AUD/GST sentence reads as cross-tool boilerplate rather than needing to be here.

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?

With a single required parameter, full schema coverage, and an output schema covering return values, the agent has what it needs; the description's real contribution is the workflow framing (read first, feed price_job) which it supplies clearly. Only the missing sibling routing for product_id discovery keeps it from being fully self-contained.

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 100% and there is a single required product_id whose provenance is documented in the schema (from list_products or search_products). The description adds nothing about the parameter — no format hints, no error behavior for unknown ids — so this sits at the baseline for a fully-schema-documented parameter.

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 is specific about the resource (one Printdash product's complete option form) and enumerates its contents in concrete terms — required flags, option ids/labels, defaults, quantity and custom size limits, page counts, finish stock pricing, image, artwork guides, and default_configuration. It implicitly distinguishes itself from list_products/search_products by describing the per-product option form rather than a listing, though it never names those siblings outright.

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?

"Read this before asking the customer anything" is a clear, actionable usage directive that sequences this call ahead of customer interaction, and "ready for price_job" names the natural downstream tool. It lacks explicit when-not-to-use guidance or a direct pointer to list_products/search_products as the source of product_id (that link lives only in the schema).

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