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

Annotations already cover read-only/idempotent/non-destructive, and the description adds genuinely new behavioral facts: check digits are auto-added or verified, output is format-valid but not GS1-registered, and scannability depends on contrast, print size, quiet zone and reader. These are limitations an agent could not derive from structured fields.

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?

Four compact sentences with no filler: capabilities first, then input convention, then exclusions, then caveats. Each clause carries distinct information and the most decision-relevant facts (symbologies, formats, static-only) are front-loaded.

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 no output schema, the description correctly tells the agent what comes back (SVG/PNG/data URL) and sets expectations about validity and scannability. It is nearly complete for an 8-parameter tool, with the only gap being the unaddressed styling and sizing parameters.

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% across 8 parameters, and the description only adds meaning for three of them: symbology, format and data (with its check-digit convention). The bg, fg, size, height and margin parameters receive no semantic guidance in either place, so compensation is partial.

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 opening states the exact symbologies (Code 128, EAN-13, UPC-A, EAN-8) and output formats (SVG/PNG/data URL), so the resource and result are unambiguous. Combined with the title's verb, an agent can distinguish this from the qr_* siblings (2-D) without opening any 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?

"Static codes only: no redirects, no dynamic/editable codes, no scan analytics" gives explicit when-not guidance, and the check-digit rule tells the caller how to supply EAN/UPC data. It stops short of naming qr_generate as the alternative for 2-D codes, so sibling routing is implied rather than stated.

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