Get a player's wishlist

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

Annotations provide readOnlyHint and openWorldHint, and the description adds substantial behavioral context: public requirement with found:false, output caps (100 light, 60 detailed), ranking logic (priority vs discount), and the Steam limitation where only ~100 wishlist entries get enriched data, exposed via `enriched` and `note`. This goes well beyond annotations without contradicting them.

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?

While long, every sentence serves a purpose: purpose, auth/preconditions, filtering semantics, caps, ranking, Steam's data limitation, and a pointer to a sibling tool. The flow moves from core behavior to details to edge cases, and the front-loaded first sentence gives immediate utility. No filler or redundant statements.

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 tool with 13 optional parameters, 5 enums, and an output schema, the description covers all key aspects: what the tool returns (light vs detailed), how filters interact, limits, ranking, data availability quirks, and related tools. The existence of an output schema means return-value details don't need to be repeated, and the description fills all other contextual gaps.

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%, but the description adds critical interpretive value beyond parameter names/types: it distinguishes platform (native) from steam_os/steam_deck (Proton), explains that filters imply include_details, notes that misspelled tags silently match nothing, and clarifies the precedence of country/language overrides. This transforms flat enum descriptions into actionable usage rules.

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 opens with 'List a player's Steam wishlist by SteamID64,' a specific verb+resource combination that clearly distinguishes it from sibling tools. It also explicitly differentiates from get_items by noting the one-call detailed mode, and mentions resolve_vanity_url for name conversion.

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 explicit when-to-use guidance: it states the public/wishlist requirement, explains when to use include_details versus the light list, and clarifies that filters switch to detailed view. It also points to the sibling tool resolve_vanity_url for vanity names and notes it requires an API key, which is helpful for choosing the right path.

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