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 a genuinely useful performance caveat about the first all-console search, but says nothing about pagination behavior, rate limits, or what the slow operation implies for repeated calls.

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 short sentences with the primary purpose front-loaded ahead of the performance note. Efficient overall, though the performance caveat could be slightly more specific.

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?

With five parameters, 20% schema coverage, and no output schema, the description should carry more weight. It omits pagination semantics, the meaning of the has_achievements default, and what a result actually contains beyond 'game IDs'.

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% (only 'query' is documented), and the description names just two of five parameters (title, console). It does not explain limit/offset pagination or what has_achievements=true (the default) filters on, leaving most parameters undocumented.

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?

States a specific verb and resource — 'Find game IDs by title and/or console' — which clearly distinguishes it from the singular sibling get_game and from list-oriented siblings like get_user_games. No explicit sibling routing, but the verb+resource is unambiguous.

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 note that the 'first all-console search may be slow' implies you should supply a console filter when possible, which is useful implied guidance. However, it names no alternative tool and gives no explicit when-to-use/when-not 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=true and openWorldHint=true, so safety is covered. The description adds genuinely useful behavioral context the annotations do not: results are sorted newest-first and include aggregate unlock rates. It says nothing about pagination behavior/caps for limit=500 or the effect of hardcore_only, so it is not complete.

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 tight sentence with the key qualifiers (newest first, unlock rates) packed in and nothing wasted. It is arguably under-specified rather than over-long, but as prose it is efficient and front-loaded.

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?

There is no output schema, so the description must explain return shape, and it only gestures at it ('unlock rates'). With four undocumented parameters and no mention of pagination, filtering, or result size, an agent lacks what it needs to call this correctly.

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% for four parameters, so the description carries the full burden and largely fails: achievement_id, limit, offset, and hardcore_only are never explained, nor is the 500 maximum or the default of 25. Only the achievement scoping is obliquely implied by the word 'achievement'.

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 (achievement unlocks) and what is returned (unlockers plus unlock rates, newest first), which distinguishes it from the sibling get_user_unlocks that works from the user side. It is clear but never explicitly contrasts itself with those siblings, so it stays 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?

There is no statement of when to call this versus get_user_unlocks, get_user_game_progress, or the leaderboard tools. The reader must infer that this is the achievement-centric view from the name alone.

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, so safety and access profile are covered. The description adds useful behavior by noting that system log entries are hidden unless include_system is set, but it does not cover pagination, rate limits, or return shape.

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 front-loaded sentence with no filler, and the include_system condition is placed usefully in parentheses. It is concise, though the phrase 'comment wall' is slightly informal for a tool purpose statement.

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 six parameters, low schema description coverage, and no output schema, the description is too sparse. It omits key parameter semantics and usage context that an agent would need to call it correctly.

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 17%, so the description must compensate but largely does not. It clarifies include_system and the target categories, but leaves id, sort, limit, and offset semantics unexplained.

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 as comments for a game, achievement, or user. It does not explicitly name sibling alternatives such as get_feed, but the target scope makes the purpose understandable.

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?

There is no explicit guidance on when to use this tool versus alternatives like get_feed or get_user_social. Usage is only implied by the resource description.

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, so the safety profile is covered elsewhere. The description adds nothing behavioral: no pagination semantics despite limit/offset existing, no ordering, no note that 'claims' returns only finished claims, no indication of what a feed entry contains. With annotations doing the light lifting, this remains well short of the bar.

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?

Very short and front-loaded, with zero filler. But it is a bare fragment rather than a sentence, and its brevity comes from omission rather than disciplined compression — there is no enough content to be concise about.

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 an 8-parameter, no-output-schema, open-world feed tool, the description omits what a feed returns, how limit/offset paginate, and which optional filters pair with which kind. An agent must reverse-engineer all of this from the schema alone.

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 63%, so several parameters (limit, offset, kind, game_id partly) are undocumented. The description does add real value by expanding the opaque enum value 'aotw' to 'Achievement of the Week' and clarifying that 'claims' means finished claims, but it says nothing about the filters that only apply to specific kinds (game_id, console_id, award_kind, claim_kind). Baseline-plus for the acronym expansion, not more.

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?

