Steam MCP Server

Server Quality Checklist

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

Latest release: v0.13.1
Disambiguation5/5
Every tool has a clearly distinct purpose. Overlapping tools like get_prices vs get_items are differentiated by the data they return, and the descriptions clearly explain when to use each. No two tools can be confused for the same task.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern, predominantly using 'get_' for data retrieval, with a few specialized verbs like 'search', 'discover', and 'compare'. No mixing of conventions like camelCase.
Tool Count4/5
25 tools is on the high side, but each tool serves a distinct and justified purpose within the broad Steam domain. The count reflects the API's comprehensiveness without being excessive.
Completeness4/5
The tool set covers the major Steam features: store browsing, game details, user profiles, libraries, wishlists, achievements, and social interactions. Minor gaps exist (e.g., no write operations, no market/community features), but for a read-only MCP, it is quite comprehensive.
Average 4.7/5 across 25 of 25 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 234 commits in the last 12 weeks
- Last stable release on August 13, 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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds useful behavioral context: 'No API key required' and the name-resolution behavior ('a title is resolved to the closest store match'). It does not detail pagination or error behavior, but the output schema covers return format, so this is sufficient.
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 two sentences, front-loaded with the main purpose, and lists the included fields without unnecessary fluff. Every sentence contributes value, and the length is appropriate for the tool's complexity.
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 has an output schema and annotations, the description covers the essential aspects: what data is returned, how to identify the game, and authentication requirements. It lacks explicit error handling or alternative-use guidance, but these are not critical for a read-only lookup tool with rich schema support, so it is nearly complete.
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 already provides 100% coverage with descriptions for all four parameters, including the appid-wins-if-both-given rule. The description merely restates the two identifier options without adding new syntactic or semantic details, so it does not elevate above the schema baseline.
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 verb ('Get') and resource ('full store details for one game'), and enumerates the specific fields included (description, price/discount, genres, etc.). It also distinguishes from sibling tools by specifying the identification methods (appid or name) and explicitly notes that it returns a highlighted-achievements sample, which is unique among the sibling list.
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 ('Get full store details for one game') and provides an integration hint by mentioning 'from search_games' to obtain appid. It does not explicitly name alternative tools for other use cases (e.g., get_prices for prices only), so it falls short of the highest bar, but the intended usage is well implied.
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 and openWorldHint. The description adds valuable behavioral context: the ban status is always public and requires a Steam API key. This 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 two sentences with no filler. It front-loads the core action and scope, then adds a key differentiator and auth requirement. 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?
Given the output schema exists and the tool has a single optional parameter, the description covers purpose, usage context, public behavior, and auth requirements. Minor gaps like rate limits or error handling are acceptable for a 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?
Schema description coverage is 100%, and the parameter description for 'steamid' is already detailed (17-digit, optional, server default, vanity resolution). The tool description only restates 'by SteamID64' without adding new parameter-specific insights, so 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 checks a player's ban status, enumerating specific ban types (VAC, game, community, economy) and the resource (SteamID64). This distinguishes it from all sibling tools, none of which cover bans.
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 explicitly provides a use case ('useful before trading or adding a friend') and notes that ban status is public even when the profile is private, guiding when to choose this tool. It lacks explicit when-not-to-use guidance, but no sibling tool offers an alternative for ban status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: it notes 'No API key required' (authentication requirement) and 'Errors clearly if the appid is unknown/invalid rather than returning a null count' (error handling behavior). These details are not provided by annotations, so the description enhances transparency.
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 two sentences with no filler. It front-loads the primary purpose, then adds necessary prerequisite and error behavior in a compact manner.
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 is simple (one param, no nested objects) and comes with an output schema, so the description does not need to explain return values. The description covers purpose, prerequisite, authentication, and error handling, making it complete 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?
Schema coverage for the single parameter 'appid' is 100%, and the schema already describes it as a Steam application id with a reference to search_games. The tool description repeats this guidance without adding new semantic value beyond what schema provides, 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's function: 'Get how many people are playing a game right now (live concurrent player count) by appid.' This is a specific verb-resource pair with clear scope, and it clearly distinguishes itself from sibling tools like get_game or get_prices.
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 explicit context for when to use this tool ('right now') and includes a cross-reference to 'Get the appid from search_games' for obtaining the required parameter. However, it does not explicitly state when not to use the tool or list alternatives, so it falls short of full exclusionary guidance.
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 openWorldHint=true, establishing a safe read-only profile. The description adds value by noting 'No API key required' and clarifying that the response is a comprehensive bundle ('all in one call') of multiple lists, which goes 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?
Two concise sentences: the first packs the tool's purpose, scope, and return contents; the second provides alternatives and the auth note. No waste, front-loaded with the core action, and easily scannable.
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 an output schema present, the description doesn't need to detail return structure, but it still mentions the key return elements (games with appid and price). It covers use case, alternatives, auth, and the fact that it's a single call, making it fully self-sufficient for an agent.
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 100% with both parameters (country and language) already described as overrides. The description does not add further parameter details but also doesn't need to, as the schema handles semantics fully. 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 names a specific verb ('Get'), a specific resource ('Steam store's featured sections'), and enumerates the exact contents (specials, top sellers, new releases, coming soon) with return details (list of games with appid and price). It also distinguishes itself from siblings by framing it as a single-call front-page overview.
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?
Explicitly states the primary use case (general store front page overview) and provides clear alternatives for narrower needs: 'For just current discounts use get_specials (lighter), or discover_games for catalog-wide deals with filters.' This tells the agent exactly when to choose this tool versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint), the description reveals that unknown appids return an empty list rather than an error, and that no API key is required. It also lists the output fields, adding practical context for handling results.
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?
Two sentences achieve high density: the first defines purpose and output, the second covers edge-case behavior and input sourcing. Every sentence earns its place; no wasted words.
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 two parameters and an output schema, the description covers purpose, input source, edge-case behavior, auth requirements, and return fields. No significant operational gaps remain.
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 coverage is 100%, with both appid and limit fully described in the input schema. The description mostly repeats appid provenance ('Get it from search_games') and adds no new parameter-level meaning beyond what the schema already provides. 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 game news/patch notes by appid, using a specific verb and resource. It lists the returned fields (title, date, author, excerpt, link) and is distinct from sibling tools like get_game_reviews or get_global_achievements.
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 instructs the agent to obtain the appid from search_games, a key prerequisite. It also explains that an unknown appid returns an empty list, which helps set expectations. However, it does not explicitly contrast when to prefer this tool over alternatives, so it misses the full 5.
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 openWorldHint=true. The description adds useful context beyond annotations: scoped to the Steam store front page, returns discount percentage and original/final price, and requires no API key. This is meaningful extra behavioral disclosure.
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?
Two sentences, front-loaded with the core purpose, followed by a targeted alternative pointer and an auth note. Every sentence adds value, no fluff or repetition.
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?
Given the tool's simple list behavior, the output schema, and annotations, the description sufficiently covers scope, return content, auth requirements, and the key sibling alternative. Nothing important is missing for an agent to select and invoke this 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?
Input schema covers both parameters (country, language) with descriptions, giving 100% coverage. The description doesn't add parameter-specific details but doesn't need to since the schema already explains overrides. Baseline of 3 is appropriate when schema carries the weight.
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 ('List') and identifies the exact resource ('games currently on special on the Steam store front page'). It clearly distinguishes itself from the sibling discover_games by contrasting front-page-only scope with the all-catalog alternative.
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?
Explicitly provides when-to-use context: front-page specials. Names discover_games with min_discount as the alternative for broader catalog discounts, giving clear exclusion and direction. Also notes no API key required, reducing usage friction.
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 indicate readOnlyHint and openWorldHint. Description adds key behavioral details: requiring an API key and returning a specific false flag. 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?
Two sentences, no wasted words. First sentence informs purpose and input, second covers prerequisite and a possible output. Front-loaded with action and result.
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 one parameter, 100% schema coverage, existing annotations, and an output schema present, the description covers the input format, a prerequisite, and a failure case. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the parameter fully; description adds a concrete example ('gabelogannewell') and explains its origin from the URL. Provides meaning beyond the schema description.
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?
Clearly specifies the action (convert/ resolve), the resource (vanity profile name), and the result (17-digit SteamID64). Distinguishes itself from sibling tools which are about games, reviews, or player lists; this is the only one that resolves vanity URLs.
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?
States requirement for STEAM_API_KEY and describes behavior when the name doesn't resolve (found:false). Implicitly tells when to use (when you have a vanity URL part) but could be more explicit about when not to use (e.g., if already have SteamID64).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds rich behavioral context beyond the readOnlyHint/openWorldHint annotations: the 150-cap with returned vs total, the empty-list/total:0 edge case for DLC/nonexistent games, and the API key dependency. It also clarifies what the tool does NOT report (why a list is empty), which is valuable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every detail serves a purpose, covering scope, cap, edge cases, prerequisites, and alternatives in a compact block. Semicolons and clauses keep it readable, though it could be slightly more scannable. Still, it earns a high score for efficiency.
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?
Given the tool's moderate complexity, the description covers all needed context: what is returned, how to handle edge cases, the required key, and sibling differentiators. With an output schema present, the description doesn't need to detail return structures; it fully addresses the contextual gap.
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 coverage is 100% with both parameters described. The description reinforces the appid's source and language's override behavior but doesn't add substantial meaning beyond the schema. Baseline 3 is appropriate when the schema already documents parameters well.
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?
Clearly states the tool lists a game's achievements with specific fields (names, descriptions, hidden flag, rarity) and order. It explicitly distinguishes from sibling tools like get_global_achievements and get_player_achievements, making its purpose unambiguous.
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?
Provides explicit guidance on when to use this tool versus alternatives: 'For just the rarity by internal id without a key, use get_global_achievements; for a few named highlights, see get_game's achievements_highlighted; for a specific player's own unlock progress, use get_player_achievements.' Also notes the STEAM_API_KEY requirement and directs users to get appid from search_games.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint annotations, the description discloses the full-library scanning behavior, the returned-list cap at top 50 by combined playtime, the need to compare `returned` vs `shared_count`, and the self-compare behavior when steamid is omitted. 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?
Three sentences, each packed with distinct value: purpose, comparison/limitation, prerequisites and self-compare. Front-loaded with the primary purpose, no wasted words.
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?
Given the tool's complexity and existing schema/annotations, the description fully covers selection, behavior, limitations, and edge cases (self-compare, public-profile requirement). The output schema likely handles return-value details, so the description is complete enough.
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 coverage is 100%, so baseline is 3. The description repeats the self-compare idea already in schema ('Omit to use the STEAM_ID configured on the server') but adds no new parameter syntax or format details beyond what the schema 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 opens with a specific verb: 'Find games two players both own, with each one's playtime'—clearly identifying the resource (two players' libraries) and differentiating from sibling get_owned_games. It also quotes user intents ('what can my friend and I both play'), making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly contrasts with get_owned_games, noting this tool checks full libraries while that caps at top 50, helping agents choose the right tool. It states prerequisites (STEAM_API_KEY, public profiles) and the failure condition (found:false), giving clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint and openWorldHint annotations. It discloses dependencies (STEAM_API_KEY, public friends list), failure modes (found:false, per-friend private_library, rate-limited lookups), caps (100 entries per list, 200-friend lookup limit), and the timeout rationale. This is rich, behavior-critical context.
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?
Though lengthy, the description is tightly packed and front-loaded with the core purpose. Each subsequent sentence addresses a distinct edge case or behavioral caveat, so every sentence earns its place. The structure uses clear separators and comparative language to keep it readable.
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?
Even with an output schema present, the description explains the meaning of key output fields (owners, private_friends, unavailable_friends, friends_checked, total_friends) and truncation behavior. It also covers operational context like timeouts and limits, making it fully complete for agent decision-making.
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 already provides 100% coverage for both parameters (appids and steamid), including descriptions. The tool description does not add new parameter-level semantics beyond referencing appids and mentioning source via search_games; it focuses on tool behavior rather than parameter syntax.
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 opens with a specific verb and resource: 'Check which of a player's Steam friends own one or more games by appid, with each owner's playtime_hours'. It immediately distinguishes itself from get_owned_games and other sibling tools by clarifying scope ('a player's friends' vs 'own ownership').
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?
Explicit guidance is given: 'For the PLAYER'S OWN ownership instead of a friend's, use get_owned_games's check_appids' and 'Get appids from search_games.' It also explains when the tool should not be used or how to interpret missing friends ('treat a friend missing from all three lists as unchecked, not as a non-owner').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses specific behaviors: returns only appids and store_url, no price/name, capped at 200 items with a 'returned' vs 'total' check, and returns found:false on private profiles. This significantly enriches the agent's understanding of what to expect.
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 dense but every sentence contributes unique value: purpose, distinction, prerequisites, output format, pagination, and next steps. It is front-loaded with the primary function and avoids redundancy.
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?
Given the tool's low complexity and existing output schema, the description covers all essential aspects: input, output, failure mode, pagination, and related tools. It is complete enough for an agent to select and invoke the tool correctly without additional lookups.
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 already fully describes the steamid parameter, including format and optional omission. The description essentially repeats this information and adds no new parameter-specific semantics; the only extra detail concerns the resolve_vanity_url prerequisite, which is a cross-tool note rather than 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 lists a player's followed games by SteamID64, using a specific verb (list) and resource (followed games). It explicitly distinguishes this from the wishlist, making the scope unambiguous and differentiating it from sibling tools like get_wishlist.
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 when-to-use guidance: mentions using resolve_vanity_url to convert vanity names, passing appids to get_items for additional data, and notes that the profile must be public. It also clarifies that no API key is required for this tool while the conversion does, giving clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses ordering (most-common first), a cap (first 200), the need to check `returned` vs `count`, error behavior (empty list for unknown/no-schema appids), and that no API key is required. This richly informs the agent's expectations.
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 information-dense yet well-structured. Each sentence adds unique value: purpose, return data and limitations, edge-case behavior, source of appid, and authentication. No filler or redundancy.
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 tool with one parameter, an output schema, and annotations, the description covers return fields, ordering, limits, error handling, and data source. It is fully sufficient for an agent to invoke this tool correctly without additional external knowledge.
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 100% coverage, including a description for appid ('Steam application id (appid). Get it from search_games.'). The tool description repeats 'by appid' and 'Get the appid from search_games' but adds no new meaning beyond the schema, so 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 states a specific verb ('Get'), a resource ('global unlock percentage of each achievement'), and a scope ('by appid'). It clearly differentiates from the sibling get_game_achievements by noting it returns internal names and unlock percentages rather than display names/descriptions.
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?
Explicitly directs users to get_game_achievements for display names/descriptions, references get_game_news for similar behavior on unknown appids, and instructs to obtain appid from search_games. This provides clear when-to-use and alternative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses the STEAM_API_KEY requirement and the private-profile behavior where country, account age, and current game only populate for public profiles. This is valuable contextual information that enriches the agent's understanding of side effects and response variability.
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 three sentences long, front-loaded with the main purpose, and every sentence adds substantive value—purpose, auth requirements, privacy caveats, and alternative tool. No filler or repetition.
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 read-only profile lookup tool with an output schema present, the description sufficiently covers the essential nuances (auth, private profiles) and the distinction from a sibling tool. The output schema handles return value details, so no further information is needed.
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 already provides a full description of the steamid parameter, including format, default behavior when omitted, and conversion guidance via resolve_vanity_url. The description does not add further meaning beyond referencing the ID type, so the baseline score of 3 for high schema coverage 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 identifies what the tool does: retrieves a player's profile using SteamID64 and enumerates the specific fields returned (display name, online state, country, account age, Steam level, current game). This explicit verb-resource structure distinguishes it from siblings like get_player_bans, which handles a different purpose.
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 states when not to use this tool: 'For VAC/game/trade ban status instead, use get_player_bans.' This provides a clear exclusion and names an alternative, meeting the highest bar for usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds critical behavioral details: the 50-item cap with instruction to check returned vs total, ordering by playtime not recency, and the exact requirement for public profile with game-details visibility. It also discloses the found:false response on failure, giving the agent a clear picture of behavior.
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?
Three sentences, each earning its place: the first defines the core behavior and ordering/cap, the second provides the alternative tool, and the third covers prerequisites and failure behavior. No redundancy or fluff; information is front-loaded and well-structured.
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?
Given the tool's simplicity and the presence of an output schema, the description covers all essential context: behavior, ordering, cap, alternative, authentication requirement, and failure mode. It is fully complete for an agent to decide when and how to 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 input schema already fully documents the single steamid parameter with a detailed description including how to omit it and vanity URL conversion. The tool description adds no additional parameter semantics beyond implicit player context, so the baseline of 3 is appropriate given 100% 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 uses a specific verb 'List' and clearly states the resource: games a player has played in the last two weeks, including recent and total playtime. It also distinguishes itself from get_owned_games by explicitly noting the difference in time window and sorting, making its purpose unmistakable.
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?
Provides explicit when-to-use guidance by directing users to get_owned_games for all-time top games. It also states prerequisites (STEAM_API_KEY, public profile with game-details visibility) and the failure mode ('returns found:false'), which clearly indicates when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint, and the description adds substantial behavioral detail beyond these: rollup_type is chosen server-side, long-term history is capped at 24 entries, per-day data at 30 days, and each entry contains positive/negative counts and positive %. It also mentions 'No API key required', which is not in 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 paragraph but every sentence earns its place: the core action, the output structure, limits, use case, alternative, and attribution. It is dense without being rambling, front-loads the verb and resource, and remains easy to parse.
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?
Given a single parameter, a rich output schema, and annotations for read-only safety, the description sufficiently covers all relevant operational details: data granularity, caps, positive percentage, and the differentiator from get_game_reviews. It is complete for an agent to make an informed invocation decision.
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 for the only parameter (appid) is complete and even includes the instruction to get it from search_games, so the description adds no new parameter semantics. Per the baseline rule for schema coverage >80%, a score of 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 trends over time by appid, specifying two distinct data components (long-term history and per-day breakdown) with counts and positive percentages. It also explicitly distinguishes itself from sibling tool get_game_reviews, making the purpose unambiguous.
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?
It explicitly provides use-case guidance ('Good for are reviews improving / did an update hurt reception') and names the alternative (get_game_reviews) for a different need. It also instructs the user to obtain the appid from search_games, covering all prerequisites for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world (public), but the description adds critical behavioral detail: the 'type' caveat, lack of pagination, ~10 result cap, and no API key requirement. This goes well 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?
Every sentence carries essential information: the action, return fields, important caveat about type, pagination limitation, and auth requirement. No filler, well front-loaded with the core purpose.
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 is a search endpoint with moderate complexity; the description covers return fields, limitations, the relationship to sibling tools, and authentication. With an output schema present, return values don't need repeating, making this fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 3 parameters, but the description adds meaningful semantics for 'term' (partial/approximate, not exact match). This exceeds the baseline for high schema coverage and gives the agent the needed search behavior context.
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?
States the exact action ('Search the Steam store by title') and clearly differentiates from siblings by noting it returns appids needed by other game tools, plus the specific fields. This is a specific verb+resource+scope.
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?
Provides clear context for use including partial/approximate matching, pagination limits, and refining query terms. Explicitly points to an alternative (get_game) for obtaining the real type, though it does not explicitly say 'use this when you have a title but not an appid'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and openWorldHint annotations already declaring the safety profile, the description adds substantial behavioral detail: unknown/invalid appids are returned as available:false rather than dropped, compatibility fields are explained (including the important distinction between steam_frame and vr_support), and discount_end is defined as ISO UTC time. This goes well beyond the annotations and provides critical runtime expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded with the core purpose and then details each returned field, with disambiguation and alternative tool references. Every sentence serves a purpose, though some field explanations might be redundant given the output schema exists. Overall it is well-structured but slightly verbose for a tool with a full schema.
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 description is comprehensive: it covers the purpose, batch limit (implied by schema and restated), invalid appid behavior, detailed field semantics, and points to sibling tools for discovery and price-only batches. It leaves no ambiguity about how to use this tool within the broader tool ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all three parameters with descriptions (appids 1-50, country, language), so the baseline is 3. The description adds useful input-related context: invalid appids are tolerated and returned as rows, and the 'keyless call' note clarifies no authentication is needed. However, it does not add much about country/language 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 opens with a specific verb and resource: 'Get price/discount, review % (positive), hardware compatibility, popular user tags and release date for a LIST of games by appid in ONE keyless call.' It clearly distinguishes from siblings by emphasizing batch handling of an existing appid list, and explicitly names alternatives such as get_prices and discover_games.
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 when-to-use guidance: it calls itself 'The efficient way to price-, rating-, tag- and compat-check a wishlist or library without a request per game.' It also states when to use alternatives ('For a bigger batch (up to 250 appids) when you only need price, use get_prices instead') and how to obtain appids ('Get appids from search_games / get_wishlist / get_owned_games').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, but the description adds key behavioral details: the achievements array caps at 200, unlocked first, and to check returned vs total; returns found:false for private profiles or games with no achievements. These go beyond the annotations and are critical for interpreting results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two dense sentences, packed with valuable information. It is front-loaded with the core purpose, then expands on limitations, alternatives, and prerequisites. While every clause earns its place, the density and multiple parentheticals make it slightly harder to parse quickly.
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?
Given the tool's complexity (capped array, alternative tools, auth requirements, error cases) and the presence of an output schema, the description covers all necessary context. It explains what data is returned, the cap behavior, and when found:false appears, making it sufficiently complete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented. The description adds context by highlighting the role of SteamID64 and appid, noting steamid is optional (falls back to configured STEAM_ID), and language overrides. This extra explanation is valuable but not strictly necessary given 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 specifies the tool's function: retrieving a player's achievement progress for a single game via SteamID64 and appid. It differentiates from siblings by naming get_game_achievements for the full list and get_global_achievements for rarity without a key.
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 states when to use the tool (for player-specific progress) and when to use alternatives (get_game_achievements for full game list, get_global_achievements for rarity). It also includes prerequisites (STEAM_API_KEY, public profile visibility) and the found:false outcome, giving clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses a concrete behavioral trait: 'Review text over 600 characters is truncated.' It also notes 'No API key required,' addressing authentication expectations. There is 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 three sentences, front-loaded with the core action, and every sentence adds distinct information: what it returns, a behavioral caveat, and usage alternatives/prerequisites. No wasted words.
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 an output schema present, return values are fully described there. The description covers prerequisites, alternatives, and a key edge case (truncation), making it complete for a read-only retrieval tool. The presence of annotations and a well-described schema round out the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for all parameters, including detailed descriptions for type, limit, and review_language. The description adds value by telling the agent to get appid from search_games, which is a useful provenance hint not present in 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 specifies the resource ('game reviews') and the exact output ('summary (score label, positive/negative counts, %) and a few recent reviews'), with a precise parameter ('by appid'). It also distinguishes this tool from get_review_histogram, making the purpose unambiguous.
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?
It explicitly tells the agent when to use this tool (for a snapshot) and when not to (for long-term trends, use get_review_histogram). It also directs the agent to search_games for obtaining the appid and notes that no API key is required, covering prerequisites and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds valuable behavioral details: rows preserve input order, unavailable appids are marked available:false and never dropped, and each row includes final/initial price and discount_percent (or is_free). It also notes no API key is required, which is non-obvious.
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 dense paragraph, but every sentence adds critical information: purpose, batch capacity, alternatives, output ordering and availability handling, and API key requirements. It is front-loaded with purpose and perfectly sized for a tool with this complexity.
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 an output schema present, the description still goes beyond it by explaining row ordering, unavailable handling, and the exact fields returned. It also covers rate limits (250 appids), usage alternatives, and authentication requirement (none). This is complete for a batch price-lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the explanation carries little burden. Still, the description adds extra context by suggesting where to get appids (search_games or get_wishlist) and implicitly explains the purpose of the batch. This is more than the schema provides, though not substantial.
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 opens with 'Get current price and discount for a batch of games by appid in one call', which is a specific verb-resource combination. It clearly distinguishes itself from siblings by contrasting with get_items for additional data like reviews or tags.
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?
Provides explicit when-to-use (checking a wishlist for deals), a hard limit (250 appids), and names an alternative (get_items for review %, hardware compatibility, tags). It also directs users on how to obtain appids via search_games or get_wishlist, fully covering usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint and openWorldHint annotations by disclosing the weighted-tag ranking logic, discounting by review score, exclusion of owned games, the 30-game/300-catalog scan limitations, and the edge case where found:false is returned. There is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed and every sentence contributes useful context, but it is longer than necessary. The opening sentence is dense with algorithm details, and some nuances (e.g., 're-checked client-side') could be trimmed for greater concision. Still well-structured and front-loaded.
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?
Given the tool's complexity, the description covers the algorithm, input/output behavior, failure modes, authentication requirements, and comparisons with alternatives. The presence of an output schema reduces the need to explain return values, and the description handles all other context comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already covers 100% of parameter descriptions, the tool description adds significant semantic value: it explains how exclude_tags interacts with playtime-derived preferences, gives a concrete example ('suggest games on sale, not RPGs or shooters' → exclude_tags:['RPG','Shooter','FPS'], min_discount:30), and clarifies that exclude_tags requires exact Steam tag names and that unrecognized tags silently drop nothing.
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 opens with a specific verb and resource: 'Recommend unowned Steam catalog games personalized to this player,' followed by a precise explanation of the recommendation algorithm. It clearly differentiates from sibling discover_games by stating that this tool infers taste from the whole library rather than requiring user-named filters.
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?
Explicit usage guidance is given: when to use this tool ('what should I play next' / 'recommend me something') and when not to (for a single named title, use discover_games after fetching tags via get_items). It also states prerequisites (STEAM_API_KEY, public profile with game-details visible) and notes that heavy exclude_tags/min_discount combinations can return fewer than limit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: keyless operation, server-side vs client-side filtering, popularity-first scanning with potential niche misses, 60-result cap, and the need to compare returned vs matched. This goes well beyond the readOnlyHint/openWorldHint annotations, giving agents realistic expectations about result sparsity and pagination.
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?
Though long, the description is tightly structured: core function, examples, sibling distinction, then caveats. No redundant sentences; every clause carries operational meaning for a 15-parameter tool.
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 15-parameter discovery tool with output schema, the description covers filtering semantics, pagination, result cap, and alternative tools. It even addresses edge cases like misspelled tags and Proton-vs-native distinctions. Missing nothing critical for selecting and invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already has 100% parameter coverage; the description adds cross-parameter meaning via examples (e.g., min_discount + min_review for '>80% off with 90%+ reviews'), explains that count is a scan window not a result limit, and clarifies server-side enforcement for min_discount and released_after. This is substantial added value beyond 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 opens with 'Find games across the whole Steam catalog (keyless)' – a specific verb + resource + scope. It enumerates all filter dimensions and explicitly contrasts itself with get_items and get_recommended_games, distinguishing it from siblings.
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?
Explicitly names alternatives: 'unlike get_items...' and 'use get_recommended_games' for library-based taste. Provides concrete use-case examples and clarifies when to use this tool vs others, including key-gating caveats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that list is capped at 100 most-recently-added, provides check via 'returned' vs 'total', and explains failure case (found:false if not public). Annotations (readOnlyHint, openWorldHint) are complemented.
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 paragraph, front-loaded with core functionality, followed by caveats and alternative. Every sentence adds value; no fluff.
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?
Covers all needed context: output fields, pagination hint, error conditions, and prerequisite steps. Output schema exists, so return details are optional but description adds extra clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning beyond schema: explains that omitting steamid uses server-configured ID, and advises converting vanity URLs via resolve_vanity_url. Schema coverage is 100%.
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 verb 'List', the resource 'a player's Steam friends', and includes specific fields (name, online state, current game, friendship duration). It also distinguishes from sibling tool 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use the alternative tool (find_friends_who_own), mentions prerequisites (STEAM_API_KEY, public friends list), and instructs to convert vanity URLs using resolve_vanity_url.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint annotations, the description discloses the top-50-by-playtime cap on `games`, the uncapped behavior of check_appids, the free-to-play never-launched omission, and the private-profile reporting ('no `owns` at all'). These are crucial behavioral caveats not evident from annotations alone.
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?
Every sentence serves a purpose: main capability, cap caveat, ownership-check alternative, two sibling differentiators, requirements, and input resolution. Information-dense without redundancy, and the most important action ('List...') is front-loaded.
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?
Given the output schema exists and annotations cover safety, the description still adds essential context: alternatives, limits, prerequisites, and edge cases. The agent can confidently select, invoke, and interpret results without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already describes both parameters with 100% coverage, the description enriches them with real-world usage context: check_appids is positioned as a reliable ownership test, explains the `owns` result shape, and highlights edge cases (free-to-play, private profiles). It also adds practical advice for the `steamid` parameter via resolve_vanity_url.
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 opens with a specific verb+resource+scope: 'List the games a player owns with playtime (hours), most-played first.' It also explicitly contrasts with sibling tools (get_recently_played, find_friends_who_own), making its unique purpose unmistakable.
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?
Provides explicit when-to-use guidance: use check_appids for specific ownership checks, use get_recently_played for two-week activity, and use find_friends_who_own for friends. Also states prerequisite visibility requirements (public profile + game-details visibility) and how to obtain the required SteamID64.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint, and the description adds substantial behavioral context: public requirement with found:false, output caps (100 light, 60 detailed), ranking logic (priority vs discount), and the Steam limitation where only ~100 wishlist entries get enriched data, exposed via `enriched` and `note`. This goes well beyond 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?
While long, every sentence serves a purpose: purpose, auth/preconditions, filtering semantics, caps, ranking, Steam's data limitation, and a pointer to a sibling tool. The flow moves from core behavior to details to edge cases, and the front-loaded first sentence gives immediate utility. No filler or redundant statements.
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 tool with 13 optional parameters, 5 enums, and an output schema, the description covers all key aspects: what the tool returns (light vs detailed), how filters interact, limits, ranking, data availability quirks, and related tools. The existence of an output schema means return-value details don't need to be repeated, and the description fills all other contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds critical interpretive value beyond parameter names/types: it distinguishes platform (native) from steam_os/steam_deck (Proton), explains that filters imply include_details, notes that misspelled tags silently match nothing, and clarifies the precedence of country/language overrides. This transforms flat enum descriptions into actionable usage rules.
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 opens with 'List a player's Steam wishlist by SteamID64,' a specific verb+resource combination that clearly distinguishes it from sibling tools. It also explicitly differentiates from get_items by noting the one-call detailed mode, and mentions resolve_vanity_url for name conversion.
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 gives explicit when-to-use guidance: it states the public/wishlist requirement, explains when to use include_details versus the light list, and clarifies that filters switch to detailed view. It also points to the sibling tool resolve_vanity_url for vanity names and notes it requires an API key, which is helpful for choosing the right path.
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-games-mcp MCP server](https://glama.ai/mcp/servers/Grinv/steam-games-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Grinv/steam-games-mcp)

Score Badge

Copy to your README.md:

[![steam-games-mcp MCP server](https://glama.ai/mcp/servers/Grinv/steam-games-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Grinv/steam-games-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/Grinv/steam-games-mcp'

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