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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so safety is covered by structured data. The description adds genuinely new behavioral context: the catalogue is "live" (real-time data), no design session/state is needed, and it enumerates return content (colours, sizes, print areas, recommendations) despite there being no output schema. Pagination and rate/limit behavior remain unstated.

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?

Purpose is front-loaded in the first sentence and the closing "No design session is required" earns its place. The middle sentence, however, duplicates the query field list already fully documented in the schema, and the description is thin on anything the structured fields do not already say.

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 partially carries the return burden by naming catalogue attributes and recommendations, which is helpful. It still omits pagination/limit semantics, result shape, and any differentiation from choose_product, leaving meaningful gaps for a catalogue-discovery tool with a nested, free-form query object.

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 100% for the single nested query object, and the description merely re-lists the same field names (search, category, fit, quality, country, market, locale, quantity, sort, limit) without adding syntax, defaults, value constraints, or interaction rules. Baseline 3 for high-coverage schema plus a pure restatement.

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?

"Read the live garment catalogue, colours, sizes, print areas and recommendations" gives a specific verb (read) and resource (garment catalogue) plus the payload it covers. It does not, however, explicitly separate itself from the obvious sibling choose_product, so the agent must infer the browse-vs-select boundary.

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?

"No design session is required" establishes a prerequisite/context (usable without start_design_session), which implies this is the pre-session browsing step. But there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. choose_product vs discover_products), so routing is left to inference.

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