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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the no-argument panel flow and the note that the file is read on the user's device — a privacy detail that explains why no server-side upload is needed. It stops short of describing the produced label's format or how the result is surfaced, though the output schema covers return values.

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, front-loaded with the outcome and followed by the routing rule and the guardrail. The first sentence is heavy with stacked examples inside parentheses, which slows scanning slightly, but every clause carries discriminative information.

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 single optional parameter with an output schema, everything an agent needs is present: when to call bare, when to supply qr_text, what the output is (a printable 6x4 label), and the one prohibition that prevents bad input. No relevant gap remains.

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 100%, so the baseline is 3, but the description goes further by constraining qr_text's provenance ('exact decoded text from a QR decoder', 'never transcribe') and explaining the omit case. That is meaning beyond the shape of the string that the schema alone conveys.

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 names a specific verb+resource transformation: converting a Royal Mail QR code into a 6x4 shipping label the user can print. The parenthetical examples (Vinted digital labels, eBay QR codes, ASOS returns, 'Labels to Go') pin down exactly which QR codes are in scope, so an agent knows what this tool is for without touching the schema.

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?

It gives explicit routing rules: call with no arguments when the user has an image or PDF (a file-picker panel handles it), and only pass qr_text when the decoded text is already in hand. It also states a hard exclusion — 'Never transcribe a QR code from an image' — which is the exact failure mode an agent would otherwise fall into.

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