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

Annotations already declare the read-only, idempotent, non-destructive, closed-world profile, so the safety burden is lifted. The description adds real behavioral context beyond that: what the payload contains (two sizes per design kind, measurement convention per design type, comparison anchors, range buckets) and the side effect of passing size_cm (it flags which designs meet their minimum).

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, no filler, front-loaded with the usage trigger before the return contract and the optional parameter. Each sentence carries distinct information: when to call, what comes back, what the argument does.

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 read tool with an output schema, the description supplies everything an agent needs: the trigger condition, the scope of the data (eight design kinds), the measurement convention, and the effect of the one argument. Return values are further documented by the output schema, so nothing material is missing.

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% and the schema already defines size_cm as an optional centimetre value, so the baseline is 3. The description earns above baseline by explaining the parameter's actual semantics: it is not just a lookup key but a filter that "marks which designs meet their minimum at that size," which tells the agent what changes in the response.

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 gives a specific resource (a size chart covering eight design kinds) plus the exact shape of the answer: smallest and better size, letters measured by height, other designs by longest side, real-world comparisons, and small/medium/large ranges. This is concrete enough that an agent can distinguish it from check_line_spacing or compare_tattoo_placements without inspecting 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?

It opens with an explicit trigger: "Use when the user asks how big or how small a kind of tattoo can be, or what fits at a given size." That is a clear when-to-use condition covering both the no-argument and size-provided cases. It stops short of naming when not to use it or pointing at a sibling tool as the alternative.

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