wish_product_reviews

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

There are no annotations, so the description carries the full behavioral burden. It discloses the edge case of zero reviews returning an empty result instead of an error, explains the pagination limitation with a reason (upstream doesn't support offset/cursor), and notes reviews are normalized. It doesn't describe the review payload structure or error scenarios beyond zero reviews, but the disclosed edge cases are genuinely useful.

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 mostly compact and the key facts are front-loaded. The only minor redundancy is the first two sentences both stating the same thing: 'get reviews' and 'returns reviews'. The remaining sentences each add distinct value: id source, zero-result behavior, and pagination guidance.

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 simple two-parameter tool with no output schema, the description covers what's needed to invoke correctly: realistic resource, id provenance, count behavior, and edge case handling. The only gap is that it doesn't describe the actual review payload fields (e.g., rating, text, author), but the invocation and expected return pattern are clear enough for an agent to call and interpret the result.

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 important semantic nuance by explaining that count is the only pagination mechanism (since offset/cursor is unsupported) and by giving the id provenance (from search result or URL). This goes beyond the schema's basic '24-character hex id' description.

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 states the action 'Get' and the resource 'Wish product's customer reviews', which distinguishes it from the many sibling product-review tools (e.g., walmart_product_reviews, bestbuy_product_reviews) by naming the Wish platform. The resource boundary is immediately obvious even without opening the schema.

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 provides practical guidance: the id is sourced from a search result's product_id or a product URL, and when more reviews are needed, the caller should re-request with a larger count. It explicitly states this endpoint does not support offset/cursor pagination, which is a clear 'when-not' instruction. It doesn't name alternatives for other platforms, but the Wish-specific scope makes that less necessary.

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