Provides tools for managing Steam gaming library, achievements, stats, and store discovery, including game details, reviews, wishlist, player profiles, and more.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-steam show me my top 5 games by playtime"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Steam, focused on gaming library management, achievements, stats, and store discovery. 20 tools designed for use with Claude and other LLM agents.
Python 3.14+
Your Steam ID (numeric, up to 17 digits)
Related MCP server: Steam MCP Server
Go to the Steam Web API Key page
Sign in with your Steam account
Register a domain name (any name works for personal use)
Note your API key
Your Steam ID is the numeric identifier in your profile URL. If your profile URL is https://steamcommunity.com/profiles/1111111111111111, your Steam ID is 1111111111111111.
If you use a custom URL (e.g., /id/username), use a Steam ID finder to look up the numeric ID.
cd mcp-steam
uv syncSet these before running the server:
export STEAM_API_KEY="your_api_key"
export STEAM_ID="your_steam_id"uv run mcp-steamThe server verifies your API key and Steam ID on startup by fetching your player summary.
Add to your MCP server config. If installed from PyPI:
{
"mcpServers": {
"steam": {
"command": "uvx",
"args": ["mcp-steam"],
"env": {
"STEAM_API_KEY": "your_api_key",
"STEAM_ID": "your_steam_id"
}
}
}
}Or if running from a local clone:
{
"mcpServers": {
"steam": {
"command": "uv",
"args": ["--directory", "/path/to/mcp-steam", "run", "mcp-steam"],
"env": {
"STEAM_API_KEY": "your_api_key",
"STEAM_ID": "your_steam_id"
}
}
}
}Tool | Parameters | Description |
|
| Convert a custom profile URL name to a 64-bit Steam ID. |
Tool | Parameters | Description |
|
| Your game library with playtime. Sort by playtime, recent, or name. |
|
| Games played in the last 2 weeks. |
Tool | Parameters | Description |
|
| Store page info: description, price, genres, metacritic, platforms. |
|
| Search the Steam store. |
|
| Live concurrent player count for a game. |
|
| Achievement and stat definitions for a game. |
|
| User reviews with recommendation, playtime, and helpfulness. |
|
| Bundle/package pricing, included apps, and platforms. |
Tool | Parameters | Description |
|
| Your achievement progress with global rarity percentages. |
|
| Game-specific stats (kills, deaths, etc.). |
|
| Global unlock percentages for all achievements. |
Tool | Parameters | Description |
|
| Your wishlist sorted by priority, with prices and discounts. |
Tool | Parameters | Description |
|
| Recent news and updates for a game. |
Tool | Parameters | Description |
|
| Profile summary. Accepts Steam ID or vanity name; defaults to you. |
|
| Friends list. Accepts Steam ID or vanity name; defaults to you. |
|
| VAC, community, game, and trade ban status. Defaults to you. |
|
| Steam level for a player. Defaults to you. |
Tool | Parameters | Description |
| (none) | Currently featured and on-sale games. |
| (none) | Top Sellers, New Releases, Specials, Coming Soon, and more. |
API key security: Your config file contains your Steam API key. Never commit it to version control or share it publicly.
Rate limits: The Steam Web API has undocumented rate limits. If you hit them, the server will return a rate limit error.
Profile visibility: Some tools require your Steam profile to be public (achievements, game stats). Library data works regardless.
Game stats availability: Not all games expose stats through the API. get_player_stats will return an error for unsupported games.
Wishlist access: Wishlist data requires your profile's wishlist to be public.
uv run mcp-steam # Run the server
uv run ruff check src/ # Lint
uv run ruff format src/ # Format
uv run pyright src/ # Type checkThis project uses lefthook for pre-commit checks. Install with brew install lefthook (or see other install methods), then:
lefthook installGet your achievement progress for a Steam game.
Returns each achievement's unlock status, description, unlock time, and how rare it is globally. Includes unlocked/total summary.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It correctly implies a read-only operation and lists returned data. However, it omits details on authentication, rate limits, or error cases. The description is adequate but lacks depth expected for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loaded with purpose followed by return details. No unnecessary words. Minor improvement possible by adding parameter context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the purpose and return values. Missing context includes authentication requirements, that it is user-specific, and the meaning of 'app_id'. Overall adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'app_id' with no description and 0% schema coverage. The description adds no meaning about what 'app_id' is (e.g., the game's Steam ID) or its format. The agent would have to infer from context, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves achievement progress for a Steam game, specifying verb (get) and resource (achievement progress). It details the returned data (unlock status, description, unlock time, rarity) and distinguishes from siblings like 'get_global_achievement_stats' which returns global percentages rather than per-user progress.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention that it requires authentication or that it returns only the current user's achievements. Sibling tools exist for global stats or other game info, but no differentiation or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get user reviews for a Steam game.
Returns review text, recommendation, playtime, and helpfulness votes. Includes summary with total positive/negative counts and score description.
review_type: "all" (default), "positive", or "negative".
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| app_id | Yes | ||
| review_type | No | all |
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 indicates the tool is read-only (get) and describes the returned data fields and summary. However, it does not disclose potential limitations like pagination, authentication requirements, rate limits, or error handling. The description is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three short sentences that quickly convey the tool's purpose, output, and a key parameter. The most critical information (purpose) is front-loaded. However, there is no title, and the structure could be slightly improved by separating the parameter explanation more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, 0% schema description, and no output schema, the description provides a good overview of what the tool does and what it returns (including a summary). However, it lacks explanations for the limit and app_id parameters, and does not mention potential constraints like authentication or rate limits. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It adds value by explaining the review_type parameter: 'all' (default), 'positive', or 'negative'. However, it does not explain app_id (though implied by the tool's purpose) or limit (what it limits). The description partially fills the gap but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get user reviews for a Steam game.' It specifies the resource (reviews) and action (get), and lists what is returned (review text, recommendation, playtime, helpfulness votes). This distinguishes it from sibling tools like get_game_details or get_owned_games, 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.
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 need user reviews for a specific Steam game. However, it does not explicitly state when not to use it or mention alternatives. For example, it doesn't contrast with get_game_details, which might also include review summaries. The guidance is minimal and left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current number of players in a Steam game.
Returns the live concurrent player count.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description indicates read-only behavior ('Returns the live concurrent player count') but lacks disclosure on rate limits, authentication needs, or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, efficient sentences. First sentence states purpose, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and description only vaguely mentions return value. Does not specify exact structure (e.g., integer, object). Adequate for a simple tool but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description does not clarify the format of app_id (e.g., numeric Steam App ID) beyond its name. Leaves ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets the current number of players in a Steam game, with specific verb 'Get' and resource 'current number of players'. Distinguishes from siblings like get_game_details 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No explicit context or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Steam store featured categories.
Returns games organized by category: Top Sellers, New Releases, Specials, Coming Soon, and more. Each category includes game names, prices, and discounts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation by describing what it returns (games, categories), but it does not explicitly state that no modifications occur, nor does it mention any authorization or rate limits. Since no annotations are provided, the description carries the burden but falls short of fully disclosing behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no redundant information, and front-loaded with the core action and result. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description adequately explains what the tool does and what is returned. However, it could be more complete by distinguishing it from the similar-sounding 'get_featured_games' sibling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema covers all input requirements. The description adds value by explaining the output structure (categories with games, prices, discounts), which is helpful for understanding what the tool returns without needing an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves Steam store featured categories and lists examples of categories and included data (names, prices, discounts). However, it does not explicitly differentiate from the sibling tool 'get_featured_games', which might have a similar but distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as 'get_featured_games' or other game-listing tools. The context of use is entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get currently featured and on-sale games on Steam.
Returns featured games split into on-sale (with discounts and prices) and regular featured titles.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 games split into two categories, with on-sale items including discounts and prices. This sufficiently conveys the read-only, non-destructive nature and output structure, though it could explicitly state no authentication needed or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, no wasted words, and front-loaded with the primary action. Every sentence adds value, meeting the highest standard for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description fairly completely explains what the tool returns. It specifies the two categories and mentions discounts/prices for on-sale items. However, it lacks details on the output format (e.g., list of IDs or names) or possible empty results, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is automatically 100%. The description does not need to add parameter semantics. The baseline for no parameters is 4, and the description adds no contradictory or missing information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get currently featured and on-sale games on Steam.' It specifies the resource (featured and on-sale games) and the verb (get), and elaborates on the output split into on-sale and regular titles. This distinctively sets it apart from sibling tools like get_game_details or search_games.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when not to use it, nor does it compare to siblings like get_featured_categories or search_games. The agent is left to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Steam friends list.
Returns friend Steam IDs, relationship status, and when you became friends.
steam_id: optional Steam ID or vanity name. Defaults to your own profile.
| Name | Required | Description | Default |
|---|---|---|---|
| steam_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the tool is read-only and returns specific fields, but does not disclose potential error behaviors (e.g., invalid steam_id), rate limits, or authentication requirements. The description is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using three short lines to convey purpose, return values, and parameter details. It is front-loaded with the core action and contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with a single optional parameter and a known output (friend list), the description provides essential information: what it does, what it returns, and how to use the parameter. The existence of an output schema is mentioned in context, so the description need not detail the output format. It is complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the parameter. The description compensates by explaining that steam_id is optional, can be a Steam ID or vanity name, and defaults to the user's own profile. This adds meaningful context beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a Steam friends list and details the returned information (friend IDs, relationship status, date befriended). It distinguishes itself from sibling tools which focus on games and achievements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not discuss prerequisites, alternative tools for similar tasks, or situations where this tool is inappropriate. The sibling tools are mostly unrelated, but explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed store information for a Steam game.
Returns name, description, price, genres, platforms, metacritic score, and release date. Use the app_id from library or search results.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. Describes return fields but lacks details on error handling, rate limits, or authentication requirements. However, as a read operation, the risk is low.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the purpose, the second lists outputs and provides input guidance. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is sufficient. It explains what it does, what it returns, and how to get the input. Could mention default behavior for invalid IDs, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaningful context by specifying the source of the app_id. The single parameter's purpose is clear from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'detailed store information for a Steam game'. It lists specific fields returned, distinguishing it from siblings like get_owned_games or get_current_players.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells where to obtain the input ('app_id from library or search results'), providing clear context. Does not explicitly exclude alternatives but the returned fields imply when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent news and updates for a Steam game.
Returns news titles, authors, dates, summaries, and URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | ||
| app_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the type of data returned (titles, authors, dates, summaries, URLs), which gives basic behavioral insight. Without annotations, it carries some burden but lacks details on potential side effects, rate limits, or behavior when no news is available.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) and front-loaded with the purpose. However, it omits necessary parameter details, making it inadequate despite being concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters (one required) and an output schema, the description does not cover essential usage context like the expected format of app_id or the default count. The agent would likely need additional information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the description does not explain the parameters 'app_id' and 'count' at all. The description adds no value beyond the input schema, which is insufficient for an agent to correctly set parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves recent news and updates for a Steam game, using a specific verb and resource. However, it does not differentiate from sibling tools like get_game_details or get_app_reviews, which could cause confusion for an agent deciding which tool to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or exclusions. The description implies usage for news retrieval but offers no context for tool selection among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get achievement and stat definitions for a Steam game.
Returns achievement display names, descriptions, and hidden status, plus stat definitions. Useful for understanding what stats and achievements a game tracks.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes |
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 the return content (display names, descriptions, hidden status, stat definitions) and implicitly indicates it is a read operation. However, it does not discuss potential errors, rate limits, or permissions, limiting full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two short paragraphs that front-load the primary action and then elaborate on return values. Every sentence contributes useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema (one required parameter, no nested objects, no output schema), the description adequately covers the tool's purpose and return information. It could be improved by mentioning the parameter, but it remains sufficient 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one required parameter (app_id) but the description does not explain its meaning (Steam App ID), format, or constraints. With schema description coverage at 0%, the description should compensate but fails to add value beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves achievement and stat definitions for a Steam game. It uses a specific verb ('Get') and resource, and distinguishes from sibling tools like 'get_achievements' (which likely returns user-specific progress) and 'get_player_stats' (current stats), by emphasizing 'definitions' (schema/metadata).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes it is 'useful for understanding what stats and achievements a game tracks,' which implies a use case of exploring game metadata. However, it does not explicitly state when not to use it or provide alternatives, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get global achievement unlock percentages for a Steam game.
Shows how rare each achievement is across all players. Useful for identifying the hardest or rarest achievements.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions it shows rarity percentages. It does not disclose authentication needs, error handling, rate limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. First sentence states purpose, second provides usage hint. Very efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema, the description covers the purpose but lacks explanation of the parameter and additional behavioral details. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (app_id) with 0% description coverage. The tool description fails to explain what app_id represents (Steam App ID), leaving the agent without crucial context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves global achievement unlock percentages for a Steam game, using a specific verb and resource. It distinguishes from siblings like get_achievements by specifying it's global across all players.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it's useful for identifying rare achievements, implying when to use it, but does not explicitly state when not to use it or provide comparisons to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your Steam game library with playtime stats.
sort_by options: "playtime" (default, most played first), "recent" (most recently played first), "name" (alphabetical).
Returns game names, app IDs, and total/recent playtime.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| sort_by | No | playtime |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description adequately implies a read operation by using 'Get'. However, it does not disclose pagination behavior or potential rate limits, leaving some behavior unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the main purpose, and every sentence adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the main purpose and return fields, it lacks details on pagination and how to retrieve all games. Given the presence of an output schema, the return value explanation is sufficient but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains sort_by options, adding value beyond the schema's default value. However, the limit parameter is not explained, and schema coverage is 0%, so the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a Steam game library with playtime stats, specifying return fields. It implicitly distinguishes from sibling tools like get_recently_played by focusing on all owned games, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings such as get_recently_played or search_games. The description only covers what the tool does, not when it is appropriate to use over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a Steam package or bundle.
Returns package name, price, discount, included apps, platforms, and release date. Use for bundles and multi-game packages.
| Name | Required | Description | Default |
|---|---|---|---|
| package_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It lists output fields but does not mention safety traits (e.g., read-only, idempotent) or operational details like error handling or rate limits. This is adequate for a simple retrieval tool but lacks explicit 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no extraneous words. Efficient but could include parameter detail without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and return fields, which is good given no output schema. However, it lacks parameter format, error behavior, or prerequisites, leaving gaps for a tool with only one parameter and no schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the package_id parameter beyond its name. Since schema coverage is 0%, the description should provide format or example (e.g., numeric ID). It only adds context that it's for packages/bundles, which is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets details for a Steam package or bundle, listing specific return fields. It distinguishes itself from the sibling tool get_game_details by specifying 'Use for bundles and multi-game packages.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for bundles and multi-game packages,' providing clear context for when to use this tool. However, it does not explicitly state when not to use it or mention alternatives beyond the implied differentiation from get_game_details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ban status for a Steam player.
Returns VAC bans, community bans, game bans, and trade/economy ban status.
steam_id: optional Steam ID or vanity name. Defaults to your own profile.
| Name | Required | Description | Default |
|---|---|---|---|
| steam_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description discloses that it returns multiple ban types, which is useful. However, it does not mention authentication needs, rate limits, or whether the operation is read-only. Given the simple retrieval nature, the disclosure is adequate but could be more thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each with clear purpose. First sentence states the function, second lists return types, third explains the parameter. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter optional tool, the description covers the return value types (VAC, community, game, trade bans). It does not detail the format or provide examples, but it is sufficient for basic usage. No output schema exists, so description fills the gap reasonably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains that steam_id can be a Steam ID or vanity name and defaults to own profile, adding significant meaning beyond the empty schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves ban status for a Steam player and lists specific ban types (VAC, community, game, trade/economy). It is specific about the verb 'Get' and resource 'ban status', but does not explicitly differentiate from sibling tools like get_player_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context by noting the steam_id parameter is optional and defaults to the user's own profile, but no explicit guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your gameplay statistics for a Steam game.
Returns game-specific stats like kills, deaths, time played, etc. Not all games provide stats.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions the tool returns stats and that not all games support it, but does not disclose whether it is read-only, requires authentication, rate limits, or what happens if a game lacks stats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences front-loading the main purpose. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the basic functionality and an important caveat (not all games provide stats). However, it lacks details on authentication, error handling, and the exact format of returned data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter app_id with 0% description coverage. The description does not explain the format or how to obtain the app_id value, relying solely on the parameter name for interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves gameplay statistics for a Steam game, with examples like kills, deaths, time played. It distinguishes from sibling tools like get_achievements or get_current_players by focusing on game-specific player stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing game stats, but does not explicitly state when not to use it or suggest alternatives among siblings. No guidance on prerequisites like authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Steam profile summary.
Returns display name, online status, profile URL, and currently playing game (if any).
steam_id: optional Steam ID or vanity name. Defaults to your own profile.
| Name | Required | Description | Default |
|---|---|---|---|
| steam_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry all behavioral disclosure. It describes the return fields and default parameter behavior, but does not explicitly state that the operation is read-only, nor mention potential errors or rate limits. For a simple lookup tool, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, front-loading the main purpose in a single sentence, then listing return values and parameter info. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, no output schema), and the description adequately explains purpose, return values, and parameter semantics. It could mention error handling or the exact format of the steam_id, but overall it provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides type and default, but the description adds crucial context: steam_id can be a Steam ID or a vanity name, and defaults to the user's own profile. This significantly clarifies parameter usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a Steam profile summary and lists specific return fields (display name, online status, profile URL, currently playing game). This distinguishes it from sibling tools like get_player_stats or get_friend_list, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the optional steam_id parameter and its default behavior, but does not explicitly guide when to use this tool versus alternatives. Implicitly, it is for basic profile info, but no when-not or direct sibling comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your recently played Steam games (last 2 weeks).
Returns game names, app IDs, and playtime for the period.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It reveals that the tool returns game names, app IDs, and playtime for the last 2 weeks, implying a read-only operation. However, it does not mention any error conditions, rate limits, or data freshness guarantees, which would add transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief (two sentences) and front-loaded with the main purpose. However, it omits essential information about the parameter, making it incomplete. Conciseness should not come at the cost of missing critical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists and the description hints at return values, the parameter 'limit' is left completely unexplained. For a tool with one optional parameter, the description should at least mention it to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema lacks parameter descriptions. The tool description fails to explain the 'limit' parameter, its purpose, valid values, or its impact on results. The description adds no value beyond the schema's type and default. This is a critical gap for a single-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves recently played Steam games from the last 2 weeks and lists the returned data (game names, app IDs, playtime). It distinguishes from siblings like get_owned_games and get_current_players by specifying 'recently played' and the time window.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It lacks context about typical use cases or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the installed version of the mcp-steam server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It correctly states it returns the installed version, indicating a read-only operation. Additional details like non-destructive nature are implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous information. Every word is necessary and contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the existence of an output schema (though not shown), the description adequately conveys the tool's purpose. It could specify the version format, but for a simple retrieval, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is effectively 100%. The description adds no parameter info, but the baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the installed version of the mcp-steam server, which is a specific and distinct action. No sibling tool performs this function, so it is well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when version info is needed, but does not explicitly state when not to use or mention alternatives. However, for a simple version check, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Steam level for a player.
steam_id: optional Steam ID or vanity name. Defaults to your own profile.
| Name | Required | Description | Default |
|---|---|---|---|
| steam_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only mentions the default behavior for steam_id, but does not disclose authentication requirements, rate limits, error handling, or what constitutes a valid input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey the core purpose and parameter details. No filler words, but the structure could be slightly improved by separating the parameter description into its own line or bullet.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should hint at the return value (e.g., level number). It adequately covers input but leaves output and error behavior unspecified, which is a gap for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the schema: it explains that steam_id is optional, accepts Steam IDs or vanity names, and defaults to the caller's profile. The schema only provides type and title, so this context is essential.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the Steam level for a player, with a specific verb and resource. It distinguishes from sibling tools like get_game_schema or get_owned_games, which focus on games or other player data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or scenarios where another tool might be more suitable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your Steam wishlist.
Returns wishlisted games sorted by priority, with prices and current discounts if available.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It mentions returned data (prices, discounts) but omits authentication, rate limits, pagination, or whether it is read-only. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. No extraneous information. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema, the description lacks parameter explanation and usage context. For such a simple tool, it is incomplete regarding input semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, limit, is not explained in the description. With 0% schema coverage, the description should clarify its meaning, but it does not. This leaves the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the user's Steam wishlist, specifying it returns games sorted by priority with prices and current discounts. This distinguishes it from sibling tools like 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no when-not statements, and no reference to sibling tools. The description lacks usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a Steam vanity URL name to a 64-bit Steam ID.
Converts a custom profile URL name (e.g. "gabelogannewell") into the numeric Steam ID needed by other tools. Useful when you only know someone's profile name.
| Name | Required | Description | Default |
|---|---|---|---|
| vanity_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It correctly signals a non-destructive conversion ('resolves', 'converts') and specifies the output (64-bit Steam ID). It could explicitly state it's a read-only operation, but the intent is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences and a brief note, all front-loaded with essential information. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description is complete. It explains purpose, parameter, and output type, covering all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameter. It does so effectively: 'custom profile URL name' with an example, adding meaning beyond the schema's 'Vanity Name' title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves a Steam vanity URL name to a 64-bit Steam ID, providing an example ('gabelogannewell'). This purpose is distinct from any sibling tools, which are game or player info tools, making it easy to differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Useful when you only know someone's profile name,' which implies when to use it. It does not explicitly state when not to use it or provide alternatives, but the context is clear given the tool's unique role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Steam store for games.
Returns game names, app IDs, prices, and supported platforms.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions return fields (game names, app IDs, prices, platforms) which helps, but omits details like whether it's read-only, rate limits, or pagination behavior. The description is partially transparent but not fully.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states purpose, the second describes return values. Every sentence is meaningful, and the description is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema available, return value details are covered elsewhere. However, the description lacks parameter documentation and usage guidelines, especially given the presence of sibling tools. It is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. The description implies that 'query' is a search term, but does not explain 'limit' or its default value. It adds minimal meaning beyond the schema's property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search the Steam store for games,' which is a specific verb and resource. It clearly distinguishes from siblings like get_featured_games or get_owned_games by focusing on search functionality and listing return fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_featured_games or get_owned_games. The description does not provide when-not-to-use or mention any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes, but some are closely related (e.g., get_game_schema, get_achievements, get_global_achievement_stats; get_featured_games and get_featured_categories). Descriptions help differentiate them, but minor overlap exists.
All tools follow a consistent verb_noun pattern using snake_case (e.g., get_owned_games, search_games, resolve_vanity_url). No mixing of conventions, making the set predictable.
21 tools cover multiple Steam domains (library, store, user profile, achievements, etc.) without being excessive. The number is well-scoped for the platform's complexity.
Covers major read-only queries: game details, library, user profiles, achievements, store features. Missing write operations and some niche features (market, trading cards), but core functionality is solid.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for building and testing AI agents with multi-model experimentation and insights.
A registry of AI agent tools — MCP servers, APIs, CLIs, SDKs — kept current by automated ingestion.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/obrien-matthew/mcp-steam'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
