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

With all annotation hints false, the description carries the behavioral burden — and it delivers: it discloses persistence ('uloží' — saves), an upload side effect (returns layers with uploaded URLs), that the surcharge is only indicative ('orientační'), and that the design becomes customer-visible/orderable via the previewUrl. No contradiction with annotations; only validation-failure behavior is left undisclosed.

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?

The description is one dense, run-on compound sentence packing validation, saving, three return values, and a customer-ordering detail. It is front-loaded with the core action, but the structure hurts scannability; splitting into two or three sentences would improve readability without adding length.

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 5-parameter tool with 20% schema coverage, no output schema, and all-false annotations, the description must carry more weight. It explains return values well (needed since no output schema exists) and the workflow, but leaves the required 'product' parameter and other three optional parameters completely unexplained — an agent cannot reliably invoke this tool correctly without guessing their formats.

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 only 20% — four of five parameters (colorId, product, previewBackDataUrl, previewFrontDataUrl) are undocumented in the schema, and the description does not compensate for any of them. The layers parameter has a rich inline schema description, but the tool description itself adds no parameter-level meaning beyond the phrase 'logo/text na stranách trička', which loosely maps to layers content only.

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 states a specific action ('Zvaliduje a uloží design' — validates and saves a design) with a specific resource (logo/text on t-shirt sides). It goes beyond the title 'Připravit design' by detailing what it returns (uploaded layer URLs, surcharge, previewUrl) and clearly positions itself as the preparation step feeding into create_order, distinguishing it from order-creation and quoting siblings.

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?

Usage context is implied through workflow references: the returned layers are 'pro create_order' (for create_order), and the previewUrl lets the customer order from the configurator. This tells the agent this tool precedes order creation, but there are no explicit when-not-to-use conditions or comparisons against alternatives like get_quote or quote_order.

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