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

Annotations already cover read-only, idempotent, non-destructive and closed-world, so the description adds real value instead of repeating: it discloses AND-matching semantics ("Every query word must match"), what is returned (public offer details plus SecretPass offer page links), and an important limitation ("never voucher codes"). It omits pagination/truncation behavior despite exposing limit and offset.

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?

Four tight sentences, each carrying distinct information: capability, trigger, query-wording constraint, and return content plus the list_filters hand-off. Nothing is repeated from the schema or annotations and the most decision-relevant facts (what it searches, how keywords behave) come first.

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 9-parameter, nested-object search tool with no output schema, the description covers the essentials: what is matched, which facets narrow results, where to get valid slug/value inputs, and what the results contain. Pagination nuances are the only gap and are minor for a read-only search.

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?

With 67% schema coverage and 9 parameters, the description compensates meaningfully: it explains the AND-matching logic behind `query`, prescribes 1-2 short singular keywords, scopes `region` to AU/UK/US, and tells the agent to source `category`, `product_type` and `specifications` values from list_filters. `limit`, `offset` and `business` remain undocumented beyond 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 current shop offers and voucher deals") with explicit geographic scope and the facets searched (keyword, country, category, shop, brand, specifications). It distinguishes itself from list_filters by naming it as the filter-lookup helper, but never contrasts with get_offer, so the sibling boundary is only half drawn.

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 a clear triggering scenario ("Use when someone is shopping for a product, brand or shop and wants to check current offers, savings and conditions before buying") and routes filter discovery to list_filters. It also supplies an operational rule for keyword construction. It does not say when to prefer get_offer or what to do when no facet is supplied, so no exclusion boundary is stated.

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