It identifies the resource as 'Site feeds' and enumerates the five feed kinds, which does distinguish it from siblings like get_leaderboards or get_user_games. However, there is no verb ('retrieve', 'list') and the content is essentially a restatement of the 'kind' enum already present in the schema, so the purpose is only implied rather than stated.

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 when-to-use guidance, no conditions, no alternative named among the 14 sibling tools. An agent has no idea when this tool is preferable to get_leaderboards, get_achievement_unlocks, or get_user_profile.

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, so the safety profile is covered. The description adds nothing behavioral beyond that: no pagination behavior (limit/offset exist), no note that optional sections cost extra calls or that data may be missing, no return-shape context.

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 dense sentence that front-loads the core purpose before the optional expansions. The semicolon-and-parenthetical style is compact and mostly earns its words, though it reads more like a schema comment than prose.

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?

With six params, no output schema, and 17% schema coverage, the definition should carry far more weight. It never mentions pagination defaults/bounds, the images flag, or how achievement_type interacts with the achievements include, so an agent has to guess at key invocation details.

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 only 17%, so the description must compensate, and it does explain five of the six 'include' enum values with useful detail (achievements carry rarity/type, progression carries median times). However, limit, offset, and images are entirely unexplained in both schema and description, leaving a real gap.

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?

States a specific verb+resource ('Game details') that is clearly distinguishable from siblings like find_games (search) and get_user_games (user-scoped listing). It is terse and telegraphic, but an agent can tell what the tool retrieves.

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?

There is no when-to-use guidance and no named alternative. An agent can't tell from the description whether this is the right tool versus find_games or get_user_game_progress for a given lookup.

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, so safety is covered. The description adds the useful constraint that the result is exactly a top 10 (bounded size), but says nothing about permissions, ordering guarantees, or pagination/absence of results.

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 compact clause that is front-loaded with the core resource. It is efficient, though the fragmentary phrasing costs a little clarity.

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 read tool with no output schema, the description conveys the essential shape of the result (top 10, two ranking modes). It stops short of explaining what 'masters' means or how ties/ordering are handled, but nothing critical to invoking it 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?

