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

Annotations already declare the read-only/open-world safety profile, and the description adds useful behavioral detail such as fuzzy matching and needing np_service_name only with a raw ID. However, it calls the result 'Full' while the schema defaults limit to 150, and it doesn't disclose hidden-trophy behavior or what happens when no identifier is passed.

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?

Two sentences deliver output, input modes, and use cases with no filler. The most decision-relevant information appears first.

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?

It is strong for a read-only tool with output schema present, but several invocation details are left implicit: 0 required parameters means both identifiers can be omitted, yet no fallback behavior is described, and the default limit of 150 qualifies the 'Full' claim. Those gaps matter for correct invocation.

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 moderate (67%), and the description contributes beyond schema by explaining the game-vs-np_communication_id choice and fuzzy matching. It does not add meaning for limit, status, or include_hidden, but those are partially covered by schema defaults and titles.

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 a specific resource (full trophy list for a single game) and the data it returns (earned status, earn dates, rarity), which clearly separates it from sibling tools focused on libraries and profiles. The verb 'Pass' and the title make the operation obvious.

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 states two concrete input routes (fuzzy title match or exact np_communication_id) and gives use cases ('what's left to platinum', engagement depth). It does not explicitly name sibling alternatives or when-not conditions, but the context makes the intended selection clear.

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

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.

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

With readOnlyHint=true, the safety profile is already established by annotations. The description adds useful behavioral context beyond that: the inventory includes PS Plus claims, playtime data is only present 'where known', and the tool is meant to surface unplayed purchases. No contradiction with the annotations is present.

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 two tight sentences with no filler. The first sentence front-loads the data scope, and the second sentence explains when and why to use the tool, earning every word.

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?

The description covers the core use case well and an output schema exists, so return-value details are not needed. However, with five parameters and only 20% schema coverage, the descriptions do not fully explain how to leverage search, platform filtering, or pagination. It also does not contrast with psn_library, which may be a close sibling, leaving some contextual ambiguity.

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 20%, so the description needed to compensate for limit, offset, search, and platform, but it does not explain any of those. Only 'unplayed purchases' loosely maps to the unplayed_only parameter. The parameter names are somewhat self-explanatory, which keeps this above a 1.

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 specifies the resource: games the account has bought or claimed, including PS Plus monthly claims, with hours played where known. It also states the practical purpose: avoid recommending owned games and surface unplayed purchases. It stops short of explicitly distinguishing itself from the sibling psn_library, so it is not a full 5.

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 an explicit trigger: 'Check this before recommending anything' and explains why, preventing duplicate game suggestions and highlighting unplayed purchases. It does not name sibling alternatives or state when not to use it, but the guidance is clear enough for an agent to know when to call it.

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

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

Annotations already communicate readOnlyHint=true and openWorldHint=true, so the description is not burdened with stating that this is a safe read operation. It adds a little context by enumerating the returned profile fields, but it does not disclose any additional behavioral traits such as authentication needs, staleness, or relationship to refresh operations. No contradiction with annotations exists.

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 single compact phrase with no filler and front-loads the core identity of the tool. It is appropriately terse for a zero-parameter read-only tool, though it reads as a fragment rather than a complete, well-formed sentence.

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 low complexity — no parameters, simple read-only behavior, and an output schema present — the description is mostly sufficient by listing the main profile fields. It could be more complete by explicitly stating that this is the authenticated user's account profile and by clarifying how it differs from psn_taste_profile, but these are minor 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?

The tool has zero parameters and fully covered schema documentation, so the baseline for this dimension is 4. The description has no parameter semantics to add because there are no inputs to explain.

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 identifies the resource — a PSN account profile — and lists the concrete data fields it exposes (Online ID, PS Plus status, trophy level, lifetime trophy counts). It lacks an explicit verb like 'returns' or 'gets,' and it does not directly distinguish itself from sibling psn_taste_profile, so it stops short of a 5.

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?

No guidance is given about when to use this tool versus psn_taste_profile, psn_library, psn_refresh, or psn_recently_played. The intended use is only implicit from the name and fields; there are no exclusions, alternatives, or context conditions.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful context about account scope and sort order, but it does not disclose behavior such as how the limit parameter applies or what happens if the account has no recent activity. This is acceptable but not rich.

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 single, concise sentence that front-loads the core purpose and ordering information. Every word contributes meaning, and there is no redundant or filler content.

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 read-only listing tool with one optional parameter and an output schema, the description is nearly complete. It states the resource, account scope, and sort order. The only notable omission is any mention of the limit parameter, though the schema fully documents it with defaults and constraints.

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 0%, so the description needed to compensate by explaining the 'limit' parameter. It does not mention the limit at all. The parameter name and constraints (default 20, min 1, max 50) are somewhat self-explanatory, but the description itself adds no parameter-level meaning.

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 identifies the resource: the account's most recently launched games, and even specifies ordering ('newest first'). It does not use an explicit verb like 'list' or 'retrieve', but the meaning is unambiguous. It also distinguishes itself from sibling tools by the recency filter.

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 implies the tool should be used when the agent needs the account's recently played or launched games. However, it does not explicitly state when to use this tool versus alternatives like psn_library or psn_owned_games, nor does it provide any exclusion criteria.

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

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

The description explicitly discloses that the tool invalidates cached data and that subsequent calls will re-read from live sources, which goes beyond the annotations (readOnlyHint=false, idempotentHint=true). This gives the agent a clear mental model of the mutation and its deferred effect.

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 compact: one sentence explains the operation and its effect, and a second sentence gives the usage trigger. Every word earns its place with no redundancy.

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 parameterless cache-refresh tool with an output schema and clear annotations, the description explains both what happens and when to call it. No important behavioral or usage detail is missing.

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 tool has zero parameters, and the schema fully covers this with an empty properties object. The description adds no parameter details, but none are needed; the baseline for a parameterless tool is appropriate here.

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 ('Drops the cached PSN responses'), the resource (PSN cache), and the intended outcome ('the next call re-reads live data'). This distinguishes it from all sibling read tools such as psn_library or psn_profile.

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 phrase 'Use after the user has just played something' gives a concrete trigger condition for when to invoke the tool. It does not name exclusions or alternatives, but for a cache-refresh tool this clear contextual cue is sufficient.

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

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

The description adds behavioral context beyond the readOnlyHint annotation by specifying that this is a one-shot, consolidated digest covering multiple dimensions of the account's gaming history. It does not detail potential rate limits or freshness caveats, but the read-only nature is already covered by annotations and the description does not contradict 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?

The description is two sentences with no filler, front-loading the core purpose and then giving a direct usage directive. Every phrase contributes either to scope, content, or routing.

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 output schema, readOnlyHint annotation, and clear parameter schema, the description covers account scope, content scope, and intended usage. Nothing essential is missing for an agent to decide to call this tool and understand what it will receive.

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 has 100% description coverage for both parameters, so the baseline is 3. The description loosely reinforces 'top games by hours' for the top parameter and 'unplayed purchases' for include_backlog, but it adds no new semantic detail beyond what the schema already provides.

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 'One-shot digest of the account's gaming taste' and lists concrete content areas like totals, playtime habits, top games, franchises, and platinums. This clearly distinguishes it from sibling tools such as psn_profile, psn_owned_games, and psn_library by framing it as a consolidated taste summary rather than a single-purpose lookup.

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 closing instruction, 'Start here for any recommendation request,' gives explicit routing guidance for when to use this tool. It does not enumerate when-not-to-use conditions or name alternative siblings, but the primary usage context is clear and actionable.

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