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

Annotations only declare that this is a non-read-only, non-destructive, closed-world write; the description adds real value beyond them — the accepted file formats (PNG, JPG, SVG, PDF), the 25 MB ceiling, the two-line text cap, and idempotency semantics for retries. Gaps remain around whether the design persists in the account, whether creation is billable, and what happens on a failed preflight.

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, with the core action stated first and return values, file constraints, and the idempotency caveat ordered by importance. Every clause carries information an agent needs before calling.

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 does the right thing by enumerating what comes back (design_id, design_version, preflight result, mockup_url). The nested artwork object and its constraints are covered; the main remaining gap is failure behavior and post-creation lifecycle, which matters for a mutating tool with a preflight step.

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 50%, and the description fills part of the hole by explaining the artwork payload's accepted formats and size limit and by explaining when idempotency_key is honoured. It adds nothing about colour, coverage, or blank_shape_id beyond what the schema already says ('From list_cups'), so a few parameters still rely on the enum/schema alone.

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 concrete verb and resource plus the scope of the payload: placing a customer's logo and up to two text lines on a cup. It also names the outputs (design_id, design_version, preflight, mockup_url), which separates it from read-only siblings like get_mockup and search_designs, though it never names an alternative explicitly.

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 description implies prerequisites via the schema (blank_shape_id, colour, coverage come from list_cups) and specifies that only partner agent keys may pass idempotency_key. There is no explicit 'use this when…' or 'do not use this for…' guidance, and no mention of what to do when the preflight check fails.

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