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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: results are sorted cheapest-first, each result includes price, stock status, EAN, and a direct purchase link, and pricing supports DE and AT. This gives the agent a clear picture of what the call will return and how output is ordered.

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?

The description is three sentences with no filler: it states the scope, the output behavior, and the key routing exception. The most important orientation information is front-loaded, and every sentence contributes something useful.

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?

Given the rich input schema, the output schema, and the annotations, the description covers all essential context an agent needs to decide when to use the tool and what to expect. It explains scope, ordering, result contents, pricing countries, and the alternative for EAN lookups, leaving no significant gap.

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 adds extra semantic value by clarifying that the query parameter searches by name, brand, or model number, and that country-specific pricing applies to DE and AT. These details complement the schema rather than merely repeating it.

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 identifies a specific verb ('Search'), a concrete resource ('bicycle parts, components, accessories, and cycling clothing'), and the search dimensions (name, brand, model number). It also differentiates itself from get_best_price by explicitly stating that EAN-based lookup should go to that sibling instead.

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 description gives clear context for when search_product is appropriate and provides an explicit exclusion: if the agent already has a product's EAN, it should use get_best_price instead. This is direct routing guidance rather than leaving tool selection to inference.

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