PSN game library

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description is consistent with them (no contradiction). The description adds one useful behavioral detail — the store page URL pattern — but does not disclose edge behaviors such as how unplayed games sort, whether filters combine, or the meaning of 'recently_played' for never-played titles. With annotations covering the safety profile, the added value is modest.

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 a tight two-sentence structure that is front-loaded with the purpose, followed by illustrative examples and a practical store-page URL. Every element earns its place with no filler. Minor deduction for the trailing URL being lower-priority context for tool selection, but it adds real operational value.

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?

Given the tool's complexity (13 parameters) and six siblings, the description covers the core purpose and gives usable examples, and the output schema covers return values. But it omits sibling differentiation and edge-case behavior entirely. It is sufficient for a basic call but leaves an agent to guess at how this tool relates to the other five library 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?

Schema description coverage is only 46%, so the description must compensate. It partially does: 'joining playtime with trophy progress' maps to the playtime filters (min/max_hours, played_since/before) and trophy filters (min/max_trophy_progress, only_platinum), and the examples imply date-range and sort usage. But it never explains the undocumented params (limit, offset, only_platinum) in any detail, and param names carry much of the burden. Adequate but not thorough compensation.

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 opening states a specific verb and resource — 'Filtered, sorted list of games on the account, joining playtime with trophy progress' — which distinguishes it from likely siblings like psn_owned_games (just ownership) and psn_recently_played (just recency). The example questions reinforce the combined playtime+trophy scope.

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 three example questions ('what did I play most in 2024', 'what have I nearly finished', 'what did I drop quickly') give strong implicit context for when to use this tool. However, with six siblings available, it never names alternatives or states when NOT to use this tool (e.g., when psn_owned_games or psn_recently_played would suffice), leaving the selection decision partially to inference.

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