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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds meaningful behavioral detail: sorting by cheapest first, returning all store offers for one add-on, and including conditional net price/cross-currency fields. It does not cover failure modes or pagination, but the output schema reduces that burden.

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?

Two sentences with the core scoping ('Every store offer for one add-on, cheapest first') front-loaded before the field list. The first sentence is dense but earned; the second sentence adds a positioning statement that is helpful, though slightly vague.

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 single-parameter read-only tool with an output schema and strong annotations, the description covers the result shape, sort order, and key edge case ('where the rate is known'). The main completion gap is the undocumented slug parameter, but this is minor given the low complexity.

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 0% and the only parameter is an undocumented 'slug'. The phrase 'one add-on' implies slug is the add-on identifier and adds some meaning, but the description never explicitly defines slug, its format, or where to obtain it, so it only partially compensates for the schema's lack of documentation.

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 clearly identifies a singular resource ('one add-on') and the action ('Every store offer ... cheapest first'), plus the returned price details, so an agent knows what the tool computes. It does not explicitly contrast itself with siblings such as price_history or list_deals, though the scope 'one add-on' plus title is enough to separate it from the broader listing tools.

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?

The final sentence ('the question the website cannot answer in one shot') provides a rough use case but no explicit when-to-use or when-not-to-use guidance. It never names an alternative tool or states conditions that should route the agent to price_history, search_addons, or list_deals.

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