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

Annotations already declare read-only, idempotent, closed-world, non-destructive, so the description's job is context — and it delivers: answers from stored prices with a rule-based verdict, each offer carries source_name/captured_at/blockers/reasons/warnings, and an unknown id surfaces as error.code not_found. It stops short of covering the offers list shape or any limits, but the error semantics and stored-vs-live framing are real additions.

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 and the identity precondition are front-loaded, and the trailing 'Next:' sentence is a useful routing cue rather than padding. A few clauses are dense and jargon-heavy ("without reading a query", "blockers"), but almost every sentence carries information.

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 7 optional-leaning params, no output schema, and full annotation coverage, the description covers purpose, id sourcing, return contents, error behavior and next steps. Only minor gaps remain, such as the exact shape of `offers` or whether the card is cached versus live when `ai` is false.

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%, so the baseline is 3; the description earns above that by explaining that `product` accepts a slug or a variant id from specific sibling tools, and that `product.variant` exposes storage, colour, model words, connectivity, size and family_id. The `ai`, `sort` and `include_shipping` semantics live mostly in the schema itself.

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?

It defines the tool concretely — the product card for a product id you already hold — and anchors it against find_best_price and the website's /{locale}/p/{product} page. The key distinction (no query interpretation, so no risk of resolving to a different variant) makes it trivially separable from search_products and find_best_price.

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 precondition (you already hold product.slug / product.variant.id) and names the source tools that supply it, plus the explicit handoff: product_variants for other capacities or colours, price_history for the trend. When-to-use and alternatives are both spelled out.

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