SecretPass

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds non-obvious content beyond annotations: what fields the response contains, that public data only is returned, and that voucher codes are deliberately omitted and must be obtained on the website.

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 short sentences, front-loaded with the resource and payload, then the id provenance, then the voucher caveat. Every sentence carries information; the closing website sentence is useful but slightly tangential.

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?

No output schema exists, and the description compensates by listing the returned fields and calling out what is excluded. For a single-parameter read with full annotations, the only gap is behavior on an invalid or stale id.

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 100% and the schema already explains the id must be the exact offer id including the country prefix. The description reinforces the provenance (from search_offers) but adds no format or syntax detail beyond the schema, so baseline 3 applies.

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 and resource ('Read the full public details of one current offer') and enumerates the payload ('description, shop, savings, conditions and dates'). The reference to 'the exact id returned by search_offers' cleanly separates it from the search/list 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?

Clear context: use it after search_offers, with the exact id from that call. It also states a scope exclusion (voucher codes are not included; members reveal them on the website) which steers the agent away from requesting voucher data here. No explicit statement of when NOT to call it beyond that.

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

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

Annotations already cover safety: read-only, idempotent, non-destructive, closed-world. The description adds real behavior that they do not: the results carry current offer counts, and passing brand or product_type changes the result set to include specification filters. It does not say whether unfiltered results are paged or limited, which is the remaining gap.

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 short sentences with zero padding. The return-content summary leads, followed by the use case and then the parameter effect.

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?

There is no output schema, but the description still says what comes back: facet lists with counts, plus specification filters when a brand or product type is supplied. That is enough for a read-only discovery call; only paging and value-matching semantics are left implicit.

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 0%, so the description has to compensate, and it does explain what each parameter causes: brand or product_type surfaces that item's specification filters. It stops short of saying whether values must match entries from the unfiltered list or whether free text is accepted, and it gives no maxLength or format guidance.

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?

A specific verb plus a concrete enumeration of resources: countries, categories, product brands, product types, each with current offer counts. That scope is clearly distinct from search_offers and get_offer, so an agent can pick this tool without opening either schema.

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?

It states the call sequence explicitly ('Use before filtering search_offers by category, brand...') and gives the condition for the optional parameters ('Supply a brand or product type to see its specification filters'). No alternatives need to be inferred.

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

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.