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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds behaviour beyond that: it returns region-aware retailer listings, requires no visual input, and rejects a class of editorial queries — useful operational context the annotations do not convey.

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?

Front-loaded with the core use case, then examples, then exclusions — a sensible order. It is on the long side and the example list and negative list partially overlap in spirit, but every sentence carries routing value.

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?

An output schema exists, so return values need not be spelled out, and the description still summarises them as region-aware retailer listings. With scope, exclusions, input-medium constraint, and examples all present for a 5-parameter read tool, nothing needed for correct invocation 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 80%, so the baseline is 3, but the description adds real meaning by mapping natural-language facets (brand/model, budget, colour, size, condition, second-hand, dupe) onto the query/condition/max_price/region parameters and giving composite examples like 'black midi dress under $100'. Only max_results is left entirely 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+resource (find fashion products from text) and enumerates the product categories it covers, so the agent can tell it apart from watch/price siblings. It does not explicitly distinguish itself from the near-identical sibling find_fashion_items, which keeps it short of a 5.

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?

Gives explicit when-to-use (concrete purchase-intent text requests, with concrete examples), an explicit negative list (styling advice, outfit ratings, trends, news, care, beauty, furniture), and an anti-pattern instruction ('Do not ask for a photo when the text already identifies the product'). This is textbook routing guidance.

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