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

Annotations already mark this as read-only, idempotent, and non-destructive, but the description adds substantial behavioral detail: it searches public merchant snapshots, exact IDs do not fall back to title search, affiliate approval can be pending, optionQuery excludes incompatible ranking, and failures expose structuredContent.recovery. It also repeatedly clarifies that the tool never places orders and never selects options, which is valuable context beyond the annotations.

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 purpose is front-loaded in the first sentence, but the remaining description is a dense run-on paragraph with many semicolon-linked constraints and some repetition around option selection. Given the tool's complexity, much of the content is useful, but the structure makes it harder to scan than necessary.

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 25-parameter search tool with no output schema, the description provides useful return-related detail such as matchedIdentifierEvidence, matchedQueryTerms, dated price/stock scopes, and recovery fields. Still, it leaves many parameter behaviors and result-shape details under-specified, so an agent would need to infer too much from the schema alone.

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 only 32% across 25 parameters, so the description must compensate heavily. It explains several complex parameters such as optionQuery, maxOptionPrice, productCondition, and affiliateLinkedOnly, but many core search, pagination, price, market, category, and availability parameters remain semantically unspecified or only inferable from names and enums.

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 states a specific verb and resource: searching multiple KR/US merchant catalogs by product keywords or exact identifiers. It clearly defines the search scope and exact-identifier behavior, though it does not explicitly differentiate itself from sibling tools such as get_product or find_purchase_candidates.

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 gives some explicit usage guidance, such as using affiliateLinkedOnly true to find recorded issued purchase routes, and explains optionQuery/maxOptionPrice constraints. However, it does not state when to use search_products versus the sibling tools, nor does it name alternatives or exclusions for catalog search versus direct product lookup.

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