wish_search

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

With no annotations, the description carries the behavioral disclosure burden. It discloses the offset-based pagination, the normalized product fields, and the empty-result behavior for no match. It does not cover rate limits or state, but for a search tool this is a strong behavioral context.

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 only about 70 words, but the first two sentences are redundant ('Search Wish products' and 'Searches Wish's product catalog by keyword'). The informative details about features and empty results come after a slightly repetitive opener; still compact overall.

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 and no annotations, but the description compensates by listing the returned product fields and describing the empty-result edge case. Combined with the detailed input schema, the agent has enough context to invoke the tool and interpret the result. Missing Sorting semantics is a minor omission at best.

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?

The input schema already documents every parameter at 100% coverage, including nonobvious constraints like the offset multiple behavior. The description adds only 'real offset-based pagination' and does not materially enrich parameter-level semantics; baseline 3 is appropriate.

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 uses a specific verb and resource ('Search... Wish's product catalog by keyword') and clearly states the return shape ('normalized products with price, currency, rating, review count, and merchant id'). This distinguishes it from catalog/structure tools like wish_categories, single item lookups like wish_product, or suggestion tools like wish_suggest.

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 intended use case is inferable: use this when you need to search Wish products by keyword. However, there are no explicit alternative/non-excluded mentions such as 'use wish_suggest for typeahead' or 'use wish_categories for browsing'. The usage is implicit rather than clearly routed to the agent.

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