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

The readOnlyHint annotation already establishes that this is a safe read operation, so the description does not need to repeat that. It adds useful scope ('thousands', 'sentiment over time') but does not disclose operational details like pagination via cursor, request-volume implications, or output format behavior beyond what the schema already captures.

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 tight sentence with a front-loaded verb/resource and a colon-separated capability list. There is no filler, redundancy, or unnecessary background.

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 tool has a nested parameter object with nine settings, no output schema, and a fairly complex analytical behavior. The one-line description does not explain return value shape, cursor-based pagination, output format selection, or performance/request trade-offs, leaving an agent without sufficient context for confident 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 description hints at dimensions that map to parameters ('by language' → language, 'key vs Steam purchase' → purchase_type), but it provides no parameter-level guidance, defaults, constraints, or trade-offs. Given schema_description_coverage is 0% for the top-level tool signature, the description fails to compensate for undocumented parameter 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 states a specific verb and resource — 'Analyze ... a game's reviews' — and enumerates concrete analytical dimensions (sentiment over time, language, playtime, Deck, purchase type, dev replies). It clearly signals an aggregation/analysis tool rather than a raw review fetcher like steam_get_app_reviews, though it does not explicitly name any sibling alternative.

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 vs alternatives such as steam_get_app_reviews or steam_analyze_game. The word 'Analyze' implies the use case, but no exclusions, prerequisites, or contrasting sibling conditions are mentioned.

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 readOnlyHint annotation covers the safety profile, but the description adds little behavioral context beyond the data scope. 'Latest update's effect' is ambiguous, and the description does not disclose how the aggregation works, whether results may be partial, or what the response structure looks like. Since there is no output schema, the description carries a heavier burden that it does not meet.

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 sentence that front-loads the core value proposition ('One-call brief on a game') and then lists the covered data points. It is efficient and free of filler, though the dense list could benefit from slight structuring.

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 that aggregates many data sources, the description is incomplete: it does not specify return format, whether all listed data points are always present, what 'latest update's effect' means, or how country_code affects results. The lack of an output schema makes these gaps more significant.

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 schema only describes appid; country_code and response_format are undocumented. The description adds no parameter guidance, leaving the agent to infer the meaning of country_code and the difference between markdown and json output. With schema coverage reported as 0%, the description should compensate but does not.

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 a specific action ('One-call brief') and resource ('a game'), and enumerates the data dimensions covered: price, reviews, players, Deck, tags, update effect, and news. This distinguishes it from single-purpose sibling tools like steam_get_app_reviews or steam_get_deck_compatibility, though it does not name those alternatives explicitly.

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-call brief' implies this is for getting a broad overview in a single call rather than a deep dive. However, it does not explicitly state when not to use it or name alternatives such as steam_get_app_reviews for detailed review analysis or steam_get_update_impact for update-specific details.

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 declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds useful behavioral context: it analyzes the whole library, counts abandoned games by staleness, and excludes temp clients by default. However, it doesn't disclose what happens if steamid is omitted and STEAM_USER is not set, or whether the analysis is expensive/slow for large libraries.

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. It's efficient and doesn't waste words. It could arguably add a bit more context about the analysis outputs, but for a tool with a rich schema, this is appropriately sized.

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 tool has no output schema, so the description should hint at what the analysis returns. It lists three output categories (backlog, playtime distribution, abandoned games) which gives a rough idea, but doesn't describe the structure of the response (e.g., markdown vs json, what stats are included). The parameter descriptions fill in some gaps (e.g., abandoned_sort options), but the overall return shape is left to inference. For a complex analysis tool, this is a moderate gap.

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 carries the full burden. The description itself doesn't explain parameters, but the input schema has rich descriptions for every parameter (steamid, top_limit, stale_days, backlog_limit, abandoned_sort, abandoned_limit, response_format, exclude_temp_clients). The description's mention of 'backlog, playtime distribution, abandoned games' maps conceptually to the parameters. Since the schema already does the heavy lifting, the description adds marginal value but doesn't need to.

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 states a clear verb ('Analyze') and resource ('a whole game library') and lists three concrete outputs: backlog, playtime distribution, abandoned games. It distinguishes itself from siblings like steam_get_owned_games (which just lists games) and steam_analyze_game (which analyzes a single game), though it doesn't explicitly name them.

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 when to use it: when you need an aggregate analysis of a library rather than a single game or list. It doesn't explicitly state when not to use it or name alternatives, but the sibling list makes the distinction fairly clear. The parameter descriptions add some usage context (e.g., backlog_limit defaulting to max so 'what should I play' sees the whole backlog), which helps.

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 the description is consistent with that, so the safety profile is covered. The description adds useful behavioral context by previewing what data the tool surfaces (price, reviews, players, Deck, co-op, tags). It doesn't disclose whether the comparison fans out into multiple Steam API calls or how results are rendered, but for a read-only tool this is an acceptable gap.

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: verb, resource, range, dimensions, and use case, with zero filler. Every clause earns its place and the key scoping constraint ('2-5 games') appears immediately.

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 dimension list partially tells the agent what to expect back, and the response_format default hints at markdown rendering. But the description omits the semantics of country_code and response_format and how the comparison output is structured, leaving moderate gaps for what is otherwise a simple tool.

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 low — only appids has an inline description; country_code and response_format have none. The description text mirrors the appids constraint ('2-5 games') and lists comparison dimensions, but never explains country_code's effect on regional pricing or how response_format shapes the output, so it fails to compensate 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?

States a specific verb ('Compare'), a resource (Steam games), a bounded input range (2-5), and the exact comparison dimensions (price, reviews and trend, players now, Deck, co-op, tags). The 'X or Y?' framing makes it immediately distinguishable from siblings like steam_compare_players and steam_analyze_game.

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 'for "X or Y?" questions' clause gives a clear when-to-use signal, and the 2-5 game range implies a side-by-side selection context. However, it names no alternatives or exclusions — it doesn't tell the agent when to prefer steam_should_i_buy, steam_recommend, or steam_analyze_game instead.

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 provide readOnlyHint=true, so the read-only nature is known. The description adds that the tool computes shared games and per-game playtime comparison, which is useful context. It does not disclose behavior such as how steamid_a defaults to the configured STEAM_USER, response format handling, or any rate-limit/error behavior, but with annotations present the description provides acceptable additional 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?

