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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely new behavior — the report is free/built-in and performs no artwork analysis — but the phrase 'never pays' is ambiguous (no cost to caller vs. no payout) and nothing is said about whether the sample is static fixture data or tied to a real account.

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?

Two tight sentences with the core constraint ('does not analyze your artwork') front-loaded after the resource. The trailing 'never pays' is vague enough that it spends words without fully earning them, but overall there is no padding.

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?

This is a simple single-parameter read-only tool with no output schema, so the bar is low. Still, an agent cannot tell from the description whether the returned sample is identical regardless of account, how it differs from a real prepare_* report, or what the enum values refer to — details that matter for deciding to call it.

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 0% for the single required 'service' parameter, so the description must carry the meaning, yet it only says 'for one service.' It never explains that the value selects which sample report to return or that valid values correspond to the services listed by list_print_qa_services, leaving the enum to speak for itself.

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 identifies the resource as a 'free built-in sample report for one service,' which pairs with the tool name to convey retrieval of a demo report. It lacks an explicit verb ('returns/get') and never states that the report is static/illustrative sample data rather than real analysis output, leaving the core purpose only implied.

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 clause 'Does not analyze your artwork' implicitly tells the agent this is not a substitute for the prepare_* siblings, which is useful when-not guidance. However, it never names those alternatives or states the positive condition for calling it (e.g., 'use to preview report format before running prepare_preflight').

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