mcp-server-steam

Server Quality Checklist

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

Latest release: v1.0.6
Disambiguation5/5
Each tool targets a distinct resource/action: profile, friends, games, achievements, store details, news, workshop, reviews, bans, and vanity URL resolution. Even similar tools like get_owned_games vs get_recently_played_games are clearly differentiated by scope (all vs recent).
Naming Consistency5/5
All tool names use snake_case with a verb_noun pattern, predominantly 'get_*' (e.g., get_user_profile, get_friends_list). The two exceptions, search_games and resolve_vanity_url, still follow verb_noun and are semantically distinct, so the overall convention is consistent and predictable.
Tool Count4/5
With 16 tools, the count is slightly above the typical 3-15 sweet spot, but each tool maps to a real Steam Web API endpoint and the coverage is broad, so it does not feel bloated. The slight excess is justified by the platform's feature set.
Completeness4/5
The set covers major Steam data domains: user profiles, friends, games, achievements, store info, news, workshop, reviews, and bans. Minor gaps exist (e.g., no user game stats or DLC listing), but these are edge cases; core read workflows are well represented.
Average 3.8/5 across 16 of 16 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on February 23, 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention authentication, rate limits, side effects, or any constraints beyond the returned data. This is a significant gap for a tool that performs an external API call.
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 succinct, comprising a purpose statement, bullet-like return data summary, and an example. Every sentence contributes meaningful information without redundancy or verbosity.
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 two parameters and an output schema (as indicated by context signals), the description covers the essential purpose and return fields. It lacks usage guidelines and transparency details, but considering the low complexity and schema richness, it is largely 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 input schema already thoroughly describes both parameters (steam_id and count, with default and max). The description adds a usage example, which is helpful but does not provide additional semantic meaning beyond the schema. With 100% schema coverage, a baseline 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 a list of recently played games (최근 플레이한 게임 목록을 조회합니다). It specifies the resource and verb, and the return data (App ID, name, playtime) distinguishes it from siblings like get_owned_games or get_user_profile.
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 includes a usage example but does not mention exclusions or compare with sibling tools like get_owned_games. Usage context is only implied by the tool's name and purpose.
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?
With no annotations, the description carries the burden of behavioral disclosure. It does disclose the return fields and provides an example call, which is useful. However, it does not mention pagination behavior (despite page/count params), sorting semantics beyond query_type, or any side effects (though likely read-only). It 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. It includes example usage and return fields in a compact format, which is efficient. No wasted words, though it could be slightly better organized.
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?
Given the output schema exists, the description need not explain return values, but it does anyway, which is helpful. The main gap is lack of usage guidance and differentiation from the sibling tool. For a list endpoint with moderate complexity, it is adequate but not comprehensive, especially since no annotations are provided.
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%, so the schema already documents all parameters. The description adds a concrete example with typical values and the return fields, but does not explain parameter meanings beyond what the schema provides. Baseline 3 is appropriate.
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 queries Steam Workshop items and lists the returned fields, which is a specific verb+resource. The name vs. sibling (get_workshop_item_details) suggests a list operation, but the description does not explicitly differentiate between them, 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?
No explicit guidance is given on when to use this tool versus get_workshop_item_details or other siblings. The example usage with app_id/query_type/page/count provides a concrete scenario, but it does not state exclusions or alternatives, leaving the agent to infer.
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?
No annotations are provided, so the description carries the burden. It discloses return data fields (steamid, friend_since, relationship) and mentions relationship filter behavior. It does not disclose potential rate limits, auth requirements, or side effects, but it's a read-only operation implied by '조회' (retrieve). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and includes a useful example. It is structured with a summary, return data explanation, and example. It's slightly verbose due to the example but each part 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 tool's simplicity, the description covers the essential aspects: what it does, what it returns, and a usage example. An output schema exists, so return structure details are not necessary. It's complete enough for an agent to select and invoke the tool correctly, though it could mention edge cases like empty friend lists.
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 parameters are already documented. The description adds value by providing a concrete usage example and explaining the 'relationship' filter values ('all' vs 'friend') in the schema. This goes beyond the schema definitions and helps clarify expected input format.
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?
Description clearly states the tool retrieves a Steam user's friend list (친구 목록을 조회합니다), which matches the tool name. It distinguishes from sibling tools like get_user_profile and get_owned_games by specifying the resource (friends) and operation (list). However, it doesn't explicitly contrast with sibling tools, so it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an example usage with specific parameter values, implying when to use it (to fetch friends with optional relationship filter). But it doesn't explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites beyond the required steam_id.
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?
No annotations are provided, so the description must carry the burden. It discloses behavioral traits such as return data fields, the fact that playtime is in minutes (with a conversion example), and the fallback to environment variable STEAM_USER_ID for steam_id. However, it does not mention rate limits, authentication requirements beyond the env var, or potential pagination/limits, leaving some behavioral aspects opaque.
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 well-structured: purpose, return data, unit clarification, and a usage example. Each sentence adds value, though the unit clarification and example are slightly redundant with the schematic information. Overall, it is efficient and front-loaded with the primary 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 output schema exists and the input schema is fully documented, the description provides sufficient context for an agent to select and invoke the tool. It covers the resource being queried, key return fields, and a concrete example. It could be enhanced by explicitly differentiating from get_recently_played_games, but this is not a major 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?
The input schema has 100% coverage with descriptions for all three parameters, including defaults and the env var fallback for steam_id. The description adds an example (steam_id='76561198000000000', include_app_info=True) but does not provide additional semantics beyond the schema. This matches 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 '사용자가 소유한 모든 게임을 조회합니다' (retrieves all games owned by the user), using a specific verb and resource. It distinguishes from siblings like get_recently_played_games by focusing on the complete owned library, and lists key return fields (appid, name, playtimes, last_played), making the 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context (gets all owned games) but does not explicitly state when to use this tool versus alternatives like get_recently_played_games or get_game_details. No exclusions or alternative tool mentions are provided, so the usage guidance is merely 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?
With no annotations, the description carries the transparency burden. It discloses returned data fields, but it does not mention authorization, rate limits, error behavior, or confirm the read-only nature explicitly, though '조회' implies a safe read.
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 compact and front-loaded with the purpose, followed by useful return data and a concrete example; no wasted sentences.
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 one-parameter detail query with an output schema, the description adequately covers purpose, return contents, and an invocation example. It could add caveats around invalid IDs or limits, but is not incomplete.
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 describes the only parameter (published file ID list), and the description's example only illustrates values without adding semantic meaning beyond the schema, so the baseline 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 uses a specific verb ('조회합니다' - retrieve) and resource ('워크샵 아이템의 상세 정보' - workshop item details), and the return-data breakdown (metadata, tags, preview image, dependencies, stats) clearly distinguishes it from sibling list tool get_workshop_items.
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 this is for retrieving item details and provides a usage example, but it does not explicitly state when to use this tool over alternatives (e.g., get_workshop_items) or mention exclusions/prerequisites.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the return fields (title, contents, URL, date, feed_label) and gives an example, but does not mention rate limits, authentication, or any side effects. This is sufficient for a simple read-only query, but lacks depth.
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 concise and well-structured: a single sentence for the main purpose, a sentence listing return fields, and a usage example. Every sentence adds value without 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?
Given that an output schema exists (as indicated by context signals), the description need not explain return values in detail. It already covers the core fields and provides an example, while the schema handles the rest. It lacks edge-case or error handling details, but these are not critical for a straightforward query 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 covers all parameters with clear descriptions (e.g., app_id is the Steam App ID, count is the number of news items, max_length is the character limit). The description's usage example (app_id=730, count=5, max_length=300) adds a concrete illustration but no new semantic meaning 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 explicitly states it queries news and updates for a specific game ('특정 게임의 뉴스와 업데이트를 조회합니다'), making the operation clear. It distinguishes itself from sibling tools like get_game_details and get_user_reviews, 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 provides a usage example with concrete parameter values, implying the tool is for retrieving game news. However, it offers no explicit guidance on when to use this tool over alternatives or exclusions, leaving the agent to infer context from the tool's name and description.
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?
The description discloses the return data structure and gives a concrete usage example, which is useful behavior information. With no annotations provided, it carries the full burden, but it does not mention access requirements (e.g., public profile), error cases, or rate limits. It is a moderate disclosure but not exhaustive.
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-loading the purpose, then providing return data and a usage example without any wasted words. It is appropriately sized 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?
The tool has a simple query purpose, all parameters are well-defined in the schema (100% coverage), and an output schema is stated to exist. The description adds return data details and an example, making it fairly complete for an agent. It falls short of 5 due to missing guidance on error conditions or profile privacy requirements, but is otherwise adequate.
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 covers 100% of parameters with descriptions and examples (e.g., app_id 730 for CS2, language 'english'). The description adds a usage example, but it largely duplicates what the schema already provides. Baseline of 3 applies due to high schema coverage, with minimal 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 'retrieves achievement progress for a specific game' (특정 게임의 업적 진행상황을 조회합니다), with a specific verb and resource. It also lists return fields (name, achieved, unlocktime, description), distinguishing it from sibling tools like get_global_achievement_percentages or get_game_schema.
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 provides a usage example showing steam_id, app_id, and language, and implies per-user/per-game usage. However, it does not explicitly state when to use this tool versus alternatives (e.g., global achievement percentages, game schema), and lacks any exclusion criteria or alternative tool 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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns player_level and gives a usage example, but does not mention error conditions, authentication needs, or that it is a read-only operation. However, the verb '조회' implies a read, and the simple nature of the tool partially compensates.
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 consists of two short sentences and an example, all front-loaded with the purpose. Every sentence contributes value without 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?
The tool has one required parameter and an output schema, and the description includes the purpose, return data, and a usage example. It is slightly incomplete because it lacks any caveats or usage guidance, but for a simple getter it is largely sufficient.
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 describes steam_id as the 64-bit Steam ID with 100% coverage. The description adds a concrete example value ('76561198000000000'), which clarifies the expected format and aids invocation. This is a useful addition 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 'retrieves the user's Steam level' with a specific verb and resource. It distinguishes from sibling tools like get_user_profile or get_player_bans by focusing on the specific Steam level metric. The mention of player_level in return data reinforces the specific output.
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. It only provides a usage example with steam_id, but does not explain context, prerequisites, or exclusions. This is a clear gap given the many sibling 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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It discloses return data fields (author, content, votes, playtime, timestamp, length) and provides an example, but it does not mention potential side effects, rate limits, authorization requirements, or error conditions. This is helpful but not exhaustive.
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 compact and well-organized: a one-sentence purpose, a list of return data, and a usage example. Every sentence contributes useful information, with no redundancy or irrelevant 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?
Given the complete input schema, available output schema, and lack of annotations, the description covers the essential context: purpose, return data, and an example. It lacks explicit error-handling or edge-case guidance, but for a simple retrieval tool, it is quite 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 input schema describes all parameters with 100% coverage, including defaults and value ranges. The description adds a concrete usage example that shows how parameters combine, but it does not provide additional semantic meaning beyond the schema. Baseline 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's purpose: 'Retrieves user reviews for a game' (게임의 사용자 리뷰를 조회합니다). It specifies the action (retrieve) and resource (user reviews), distinguishing it from sibling tools like get_game_details and get_game_news.
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 includes a usage example (app_id=730, review_type='all', count=10) that demonstrates how to call the tool, but it does not explicitly state when to use this tool vs alternatives or when not to use it. The intended usage is implied by the verb 'retrieve', but no exclusions or alternative tool references are 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?
No annotations are provided, so the description must carry the transparency burden. It discloses the return data (achievements, availableGameStats, gameStats), which is helpful. However, it doesn't mention whether the operation is read-only, any permissions needed, or error conditions. The read-only nature is implied by '조회' but not explicitly stated.
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 compact: a one-sentence purpose, a list of return data, and a usage example. It is well-structured and wastes no words. However, there is a minor corrupted character in the text ('�적들'), slightly detracting from polish.
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, an output schema, and full parameter coverage, the description is quite complete. It states the purpose and return contents. It lacks guidance on when to use versus alternatives, but that's covered under usage guidelines. The availability of an output schema reduces the need to explain return values in detail.
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 descriptions for both parameters (app_id and language) with 100% coverage. The description adds a concrete usage example, but no additional semantic meaning beyond the schema. 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 explicitly states the tool retrieves the game's achievement and stats schema, using a specific verb ('조회합니다') and resource ('업적과 통계 스키마'). This distinguishes it from siblings like get_player_achievements (player-specific) and get_game_details (general info).
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 a clear usage example (app_id=730, language='english'), implying this tool is for retrieving schema data. It doesn't explicitly mention when not to use it or name alternatives, but the context is clear enough for an agent to infer appropriate use.
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?
With no annotations provided, the description carries the full burden. It discloses the return data content and a usage example, but does not mention error handling, rate limits, authentication requirements, or behavior for invalid app_ids. This is a mild transparency gap, hence a middle score.
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 concise and well-structured. It opens with the primary action, then lists return data, and ends with a concrete usage example. Every sentence adds value, with no filler or redundant 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 tool is simple (2 parameters, no nested objects) and an output schema exists, so the description does not need to explain return values in depth. It nevertheless does so, which is slightly redundant but still useful. The description, schema, and context signals together provide enough information 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 covers both parameters with descriptive text, including the 100-item limit for app_ids and supported language strings. The description also provides an example of parameter usage ('app_ids=[730, 570, 440], language="english"'), reinforcing the schema. It does not add meaning beyond what the schema already provides, so the baseline score 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 purpose: to retrieve game details from the Steam store. It lists specific return fields (name, developers, publishers, price, etc.), which distinguishes it from sibling tools like get_game_schema or search_games. The verb '조회합니다' (retrieve) and resource '게임 상세 정보' 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: when you have Steam app_ids and need detailed game information. It provides a usage example with app_ids and language, but does not explicitly mention alternatives or exclusions. The context makes the use case clear, though it stops short of naming sibling tools for differentiation.
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?
No annotations are provided, so the description carries the burden. It discloses the return fields and includes a usage example, but doesn't mention rate limits, error behavior, or confirm this is a read-only operation. The return data description is helpful but not exhaustive.
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 concise, front-loaded with the purpose, lists return fields efficiently, and includes a short example. 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?
Given the single parameter with 100% schema coverage and an output schema, the description provides sufficient context for an agent. It explains returns even though output schema exists, which is a bonus. It lacks details on error handling but that's not critical for this simple 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 coverage is 100%, so the parameter is well documented. The description adds a usage example but does not significantly expand on the parameter semantics 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 retrieves VAC and game ban status for players, specifying the resource (player bans) and the action (retrieve). It lists the returned fields, distinguishing it from sibling tools like get_user_profile or 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 provides a usage example with steam_ids and implies use for ban queries. However, it doesn't explicitly state when to use this over alternatives or any exclusions, but the context with sibling tool names makes it 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?
With no annotations provided, the description carries the burden of behavioral disclosure. It lists the output fields and implies a read-only operation, but does not mention potential limitations (e.g., private profiles), authentication requirements, or error cases. The description adds some context about return values but lacks depth.
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 concise and well-structured: a one-sentence purpose, a bulleted list of return fields, and a usage example. Every sentence adds value, with no redundancy or filler.
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 tool with one parameter and an output schema present, the description provides sufficient detail: purpose, return fields, and an example. The only minor gap is the absence of any note about profile visibility or data availability, but the existing output schema likely covers return structure, making this adequate.
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 describes the steam_id parameter thoroughly, including an example and the vanity URL resolution note. The description does not add additional parameter semantics beyond what the schema provides, so the baseline score of 3 applies 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 clearly states the tool retrieves a Steam user profile (조회합니다) and lists the specific return fields (personaname, avatarfull, etc.), making its purpose unambiguous. It is distinct from sibling tools like get_friends_list or get_owned_games, which focus on other data types.
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 includes a concrete usage example with steam_id and adds a helpful cross-tool reference to resolve_vanity_url for vanity URLs, indicating a prerequisite workflow. However, it does not explicitly state when to use this tool versus alternatives or when not to use it, though the sibling context makes this implicit.
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?
With no annotations provided, the description takes on the full burden of behavioral disclosure. It explicitly states the return data (achievement name and percentage) and explains how to interpret the results (rare vs common), providing useful behavioral context beyond 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 concise and well-structured: it starts with the main purpose, then explains the return data, provides an interpretation guideline, and ends with a usage example. Every sentence earns its place with no 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?
As a simple tool with one parameter and an existing output schema, the description adequately covers the purpose, return shape, and interpretation. It could potentially mention edge cases (e.g., games without achievements), but the current description is sufficiently complete for a typical query 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 already provides 100% coverage for the single parameter app_id, making the baseline 3. The description adds a usage example (app_id=730) which is helpful but does not add any new semantic meaning to the parameter beyond what the schema already states.
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 '조회합니다' (queries) and clearly identifies the resource as the game's global achievement percentages. It differentiates itself from the sibling get_player_achievements by emphasizing global achievement statistics, making its scope distinct.
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 its usage context by focusing on global achievement rates, which is clearly distinct from player-specific tools. It also provides a usage example, but it does not explicitly mention when not to use it or name alternative 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?
No annotations are present, so the description carries full burden. It discloses the return data structure and notes that English searches are more accurate. However, it does not explain matching behavior, error handling, or other edge cases that could affect agent 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 concise and well-structured: a one-sentence purpose, a list of return fields, a search tip, and an example. Every sentence adds useful information without 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 two-parameter search tool with an output schema, the description covers purpose, return data, and usage guidance. It lacks explicit boundary conditions (e.g., max count is already in schema) but is otherwise complete 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, but the description adds value beyond the schema by clarifying that the 'query' works best in English and by providing a concrete usage example with 'query="action", count=25'.
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 'Steam에서 게임을 검색합니다' (Searches for games on Steam) with a specific verb and resource. It lists the return fields, distinguishing it from sibling tools that retrieve specific game data or user profiles.
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 practical search tips: using English or App ID for better accuracy, and includes a usage example. It implies when to use this tool over alternatives (e.g., when you need to find a game by name), though it doesn't explicitly contrast with 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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions the return data includes 'steamid' and 'success', which adds transparency. However, it does not disclose failure behavior (e.g., what happens if the vanity URL is invalid) or explicitly state that the operation is read-only and side-effect-free.
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 well-structured and concise, covering the function, return data, an important usage note, and an example in a compact format. Every sentence adds value, and 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?
Given the tool's simplicity, an output schema exists, and the description explains the purpose, usage context, return data, and provides examples. It is missing explicit error-handling details, but that is not critical for this conversion tool. Overall, it is complete for its complexity.
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 provides a clear description of the parameter with 100% coverage, so the baseline is 3. The description adds value by providing usage examples ('robinwalker', 'customusername') and clarifying the parameter's role in the conversion process, going 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 explicitly states the function: converting Steam custom URLs (vanity URLs) to 64-bit Steam IDs. It uses a specific verb and resource, and clearly distinguishes itself from sibling tools, which are all data retrieval tools, by being a conversion utility.
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 clear usage guidance: 'Most other tools require 64-bit Steam ID. If user provides only custom URL, must first convert with this tool.' This explicitly tells when to use it and implies when not to use it (when a 64-bit ID is already available).
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:

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

Score Badge

Copy to your README.md:

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

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/deuxksy/mcp-server-steam'

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