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

Annotations already declare this a read-only, idempotent, non-destructive computation, so the safety burden is offloaded. The description adds value by disclosing the shape of the result: long-edge pixel count, fitting quality level, and the maximum print size per level at 300 and 150 dpi reference resolutions.

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 sentences with no filler, and the core conversion is front-loaded. The second clause ('with the largest print each level allows at 300 and 150 dpi') is dense and slightly awkward to parse, but it carries 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?

With five optional parameters, no output schema, and no required field, the description does enough by explaining what the response computes. It does not address what happens if the tool is called with no arguments (all params optional) or that the answer is localized via the language parameter.

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 would be 3, but the description adds real meaning by signaling that width_cm/height_cm/dpi and long_edge_px are alternative input modes ('... or a pixel width'), which the flat schema does not express. The language parameter and the 300 dpi default are left to the schema.

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?

States a specific verb (converts) with a concrete input pair (print size in cm + dpi, or a pixel width) and a concrete output (pixels on the long edge plus the fitting quality level). No sibling tool overlaps this domain, and the name/title are fully realized in the description.

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 trailing clause 'Use for brochures, boards, site hoardings, websites' gives usage contexts but not decision rules. It does not tell the agent when to pass print dimensions versus when to pass long_edge_px, nor when computing resolution is unnecessary, so the guidance is implied rather than explicit.

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