Schema description coverage is 0%, so the description must carry parameter meaning. It does gloss the two type values ('highest scorers' = high_scores, 'most recent masters' = latest_masters), but game_id is left entirely unexplained and the gloss is loose rather than matching the enum semantics.

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 resource (a game's top 10) and the two ranking modes, which lets an agent distinguish it at a high level. However it is a noun fragment with no verb, and it does not clearly separate itself from the sibling get_leaderboards.

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?

There is no explicit when-to-use guidance, no prerequisites, and no mention of the sibling alternatives such as get_leaderboards or get_game. The two modes are only implied by the phrase 'highest scorers, or most recent masters'.

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, so the safety profile is covered. The description adds one behavioral fact: the tool returns structurally different results depending on whether user_entries is set (a list of leaderboards vs. ranked entries). It says nothing about pagination behavior, result size, or the open-world lookup cost implied by the annotation.

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 tight sentences with the primary resource and the parameter selector front-loaded; no filler. The parenthetical for user_entries is compact but slightly cryptic in isolation.

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 tool with no output schema and 0 required parameters, the description is adequate on the core axis of what is returned. It is incomplete on pagination semantics (limit/offset) and on how the configured-user default interacts with user_entries, both of which an agent needs to call it correctly in the ranked-entries mode.

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 17% across 6 parameters, so the description must compensate. It does clarify the game_id/leaderboard_id selectors and the user_entries flag, but leaves user, limit, and offset (pag ordering, max 500) entirely unexplained, and it is unclear to which mode pagination applies.

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 resource (leaderboards) and clearly distinguishes its two modes: a game's leaderboard list versus one leaderboard's ranked entries. It does not differentiate itself from the sibling get_game_rankings, which an agent could easily confuse with the second mode, 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?

"Give game_id or leaderboard_id" gives a concrete selector rule for which parameter drives which mode, which is genuine usage guidance. However, it offers no when-to-use/when-not guidance relative to get_game_rankings, and no note on whether the two modes are mutually exclusive or what happens if both are supplied.

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, so the safety profile is covered. The description adds essentially nothing beyond that — no note on pagination behavior, the fact that different modes require different id semantics, or output differences per mode, even though limit/offset exist and modes return heterogeneous shapes.

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 with no filler, so nothing wastes space. The telegraphic, comma-fragmented style is efficient but slightly cryptic for an agent parsing mode semantics.

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?

With 7 parameters, 57% schema coverage, no output schema, and modes that return fundamentally different structures, the description does far too little. It never explains what 'id' means per mode, how 'user' relates to the developer mode, or what 'details' expands, leaving an agent to guess at 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?

The mode listing does map the enum values to what is returned (one ticket vs per-game/achievement/developer summary), which adds real meaning for the required parameter. However, the other six parameters (id, user, limit, offset, details, unofficial) get no explanation in the description, and schema coverage is only 57%.

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 resource precisely — 'Achievement bug tickets' — and enumerates the six retrieval modes (recent, ticket, game, achievement, developer, most_ticketed), so an agent understands this is a multi-mode ticket lookup rather than a generic list. It lacks an explicit verb, but the noun phrase plus mode list is unambiguous.

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?

Listing the modes implies when each is appropriate, but the description never states conditions for choosing between them (e.g. when to use 'ticket' vs 'game'), and names no alternative sibling tools. Usage is inferred from the enum labels rather than explained.

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, so safety is covered. The description usefully adds what is returned (summary + achievements with rarity %, or summary rows per game_ids entry), but says nothing about auth requirements, pagination, or the default-filtering behavior of the achievements field.

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 packs both operational modes efficiently with no wasted words. Brevity is appropriate, though the density leaves semantic gaps rather than trimming 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?

With 9 parameters, 33% schema coverage, and no output schema, the description is too thin: it omits default filtering ('locked' achievements), pagination, and the optional parameters. Annotations cover the safety profile but not enough of the calling contract.

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 only 33%, so the description must compensate for roughly six undocumented parameters, yet it explains only the game_id vs game_ids output distinction. Critical params like achievements ('locked' default), limit, offset, images, and include_rank are left unaddressed.

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?

States a specific verb+resource ('User's progress in one game') and distinguishes the two output modes: full details for game_id versus summary rows for game_ids. It does not name siblings like get_user_unlocks or get_achievement_unlocks, so an agent must infer differentiation from the resource alone.

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?

Usage is only implied through the parameter-dependent modes: one game produces summary+achievements, game_ids produces summary rows. There is no explicit when-to-use guidance versus siblings such as get_user_unlocks or get_user_games, and no exclusions are stated.

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, so safety is covered. The description adds semantic context about what data each list contains (progress = per-game counts + award, completed = 100%), which is genuinely useful, but says nothing about pagination, the default user, or result size limits.

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 terse sentence that front-loads the resource and enumerates the options; nothing is wasted. It is slightly cryptic (relies on list-noun vocabulary without a verb) but efficient.

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 an 8-parameter tool with 38% schema coverage and no output schema, the description covers only the primary enum semantics. Pagination behavior, filtering dimensions, and the user/console scoping are left entirely to the schema, leaving real 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 description coverage is only 38% across 8 parameters, so the description must compensate more than it does. It usefully clarifies the meanings of the required 'list' enum values, but the other seven parameters (limit, offset, images, console_id, user default) get no added meaning beyond the schema.

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 resource precisely ('User's game lists') and enumerates the four list types, so an agent knows this is a list-retrieval tool. It does not, however, distinguish itself from the closely related sibling get_user_game_progress, which likely overlaps with the 'progress' list.

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?

There is no guidance on when to choose this tool over get_user_game_progress or get_user_unlocks, despite obvious overlap. No prerequisites, no exclusions, no alternative routing are stated.

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, so the safety profile is covered. The description adds value by disclosing the shape of returned content (summary fields, awards) but says nothing about pagination, data freshness, or what the limit parameter controls.

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?

Very short and front-loaded: the resource is stated first, then the include options. The telegraphic 'include: summary (...), awards' phrasing is compact but slightly fragmented; nothing is wasted.

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?

With no output schema, the description should carry more of the return-value burden; it does sketch the summary and awards sections, which helps. But three of four parameters remain undocumented in both the schema and the description, so an agent cannot fully determine how to scope or shape the request.

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 only 50%, and the description meaningfully expands on the 'include' enum by explaining what 'summary' contains. It gives no information about the undocumented 'user', 'limit' (max award rows), or 'images' parameters, leaving half the parameter surface unexplained. Baseline 3 given the partial coverage.

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 identifies the resource (user profile and points) and enumerates the retrievable sections (summary: rank, status, recent games/unlocks; awards), which goes slightly beyond restating the name. However, it never states a verb and offers no differentiation from siblings like get_user_games, get_user_unlocks, or get_user_social, all of which appear to return overlapping user data.

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 only usage signal is the 'include' list, which implies the include parameter's valid values but says nothing about when to call this tool versus the many sibling user-data tools. No exclusions, prerequisites, or alternatives are named.

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 real behavioral context beyond that: it discloses that for following/followers the tool silently ignores the user argument and instead reads the API-key owner's graph. That is a non-obvious quirk worth surfacing.

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?

It is a single compact sentence with no filler, and the behavioral caveat is present. However, the telegraphic phrasing and semicolon-splice make it harder to parse than a plainly front-loaded sentence would be, so brevity comes at some cost to clarity.

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?

With 5 parameters, 40% schema coverage, and no output schema, the description covers the trickiest interaction (kind × user) but omits return shape and pagination semantics. It is minimally adequate rather than complete for a tool of this complexity.

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 40%, so the description is expected to carry some weight. It clarifies the semantics of `user` (ignored for two of four kinds) and implicitly the mapping of `kind` values, but says nothing about limit/offset pagination behavior or the all_requests flag, leaving a partial gap.

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 resource (user social data) and enumerates the four facets it can return, but relies on opaque jargon like 'set requests' and 'dev claims' that an agent cannot decode without external knowledge. It does distinguish the two behavioral modes (per-user vs. API-key-owner), which separates it somewhat from siblings, but the core purpose remains murky.

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 '(ignores user)' clause is genuine usage guidance – it tells the agent that the user param is void for the following/followers kinds – but there is no explicit when-to-use framing and no mention of the sibling tools (get_user_profile, get_feed, etc.) that cover adjacent data. Usage is implied rather than stated.

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 and openWorldHint=true already declared, the safety profile is covered, and the description usefully adds the 'newest first' ordering and the default 24h window. It still omits auth requirements, pagination behavior, and what happens when multiple time parameters are supplied.

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 clipped sentences with zero filler, front-loading what the tool returns before the time-window constraints. It is dense and slightly telegraphic, but every clause carries information.

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 7-parameter read tool with no output schema, the description nails the time-window semantics but leaves limit/cap behavior (max 500), hardcore_only's meaning, and the user default unexplained. It is adequate but not complete.

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 only 57%, but the description adds genuinely non-schema information: the mutual exclusivity of minutes/from/date and the default 24h window, which the schema does not state. It says nothing about limit, hardcore_only, or user, so it only partially compensates for the coverage gap.

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 identifies the resource (a user's unlocks) and the ordering (newest first), so the agent knows it returns a reverse-chronological list. However, it is a bare noun phrase with no verb and never clarifies what an 'unlock' is, leaving it ambiguous against the sibling get_achievement_unlocks.

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?

'One of minutes, from[/to], date; default last 24h' constrains how to use the time parameters but says nothing about when this tool should be chosen over siblings such as get_achievement_unlocks or get_user_game_progress. No exclusion or alternative routing is given.

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, so the safe-read profile is covered. The description adds only the word 'active', implying an implicit filter on returned systems, and says nothing about the return shape, ordering, or whether the list is exhaustive.

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?

It is a single short fragment with no wasted words, but it is a noun phrase rather than a sentence, so it is under-specified rather than genuinely concise; nothing is front-loaded because there is no verb to lead with.

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 zero-parameter read-only list with no output schema, the description does the minimum: it names the resource and notes the 'active' filter. It omits any statement of the action performed and any hint at what the returned IDs represent or how to use them, leaving the agent to infer the operation.

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 takes zero parameters, so the schema imposes no semantic load and the baseline for this dimension is 4. Nothing in the description contradicts or supplements the empty schema.

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 fragment identifies the resource and its scope ('IDs of the active RetroAchievements game systems'), and usefully maps 'consoles' to game systems, but it supplies no verb, so the agent must infer that this is a list/retrieve operation from the name alone. It is understandable but not stated as a specific action.

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?

There is no when-to-use guidance, no prerequisites, and no reference to alternatives. The sibling tools are mostly user/game/achievement oriented, so overlap is low, but the description does nothing to help the agent decide 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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that it returns raw JSON and acts as an escape hatch, but it does not disclose output truncation via max_chars, rate limits, or error behavior.

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 tightly written sentences with the core role front-loaded and no wasted words. The fallback guidance follows immediately and the example is embedded efficiently.

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 an open-world escape-hatch tool with no output schema, the description should clarify return format and truncation behavior. 'Raw JSON' is a start, but max_chars output limiting and any invocation constraints remain undocumented, leaving meaningful 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 description coverage is 67%, with max_chars having no description anywhere. The description only illustrates the endpoint parameter with 'GetGameExtended' and adds no meaning for the params object or max_chars behavior, so it does not compensate for the schema gap.

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?

States the resource ('raw JSON from any RA Web API endpoint') and gives a concrete example endpoint. The 'escape hatch' framing plus 'Prefer the dedicated tools' distinguishes it from the many specific sibling tools, though it never uses an explicit verb like 'fetch' or 'call'.

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?

Clearly positions itself as a fallback by saying 'Prefer the dedicated tools,' which tells the agent to use siblings when available. It stops short of naming the exact condition or listing the relevant dedicated alternatives explicitly.

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