The description is a single, front-loaded sentence with no filler: it states the resource, the action, and the key output. Every word contributes meaning, and it is appropriately sized for the tool.

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 readOnly annotation and a schema that documents all parameters, the description is nearly complete for correct invocation. It conveys the output shape ('shared games and who has played each more'), which is essential since there is no output schema. Minor gaps like the default steamid_a behavior and response_format are covered by the schema, so the description itself is sufficient for an agent selecting the tool.

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 free-text description does not mention any parameters (limit, steamid_a, steamid_b, response_format), so it adds no parameter-level meaning. However, the input schema itself provides thorough descriptions for all four properties, including defaults and accepted formats. Despite the context signal indicating 0% coverage, the schema is self-documenting, so a baseline 3 is appropriate.

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 states a specific verb and resource: "Compare two users' libraries" and further specifies the output as "shared games and who has played each more." This clearly distinguishes it from sibling tools like steam_compare_games, which presumably compares game details rather than player libraries.

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 use case: use this when you need to compare the libraries of two Steam users and see shared games/playtime. However, it does not explicitly state when to choose this over alternatives such as steam_compare_games, steam_find_friends_who_own, or steam_plan_coop_night, nor does it mention any exclusions or prerequisites.

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 readOnlyHint annotation already establishes safety, so the bar is lower. The description adds the behavior 'optionally personalized to a user's taste', which hints at reading a user's Steam data, but it does not disclose details like default exclusion of owned games or that unknown tags are ignored. These are in the schema, but the description itself adds only modest behavioral context beyond 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?

