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

With no annotations, the description carries the full burden, and it does disclose two useful behaviors: output is a file in PNG (2048 px) or SVG, and each call consumes one QR API request. However, it says nothing about permissions, whether files persist, error conditions, or what the call actually returns.

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?

Only two sentences, so there is little waste, and the quota note earns its place. But the lead sentence is awkwardly constructed ('the QR code file Download makes'), which delays the core message rather than front-loading it cleanly.

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 complex tool: four parameters including a deeply nested design object and a 37-value template enum, with no output schema. The description omits the template-vs-design interplay, defaults, and entirely omits what the caller gets back (a URL, a file object, bytes?), which is a significant hole given no output schema exists.

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 75%, and the schema already explains key semantics like 'Each top-level field replaces the template's' and 'Template id from list_templates'. The description adds nothing about content, format, template precedence, or the deeply nested design object, so it neither compensates for the gaps nor misleads.

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 verb+resource is evident: it makes a QR code file, output as a 2048 px PNG or an SVG. The phrasing 'the QR code file Download makes in the Pretty QR editor' is garbled, but an agent can still infer that this generates a downloadable QR image. It does nothing to distinguish itself from open_in_editor or list_templates.

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?

There is no when-to-use guidance: nothing says whether to call list_templates first, when to pass template versus design, or how this differs from open_in_editor. The only quasi-guidance is the cost note that it counts as one QR API request, which informs budgeting rather than tool selection.

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