Steam MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.14.0
Disambiguation4/5
Most tools are clearly distinct, targeting specific Steam API endpoints (e.g., get_owned_games vs. get_recently_played_games). A few discovery/decision tools like steam_discover, steam_recommend, and steam_should_i_buy could be confused, but their descriptions specify exact use cases, reducing ambiguity.
Naming Consistency5/5
All tools follow the 'steam_<verb>_<object>' pattern with snake_case. Even complex verbs like find_friends_who_own, analyze_library, and plan_coop_night are consistent and predictable. No mixing of styles or conventions.
Tool Count3/5
At 37 tools, this is a large set, but it reflects the enormous breadth of the Steam platform (user profiles, library, store, market, workshop, etc.). While the volume could overwhelm an agent, each tool serves a different API resource, so it is borderline appropriate.
Completeness5/5
The tool surface covers all major read-only Steam features: user information, friends, owned games, achievements, stats, store details, discovery, reviews, pricing, market, workshop, inventory, and community groups. There are no obvious gaps for a read-only Steam API, and workflows like comparing players or analyzing libraries are well-supported.
Average 3.7/5 across 37 of 37 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 64 commits in the last 12 weeks
- Last stable release on July 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds no further behavioral context (e.g., how it aggregates friend libraries, potential rate limits, or that 'owned' mode ranks by ownership count). With annotations present, the baseline is satisfied but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that gets to the point immediately. No wasted words, and the core action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (multiple modes, several parameters, output schema), but the description only covers the 'owned' aspect and ignores the 'new' mode for suggesting unpurchased games. The rich schema and annotations cannot compensate for the missing high-level context that would help an agent select and invoke the tool correctly in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 top-level param ('params') with no description, giving 0% schema coverage. The nested properties do have descriptions, but the tool description itself adds no parameter semantics. It does not compensate for the low coverage, leaving the agent to rely entirely on the schema for meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Find') and resource ('co-op games the host and their friends all own') with a clear purpose ('for game night'). This distinguishes it from siblings like steam_get_owned_games and steam_find_friends_who_own, though it does not mention the 'new' mode, which limits full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case ('for game night') but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions. Context signals indicate rich parameters like 'mode' and 'friends', but the description gives no hint of when to choose this over simpler library lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, open-world, idempotent, and non-destructive aspects. The description adds a minor scope clarification (game items vs. community items) but does not mention important behavioral traits like sampling behavior (count parameter), rate limits, or authentication requirements. Since annotations handle the safety profile, a mid-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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clearly worded sentence with no redundant words. It front-loads the verb and object, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with six parameters and an output schema, but the description alone is too sparse to guide selection among 36 siblings. The schema and annotations partially compensate, but the description lacks situational guidance, making it minimally viable rather than comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any of the six parameters (appid, count, steamid, language, context_id, response_format), despite the schema having detailed property descriptions. With 0% coverage in the description, it fails to compensate for parameter meaning, leaving the agent to rely entirely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List') and resource ('a user's Steam inventory'), and adds the clarification of 'game items or generic Community items,' which distinguishes inventory from related concepts like owned games or badges. However, it does not explicitly differentiate from sibling tools, 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.
Usage Guidelines2/5
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 like steam_get_owned_games, steam_get_player_badges, or steam_get_market_price. It does not mention context, prerequisites, or exclusions, leaving the agent without selection rationale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds little behavioral context beyond the section list, and that list is incomplete (missing 'specials'). No mention of rate limits, regional pricing behavior, or output format defaults, leaving the description to add minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 verb and resource clearly and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 strong annotations and an output schema, the description covers the primary function but leaves gaps: missing 'specials', no usage differentiation from near-neighbor tools, and no mention of default response format. The schema fills many details, but the description alone is not sufficiently complete given the dense sibling toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain limit, country_code, or response_format. It partially covers the 'section' parameter but omits the 'specials' option. With schema description coverage reported as 0%, the description should compensate for parameter ambiguity, but it does not, forcing the agent to rely on the nested schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('Steam storefront section'), and names three concrete sections (top sellers, new releases, coming soon). This distinguishes it from siblings like steam_get_featured_specials. However, it omits 'specials' which is a valid section in the schema, creating a minor clarity gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 a standard storefront list like top sellers or new releases) but provides no explicit guidance on alternatives or exclusions. There is no mention of how it differs from similar tools such as steam_get_featured_specials or steam_discover.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds the behavioral detail that each friend is enriched with name and current status, which is useful context. However, it does not disclose pagination behavior, default user handling, or any potential edge cases, so it only modestly extends what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 11 words. Every word earns its place, clearly conveying the key action and the enrichment aspect without fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 with a rich input schema, a high-quality output schema, and strong annotations, this description is mostly complete. It captures the core value proposition (friend list with enrichment). It could be slightly richer by noting how the target user is specified (e.g., uses steamid or defaults to configured STEAM_USER), but that information is already in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schematic description coverage at 0%, the description was expected to compensate for parameter guidance, but it mentions no parameters at all. The input schema itself contains thorough descriptions for steamid, limit, offset, online_only, and response_format, but the tool description adds no extra meaning and relies entirely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists a user's Steam friends and enriches them with name and current status. The verb 'List' and the specific resource ('a user's Steam friends') make the purpose unambiguous, though it does not explicitly contrast with sibling tools like steam_find_friends_who_own or steam_get_player_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites, and no exclusions. There is no mention of when to prefer this over sibling tools such as steam_get_player_summary or steam_find_friends_who_own, leaving usage entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, giving a clear safety profile. The description adds the domain clarification about packages but no further behavioral quirks. This is adequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that precisely states the tool's purpose. Every word earns its place, with no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only fetch tool with a rich schema, an output schema, and comprehensive annotations, the description is nearly complete. It lacks usage differentiation and some regional-pricing context, but those are already covered by the schema and sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description does not mention any parameters, while the schema itself provides solid descriptions for packageid, country_code, and response_format. With 0% parameter coverage in the description, it fails to compensate, though the schema handles most of the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and names a precise resource ('store details for a Steam package'), clarifying that a package is a sub/bundle of games. This distinguishes it from sibling app-related tools, though it does not explicitly name an alternative like steam_get_app_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives such as steam_get_app_details or steam_get_dlc. It only defines what a package is, not the contexts that favor this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, so the description only needs to add context. It adds the detail that the tool returns an XP breakdown, which is useful, but it does not disclose anything about rate limits, auth specifics, or the shape of the XP breakdown. No contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the primary action and resource. Every word adds value, with no repetition, filler, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read-only operation with an output schema and strong annotations. The description is sufficient for an agent to understand the basic purpose, but it could be slightly more complete by mentioning that the user can be specified via steamid or that the response includes detailed XP components. Minor gap given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% according to context signals, meaning the tool description provides no parameter information. The description does not mention steamid or response_format, nor does it compensate for the low coverage. While the schema itself contains descriptions for each parameter, the tool description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('a user's badges') plus a distinguishing detail ('XP breakdown behind their Steam level'). This differentiates it from sibling tools like steam_get_steam_level, which focuses on the level itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It implies use when badges or XP breakdown are needed, but it does not mention any exclusions, prerequisites, or comparison with related tools such as steam_get_steam_level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so safety is clear. The description adds a bit of behavioral context by indicating the response covers 'each achievement' and focuses on 'global unlock percentage', which hints at the return scope. However, it does not disclose rate limits, pagination, or other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, fully front-loaded with the action and resource. Every word contributes to clarity with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter, the description is adequate but minimal. Annotations and output schema cover safety and return structure, but the description lacks usage context or guidance on when to choose this tool over siblings. It does not explain the value of 'rarity' or how this relates to other achievement tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description has 0% schema description coverage, meaning it does not mention any parameters. It does not compensate for the low coverage, even though the input schema provides descriptions for appid and response_format. Since the description adds no meaning beyond what the schema already provides, the score is at the lower end.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the specific resource ('global unlock percentage (rarity) of each achievement in a game'). It distinguishes itself from sibling tools like steam_get_player_achievements (player-specific) and steam_get_rarest_unlocks (user-specific rarest unlocks) by emphasizing 'global' and 'rarity'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 exclusions or alternative tools, leaving the agent to infer from the word 'global' that it is for public statistics. No when-not or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that it covers backlog, playtime distribution, and abandoned games, which gives some behavioral context beyond the annotations, but it doesn't discuss rate limits, data freshness, or any potential edge cases. It's 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence states the core purpose and the three main outputs. No wasted words, perfectly concise while still being informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a rich parameter schema and an output schema (mentioned but not shown), so the description doesn't need to explain return values. However, for an 'analyze whole library' tool, the description omits any mention of how the analysis is structured (e.g., aggregated stats vs. per-game lists) and the overall scope is broad. It's minimally complete but leaves gaps for a first-time user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The main description adds no parameter information, but the input schema provides detailed descriptions for every parameter (e.g., stale_days, abandoned_sort, exclude_temp_clients). Since schema description coverage is effectively 100% from the schema's own field descriptions, the baseline of 3 applies; the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the verb 'analyze' and the resource 'whole game library', then lists three concrete outputs (backlog, playtime distribution, abandoned games). This gives a specific sense of what the tool does and differentiates it from simple retrieval tools like steam_get_owned_games, though it doesn't explicitly compare to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for high-level library analysis rather than raw data retrieval, but it provides no explicit 'when to use' or 'when not to use' guidance and names no alternatives. The use case is clear from context, but there are no exclusions or comparison to other Steam tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only the specificity of 'recent' and examples but no additional behavioral context like return format or pagination. This is minimal but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (13 words) with the verb and resource front-loaded. Every word contributes to meaning, and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, so the description plus schema and annotations provide adequate completeness. An output schema exists, so return values don't need explanation. Minor gap: no mention of default count or response format, but these are in the schema. The lack of usage guidance is the only notable shortfall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% because the description mentions none of the parameters (appid, count, response_format). While the schema itself includes descriptions for each parameter, the description adds no value beyond the schema. The rubric requires compensation at low coverage, which is absent here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action 'Get' and the resource 'recent news/update posts for a game', with clarifying examples 'patch notes, announcements'. This clearly 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no information about when to use this tool versus alternatives. It does not mention scenarios, prerequisites, or alternative tools. The only context is the purpose itself, leaving usage entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds the 'by weight' ordering behavior, which is useful, but does not disclose other potential behavioral traits such as whether the appid must exist or how errors are handled. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and resource, includes illustrative examples, and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's straightforward read-only nature, the presence of an output schema, and strong annotations, the description is largely complete. The main missing element is usage guidance, but that is already covered in the usage_guidelines dimension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description provides no parameter information, resulting in 0% schema description coverage. Although the schema itself has decent descriptions for appid and limit, and country_code/response_format are self-explanatory, the description adds no value beyond the schema and does not compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a game's top community tags, with examples (Souls-like, Roguelike) and ordering by weight. This is a specific verb+resource combination that distinguishes it from sibling Steam tools like get_app_details or 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. While the name and description make the primary use obvious, the description does not mention any exclusions, prerequisites, or alternative tools for similar tasks, which is a gap given the large sibling tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety and side-effect transparency. The description adds 'single item' and 'rarity and condition' but does not disclose the exact match requirement for market_hash_name or the extra request triggered by include_item_details. Since annotations lower the bar, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'Get', and contains no filler. It is appropriately concise for the tool's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The input schema provides detailed descriptions for all parameters, and an output schema exists, so the tool's functionality is well-documented. The description is minimal but adequate for a read-only getter, though it could mention the need for exact market_hash_name and the optional extra request for details, which are covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 any parameter names or values. It only hints at 'rarity and condition' which loosely maps to include_item_details, but this is insufficient compensation for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the Community Market price for a single item, with a specific verb and resource. It distinguishes from sibling tools by focusing on price lookup for one item, and mentions additional output details (rarity/condition).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no required context, and no exclusions. It simply states what it does, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds scope ('per game') but no extra behavioral details like default steamid behavior or output format. It 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, 11 words, directly states the action. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 strong annotations and an output schema, the description states the core function sufficiently. However, it omits helpful context like the optional steamid fallback (described in schema) and doesn't indicate how this relates to sibling tools, but the annotations and output schema cover most of the operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameter names or semantics. Schema description coverage is 0%, and though the schema provides useful descriptions for appid, steamid, language, and response_format, the description fails to compensate for the low coverage as required by the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), identifies the resource ('a user's achievement progress'), and scopes it to 'a specific game', which clearly distinguishes it from siblings like steam_get_global_achievement_percentages or steam_get_user_game_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention that steamid can be omitted to fall back to the configured user, nor does it contrast with related achievement/stats tools. The description offers no exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the context of communities/clans, but does not disclose extra behaviors like the cost of enriched lookups or that the steamid is optional for using the configured default user.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Exactly one sentence, front-loaded with the main action and resource. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has sub-parameters like enrich (which triggers extra lookups), limit, and an optional steamid, a single sentence is too sparse. The rich schema helps, but the description itself is not complete enough to guide an agent on how to invoke correctly or understand trade-offs like the enrich flag.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter information, and schema description coverage is 0%, meaning the description does not compensate for any parameters. The agent is left to rely entirely on the input schema to understand steamid, enrich, limit, and response_format. No added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List the Steam groups (communities/clans) a user belongs to' uses a specific verb (List) and resource (Steam groups) with clear scope (a given user). It distinguishes this tool from sibling tools like steam_get_friend_list or steam_get_owned_games.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is used when you need to see a user's Steam group memberships. However, it does not explicitly mention when to prefer this over alternative sibling tools or exclude any cases, so no explicit when-not guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is fully covered. The description adds the local-currency behavior but nothing about defaults, rate limits, or output details, so it provides only marginal added value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one efficient, front-loaded sentence with no filler. Every word contributes to the core action and output characteristic, making it appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, schema, and annotations together make this minimally viable: a read-only regional-pricing comparison tool with an appid requirement. However, it leaves gaps about default behavior when countries is omitted, the meaning of response_format, and how to distinguish this from sibling price tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema_description_coverage is reported as 0%, so the description must compensate for parameter understanding. It does not mention appid, countries, or response_format, nor any constraints or defaults. The schema alone provides some meaning, but the description adds nothing specific to parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'compare' with the resource 'a game's price across regions,' and the local-currency detail clearly distinguishes it from siblings like steam_get_app_details or steam_get_market_price. It is a clear, non-tautological purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for regional price comparison and currency localization, but it does not explicitly state when to use this tool versus alternative Steam pricing/detail tools, nor does it give exclusions. The usage context is clear but not actionable without some inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it includes total and recent hours, but does not disclose default behaviors such as using the configured Steam user, including free games, or pagination behavior. This is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, directly stating the action and output. It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing operation with well-documented parameters and an output schema, the description is minimal but adequate. It lacks notes on authentication, private profiles, or rate limits, but these are less critical given the annotations and schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters directly, but the input schema provides full descriptions for all parameters (limit, offset, sort_by, steamid, response_format, include_free_games). With schema coverage at 100%, the baseline of 3 applies; the description adds no extra semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource ('games a user owns') with details about the output ('total and recent hours played'). This distinguishes it from siblings like steam_get_recently_played_games, which focuses on recent play sessions rather than the full library.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_recently_played_games or steam_analyze_library. It also doesn't mention prerequisites (e.g., Steam API key) or exclusions, which is important given the broad sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds minimal context beyond 'get' and does not disclose rate limits, auth needs, or output behavior specifics. It aligns with annotations and contributes some value but not rich behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose without any filler. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 rich schema and annotations, the description provides the essential purpose. It omits details like what 'current status' entails or the optional nature of steamids, but those are captured in the schema, making the overall tool definition complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 contains detailed descriptions for steamids and response_format (e.g., accepting SteamID64/vanity names/URLs, fallback to STEAM_USER). Since schema coverage is high for the actual properties, the description need not add more; the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and clearly identifies the resource ('profile + current status') and scope ('for one or more Steam users'). It distinguishes from siblings like steam_get_player_bans or steam_get_friend_list by focusing on the summary information uniquely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 exclusions, prerequisites, or use cases, leaving the agent to infer appropriate usage from the name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds that live prices and sale status can optionally be fetched, which is a behavioral nuance. However, it does not disclose potential costs of enrichment or other side effects beyond what the schema already states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core purpose ('Get a user's Steam wishlist'). Every word earns its place, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is concise and, combined with the rich schema and annotations, gives an agent enough to understand the tool's scope. It doesn't cover every edge case, but the schema and output schema fill in the gaps, making the description adequate for this read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides rich descriptions for parameters like limit, enrich, and on_sale_only. The description's phrase 'optionally with live prices and sale status' loosely maps to the enrich and on_sale_only fields, but it adds no new meaning beyond what the schema already explains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and the resource (a user's Steam wishlist), and mentions the optional enrichment with live prices and sale status, which distinguishes it from sibling tools like steam_get_owned_games or steam_get_recently_played_games.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It is purely a statement of functionality without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the behavioral nuance of 'live concurrency', clarifying that the result is a real-time snapshot rather than a historical or cached value. This goes beyond the annotation baseline, providing useful context about the data's freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with the core verb and object front-loaded. It contains no filler or redundant information, and every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one required parameter, an output schema, and comprehensive annotations, the description is largely sufficient. It does not explain return value structure, but the output schema is expected to cover that. The lack of detail about what 'title' means (e.g., requiring an appid) is a minor gap, but the schema partially addresses it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description does not mention any parameters, and schema description coverage is 0%. While the schema itself provides brief descriptions for 'appid' and 'response_format', the description fails to compensate for the low coverage by explaining that an app ID is required or how to interpret 'title'. The description adds minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to get the number of players currently in-game for a title, with the parenthetical 'live concurrency' adding specificity. It uses a specific verb 'get' and a specific resource 'number of current players', distinguishing it from sibling tools that handle game details, reviews, or player profiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that this is for live data only or that other tools might provide historical or aggregate statistics. The phrase 'live concurrency' implies real-time context, but there is no exclusions or alternative tool references, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructiveHint, covering safety traits. The description adds a minor detail that full profile URLs are accepted as input, but it does not disclose error handling, rate limits, or behavior for invalid inputs. With annotations dominating the safety profile, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and object, and contains no extraneous words. Every word contributes to the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, rich annotations, and an existing output schema, the description sufficiently covers the core operation. It could mention the ability to omit the parameter to use STEAM_USER, but that is documented in the schema. Overall, the context is adequate, with only minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description mentions 'vanity/custom-URL name (or profile URL)' which hints at the 'steamid' parameter's accepted formats, but it does not explain the 'response_format' parameter or the default STEAM_USER behavior. Since schema_description_coverage is 0%, the description should compensate more; however, the schema itself provides detailed parameter descriptions, so the description adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Resolve') and resource ('Steam vanity/custom-URL name or profile URL to a SteamID64'), clearly distinguishing it from sibling tools that operate on already-resolved IDs. It unambiguously states the tool's transformation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need to convert a vanity URL or custom name to a SteamID64. It does not explicitly state when to use this tool over alternatives or mention any exclusions, but the purpose is clear enough that an agent can infer appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the comparison scope (shared games and relative playtime) but does not disclose additional behaviors like missing-profile handling, rate limits, or data source staleness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes meaning, and it conveys the essential comparison operation efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, annotations cover safety, and the input schema is rich. The description plus schema are sufficient for correct invocation; however, it lacks mention of potential restrictions such as Steam profile privacy, which could affect usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not directly explain parameters, but the input schema includes detailed descriptions for steamid_a, steamid_b, limit, and response_format. The description adds high-level result semantics ('shared games and who has played each more') that help understand the tool's purpose, though it does not compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb ('Compare') and resource ('two users' libraries'), and clarifies the output ('shared games and who has played each more'). This clearly differentiates it from sibling tools like steam_get_owned_games or steam_find_friends_who_own.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for comparing two players' libraries, but it does not explicitly state when to use it versus alternatives, mention prerequisites (e.g., public profiles), or provide exclusions. Context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true, idempotentHint true, and destructiveHint false, covering safety. The description adds the useful lifetime/recent distinction but doesn't disclose other behavioral traits like pagination or response details. With annotations, this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler, perfectly sized for the purpose. It front-loads the core function and includes a useful parenthetical scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters) and presence of an output schema, the description is concise but sufficient. It explains the tool's primary purpose and the lifetime/recent distinction, while the schema covers parameter details. It could be more complete with usage examples or alternative guidance, but it's above average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters directly, but the input schema provides detailed descriptions for most parameters (appid, limit, language, day_range, review_type, review_filter, response_format), covering their semantics. The description's mention of 'lifetime and/or recent' aligns with review_filter but adds no unique parameter information, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves review score and sample reviews for a game, with an explicit scope of 'lifetime and/or recent'. This differentiates it from sibling tools like steam_get_app_details or steam_get_app_tags, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when review data is needed, but provides no explicit when-to-use or when-not-to-use guidance, nor does it name alternative tools. It's sufficient but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint:false, covering the safety profile. The description adds the possible rating categories, which is useful context, but it does not disclose any additional behavioral traits such as API call behavior, rate limits, or handling of invalid appids. With annotations present, the description provides some value beyond them, earning a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of 14 words, immediately stating what the tool does and the possible output values. There is no wasted wording, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with only one required parameter and an output schema present. Annotations cover safety, and the schema documents optional parameters. The description states the output values. It is complete enough for this simple lookup, though it does not explicitly mention the optional parameters, which are already documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema itself provides descriptions for all parameters (appid, language, response_format), so schema coverage is high. The description adds no parameter semantics beyond what the schema already gives, hence the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the Steam Deck rating for a game and enumerates the exact possible values (Verified, Playable, Unsupported, Unknown). This specific verb+resource+scope distinguishes it from sibling tools, as none other mention Deck compatibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking a game's Steam Deck compatibility but gives no explicit guidance on when to use it versus alternatives. It does not name any alternative tools or provide exclusions, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the optional live prices/sale status behavior, which is useful. However, it does not disclose performance trade-offs (e.g., one store lookup per DLC when enriching) or output format flexibility, so transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and object. It is concise, with no wasted words or repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters and an output schema, and the description is minimal but not misleading. The schema and annotations cover safety and parameter details, so the description is sufficient for basic selection. However, it does not mention when to set enrich=false to avoid performance costs or how to choose response_format, which would be helpful for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The context signal reports schema description coverage of 0%, so the description must compensate. The phrase 'optionally with live prices and sale status' hints at enrich and on_sale_only, but it does not explain limit, country_code, response_format, or the appid requirement. Despite the schema actually containing descriptions, the provided signal indicates the description carried the burden and fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists a game's DLC (add-ons), using a specific verb ('List') and resource ('a game's DLC'). It also distinguishes itself by mentioning optional live prices and sale status, which sets it apart from sibling tools like steam_get_app_details or steam_get_app_tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when you need to list DLC for a game. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous enough for an agent to select it correctly among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds only a minor clarification about XP-based level, which does not disclose additional behavioral traits like auth requirements or rate limits. This is acceptable given the annotations, but no extra context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence (10 words) that is front-loaded with the action and resource. There is no wasted wording, and it is immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 detailed annotations and schema, the description is sufficient. It does not explain return values, but an output schema exists. It also does not mention the optional nature of steamid, but the schema covers that. Overall, it is complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions for both 'steamid' and 'response_format' are comprehensive, covering formats, examples, and defaults. The tool description adds no parameter-specific information, but the schema fully carries the burden, which meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a user's Steam community level' with a clarifying parenthetical about XP-based level. It uses a specific verb and resource, distinguishing it from sibling tools like get_player_summary or get_player_badges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a Steam community level, but does not explicitly state when to use this tool versus alternatives. No exclusions or context are provided, though the openWorldHint annotation suggests it is safe to use broadly. This is 'implied usage' rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds only the resource type examples and does not disclose additional behaviors like response format handling or potential limitations. With annotations covering the core safety traits, this score is acceptable but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that includes a parenthetical list of item types for clarity. It contains no redundant or filler content, making it optimally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the presence of an output schema, and strong annotations, the description is sufficiently complete. It covers the essential purpose without needing to explain return values or additional context. A slightly longer description might offer more usage nuance, but this is adequate for a read-only metadata retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema itself provides a detailed description for published_file_id, explaining it as the Steam Workshop published file ID from the community URL. The tool description adds no additional parameter guidance. Since schema coverage is effectively high, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves metadata for a Steam Workshop item, using the specific verb 'Get' and identifying the resource with examples (mod, map, guide, collection). This distinguishes it from sibling tools, none of which target Workshop items directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use the tool (when Workshop item metadata is needed) but provides no explicit guidance on when not to use it or alternatives. There is no exclusion or comparison with other Steam tools, leaving usage context somewhat implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior. The description adds useful context about friend-library scope but does not disclose behavioral traits like concurrent owned-games lookups, limits, or response shape. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: verb, resource, and scope are all present. 'not store search' earns its place by preventing confusion with sibling tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Combined with the output schema and annotations, the description sufficiently covers purpose, friend-library scope, and the play-now variant. It does not explain what happens when steamid is omitted, but that behavior is documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% at the top level, and the description does not compensate by listing parameters. It only hints at appid via 'specific game' and omits limit, steamid, max_friends, playing_now, and response_format. The nested schema has good descriptions, but the description itself adds little parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description has a specific verb ('List') and resource ('which of a user's friends own (or are playing) a specific game'). The parenthetical 'not store search' explicitly distinguishes it from store-search siblings like steam_search_apps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear use case ('who can I play X with') and an explicit scope exclusion ('not store search'). It does not name sibling alternatives such as steam_get_friend_list or steam_compare_players, so it misses the highest bar for guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the description doesn't need to restate safety. The description adds no unique behavioral context (e.g., default language behavior or potential large responses) 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource. The promotional clause 'the best tell me about X tool' is short and adds usage context without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich schema, output schema, and comprehensive annotations, the description is minimally sufficient. It communicates the core purpose but relies on the schema to convey optional parameters and response formats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description does not mention any parameter semantics; the schema itself provides detailed descriptions for appid, language, country_code, etc. Because the schema carries the parameter documentation weight, the description adds little value, but the nested parameters are well-described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('get') with a clear resource ('comprehensive store details for a game'). The added clause 'the best tell me about X tool' distinguishes it as a general-purpose game info tool compared to siblings like steam_get_app_reviews or steam_get_deck_compatibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The positioning as 'the best tell me about X tool' provides clear context for when to use it. However, it does not explicitly mention when to prefer alternatives like steam_get_app_reviews or steam_get_app_tags, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds context about 'currently ON SALE' (temporal freshness) and 'featured specials', but does not disclose other behaviors like default limit, response format, or regional pricing nuances beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the purpose. It contains no filler, is well-structured, and is easy to parse. It earns its place with zero unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, strong annotations (read-only, idempotent), and presence of an output schema that defines return values, the description is sufficient. It covers the core purpose and scope. Minor omissions like default response format or regional pricing details are already available in the schema, so the description remains complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain parameters, and schema description coverage is 0% from the description's perspective. However, the input schema itself provides clear descriptions for limit, country_code, and response_format, so the agent can understand parameters from the schema. The description adds no additional meaning, but the schema compensates, hence a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), specifies the resource ('games currently ON SALE (featured specials)'), and scopes it to the Steam store. This clearly differentiates it from siblings like steam_get_store_highlights or steam_discover by emphasizing the 'ON SALE' filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about its purpose (listing games on sale) but does not explicitly mention alternatives or exclusions. While the context is understandable, there is no direct guidance on when not to use this tool compared to similar store-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds the 'unlocked' filter and the global unlock percentage sorting basis, but does not disclose additional behavioral traits such as default steamid behavior or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence, front-loaded with the key differentiator 'RAREST' and the sorting basis. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and read-only, with comprehensive annotations and an output schema. The description adequately conveys the core purpose and enables correct tool selection, even without additional details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description mentions no parameters. However, the input schema provides detailed descriptions for appid, limit, steamid, language, and response_format, effectively covering all parameter semantics. The description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Show') and resource ('player's RAREST unlocked achievements') plus the sorting criterion ('by global unlock %'). This clearly distinguishes it from sibling tools like steam_get_player_achievements (all achievements) and steam_get_global_achievement_percentages (global percentages).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool's purpose: to list a player's rarest achieved unlocks rather than all achievements or global stats. However, it does not explicitly state when to use it over alternatives or provide exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safe read-only nature is covered. The description adds examples of stats but does not disclose behavior like falling back to the configured STEAM_USER when steamid is omitted; although the schema covers this, the description itself adds limited behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to defining the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only tool, the annotations cover safety, the schema covers parameters, and an output schema exists, the description is mostly complete. Missing explicit guidance about when to prefer this over related stats/achievement tools, but the overall tool definition is still well-rounded.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'kills, wins, distance' but does not explain parameter usage. However, the nested schema contains detailed descriptions for appid, steamid, language, and response_format, so the parameter semantics are largely covered by structured data. The description adds a little semantic flavor but not critical parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the precise resource: a user's in-game STATS for a specific game, with examples like kills, wins, distance. This clearly distinguishes it from siblings like steam_get_player_achievements or steam_get_owned_games.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies it is for retrieving stats about one game, but it does not explicitly state when not to use it or name alternatives such as steam_get_player_achievements. This is clear context without exclusions, so it earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds that it returns an appid and is not for discovery, but doesn't disclose other behavioral traits like partial-match behavior or multiple results. With annotations covering the safety profile, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that clearly states the action and exclusions with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema, annotations covering read-only/idempotent safety, and schema-described parameters, the description is largely complete. It covers purpose and exclusions, though it doesn't mention edge cases like partial matching or result limits (though these are in the schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't elaborate on parameters, but the schema provides descriptions for query, limit, language, and response_format. The description's reference to 'title' aligns with the query parameter, giving minimal added meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up a game's appid by its title, with a specific verb and resource. It also explicitly excludes discovery, recommendations, and buy decisions, distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use context ('when you already know the name and need its ID') and when-not-to-use exclusions ('not for discovery, recommendations, or buy decisions'). It doesn't name specific alternative tools, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful context by noting it aggregates multiple data sources in one call and includes taste match, but it doesn't address edge cases like invalid appids, regional price differences, or how taste match behaves without a steamid. 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.
Conciseness5/5
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 ('Decide whether to buy ONE specific game') and follows with compact, meaningful detail. Every clause earns its place, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with moderate complexity, an existing output schema, and rich annotations, the description provides enough orientation for an agent to select and invoke the tool. It clearly scopes the tool and hints at personalization, though it could be more complete by naming alternative tools or handling failure cases explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description implies that appid identifies the specific game and that taste match relates to the optional steamid, but it doesn't explicitly name or explain parameters like country_code or response_format. Schema coverage is 0% by the given signal, so the description should compensate, but it only partially does by giving context for the core inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Decide whether to buy') and resource ('ONE specific game') and lists the exact data sources included (price, reviews, tags, Metacritic, taste match). It explicitly differentiates from discovery tools by stating 'for evaluating a single known game, not finding new ones,' distinguishing it clearly from siblings like steam_discover or steam_search_apps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use the tool: for evaluating one specific known game. It also gives an explicit when-not with 'not finding new ones,' but it does not name alternative tools (e.g., steam_discover or steam_search_apps) as the rubric's top tier would require.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which conveys the safety profile. The description adds the specific ban categories (VAC, game, community, economy) but does not disclose additional behavioral traits like rate limits, authentication, or output format. It 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action (Get) and immediately specifies the resource (ban status). No unnecessary words, and it communicates the essential purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 strong annotations and a well-documented input schema, the description is sufficient. An output schema exists, so return values are handled elsewhere. The description covers the key domain-specific detail (types of bans) and the rest is provided by structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter-level information, but the input schema includes detailed descriptions for steamid (SteamID64, vanity, or profile URL) and response_format (markdown/json). The schema covers the parameters effectively, so the description adds limited value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Get' and the resource 'VAC / game / community / economy ban status' for a user. This distinguishes it from sibling tools like steam_get_player_summary or steam_get_player_badges. It is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's purpose clear but does not explicitly state when to use it versus alternatives or any when-not conditions. However, among sibling tools none overlap with ban status, so the context is implicitly clear. No alternatives or exclusions are mentioned, so it misses a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is clear. The description adds the time window and hours detail, which is useful context, but does not mention the optional steamid behavior or response formats. Given the annotations and output schema, a score of 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, front-loaded with the action verb and immediately stating the resource and output. Every word is essential and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, annotations cover its safety and idempotency, and the schema documents all parameters. The description succinctly states the core function, leaving no critical gaps for this simple read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides detailed descriptions for both parameters: steamid (SteamID64, vanity name, or URL, with fallback to configured user) and response_format (markdown/json). The description itself adds no parameter information, but the schema covers it thoroughly, warranting the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('games a user has played in the last two weeks') and specifies the output ('with hours'). This clearly distinguishes it from sibling tools like steam_get_owned_games, which lists all owned games rather than recently played ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly communicates when to use the tool (whenever recently played games and playtime are needed), and its scope ('last two weeks') distinguishes it from related queries. However, it does not explicitly name alternatives or provide when-not-to-use guidance, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, openWorld, idempotent, non-destructive), so the description only needs to add context beyond that. It adds the personalization behavior and the filter-based scope, but does not disclose deeper behavioral details like unknown-tag handling or ownership exclusion; those are left to 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose and uses a semicolon to add the exclusion clause. Every word earns its place; there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the nested params object and rich schema descriptions, the description covers the core purpose and usage boundaries well. The presence of an output schema means return values need not be described. The only minor gap is not mentioning the full set of available filters, but the schema fills that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the top-level 'params' parameter, so the description must compensate. It names four key criteria (tags, max price, on-sale, platform) and personalization, but omits other params (sort, limit, term, etc.), though those are well-documented inside the nested schema. This partial compensation is adequate but not thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Discover' with resource 'games' and enumerates criteria (tags, max price, on-sale, platform). It explicitly distinguishes from sibling steam_recommend by stating this is for filter-based search, not 'games like X'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it (filter-based search by criteria) and when not to (not for 'games like X'), naming steam_recommend as the alternative. It also notes optional personalization, giving clear context for user-specific use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is established. The description adds meaningful behavioral context by specifying exactly what the tool returns (achievement and stat definitions) and clarifying that it is not user-specific, which goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence that conveys the tool's purpose and scope without any wasted words. It is front-loaded with the action and includes a valuable qualifier about non-user-specificity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple read-only tool with one required parameter and an output schema present. Annotations cover safety, and the description covers purpose and scope. While it does not mention response_format, the schema documents it, so no critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for both parameters (appid and response_format), including an enum for response_format. The tool description adds no parameter-specific information, so with high schema coverage, the baseline of 3 is appropriate. The schema adequately covers parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves achievement and stat definitions for a game, and explicitly notes it is not user-specific. This distinguishes it from sibling tools like steam_get_player_achievements, which focus on user-specific data. The verb 'Get' and resource 'achievement and stat definitions' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by contrasting with user-specific contexts: 'not user-specific' serves as an exclusion, indicating this tool is for game schema definitions rather than player-specific achievements. While it does not explicitly name alternative tools, the exclusion is clear and provides usable context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds behavioral context by noting it 'explains the shared tags' and supports two distinct input modes (seed game vs. user taste), which goes beyond what the annotations or schema alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the main action ('Recommend games similar to...'), provides concrete examples, and includes the usage alternative inline. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich output schema and strong annotations, the description covers the core purpose, use cases, input modes, and alternatives. The presence of an output schema allows the description to avoid explaining return values. It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is reported as 0% because the top-level 'params' wraps a $ref, but the nested schema actually contains detailed descriptions for most fields. The description does add conceptual meaning by mapping 'seed game' to seed_appid and 'user's taste' to steamid, but it omits other parameters like limit, max_price, and response_format. Since the schema carries most of the parameter semantics, the description provides only partial added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: recommend games similar to a seed game or a user's taste, and explicitly distinguishes it from the sibling tool steam_discover ('for filtered search use steam_discover'). This gives a specific verb, resource, and scope, and differentiates from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'games like X' and 'what should I play', and directly points to the alternative steam_discover for filtered search. This tells the agent exactly when to use this tool versus its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![steam-mcp MCP server](https://glama.ai/mcp/servers/Sarg338/steam-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Sarg338/steam-mcp)

Score Badge

Copy to your README.md:

[![steam-mcp MCP server](https://glama.ai/mcp/servers/Sarg338/steam-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Sarg338/steam-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Sarg338/steam-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server