The description is a single sentence with zero filler. It front-loads the core action ('Discover games by criteria'), lists criteria compactly, mentions optional personalization, and adds the sibling contrast. Every clause earns its place.

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 is adequate for an agent to understand what the tool does and when to choose it, especially with the sibling distinction. However, there is no output schema, and the description doesn't mention the default markdown/json response format, pagination limits, or the behavior of ownership exclusion when steamid is provided. The schema covers the details, but for a tool with this many options, the description leaves some contextual gaps to be inferred.

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 description uses friendly labels ('tags, max price, on-sale, platform') that map to some parameters, but it omits many others (sort, limit, term, country_code, response_format, released_within_days). The input schema itself provides thorough descriptions for every parameter, so the schema carries the parameter-semantic load; the description's contribution is a light mapping, not full 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 description opens with a specific verb and resource ('Discover games'), then lists concrete criteria (tags, max price, on-sale, platform) and a personalization option. It closes by naming the sibling tool it is not ('not "games like X" (use steam_recommend for that)'), which makes the purpose unmistakable and distinct from the closest sibling.

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 explicitly says when to use the tool (filter-based search) and when not to ('not "games like X"'), and names the alternative (steam_recommend). It does not mention other sibling tools like steam_search_apps for keyword search or steam_get_featured_specials for curated lists, so the guidance is good but not exhaustive.

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, so the description does not need to repeat safety. It adds the scope clarification (friends' libraries vs store search) but does not disclose potential performance/rate-limit implications of checking many friends, which the schema notes. It is not contradictory and adds some 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?

One sentence with no fluff; the key action is front-loaded, and the clarifying note about store search is useful.

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 a clear purpose and annotated read-only, the description provides the essential 'who can I play with' context, but does not mention output format (though 'List' implies a list) or that it may make multiple lookups. It is largely complete given the schema.

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 schema includes full descriptions for each parameter (appid, limit, steamid, max_friends, playing_now, response_format), so schema coverage is high. The description does not elaborate on parameters, so it adds no extra semantics; baseline 3 is appropriate.

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 uses a specific verb (List) and resource (which of a user's friends own a game), and clarifies it is about friends' libraries not store search, distinguishing it from search tools. It is clear and 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?

It implies the usage context 'who can I play X with' and explicitly excludes store search, providing clear context. However, it does not name alternative sibling tools like steam_get_friend_list or state when not to use it, so it lacks explicit exclusions beyond store search.

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 readOnlyHint annotation already covers the safety profile, and the description adds a small amount of scope context ('comprehensive store details'). It does not disclose behavioral details such as output format, default field inclusion, or potential size of the response, but given the read-only annotation, the description is adequate.

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, well-crafted sentence that front-loads the action and adds a value proposition. Every word earns its place and there is no unnecessary detail or repetition.

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 gives a clear purpose but is vague about what 'comprehensive store details' actually includes, and without an output schema the agent cannot infer the response shape. The schema's parameters (response_format, include_long_description, etc.) partially fill this gap, but the description leaves key expectations implicit.

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 description does not mention any parameters or their semantics. Schema description coverage is 0% because the single top-level `params` property has no description, so the description would need to compensate but does not. The nested $defs do provide detailed parameter documentation, but the description itself adds no value 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 uses a specific verb and resource ('Get comprehensive store details for a game') and positions itself as 'the best tell me about X tool,' which clearly distinguishes it from more specialized siblings like steam_get_app_reviews or steam_get_app_tags. An agent can immediately understand what this tool is for and where it fits among the alternatives.

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 a general use case ('tell me about X') but does not explicitly state when to use this tool over alternatives, nor does it name any sibling tools or exclusions. It gives a hint of context but leaves the routing decision to the agent.

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, so the description doesn't need to restate that. It adds minor context by specifying the type of content (patch notes, announcements). However, it does not disclose potential rate limits, error behavior, or the fact that response_format can be json/markdown. With annotations covering safety, a 3 is appropriate.

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, focused sentence with no filler. It front-loads the core action and resource, and the parenthetical examples add value without bloat.

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 tool is relatively simple with one required parameter, but the description omits usage guidance and parameter semantics. There is no output schema to clarify return values. While the read-only annotation covers safety, an agent would benefit from knowing the response_format options or typical use cases. The description is functional but not fully complete for optimal tool selection.

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%, meaning the description should compensate for parameter explanations. It does not mention appid, count, or response_format at all. The schema itself provides only minimal descriptions (e.g., 'Steam application (game) ID.'), so the agent gets no additional clarity from the description.

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 (get), the resource (recent news/update posts for a game), and provides concrete examples (patch notes, announcements). It differentiates from sibling tools like steam_get_app_details or steam_get_app_reviews by focusing specifically on news content.

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 on when to use this tool versus alternatives. There is no mention of 'use this for news/updates, use steam_get_app_details for metadata' or any situational context. The agent must infer from the name and description 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, covering the safety profile. The description adds one behavioral detail beyond annotations: prices come back in each region's own local currency. It does not disclose behavior for unsupported/unknown country codes, rate limits, or output structure, but for a simple read-only lookup the annotation lowers the burden.

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 12-word sentence front-loaded with the verb 'Compare'. Zero filler or redundancy; the parenthetical about local currency earns its place because it clarifies the return behavior.

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 tool is simple: one required param (appid), two optional params fully documented in the schema including the output format enum, and readOnlyHint covering safety. The description supplies the core scenario. The only real gap is the absence of an output schema, leaving the exact return shape unspecified, but that is minor for a straightforward price comparison tool.

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?

Despite the 0% coverage signal, the visible input schema actually documents all three parameters well: appid as the Steam ID, countries with max 20 and local-currency behavior, and response_format as a markdown/json enum with a default. The description adds little beyond restating the local-currency note already present in the schema's countries description, so the schema carries the weight and the baseline 3 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?

States a specific verb ('Compare'), resource ('a game's price'), and scope ('across regions, each in its own local currency'). Among 40+ siblings, none offer regional price comparison, so an agent can immediately tell this apart from steam_get_market_price (community market) and steam_get_app_details (general app 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 description is purely a purpose statement and offers no explicit when-to-use or when-not-to-use guidance. It never mentions alternatives such as steam_get_market_price or steam_get_app_details, nor states conditions (e.g., 'when you need to compare store prices across countries'). Usage must be entirely inferred from the name and one-line purpose.

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 readOnlyHint annotation already signals a safe read operation. The description adds a small amount of context by mentioning 'lifetime and/or recent', which maps to the review_filter parameter. However, it does not disclose other behavioral traits like rate limits, pagination, or the fact that the summary is always returned regardless of limit. It adds some value beyond annotations but remains limited.

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 primary purpose. It is appropriately sized and free of filler. It could arguably include a note about the sibling analysis tool, but as is, it is efficient and not overly verbose.

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 many parameters, the description is minimal. It explains the core function (score and samples) and the lifetime/recent scope, but it does not mention the response_format option, language/country filters, or the fact that the score summary is always returned. The rich schema compensates for some of this, but the description still lacks enough context to differentiate from steam_analyze_app_reviews and to guide parameter choices.

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 schema itself provides detailed descriptions for most sub-parameters (appid, limit, language, day_range, review_type, purchase_type, review_filter, response_format, recent_max_reviews). The tool description adds no parameter-specific information, and schema description coverage is 0% from the description's perspective. Since the schema already carries the meaning, the baseline of 3 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 states a clear verb ('Get') and resource ('review score and sample reviews') with a scope qualifier ('for a game (lifetime and/or recent)'). It is specific and understandable, but it does not explicitly differentiate from the sibling steam_analyze_app_reviews, which likely performs a deeper analysis. Thus it is clear but not fully distinguishing.

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 provided on when to use this tool versus alternatives such as steam_analyze_app_reviews or other review-related tools. The description gives no conditions, exclusions, or recommendations, leaving the agent to infer usage from context.

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 readOnlyHint annotation already covers safety, and the description adds that tags are ordered by community weight. However, it does not disclose edge behavior such as how missing or invalid appids are handled, whether tags are localized via country_code, or the exact return structure.

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?

One tight, front-loaded sentence with zero filler. The tag examples and 'by weight' qualifier earn their place and clarify the output without bloating the definition.

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 tool, the description plus schema is mostly usable, but there is no output schema and the description does not mention the optional parameters or provide enough usage context to distinguish it from the 30+ sibling tools. An agent could call it correctly with just appid, but would not know about response_format or country_code behavior.

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 clarifies that appid refers to a game and that 'top' tags relate to limit/ordering, but it never explains country_code, response_format, or the meaning of limit beyond the schema's own default. This is only minimal 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 description uses a specific verb ('Get'), a clear resource ('a game's top community tags'), and concrete examples (Souls-like, Roguelike, Cozy) plus a sorting criterion ('by weight'). This makes the tool's purpose unambiguous and distinguishes it from sibling tools like steam_get_app_details or steam_get_app_reviews.

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 for when to choose this tool over alternatives, and no exclusions or prerequisites are stated. An agent must infer from the name and examples that this is for community tag data, with no explicit routing among the many Steam sibling tools.

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 annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds a useful behavioral nuance by emphasizing 'currently in-game' and 'live concurrency', implying a real-time snapshot rather than historical data. It does not disclose failure modes, zero-count behavior, or rate limiting, but given the strong annotation coverage, this is acceptable.

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, tightly worded sentence carries the core purpose and behavioral qualifier with no filler. All information is front-loaded and easily parsed.

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 one required parameter and a clear return concept, the description plus schema is nearly sufficient to invoke it correctly. The only notable gap is the lack of usage guidance, which is already penalized separately; the return value is adequately implied by 'number of players'.

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 context signal reports 0% schema description coverage, so the description should compensate for parameter meaning, but it does not. 'For a title' loosely alludes to appid, and response_format is never mentioned, leaving the agent to rely on parameter names and enum values alone.

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 verb ('Get'), a specific resource ('number of players currently in-game'), and a clear scoping qualifier ('for a title', 'live concurrency'). It is immediately distinguishable from the many sibling steam_get_* tools, none of which target live concurrent player counts.

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 alternatives, nor are any exclusion criteria or sibling comparisons mentioned. The intended use is only implied by the name and the description's phrasing, so an agent has to infer the use-case context.

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 readOnlyHint annotation already covers the safety profile, and the description adds the useful behavioral detail that the result is one of Verified, Playable, Unsupported, or Unknown. It does not disclose other behavior such as availability of a full report or handling of invalid appids, which is a minor gap for a simple lookup.

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 states the purpose and the exact output values without wasting words. Every word earns its place.

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 lookup, the description plus schema covers the required input and expected output categories. However, it omits usage context and relies entirely on the schema for parameter meaning, leaving the definition 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?

With schema description coverage reported at 0%, the description needed to compensate, but it only implies that a game must be identified and never mentions appid, language, or response_format. The input schema itself documents the fields, so the description contributes almost 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 (Steam Deck rating) and enumerates the four possible values, which distinguishes it from sibling Steam tools at a glance. It lacks an explicit verb like 'retrieve' or 'return', but the tool name supplies the 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?

No guidance is given about when to use this tool versus alternatives such as steam_get_app_details or steam_analyze_game. The description states only what the rating is, not the conditions that should lead an agent to choose this tool.

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, so the description is not required to restate that. However, it adds only 'optionally with live prices and sale status,' which is a capability but not a behavioral disclosure. It omits notable behaviors such as the one store lookup per DLC during enrichment, potential slowness, or rate-limit implications. With annotations covering safety, the description contributes minimal additional behavioral 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?

The description is a single, efficient sentence with no wasted words and the verb front-loaded. It is concise and easy to parse. However, it is arguably too terse for a tool with this many options; a bit more structure (e.g., mentioning enrichment or response formats) would not make it verbose.

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, including enrichment, country code, and response format, the description is extremely sparse. There is no output schema, so the description should at least hint at what the returned data looks like, but it only says 'List DLC.' It omits prerequisites (base game appid), performance caveats (enrichment is concurrent), and the meaning of options like on_sale_only. This is far from complete for an agent to call 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%, meaning the tool description does not mention any parameters. While the schema itself provides descriptions for appid, limit, enrich, and on_sale_only, the description fails to compensate for the missing parameter semantics (country_code, response_format) or to reinforce the schema's details. Since coverage from the description is zero and the tool has six parameters, the description must add value but does not.

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 ('List') and the resource ('a game's DLC'), and hints at optional features (live prices, sale status). It is distinct from siblings like steam_get_app_details or steam_get_package_details because 'DLC' is a specific resource, but it does not explicitly name an alternative or contrast itself, so it falls 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?

The description gives no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites (e.g., needing a base game appid), or when to prefer a different tool like steam_get_app_details. The agent must infer usage from the name and schema 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, so the read-only nature is covered. The description adds the 'currently ON SALE' scoping and 'featured specials' context, but does not disclose details such as regional pricing behavior or response format.

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. Every word contributes to identifying the resource and scope.

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 list tool, the description plus schema is adequate: readOnlyHint covers safety, and the schema documents parameters and defaults. It would be stronger if it stated the return shape (e.g., a list of games with prices/discounts), but no output schema exists.

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 description itself says nothing about limit, country_code, or response_format. However, the input schema's nested $defs provides descriptions and defaults for all three, so the structured data carries the parameter burden; the description adds no extra semantic value.

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 verb ('List'), a specific resource ('games currently ON SALE ... on the Steam store'), and clarifies 'featured specials' as sale items. It is clearly distinct from broader discovery tools like steam_discover, though it does not explicitly name a sibling alternative.

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 'currently ON SALE' implies this tool should be used when the agent needs discounted featured games, but there is no explicit when-to-use, prerequisite, or exclusion guidance relative to the many sibling store tools.

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?

readOnlyHint=true already establishes this as a safe read-only operation, and 'List' is consistent with that. The description adds the useful enrichment detail ('name and current status'), but it does not disclose pagination behavior, privacy limitations, or error/rate-limit behavior. With annotations covering safety, this is adequate 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 sentence with no filler: main action first, resource second, and enrichment last. It is immediately scannable and every word contributes meaning.

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 annotations and schema cover safety and arguments, but there is no output schema and the description only says the result is 'enriched with name and current status.' It does not mention the markdown/json response_format option, pagination, or cases where friend data may be unavailable or private. This is adequate for a simple read-only list tool but has clear 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 nested schema fully documents all effective parameters (limit, offset, steamid, online_only, response_format), including the steamid fallback behavior. The tool description itself adds no parameter-level meaning, but because the schema does the heavy lifting, the baseline of 3 is appropriate.

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?

Description opens with a specific verb ('List') and a clear resource ('a user's Steam friends'), then adds 'enriched with name and current status' to define the output. This distinguishes it from siblings like steam_get_player_summary, which targets a single player summary rather than the friend 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?

The description gives no guidance on when to use this tool versus alternatives, nor does it mention when to omit steamid to fall back to the configured STEAM_USER. With many sibling tools that involve players and friends, the selection context is left entirely 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?

Annotations already declare readOnlyHint=true, covering the safety profile. The description adds the 'not user-specific' distinction, which is useful, but it does not disclose behavior like pagination limits or output format variations. Given the annotation coverage, a 3 is appropriate—the description adds some context but not rich behavioral detail.

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, tight sentence with no fluff. It front-loads the core purpose and includes a scoping qualifier, making it efficient and easy to parse.

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 is incomplete for a tool with three parameters and no output schema. It does not explain how limit works, what response_format options exist, or what the returned data structure looks like. An agent would need to rely on the schema alone, which partially covers limit and response_format, but the overall tool behavior is underspecified.

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 carries the full burden for explaining parameters. It fails to mention appid (required), limit, or response_format. The schema itself has descriptions for limit and response_format, but the tool description does not reinforce or clarify them. With zero coverage and no compensation, this is a critical 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 clearly states the verb 'Get', the resource 'achievement and stat definitions for a game', and explicitly scopes it as 'not user-specific'. This distinguishes it from user-specific siblings like steam_get_player_achievements and steam_get_user_game_stats without needing to read their schemas.

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 'not user-specific' gives implied context about when to use this tool (for game-wide definitions) but does not explicitly name alternatives or state when not to use it. An agent might infer that for user-specific data it should use another tool, but the description offers no direct routing guidance.

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 readOnlyHint annotation already covers the safety profile, and the description adds semantic context by clarifying this returns community-wide rarity rather than per-player unlock status. However, it does not disclose sorting behavior, output shape, or any other behavioral traits beyond the purpose statement. No contradiction with annotations.

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 states the core action, resource, and scope with no filler or repetition. Every word contributes to the meaning.

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 statistics lookup, the description plus schema cover the necessary inputs and the core semantic of the result. It is slightly incomplete because it does not explicitly route the agent away from similar sibling tools, but the tool is otherwise adequately specified.

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 description itself adds no parameter-level guidance, but the input schema thoroughly documents appid, limit, and response_format. Since the schema carries the parameter semantics, a baseline score of 3 is appropriate.

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 uses a specific verb and resource: 'Get the global unlock percentage (rarity) of each achievement in a game.' The word 'global' clearly distinguishes this from player-specific achievement tools, and 'rarity' conveys the output's meaning.

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 context is only implied by 'global' and 'rarity.' There is no explicit statement about when to prefer this tool over siblings like steam_get_player_achievements or steam_get_rarest_unlocks, and no when-not-to-use guidance.

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 readOnlyHint annotation already conveys that this is a safe read operation, and the description is consistent with that. However, the description adds little beyond the annotation—only noting the two item types. It does not disclose sampling behavior, pagination, or the configurable defaults, which could affect user expectations. Since the annotation covers the core safety aspect, a 3 is acceptable but not standout.

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, well-structured sentence that states the core purpose concisely. It is front-loaded and has no filler. The only reason not to give a 5 is that it omits any hint at additional behavior or parameters, but as a pure purpose statement it is both concise and effective.

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 tool has seven parameters, no output schema, and the description only covers the bare purpose. It does not explain that output can be markdown or json, that large inventories are sampled rather than fully retrieved, or that default behaviors exist. For a tool with this complexity, the description is incomplete and leaves the agent without important context about what to expect from the tool's execution.

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 description does not mention any parameters, and the context signal indicates 0% coverage of parameters in the description. However, the input schema itself provides extensive descriptions for all seven parameters (appid, count, limit, steamid, language, context_id, response_format), so the schema carries full semantic weight. Per the rubric, baseline 3 is appropriate when the schema is rich and the description adds no redundant detail.

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 action ('List') and the resource ('a user's Steam inventory'), and additionally distinguishes between the two item categories (game items or generic Community items). This is specific and unambiguous, and no sibling tool appears to overlap with this functionality, so no extra differentiation is needed.

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 provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or mention that it should be used for inventory queries specifically. The agent is left to infer usage solely from the tool name and description, which is insufficient for a tool with many siblings.

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, so the safety profile is covered. The description adds that it returns rarity and condition, which is output content rather than behavioral disclosure. No side effects, rate limits, or authentication requirements are mentioned, but the annotation covers the main behavioral aspect (read-only). The description does not contradict annotations.

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 with no fluff. It front-loads the core purpose and includes relevant details (rarity, condition) without verbosity. However, it is so brief that it borders on under-specification, though that is a separate concern from conciseness itself.

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 multiple parameters and a specific input format (market_hash_name, currency codes), the description is too sparse. It does not explain how to construct the hash name, when to set include_item_details to false, or what response_format options mean. The schema covers these, but the description adds no context to help an agent decide whether this tool is appropriate or how to call it correctly. It relies entirely on the schema, which is not enough for a complex market lookup.

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%, meaning the description provides no parameter information. The schema itself has thorough descriptions for each parameter (appid, currency, market_hash_name, etc.), but the rule states that with low coverage the description must compensate. It does not, so an agent must rely entirely on the schema without any high-level guidance on how parameters relate to the tool's purpose.

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 it retrieves the Community Market price for a single item, and mentions rarity and condition as part of the result. This is a specific verb+resource combination, though it does not explicitly differentiate from sibling tools like steam_get_app_regional_pricing, which also deals with pricing but for regional store pricing rather than market.

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 no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or any context about when market price data is appropriate. An agent must infer usage from the tool name and schema, which is insufficient for confident selection among many Steam tools.

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, so the safety profile is covered. The description adds the return detail of 'total and recent hours played', which is useful but not extensive. No mention of rate limits, errors, or what happens when steamid is omitted, but that is partially covered by the schema.

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 sentence with zero waste. The core purpose is front-loaded, and the return details are appended without fluff.

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 listing tool with no output schema, the description covers the essential purpose and return fields. Pagination and sorting defaults are documented in the schema, so nothing critical is missing for an agent 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?

The input schema provides detailed descriptions for all six parameters (limit, offset, sort_by, steamid, response_format, include_free_games), giving high schema coverage. The tool description adds minimal parameter context beyond the return fields, so the baseline 3 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 uses a specific verb ('List') and resource ('games a user owns') and adds return detail ('total and recent hours played'). It is clear but does not explicitly distinguish from the sibling steam_get_recently_played_games, which overlaps in scope; the distinction is implied by the word 'owns'.

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 explicit guidance on when to use this tool versus alternatives like steam_get_recently_played_games or steam_get_wishlist. The purpose is clear enough to infer usage, but the description provides no exclusions or alternative routing.

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, so the read-only safety is covered. The description adds scoping context that it operates specifically on packages, but it doesn't disclose rate limits, external API behavior, or output format beyond what annotations imply.

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, information-dense sentence that front-loads the core action and resource. No filler or repetition of the tool name.

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 store-details lookup with well-documented parameters and a readOnlyHint annotation, the definition is nearly sufficient. It lacks an explicit statement of what fields 'store details' includes, but the response_format parameter and schema mitigate that gap.

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 description itself does not discuss parameters, but the input schema provides thorough descriptions for packageid (including the distinction from app IDs), country_code, and response_format. With rich schema coverage, the baseline of 3 applies despite no param info in the description.

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 states the specific action 'Get store details' and clarifies the resource as a Steam package (a sub/bundle of one or more games), which distinguishes it from app-level tools like steam_get_app_details. It doesn't explicitly name sibling alternatives, so it misses the top score.

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 package/bundle clarification implies this tool is for package IDs rather than app IDs, but no explicit when-to-use or alternative routing is given. The agent must infer when to select this over steam_get_app_details or steam_get_dlc.

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 only restates the read-only nature already captured by the readOnlyHint annotation and contributes no additional behavioral context such as rate limits, auth requirements, response shape, or the limit behavior on locked achievements. It adds no value beyond the annotations.

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 verb and object. It contains no fluff, but it is so minimal that it omits useful context. As a concise framing of the core purpose, it is well-structured, though not maximally informative.

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 and no output schema, the description is insufficiently complete. It doesn't explain what 'achievement progress' encompasses (total, unlocked, locked), how the limit affects the returned list, or how omitted steamid resolves to the configured user. The agent must infer result semantics and edge cases from parameter names and the schema.

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 description does not mention parameters, but the input schema provides detailed descriptions for all five parameters (appid, limit, steamid, language, response_format), including examples, defaults, and format constraints. Since the schema comprehensively documents parameter semantics, the description adds no incremental meaning but the baseline of 3 is appropriate.

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 uses a specific verb and resource ('Get a user's achievement progress for a specific game'), which clearly identifies the tool's function. It implicitly differentiates from siblings like steam_get_user_game_stats or steam_get_global_achievement_percentages by focusing on 'achievement progress' for a single user and game, though it does not explicitly name alternatives.

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 provided on when to use this tool versus alternatives. It does not mention selection criteria, exclusions, or related tools such as steam_get_global_achievement_percentages or steam_get_user_game_stats that might overlap. The agent must infer appropriate usage 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 carry readOnlyHint=true, so the read-only nature is covered. The description adds no further behavioral disclosures such as the ability to omit steamid to fall back to the configured STEAM_USER, response formatting options, or rate-limit behavior. It is consistent with the annotation but contributes little beyond it.

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 sentence with no filler. The key information ('badges' and 'XP breakdown') is front-loaded, making it immediately scannable by an agent.

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 tool with no output schema, the description reasonably conveys what data is returned, and the input schema covers the parameter details. The main gap is the lack of explicit guidance on when to use this tool instead of the closely related steam_get_steam_level or achievement tools, and no mention of the default-user behavior.

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 at the top level is 0% (the single 'params' property has no description in the schema), and the tool description does not compensate by explaining accepted steamid formats, the optional vanity-name/full-URL formats, the default to the configured user, or the response_format option. The nested schema fields do have descriptions, but the description text itself adds no parameter 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 states a specific verb ('Get'), a specific resource ('a user's badges'), and adds a distinctive detail ('the XP breakdown behind their Steam level') that differentiates it from the many player-related sibling tools such as steam_get_steam_level and steam_get_player_summary. Any agent can tell this tool is about badges plus the XP composition of the player's level.

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 use case is implied: if you need a user's badges or level XP breakdown, this is the tool. However, it does not explicitly state when to prefer it over closely related tools like steam_get_steam_level or steam_get_player_achievements, nor does it give any exclusions or alternative routing. The guidance is present only by inference from the noun phrase.

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, so the description is not required to restate safety. It adds the specific ban categories covered, but it does not disclose behavior for invalid steamids, rate limits, or the exact return structure. The added detail is useful but modest, so a mid-range score is appropriate.

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 sentence of ten words, front-loaded with the verb and resource. Every word contributes meaning, and there is no redundancy or filler. It is an exemplary model of concise writing for a tool description.

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, no mention of response_format, and no parameter details in the description, an agent lacks essential information about how to format the request and what the response contains. The description is too terse to support correct invocation beyond the simplest scenario.

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%, and the description does not mention the required steamid parameter or the response_format parameter. It only says 'for a user', forcing the agent to inspect the schema to learn how to specify the user. The description fails to compensate for the low 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 names a specific resource (ban status) and enumerates the ban categories (VAC/game/community/economy), which clearly distinguishes it from sibling tools like steam_get_player_summary or steam_get_player_achievements. The verb 'Get' and resource are explicit, leaving no ambiguity about what the tool does.

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 ban status is needed, but it provides no explicit when-to-use or when-not-to-use guidance and does not reference any sibling tools. An agent can infer its purpose from the wording, but there is no routing or exclusion advice.

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 the description says 'Get', so it is consistent. The description adds slight behavioral context by noting it supports multiple users at once, but it does not disclose rate limits, privacy handling, or vanity URL expansion.

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 with no filler. It front-loads the action and resource.

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 tool with a detailed schema and readOnlyHint annotation, this description provides sufficient context for invocation. It lacks guidance on return values or edge cases such as private profiles or rate limits, but the schema fills in identifier and format 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?

The description does not add parameter semantics beyond the input schema, which already documents steamids as a list of SteamID64/vanity/profile URLs (max 100) and response_format with markdown/json. Given the schema provides this information, the lack of param details in the description is acceptable, but it adds no extra 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 uses a clear verb ('Get'), names the resource ('profile + current status'), and specifies scope ('one or more Steam users'). This distinguishes it from sibling user-related tools like steam_get_player_bans or steam_get_friend_list, which target different specific 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?

No explicit when-to-use or alternative routing is given. However, the description implies it is the tool for retrieving a player's profile and current online status, but it does not name alternatives or exclusion conditions, so guidance is only implied.

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 readOnlyHint annotation already establishes that this is a safe read operation. The description adds the ranking criterion ('by global unlock %') which is a useful behavioral detail, but does not disclose return format, pagination, or error behavior. With annotations covering safety, the description adds minimal extra context beyond the core purpose.

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 sentence that is front-loaded with the core purpose and the key differentiator ('by global unlock %'). Zero filler; every word earns its place.

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 tool has moderate complexity (5 params, all optional except appid) and no output schema. The description is sufficient to understand what the tool returns conceptually (a list of achievements), but does not hint at the response format, sorting order beyond rarity, or how to use the response_format parameter. Given the annotations and schema richness, the description is adequate but not comprehensive.

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 already provides detailed descriptions for all five parameters (appid, limit, steamid, language, response_format). The description does not add any parameter-specific meaning, but since schema coverage is complete, the baseline of 3 applies. The description's mention of 'by global unlock %' indirectly clarifies the sorting logic that affects the limit parameter, but this is not explicitly tied to the parameter.

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 states a specific verb ('Show'), a specific resource ('player's RAREST unlocked achievements in a game'), and the ranking criterion ('by global unlock %'). It clearly distinguishes from siblings like steam_get_player_achievements (all achievements) and steam_get_global_achievement_percentages (global percentages only) by emphasizing rarity and player-specificity.

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 when to use this tool (when you need the rarest unlocks for a player) but does not explicitly name alternatives or state exclusions. It lacks the explicit routing to sibling tools that would make usage guidance strong.

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 readOnlyHint annotation already signals that this is a safe read operation, and the description's 'List' is consistent. The description adds no extra behavioral context beyond that, such as rate limits, authentication requirements, or what happens if steamid is omitted (though the schema mentions defaulting to configured user). It is adequate but minimal given the annotation coverage.

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 zero redundancy. It communicates the core purpose and output in the most efficient way possible.

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 tool, the description covers the basic purpose and hints at the output ('with hours'), but it does not explain the full return structure, the optional nature of steamid, or the response_format option. Since there is no output schema, the description could provide more detail about what the agent will receive. It is minimally adequate but leaves 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 reported as 0% for the top-level params, and the description does not mention any parameters. It says 'a user' but does not explain how the user is specified or that the response_format parameter exists. The nested schema descriptions for steamid and response_format provide some detail, but the description fails to compensate for the low coverage and adds no parameter guidance.

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 states a clear verb ('List'), a specific resource ('games a user has played'), a time scope ('last two weeks'), and an output detail ('with hours'). It clearly distinguishes from sibling tools like steam_get_owned_games (which lists all owned games) and steam_get_player_summary (which summarizes player info).

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 provides no guidance on when to use this tool versus alternatives. It does not mention any exclusion criteria, alternatives, or contextual conditions. An agent must infer that this is for recent play history, but there is no explicit routing guidance among the 40+ siblings.

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 no behavioral context beyond what annotations already provide. With readOnlyHint=true, the agent knows it's safe, but the description does not disclose potential errors (e.g., private profile), rate limits, or other behavioral traits. It merely restates the purpose.

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, clear sentence that states the core purpose. It is concise and front-loaded with the key information. Every word earns its place.

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 getter with no output schema, the description should explain what the return value looks like or at least provide usage context. It does neither. The schema covers parameters, but the description lacks guidance on when to use this tool or what to expect in the response.

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 description does not mention any parameters. Schema description coverage is 0%, so the description should compensate for the lack of parameter explanation. The schema itself has detailed descriptions for steamid and response_format, but the tool description adds no value in helping the agent understand parameter usage.

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 verb 'Get' and the resource 'user's Steam community level' with a clarifying parenthetical. It is specific enough to understand the tool's purpose, but it does not explicitly differentiate from siblings like steam_get_player_summary which might also include level information.

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 usage guidance is provided. The description does not mention when to use this tool over alternatives, nor does it suggest any context where this should not be used. There is no mention of prerequisites or related tools.

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 readOnlyHint annotation already communicates that this is a safe read operation. The description adds only the section scope and discloses nothing about output format, pagination, or regional-pricing effects, so it provides little behavioral information beyond 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?

A single front-loaded sentence states the action and the main variants without filler. Every word earns its place and the description is appropriately short for a simple list operation.

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 list tool with a simple scope, the description is nearly sufficient when paired with the schema. However, it omits the 'specials' section, gives no indication of the return format, and does not steer the agent away from similar storefront-list siblings.

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 reported at 0%, so the description should compensate for parameter meaning. It partially covers the 'section' parameter but omits the 'specials' option, and it says nothing about 'limit', 'country_code', or 'response_format'.

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 uses a specific verb ('List') and a clear resource ('Steam storefront section'), naming three relevant section types. It is not fully precise because it omits the 'specials' section accepted by the schema and does not differentiate the tool from siblings like steam_get_featured_specials.

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 provides no guidance on when to use this tool versus alternatives such as steam_get_featured_specials or steam_discover. The general context is clear, but there are no exclusions or selection criteria for edge cases like specials.

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 provide readOnlyHint=true, so the description does not need to restate that. The description adds a high-level behavioral trait (comparing reviews around updates) but does not disclose return formats, pagination, or other processing details. It adds minimal value beyond 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?

The description is a single, concise sentence that front-loads the core action and includes an illustrative example. Every word serves a purpose, and there is no filler or 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?

The tool has 7 parameters and no output schema, so the description could hint at the return format or caveats. It does not mention response_format or what the output looks like, though the schema provides defaults. The high-level purpose is clear, but the description leaves some context unspecified.

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 schema already includes descriptions for most parameters (days, appid, language, window_days, purchase_type), giving the agent adequate semantics. The description itself adds no parameter-specific meaning, so the schema carries the load. Coverage is sufficient, warranting a baseline 3.

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 uses a specific verb ('Show') and a clear resource ('how a game's reviews moved around each recent update'), and adds an illustrative example ('did the last patch hurt it?') that distinguishes it from sibling tools like steam_get_app_reviews or steam_analyze_app_reviews. The focus on updates makes the tool's purpose unmistakable.

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 use case (analyzing review changes around updates) but does not explicitly state when to prefer this tool over alternatives, nor does it mention exclusions. There is no reference to sibling tools or conditions for use, so guidance is only implicit.

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 readOnlyHint annotation already covers safety, so the bar is lower. The description adds a little context by clarifying the nature of the stats ('kills, wins, distance'), but it does not disclose return shape, missing-stat behavior, or any quirks beyond what the annotation and schema already imply.

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?

One tight, front-loaded sentence that states the core operation and gives immediately useful examples. There is no filler or redundant restatement of the tool name.

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 rich input schema and read-only annotation, the description is almost sufficient for a correct invocation. The main missing piece is explicit routing among the large sibling set, which is already penalized under usage guidelines.

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 already documents all parameters with descriptions, defaults, and examples (e.g., appid values, steamid formats, limit bounds), so the description does not need to repeat them. The description adds no extra parameter-level meaning beyond the phrase 'for a specific game,' which maps to appid.

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 verb ('Get'), a clear resource ('a user's in-game STATS'), and a scope ('for a specific game'), with concrete examples like kills, wins, and distance. This is immediately distinguishable from broader player-summary or achievement-oriented sibling tools.

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 no guidance on when to use this tool versus sibling alternatives such as steam_get_player_achievements or steam_get_game_schema. It also does not mention that steamid is optional and falls back to a configured user, though that information exists in the schema.

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 already present, the description's 'List' is consistent and adds no contradiction. It adds modest domain context by clarifying that groups are communities/clans, but it doesn't disclose defaults, enrichment cost, or output shape—those live in the schema.

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. The parenthetical 'communities/clans' earns its place by disambiguating domain terminology.

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 listing tool with a well-documented schema and annotations, the description is nearly complete for selection and invocation. It doesn't hint at the optional steamid default or the extra-lookup cost of enrichment, but those are covered in the schema, and no output schema is needed for a simple listing response.

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 description mentions no parameters, but the input schema documents each one clearly (limit, enrich, steamid, response_format) with defaults and examples. Since the schema carries the parameter semantics, the description's silence is an acceptable baseline rather than a 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 specific verb (List), resource (Steam groups/communities/clans), and scope (a user belongs to), making the tool's function unambiguous. No sibling tool targets user groups, so the purpose is clearly distinct within the toolset.

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 implicitly states when to use it: whenever a user's Steam groups are needed. There are no overlapping sibling tools, so explicit exclusions are unnecessary; however, the description gives no guidance about when to disable enrichment or how to handle an omitted steamid.

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, so the safety profile is covered. The description adds that the tool can optionally fetch live prices and sale status, which is useful behavioral context beyond the annotation. However, it does not disclose that enrichment costs store lookups or mention potential rate limits or failure modes, so it stops at adequate.

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. It states the action, target, and an optional modifier efficiently. Every word earns its place.

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 gives a clear high-level purpose, but it omits details about output format (markdown/json), user resolution via vanity name or URL, and the meaning of the limit parameter (wishlist priority). The schema covers these, but since there is no output schema, the description could have provided more context about what the agent receives. It is adequate but not fully complete for a tool with several configurable parameters.

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 schema description coverage at 0%, the description must compensate for parameter meaning, but it only hints at enrichment and sale status. It does not explain steamid, limit, country_code, response_format, or the dependency between enrich and on_sale_only. The schema itself has rich descriptions, but the tool description adds only a small amount of parameter-related context.

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 states a specific verb and resource: 'Get a user's Steam wishlist'. It also mentions optional live prices and sale status, which distinguishes it from sibling getters like steam_get_owned_games or steam_get_inventory. The tool is the only wishlist-related sibling, so there is no ambiguity about what it does.

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 provided about when to use this tool versus alternatives. It does not mention how it differs from other user-data getters, nor does it state any conditions (e.g., 'use this when you need wishlist contents, not owned games'). There is no when-not or alternative routing.

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 readOnlyHint=true annotation already covers the safety profile, and the description's 'Get metadata' phrasing is consistent with it. Beyond that, the description adds only scope examples (mod, map, guide, collection) rather than behavioral details such as return shape, markdown-vs-json behavior, failure modes, or rate limits. Consistent but thin, with the annotation lowering the burden.

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: the verb and resource appear first, and the parenthetical item-type list earns its place by disambiguating scope. There is no fluff, redundancy, or restatement of the tool name.

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 lookup with one required parameter, the description covers purpose and scope adequately. Gaps remain: it never mentions the response_format option, what fields 'metadata' includes, or the output shape — and with no output schema present, the description carries that burden and comes up short.

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 schema description coverage reported at 0%, the description partially compensates by clarifying the domain of published_file_id through item-type examples (mod, map, guide, collection). However, it adds nothing about the response_format parameter (markdown/json enum) or the ID format, leaving the optional parameter entirely unexplained by the description.

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 uses a specific verb-resource pair: 'Get metadata for a Steam Workshop item', with clarifying examples of item types (mod, map, guide, collection). Among ~40 steam_* siblings, this is the only Workshop-related tool, so the description cleanly differentiates it from steam_get_app_details, steam_get_game_schema, and the player-focused getters.

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 context is implied by the exclusive Workshop scope — an agent needing an item's metadata can infer this tool is the right choice — but there is no explicit when-to-use guidance, no named alternatives, and no exclusions (e.g., no pointer to steam_get_app_details for app metadata or notes on when not to use 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?

readOnlyHint already signals a safe read, and the description's 'find' aligns with it. However, the description does not disclose the tool's dual modes (owned vs new), the fact that it can derive a group from the host's online friends, or that it ranks suggestions by ownership count.

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?

One front-loaded sentence with no filler. It loses a point because the curt phrasing ('all own') obscures the 'new' mode, so brevity comes at some cost to accuracy.

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 multiple modes, optional friend derivation, and custom output format, a single sentence is thin. The rich parameter schema covers the mechanics, but the description still omits the alternate 'new' mode and gives no sense of the returned artifact.

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 description contributes the group-ownership concept, which relates to steamid/friends/min_friends_owning, but it maps no parameters explicitly. The nested schema is already well-documented, so the description only modestly adds 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 names a concrete resource (co-op games) and the condition (owned by host and friends), making the default 'owned' mode identifiable. It is less specific about the 'new' mode (suggesting games nobody owns) and does not name a sibling, so it is not 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 explicit guidance about when to prefer this over siblings like steam_find_friends_who_own or steam_compare_games. The 'for game night' phrase implies a social use case, but it never states prerequisites, when to supply an explicit friends list, or when to use owned vs new mode.

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 carry readOnlyHint=true, so the safety profile is covered without description effort. The description adds one useful behavioral trait — that output includes shared-tag explanations — but does not disclose return format, pagination, or how steamid ownership exclusion affects results. Modest value-add beyond annotations, not rich 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?

One sentence of roughly 25 words, front-loading the action and the key scoping (seed game vs user taste) before routing to the sibling alternative. Every clause earns its place; no filler.

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 recommendation tool with no output schema, the description covers the core decision factors: what it does, when to use it, and which sibling handles the adjacent case (steam_discover). Remaining gaps — no mention of price filtering, response format choice, or owned-game exclusion — are secondary because the schema documents the parameters, and none of them block correct tool selection.

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 reported at 0%, so the description must compensate, but it only loosely maps two main modes ('seed game' → seed_appid, 'user's taste' → steamid) and says nothing about limit, max_price, tags precedence, response_format, or country_code. The 'like Hades' example helps but is not a substitute for parameter documentation.

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 ('Recommend games'), names two input modes (seed game, user's taste), gives a concrete example ('like Hades'), and notes the explanatory output (shared tags). It explicitly distinguishes itself from steam_discover, making selection unambiguous against a very large sibling set.

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?

Explicitly names the target use cases ('games like X' / 'what should I play') and gives an explicit exclusion with an alternative: 'for filtered search use steam_discover'. This is exactly the when-to-use/when-not-to-use guidance the dimension asks for.

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?

readOnlyHint is true, so the read-only nature is already disclosed by annotations; the description does not contradict it. The description adds no further behavioral details such as error behavior for invalid names, rate limits, or what happens when the input is omitted or already an ID, so it only meets the baseline.

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?

One sentence with no filler; the action, accepted input, and output are all front-loaded. Nothing in the description 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?

For a one-purpose read-only resolver, the description covers what the tool does, what inputs it accepts, and what it returns. Minor gaps remain around the optional steamid behavior and response_format, but the schema documents those, and the core invocation context is clear.

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 description clarifies the primary input semantics (vanity/custom name or profile URL) and the output type, partially compensating for the low reported schema coverage. It does not mention the response_format option or the optional own-name fallback, though those are documented in the nested schema; the tool description adds some, but not complete, parameter 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 names a specific action ('Resolve') and resource ('Steam vanity/custom-URL name or profile URL'), and states the concrete result (a SteamID64). This makes it immediately distinguishable from sibling tools that fetch player or game 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 transformation described implies the use case: when you have a vanity/custom URL or profile URL and need the underlying SteamID64, likely as a precursor to player-ID-based calls. However, it does not explicitly name alternative tools, exclusions, or when not to use it, leaving the guidance implicit rather than explicit.

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 readOnlyHint annotation covers the safety profile, and the description is consistent with a read-only lookup. It adds the scoping nuance (only for known titles) but doesn't disclose additional behavioral details like result format, failure modes, or potential for partial matches. Since annotations already declare read-only, this is acceptable but not enriching.

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 zero waste. The primary purpose and key exclusion are stated immediately, making it highly efficient for an agent to parse and act on.

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 lookup tool with moderate complexity (5 parameters), the description is adequate but misses details on output format (list vs single appid), behavior on no match, and the meaning of response_format. Given no output schema and minimal description, an agent might be uncertain about the expected return. However, the tool is simple enough that a 3 is fair.

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 description adds no parameter-specific meaning beyond mentioning 'title', which maps to the query field. The schema provides descriptions for query, limit, and language, but country_code and response_format have none, and the description doesn't help clarify them. With 0% parameter coverage from the description and incomplete schema coverage, this is a notable 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 clearly states the verb (look up), resource (appid), and context (by title). It explicitly contrasts with discovery, recommendations, and buy decisions, which helps the agent distinguish it from siblings like steam_discover, steam_recommend, and steam_should_i_buy.

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 specifies when to use (when you already know the name) and when not to use (not for discovery, recommendations, or buy decisions). While it doesn't name specific alternative tools, the exclusions are clear and actionable. Could have been stronger by pointing to named siblings, but the guidance is solid.

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 declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context by listing the data sources consulted (price, reviews, tags, Metacritic) and the scope (single game). It does not describe the output format or that it returns a recommendation, but given the read-only annotation and the tool's simplicity, the added context is valuable and not contradictory.

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, well-structured sentence that front-loads the core purpose and follows with the distinguishing scope. Every phrase earns its place—no filler, no redundancy. It is an excellent model of concise writing.

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 tool is moderately complex (one call to synthesize multiple signals into a buy decision) and has no output schema. The description covers the purpose and scope but omits what the response looks like (e.g., a recommendation with reasoning, a score, or a binary yes/no). It also lacks parameter guidance. While the purpose is clear, an agent is left guessing about the return format and how to customize the request. This is a meaningful gap, so a 3 is appropriate.

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 description does not explain any parameters. The schema provides descriptions for appid and steamid, but country_code and response_format have no descriptions. With schema description coverage at 0% in the tool description, the description fails to compensate for the two undocumented parameters. It mentions the data sources but does not map them to parameters, leaving an agent uncertain about how to set country_code or response_format. This is a significant 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 clearly states a specific verb ('Decide whether to buy') and a specific resource ('ONE specific game'), and enumerates the key inputs (price, reviews, tags, Metacritic, taste match). It explicitly scopes to evaluating a single known game, which distinguishes it from sibling tools like steam_search_apps or steam_discover that focus on discovery. This is a precise, unambiguous purpose.

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 explicitly states the use case: 'for evaluating a single known game, not finding new ones.' This gives clear context for when to use this tool versus alternatives, though it does not name specific sibling tools or provide explicit exclusions beyond the discovery contrast. A slight upgrade would name alternatives, but the current guidance is sufficient.

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