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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds genuine semantic context by defining what the reported numbers mean (share of adds, outstanding wishlists measured at end_date), but says nothing about result size, ranking behavior, or how the Platform mode interacts with the limit parameter.

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?

A single front-loaded sentence that immediately states the subject ('Where wishlists come from for one game') and then splits cleanly into country and platform branches via parallel parentheses. It is dense but every clause carries metric information; the only minor cost is the length of the nested parentheticals.

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 read-only analytical tool with no output schema, the description usefully enumerates the returned measures per mode, which compensates substantially. However, with five parameters and a high-complexity result set it omits how limit behaves in platform mode, whether outstanding wishlists are a snapshot versus a flow, and any steering among the three sibling wishlist tools.

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?

With 80% schema coverage the baseline is 3, and the description earns the extra point by explaining what each enum value actually yields — especially that platform mode returns only OS share of adds while country mode returns a richer metric set. It stops short of clarifying that limit applies only to country results or how start_date affects cumulative versus point-in-time figures.

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 names the specific resource (where wishlists come from for one game) and enumerates the exact metrics available in each mode: adds, deletes, purchases, share of adds, and end-of-window outstanding wishlists for country mode, versus OS share of adds for platform mode. It does not explicitly contrast itself with get_wishlist_activity or get_wishlist_conversion, so an agent must infer the distinction from the metric list rather than being told it.

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 two-mode framing ('by country ... or by platform ...') is an implicit usage hint for the 'by' parameter, but nothing states when to choose this tool over the sibling wishlist tools (activity, conversion) or what conditions make one mode preferable. Guidance stops at describing outputs, 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.