Provides tools to query Steam store data, player counts, achievements, reviews, pricing, workshop items, leaderboards, and player profiles via the Steam Web API.
Provides tools for Steamworks partner APIs, including managing achievements, leaderboards, workshop items, lobbies, and inventory items via SDK guides and HTTP POST calls.
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., "@Steam MCP Server get player count for Counter-Strike 2"
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.
Query Steam store data, player statistics, achievements, reviews, pricing, workshop items, leaderboards, inventory, and player profiles - all as structured MCP tools callable from Cursor's AI agent.
No API key required for most features. Store lookups, player counts, global achievement stats, news, reviews, and app searches all work out of the box.
Node.js 20 or later
npm
git clone https://github.com/TMHSDigital/Steam-MCP.git
cd Steam-MCP
npm install
npm run buildSome tools require a Steam Web API key. Get one free at steamcommunity.com/dev/apikey.
Set it as an environment variable:
# Bash / macOS / Linux
export STEAM_API_KEY="your_key_here"
# PowerShell
$env:STEAM_API_KEY = "your_key_here"Or in a .env file:
STEAM_API_KEY=your_key_hereTools that don't need a key work out of the box with zero configuration.
Related MCP server: mcp-steam
Add the Steam MCP server to your Cursor MCP settings (.cursor/mcp.json in your project or global settings):
Via npx (recommended):
{
"mcpServers": {
"steam": {
"command": "npx",
"args": ["-y", "@tmhs/steam-mcp"],
"env": {
"STEAM_API_KEY": "your_key_here"
}
}
}
}Via local clone:
{
"mcpServers": {
"steam": {
"command": "node",
"args": ["/absolute/path/to/Steam-MCP/dist/index.js"],
"env": {
"STEAM_API_KEY": "your_key_here"
}
}
}
}Once configured, the tools are available to Cursor's AI agent. Pair with the Steam Developer Tools plugin for the full skill set.
These work without an API key:
Tool | Description |
| Store data: price, description, reviews, tags, platforms, system requirements |
| Search for games/apps by name or keyword |
| Current concurrent player count |
| Global achievement unlock percentages |
| Workshop item details (title, description, tags, subscribers) |
| Fetch user reviews with filters for language, sentiment, purchase type |
| Batch price check for multiple apps in a specific region |
| Review score, total counts, and positive percentage (no individual reviews) |
| Pricing breakdown across multiple countries/regions |
| Recent news articles with title, URL, contents, date, and author |
| Local PNG/JPEG vs Valve store and library sizes, plus library-hero heuristics |
These require STEAM_API_KEY to be set:
Tool | Description |
| Player profile: name, avatar, online status |
| Game library with playtime data |
| Search/browse Workshop items with filters |
| Leaderboard scores and rankings (pass numeric ID from Steamworks dashboard) |
| Convert vanity URL to 64-bit Steam ID |
| Achievement/stat schema with display names, descriptions, and icon URLs |
| Per-player achievement unlock status and timestamps |
| List all leaderboards with numeric IDs, names, and sort methods |
These require a publisher API key with server IP allowlisted in Steamworks partner settings. SDK-only tools return code examples instead of making HTTP calls.
Tool | Type | Description |
| SDK guide | Returns C++/C#/GDScript code for ISteamMatchmaking lobby creation |
| SDK guide | Returns code for ISteamUGC Workshop upload workflow |
| HTTP POST | Update Workshop item metadata via IPublishedFileService partner API |
| HTTP POST | Set/unlock achievements via ISteamUserStats partner API (dev/test) |
| HTTP POST | Clear/re-lock achievements via ISteamUserStats partner API (dev/test) |
| HTTP POST | Upload scores via ISteamLeaderboards partner API |
| HTTP POST | Grant inventory items via IInventoryService partner API |
Endpoint | Auth |
| None |
| None |
| None |
| None |
| None |
| None |
| None |
| API key |
| API key |
| API key |
| API key |
| API key |
| API key |
| Publisher key |
| API key |
| Publisher key |
| Publisher key |
| Publisher key |
| Publisher key |
npm run dev # Watch mode with auto-reload
npm run build # Compile TypeScript to dist/
npm start # Run the compiled server
npm test # Run all tests (vitest)
npm run test:watch # Test watch modeSee CONTRIBUTING.md for how to add new tools and submit PRs.
Partner-admin tools (steam_partnerLogin, steam_uploadStoreImage, steam_uploadTrailer) are not registered by this package's default bin and are not in the npm tarball. They live in src/partner/ for local use only (STEAM_PARTNER_ADMIN=1 plus a cookie-jar path or Chromium profile dir outside the repo). There is no Publish tool.
Steam Developer Tools - Cursor IDE plugin with 30 skills and 9 rules for Steam/Steamworks development
CC BY-NC-ND 4.0 - see LICENSE for details.
Clear (re-lock) an achievement for a player via the partner API. Intended for dev/test use. Requires a publisher API key with server IP allowlisted in Steamworks partner settings.
| Name | Required | Description | Default |
|---|---|---|---|
| appid | Yes | Steam application ID | |
| steamid | Yes | 64-bit Steam ID of the player | |
| achievement | Yes | Achievement API name (e.g. ACH_BEAT_LEVEL_1). Must match a name configured in Steamworks. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits itself. It discloses that the call is via the partner API and requires specific authentication, but it does not mention error handling, idempotency, or lack of side effects beyond clearing the achievement. Given the simple action, 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 extremely concise: two sentences that immediately convey the purpose, intended use, and a key prerequisite. Every phrase adds value 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?
There is no output schema. The description does not explain what the tool returns on success or failure, nor does it cover potential error conditions. While the tool is simple, the lack of return information leaves a gap in understanding the full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds extra context to the 'achievement' parameter: 'e.g. ACH_BEAT_LEVEL_1. Must match a name configured in Steamworks.' This provides valuable guidance beyond the schema's minLength and type. The other parameters are also well-described in 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 verb 'clear' and the resource 'achievement', and explicitly says 're-lock' which distinguishes it from the sibling tool steam_setAchievement (which typically unlocks). This provides specific purpose differentiation.
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 context by specifying 'Intended for dev/test use' and lists a clear prerequisite: 'Requires a publisher API key with server IP allowlisted in Steamworks partner settings.' It does not explicitly mention when not to use or alternative tools, but the dev/test restriction guides appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get code examples and documentation for creating Steam multiplayer lobbies. Lobby creation is a client-side SDK operation (ISteamMatchmaking) and cannot be done via HTTP API. This tool returns ready-to-use code for C++, C#, and GDScript.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Lobby visibility type | |
| metadata | No | Key-value pairs for lobby metadata (e.g. map name, game mode) | |
| max_members | Yes | Maximum number of players in the lobby |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the tool returns code and is client-side, but does not detail side effects, permissions, or rate limits. Adequate for a read-only code generation tool.
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?
Three sentences, front-loaded with core purpose. No unnecessary words. Every sentence adds value, including the languages supported and client-side nature.
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, but description explains return is code examples for three languages. Could mention output format or that no actual lobby creation occurs, but largely complete for a simple code generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description adds no additional meaning beyond the schema, which already defines parameters adequately. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides code examples and documentation for creating Steam lobbies, not actual creation. It specifies the verb 'Get' and resource 'code examples', distinguishing it from typical creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions that lobby creation is a client-side SDK operation and cannot be done via HTTP API, guiding the agent away from expecting actual creation. It lacks explicit when-to-use vs alternatives, but the context is clear.
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 app. Shows how many players have unlocked each achievement. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| appid | Yes | Steam application ID to get achievement stats for |
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 states the tool is read-only and requires no API key, but does not disclose behavior on invalid appid, error handling, rate limits, or the response format. This is insufficient 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 very concise: two short sentences with no filler. It front-loads the purpose and adds a key detail (no API key) efficiently.
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 (single integer parameter, no output schema), the description covers the core purpose and input. It could optionally mention the response structure or error cases, but is largely complete for its 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 description coverage is 100% as the only parameter (appid) has a description. The description's text 'Steam application ID to get achievement stats for' adds no new meaning beyond the schema's 'Steam application ID to get achievement stats for'. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves global achievement unlock percentages for a Steam app, distinguishing it from sibling tools like steam_getPlayerAchievements which target individual players. The phrase 'Shows how many players have unlocked each achievement' reinforces the aggregate nature.
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 'No API key required,' which implies ease of use, but lacks explicit guidance on when to use this tool versus alternatives like steam_getPlayerAchievements for per-player data. Context is implied but not directly compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Steam store data for an app including price, description, reviews, tags, platforms, and system requirements. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| l | No | Language code for descriptions (e.g. english, german) | |
| cc | No | Two-letter country code for pricing (e.g. US, GB, DE) | |
| appid | Yes | Steam application ID (e.g. 440 for Team Fortress 2) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes 'No API key required', which is a behavioral detail. However, without annotations, it does not disclose other relevant behaviors (e.g., read-only, rate limits, or data freshness). The description is adequate but incomplete.
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: one specifying purpose and data types, another noting no API key requirement. No redundant information, efficient and 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?
The description lists data types but does not explain the return format or structure. Given the complexity of Steam store data and no output schema, more detail on the response would improve completeness. However, the description is adequate for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all three parameters with clear descriptions (appid, cc, l). The description does not add semantic value beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Steam store data including specific types (price, description, reviews, tags, platforms, system requirements), distinguishing it from sibling tools that focus on subsets (e.g., steam_getReviews, steam_getPriceOverview).
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 comprehensive tool versus the more specific sibling tools (e.g., steam_getReviews, steam_getPriceOverview). No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get review summary statistics for a Steam app: total positive/negative counts, review score, and score description. No individual reviews returned. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| appid | Yes | Steam application ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses key behavioral traits: returns only summary stats, no individual reviews, and no API key required. It does not mention potential rate limits or response format, but for a simple read-only retrieval, the information provided is adequate and consistent.
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, front-loading the purpose and key details. Every word adds value, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description is complete. It specifies what is returned, what is not, and highlights no API key requirement. No additional context is needed for effective use.
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 covers 100% of the single parameter (appid) with description 'Steam application ID', so the schema already provides the meaning. The tool description adds no additional parameter-level details beyond contextualizing the appid as 'Steam app', but does not enhance semantics beyond what the schema provides.
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 'review summary statistics for a Steam app', listing specific outputs (positive/negative counts, review score, score description) and explicitly states what is not returned ('No individual reviews returned'). This effectively distinguishes it from sibling steam_getReviews.
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 clear context for when to use this tool (for summary statistics) and explicitly states a limitation ('No individual reviews returned'), which hints that steam_getReviews should be used for individual reviews. However, it does not explicitly name the alternative tool, leaving some inference needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get leaderboard scores and rankings for a Steam app. Pass the numeric leaderboard ID from your Steamworks dashboard, not the name. Uses the partner API (partner.steam-api.com) which requires a publisher API key with server IP allowlisted in Steamworks. Supports global, around-user, and friends-only views.
| Name | Required | Description | Default |
|---|---|---|---|
| appid | Yes | Steam application ID | |
| steamid | No | Steam ID required for AroundUser (1) and Friends (2) requests | |
| rangeend | No | End index for entries (default: 100) | |
| rangestart | No | Start index for entries (default: 0) | |
| datarequest | No | Request type: 0 = Global, 1 = Around user, 2 = Friends (default: 0) | |
| leaderboardid | Yes | Numeric leaderboard ID from your Steamworks dashboard (Settings > Leaderboards). This is NOT the leaderboard name - use the numeric ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the API type (partner.steam-api.com), authentication requirements (publisher key, IP allowlisting), and parameter dependencies (steamid needed for certain views). This adds meaningful 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, front-loaded with the core purpose, and each sentence adds essential detail 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 absence of an output schema, the description does not explain the return format (e.g., structure of entries with scores and rankings). While it covers input constraints well, the lack of output context leaves a gap for a tool with 6 parameters and a data retrieval function.
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 100%, but the description adds extra value: it clarifies that leaderboardid is numeric (not name), explains datarequest values (0=global, 1=around-user, 2=friends), and states default ranges (0-100). This improves understanding beyond the schema's descriptions.
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 leaderboard scores and rankings for a Steam app, which is a specific verb and resource. It distinguishes from siblings like steam_getLeaderboardsForGame (lists leaderboards) and steam_uploadLeaderboardScore (posts scores) by focusing on retrieving entries with scores and rankings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit context, such as requiring the numeric leaderboard ID from Steamworks, using the partner API with a publisher key and IP allowlisting, and offering three viewing modes (global, around-user, friends-only). However, it does not explicitly state when not to use this tool or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all leaderboards for a Steam app with their numeric IDs, names, and sort methods. Requires a free Steam Web API key (STEAM_API_KEY). No publisher access needed.
| Name | Required | Description | Default |
|---|---|---|---|
| appid | Yes | Steam application ID to list leaderboards for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the API key requirement and that no publisher access is needed, but does not mention rate limits, pagination, or error handling. For a simple list operation, this is adequate but could be enhanced.
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: first states purpose and output fields, second states prerequisites. No wasted words. Front-loaded with key 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 one-parameter list tool, the description covers purpose, output details (IDs, names, sort methods), and prerequisites (API key). No output schema, but description compensates. Complete for the complexity level.
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 100% coverage: one parameter with description 'Steam application ID to list leaderboards for'. The description repeats this without adding extra meaning beyond 'appid'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('list'), resource ('all leaderboards for a Steam app'), and outputs ('numeric IDs, names, and sort methods'). It distinguishes from sibling tools like steam_getLeaderboardEntries which get entries for a specific leaderboard.
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 prerequisite (Steam Web API key) and access level ('No publisher access needed'), but does not explicitly state when to use this tool versus alternatives or provide exclusions. Usage is implied but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent news articles for a Steam app. Returns titles, URLs, contents, dates, and authors. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| appid | Yes | Steam application ID to get news for | |
| count | No | Number of news items to return (1-20, default 5) | |
| maxlength | No | Maximum length of each news item's contents in characters (default 500, 0 for full text) |
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 no API key is required, which is helpful. However, it does not mention rate limits, caching, idempotency, or whether the data is live or cached. The behavioral disclosure 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 two sentences long and front-loaded with the core purpose. Every sentence adds value, with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with three parameters and no output schema, the description provides sufficient context: returns, key fields, and authentication requirement. It lacks mention of optional parameter defaults but those are in the schema. Overall, it is nearly 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 input schema already describes all three parameters (appid, count, maxlength) with 100% coverage. The description adds no additional meaning beyond the schema, so it meets the baseline expectation for a tool with high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves recent news articles for a Steam app, listing the returned fields (titles, URLs, contents, dates, authors). This distinguishes it from sibling tools like steam_getAppDetails or steam_getReviews, 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 implicitly suggests using this tool when news articles are needed, but it does not explicitly state when to use it versus alternatives (e.g., steam_getAppDetails for app details) or provide when-not-to-use guidance. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a player's game library with playtime data. Shows all owned games, total playtime, and recent playtime. Requires STEAM_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| steamid | Yes | 64-bit Steam ID of the player (e.g. 76561197960435530) | |
| include_appinfo | No | Include game name and icon info (default: true) | |
| include_played_free_games | No | Include free-to-play games in results (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses that it shows owned games, total playtime, and recent playtime, and requires an API key. However, it does not mention potential rate limits, error conditions, or the read-only nature of the operation.
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 succinct sentences. The first sentence conveys the core purpose, and the second adds a critical requirement. No wasteful 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?
Given the absence of annotations and output schema, the description reasonably covers the tool's behavior and requirements. It could be improved by mentioning that steamid is required (though schema covers it) or listing typical output fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage, describing each parameter (steamid, include_played_free_games, include_appinfo). The description adds no additional semantic meaning or usage details beyond what the schema provides.
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 player's game library with playtime data, using specific verbs and resources. It distinguishes itself from siblings like steam_getPlayerSummary or steam_getPlayerAchievements by focusing on owned games and playtime.
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 a requirement (STEAM_API_KEY) but does not provide guidance on when to use this tool versus alternatives, nor does it specify conditions or exclusions. The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific player's achievement unlock status and timestamps for a Steam app. The player's profile must be public. Requires STEAM_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| appid | Yes | Steam application ID to get achievements for | |
| steamid | Yes | 64-bit Steam ID of the player |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses the read-only nature, required public profile, and API key dependency. It does not discuss error cases (e.g., private profile) or rate limits, but the key behavioral traits are communicated.
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 two sentences, front-loading the primary purpose and following with constraints. 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool without an output schema, the description covers the essential constraints and purpose. It does not detail the return format or potential empty results, but the context is adequate for a straightforward get operation.
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 100%, and the description adds no additional meaning beyond the parameter descriptions in the schema. The baseline score of 3 is appropriate as the schema already documents each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Get'), the resource ('achievement unlock status and timestamps'), and the scope ('for a specific player and Steam app'). It distinctly describes a read operation, differentiating it from sibling tools like steam_setAchievement or steam_clearAchievement.
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 states prerequisites (public profile, API key) but does not provide explicit guidance on when to use this tool versus alternatives like steam_getAchievementStats. The context for use is implied but not compared to siblings.
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 concurrent players for a Steam app. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| appid | Yes | Steam application ID (e.g. 730 for Counter-Strike 2) |
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 that no API key is required, which is useful for authorization awareness. However, it does not mention rate limits, data freshness, or whether the call is read-only. The description adds modest transparency 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: one stating the core purpose and the other adding a critical behavioral detail (no API key). Every word adds value, and there is no redundancy or padding.
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 parameter, no output schema), and the description covers the purpose and a key requirement. However, it does not describe the return value format (e.g., just the number, or wrapped in an object). While the output is likely intuitive, completeness would benefit from a brief indication of what is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a clear description for the single parameter 'appid' with an example (e.g., 730 for Counter-Strike 2). The tool description does not add further parameter context, so the baseline score of 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), resource ('current number of concurrent players'), and scope ('for a Steam app'). It also provides a unique selling point ('No API key required'). This effectively differentiates it from sibling tools which focus on achievements, lobbies, or other data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving player counts but does not explicitly state when to use it versus alternatives. Given the many sibling tools, guidance on when not to use it (e.g., for historical counts or filtered data) is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a player's Steam profile including display name, avatar, online status, and profile visibility. Requires STEAM_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| steamid | Yes | 64-bit Steam ID of the player (e.g. 76561197960435530) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It adds context about profile visibility and online status but does not disclose what happens for private profiles, rate limits, or authentication details beyond mentioning the API key.
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 front-loads the purpose, and the second adds a critical requirement. 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?
No output schema exists, so description should compensate by explaining the return structure. It lists some fields but not all common ones (e.g., account creation date, last logoff). Lacks error scenarios or edge cases.
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 100% with a clear description for the 'steamid' parameter. The description does not add meaningful semantic value beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a player's Steam profile and lists specific fields (display name, avatar, online status, profile visibility), which distinguishes it from sibling tools focused on achievements, games, or reviews.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Requires STEAM_API_KEY,' which is a prerequisite, and the purpose implies when to use (when you need profile info). However, no explicit guidance on when not to use or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Batch price check for multiple Steam apps in a specific region. Returns formatted price data including base price, discount, and final price. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| cc | No | Two-letter country code for pricing (e.g. US, GB, DE). Defaults to server region. | |
| appids | Yes | Array of Steam application IDs to check prices for (max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description alone must disclose behavior. It mentions 'No API key required' and the return data format, but omits critical details such as rate limits, error handling (e.g., invalid appids), whether the tool modifies state (likely not), or response structure. The agent lacks information about potential side effects or constraints.
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 filler. The first sentence clearly states the core purpose and scope, and the second adds a key behavioral note ('No API key required') and return format summary. Every word 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 the tool's simplicity (2 parameters, no nested objects) and no output schema, the description adequately covers the input requirements and return data. However, it could mention that appids must be numeric or that the tool is read-only. The lack of output schema is compensated by describing the return fields. Sibling tools table suggests many related tools; the description helps differentiate from batch vs single queries.
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 100% description coverage for both parameters. The description adds context like 'batch' and 'region', but these are already implied by the parameter descriptions. No additional semantic value 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('batch price check'), resource ('multiple Steam apps'), and scope ('in a specific region'). It also specifies the return format (base price, discount, final price). This distinguishes it from siblings like steam_getRegionalPricing which may target single apps.
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 'No API key required', which is a useful usage hint. However, it does not explicitly guide when to use this tool over similar siblings like steam_getRegionalPricing or steam_getAppDetails. The context of 'batch' implies multiple apps, but no direct alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get pricing for a Steam app across multiple regions/countries. Returns price, currency, and discount info for each region. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| appid | Yes | Steam application ID | |
| countries | No | Two-letter country codes to check (default: US, GB, EU, BR, RU, CN, JP, AU, IN, TR). Max 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavioral trait (no API key required) and implies read-only access, but does not mention rate limits, error handling, or potential side effects. The disclosure is adequate but incomplete.
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 consists of two clear, front-loaded sentences with no superfluous information. Every word adds value, achieving maximal conciseness while conveying essential purpose and a key usage note.
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 minimally indicates return data (price, currency, discount per region) but lacks details on structure, field types, or error conditions. It is sufficient for simple use but incomplete for complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (appid and countries) with 100% coverage. The description does not add further semantic meaning about the parameters, such as how to obtain an appid or how country codes affect results. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves pricing for a Steam app across multiple regions, specifying the returned data (price, currency, discount). This verb+resource structure effectively distinguishes it from sibling tools like steam_getPriceOverview, which presumably handles single-region pricing.
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 (e.g., steam_getPriceOverview). The description only mentions that no API key is required, which is helpful but does not address selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch user reviews for a Steam app with filters for language, sentiment, purchase type, and pagination. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| appid | Yes | Steam application ID | |
| cursor | No | Pagination cursor from a previous response | |
| filter | No | Review filter: recent, updated, or all (default: recent) | |
| language | No | Language code for reviews (e.g. english, german, all) | |
| review_type | No | Filter by review sentiment (default: all) | |
| num_per_page | No | Number of reviews to return (default: 20, max: 100) | |
| purchase_type | No | Filter by purchase type (default: all) |
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 does not disclose important behavioral traits such as rate limits, response format, or pagination handling beyond the cursor input parameter. The description only states that no API key is required, which is positive but 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?
The description is a single concise sentence that covers the action, resource, key filters, and an important note about API key requirements. Every part is informative and there is no wasted text.
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 complexity (7 parameters, no output schema), the description is somewhat incomplete. It does not hint at the return format (e.g., list of review objects with fields) or explain how pagination works despite having a cursor parameter. The note about no API key is helpful but more context on usage is needed.
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 100% description coverage, so the baseline is 3. The description mentions filters but adds no additional meaning beyond what the schema already provides for each parameter. It does not clarify default values or how parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (fetch), the resource (user reviews for a Steam app), and lists available filters (language, sentiment, purchase type, pagination). It distinguishes from sibling tools like steam_getAppReviewSummary, which likely provides a summary rather than detailed reviews.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that no API key is required, which is helpful. However, it does not provide explicit guidance on when to use this tool versus alternatives, such as when detailed reviews are needed versus a summary. No 'when not to use' or specific prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the achievement and stat schema for a Steam app. Returns achievement internal names, display names, descriptions, and icon URLs, plus stat definitions. Useful for mapping internal ACH_ names to human-readable names. Requires STEAM_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| appid | Yes | Steam application ID to get the achievement/stat schema for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It mentions the requirement for STEAM_API_KEY, implying authentication is needed. However, it does not explicitly state that the operation is read-only, nor does it discuss rate limits, caching, or error conditions (e.g., invalid appid). The 'Get' verb implies read-only, but more explicit disclosure would improve 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 two sentences long, front-loads the purpose, and contains no redundant information. Every sentence contributes value.
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 or annotations, the description adequately explains what the tool returns (achievement fields and stat definitions) and the prerequisite (API key). It could mention that it is a read operation or handle potential empty responses, but overall it is sufficiently 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 coverage is 100% with a single parameter (appid) described as 'Steam application ID to get the achievement/stat schema for.' The description adds no new meaning beyond the schema, as it already describes the parameter's role. Baseline is 3 due to high coverage, and the description does not introduce additional semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('Get'), resource ('achievement and stat schema for a Steam app'), and enumerates the return types (internal names, display names, descriptions, icon URLs, stat definitions). It distinguishes from sibling tools like steam_getPlayerAchievements and steam_getAchievementStats by focusing on the schema definitions rather than player-specific data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the use case ('mapping internal ACH_ names to human-readable names') and notes the required API key. It does not explicitly state when not to use the tool or list alternatives, but the context is clear given the sibling tools exist for player-specific or aggregated data.
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 Workshop item including title, description, tags, preview images, and subscriber count. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| publishedfileid | Yes | Workshop item ID (the numeric ID from the workshop URL) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits beyond listing return fields. Does not mention read-only nature, rate limits, or error handling, leaving the agent uninformed about 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 concise sentences, front-loaded with purpose and key details. No unnecessary text, every sentence adds value.
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?
Covers purpose and key return fields but lacks information on error conditions, return format, and behavioral expectations. Adequate for a simple tool, but could be more complete given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already documents the single parameter with description; the tool description adds no additional meaning beyond what schema provides. Maintains baseline due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Get details' and specific resource 'Steam Workshop item', listing attributes like title, description, tags. Distinct from sibling tools like steam_queryWorkshop which lists items.
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?
Mentions 'No API key required' as a usage condition, but lacks explicit when-to-use or when-not-to-use compared to alternative sibling tools like steam_queryWorkshop or steam_updateWorkshopItem.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Grant an inventory item to a player via the partner API. Intended for dev/test or server-side rewards. Requires a publisher API key with server IP allowlisted in Steamworks partner settings.
| Name | Required | Description | Default |
|---|---|---|---|
| appid | Yes | Steam application ID | |
| notify | No | Whether to notify the player of the grant (default: true) | |
| steamid | Yes | 64-bit Steam ID of the player to grant the item to | |
| quantity | No | Number of items to grant (default: 1) | |
| itemdefid | Yes | Item definition ID from your Steamworks item schema |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses the API type and authentication needs, but does not mention side effects (e.g., item grant is irreversible? any rate limits?). Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states action and purpose, second covers prerequisites. No fluff, front-loaded with essential 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 tool with 5 parameters and no output schema, the description provides purpose, intended use, and auth requirements. Lacks details on return value or error handling, but overall sufficient.
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 covers all 5 parameters with descriptions (100% coverage). Tool description adds no additional parameter details beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Grant an inventory item') and the mechanism ('via the partner API'), with specific intended uses ('dev/test or server-side rewards'). No sibling tool performs this function, ensuring differentiation.
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 mentions intended use cases (dev/test, server-side rewards) and required authentication setup (publisher API key, IP allowlisting). Does not provide negative guidance or alternatives, but context is sufficient for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and browse Steam Workshop items for a given app. Filter by text, tags, and sort order. Requires STEAM_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| appid | Yes | App ID to search workshop items for (e.g. 440 for TF2) | |
| cursor | No | Pagination cursor. Use '*' for the first request, then pass the cursor from previous results. | |
| numperpage | No | Number of results per page (1-100, default 10) | |
| query_type | No | Query type: 0 = ranked by vote, 1 = ranked by date, 2 = ranked by trending, 3 = favorited by friends, etc. | |
| search_text | No | Text to search for in item titles and descriptions | |
| requiredtags | No | Comma-separated tags that items must have |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives minimal behavioral context. It lacks details on rate limits, pagination behavior beyond the cursor parameter, or what happens when no results are found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence followed by a requirement note. It is front-loaded with the core purpose but could benefit from a slightly more structured breakdown.
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 that the tool has 6 parameters, no output schema, and no annotations, the description is too brief. It omits important context such as the structure of returned results, error handling, and pagination mechanics beyond the cursor parameter.
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 100%, so the baseline is 3. The description adds a high-level summary of filtering ('text, tags, and sort order') but does not provide additional meaning beyond the schema's per-parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search and browse'), the resource ('Steam Workshop items'), and the scope ('for a given app'). It also mentions filtering capabilities, distinguishing it from sibling tools like steam_getWorkshopItem which retrieves a single item.
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 prerequisite 'Requires STEAM_API_KEY', but provides no guidance on when to use this tool versus alternatives such as steam_getWorkshopItem for specific items or steam_searchApps for general app search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a Steam vanity URL (custom profile name) to a 64-bit Steam ID. Requires STEAM_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| url_type | No | Type of vanity URL: 1 = individual profile (default), 2 = group, 3 = official game group | |
| vanityurl | Yes | The vanity URL part of a Steam profile (e.g. 'gabelogannewell' from steamcommunity.com/id/gabelogannewell) |
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 the need for the STEAM_API_KEY and the conversion action, but does not mention error handling, output format, or potential side effects. This is adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence conveying the essential action and a key prerequisite. No extraneous words; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description lacks details about the output format (e.g., returns a 64-bit ID string) and does not clarify error scenarios. Without an output schema, the agent would benefit from this information. It is slightly 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?
The input schema has 100% coverage with descriptions for both parameters. The description adds no additional semantic meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: converting a Steam vanity URL to a 64-bit Steam ID. It uniquely identifies its purpose among sibling tools, as no other tool in the list performs this specific conversion.
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 'Requires STEAM_API_KEY' as a prerequisite but provides no guidance on when to use this tool versus alternatives, nor does it indicate when not to use it. Given the variety of sibling tools, this is a significant gap.
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 and apps by name or keyword. Returns app IDs, names, icons, and price info. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| l | No | Language code (e.g. english, german). Defaults to english. | |
| cc | No | Two-letter country code for pricing (e.g. US, GB) | |
| query | Yes | Search query for games or apps (e.g. 'Hades', 'Counter-Strike') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes 'No API key required', which adds useful behavioral context. However, it does not disclose rate limits, authentication needs, or any side effects. Given no annotations, 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 two sentences with no wasted words. It front-loads the primary action and output, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions return fields partially (IDs, names, icons, price), which compensates somewhat for the lack of an output schema. It could mention result limits or sorting, but for a simple search tool, it is fairly 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 coverage is 100%, so the description does not need to explain parameters. The description adds no extra context beyond the schema for parameters, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches the Steam store by name/keyword and returns specific data (IDs, names, icons, price). This distinguishes it from sibling tools like steam_getAppDetails or steam_queryWorkshop.
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. For example, it doesn't mention that for a specific app's details, one should use steam_getAppDetails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set (unlock) an achievement for a player via the partner API. Intended for dev/test use. Requires a publisher API key with server IP allowlisted in Steamworks partner settings.
| Name | Required | Description | Default |
|---|---|---|---|
| appid | Yes | Steam application ID | |
| steamid | Yes | 64-bit Steam ID of the player | |
| achievement | Yes | Achievement API name (e.g. ACH_BEAT_LEVEL_1). Must match a name configured in Steamworks. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It states the basic write operation, but lacks details on irreversibility, side effects, or error scenarios. For a mutation tool, 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 concise sentences. First sentence defines the action and resource. Second sentence provides usage context. 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?
Covers purpose, intended use, and prerequisites. Lacks description of return value (no output schema) and does not fully address behavioral transparency. Adequate for a simple write tool but with 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?
Input schema covers all 3 parameters with clear descriptions (format, constraints, examples). Description adds context about API key requirements but does not enhance parameter meaning beyond schema. Schema coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (Set/unlock), resource (achievement for a player), and API (partner API). Distinguishes from sibling tools like steam_clearAchievement and steam_getPlayerAchievements.
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 states intended use ('dev/test') and prerequisite (publisher API key + IP allowlist). Does not explicitly mention when not to use, but the dev/test qualifier provides a clear boundary. Does not reference sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update metadata for an existing Steam Workshop item (title, description, visibility, tags) via the partner API. Requires a publisher API key with server IP allowlisted. File content updates require the SDK.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Replace the item's tags with this list | |
| appid | Yes | Steam application ID | |
| title | No | New title for the item | |
| visibility | No | Visibility: 0=Public, 1=FriendsOnly, 2=Private, 3=Unlisted | |
| publishedfileid | Yes | Workshop item's published file ID | |
| file_description | No | New description for the item |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It mentions authentication requirements and a key limitation (no file content), but does not disclose whether updates are atomic, what the response looks like, or if there are rate limits. The description partially covers behavior but leaves gaps.
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 two sentences long, with the first sentence immediately stating the purpose and the second adding essential prerequisites and limitations. No extraneous 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?
The description provides necessary context about API key requirements and file content limitations, but lacks details about return values, side effects, or error handling, which are important for a mutation tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description lists parameter names (title, description, visibility, tags) but does not add significant meaning beyond the schema. The visibility enum values are already documented in 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 verb 'update', the resource 'existing Steam Workshop item', and the specific metadata fields (title, description, visibility, tags). It distinguishes the tool from siblings like steam_uploadWorkshopItem by focusing on metadata updates.
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 mentions the requirement for a publisher API key with IP allowlisting and notes that file content updates require the SDK, providing clear context for when to use this tool versus other methods. It does not, however, explicitly list when not to use the tool or compare directly with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a score to a Steam leaderboard via the partner API. Requires a publisher API key with server IP allowlisted in Steamworks partner settings.
| Name | Required | Description | Default |
|---|---|---|---|
| appid | Yes | Steam application ID | |
| score | Yes | Score to upload (interpretation depends on leaderboard sort method) | |
| steamid | Yes | 64-bit Steam ID of the player | |
| scoremethod | No | KeepBest only updates if better than existing; ForceUpdate always overwrites (default: KeepBest) | |
| leaderboardid | Yes | Numeric leaderboard ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds some behavioral context (authentication prerequisites). However, it does not disclose error handling, rate limits, or the response format, leaving gaps for the agent.
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 that efficiently conveys the core purpose and a key requirement, with no extraneous detail.
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 omits return value information and does not address potential failure modes (e.g., leaderboard not found). While parameters are well-documented, the lack of output description leaves the agent uncertain.
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 100%, and the description does not add extra semantic value beyond what the schema already provides for each parameter. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('upload') and resource ('score to a Steam leaderboard'), clearly distinguishing from read-only siblings like steam_getLeaderboardEntries or steam_getLeaderboardsForGame.
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 specifies the required credentials (publisher API key and IP allowlisting), providing clear context for when the tool can be used. However, it does not explicitly exclude cases or contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get code examples and documentation for uploading new Steam Workshop items. Workshop uploads require the Steamworks SDK (ISteamUGC) running in a client or dedicated tool — there is no HTTP upload endpoint. This tool returns ready-to-use code for C++, C#, and GDScript.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Tags for discoverability | |
| appid | Yes | Steam application ID that the Workshop item belongs to | |
| title | Yes | Title for the Workshop item | |
| visibility | No | Item visibility (default: public) | |
| description | No | Description for the Workshop item | |
| content_path | No | Local folder path containing the item content | |
| preview_path | No | Local path to a preview image (JPG/PNG, <1MB) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses that the tool does not perform uploads but returns code, which is critical behavioral context. It also specifies output format (C++, C#, GDScript). No mention of rate limits or auth, but this is acceptable for a documentation tool.
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?
Three sentences, each adding unique value: purpose, technical requirement, output specifics. No wasted words, front-loaded with core 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?
No output schema needed; description covers return format and language support. Lacks information on error handling or code snippet size, but sufficient for expected use as a documentation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds no additional meaning to parameters beyond what the schema provides (e.g., appid, title, etc.).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states it returns code examples and documentation for uploading, clarifying the tool's actual function despite the name 'uploadWorkshopItem' suggesting an upload action. It distinguishes from siblings like steam_updateWorkshopItem by specifying it is not an HTTP endpoint.
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?
Description explains when to use (need code examples for uploading) and mentions prerequisites (Steamworks SDK), but does not explicitly state when not to use or list alternatives like steam_updateWorkshopItem for actual uploads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a local store or library image against current Valve pixel sizes, format rules, and library-hero heuristics. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Local filesystem path to a PNG or JPEG | |
| slot | Yes | Store or library asset slot (headerCapsule, smallCapsule, mainCapsule, verticalCapsule, libraryCapsule, libraryHero, libraryLogo, libraryHeader, screenshot, pageBackground) |
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 states the action ('Validate'), the scope ('against current Valve pixel sizes...'), and notes that no API key is required, implying a local, read-only operation. It does not explicitly confirm zero side effects or describe the return shape, but the validation framing makes the behavior reasonably 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 entire description is a single sentence that conveys the tool's purpose, input type, and a distinguishing feature ('No API key required'). There is no filler, repetition, or overly technical jargon—every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two well-described parameters, and the description explains the core validation purpose. However, because there is no output schema and the description does not state what the tool returns (e.g., a pass/fail result, a list of validation errors), the agent is left to infer the response format. This is a notable gap for a validation 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?
Both parameters are fully described in the schema (path as 'Local filesystem path to a PNG or JPEG' and slot as an enum with all possible values), so schema coverage is 100%. The description does not add parameter-level detail beyond what the schema already provides, leaving it at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Validate') and identifies the target resource ('local store or library image') and the validation criteria ('Valve pixel sizes, format rules, library-hero heuristics'). This clearly distinguishes the tool from the sibling Steam API tools, which are all server-side data retrieval or mutation operations.
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 sets a clear context: this tool validates local image files and does not require an API key, which implicitly differentiates it from the API-dependent sibling tools. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.8.0steam_validateStoreAssetv0.7.0steam_clearAchievementsteam_createLobbysteam_getAchievementStatssteam_getAppDetailssteam_getAppReviewSummarysteam_getLeaderboardEntriessteam_getLeaderboardsForGamesteam_getNewsForAppsteam_getOwnedGamessteam_getPlayerAchievementssteam_getPlayerCountsteam_getPlayerSummarysteam_getPriceOverviewsteam_getRegionalPricingsteam_getReviewssteam_getSchemaForGamesteam_getWorkshopItemsteam_grantInventoryItemsteam_queryWorkshopsteam_resolveVanityURLsteam_searchAppssteam_setAchievementsteam_updateWorkshopItemsteam_uploadLeaderboardScoresteam_uploadWorkshopItemMost tools target distinct resources and actions, but there is some overlap (e.g., getAchievementStats vs getPlayerAchievements, getReviews vs getAppReviewSummary). Descriptions generally clarify differences.
All tools follow a consistent steam_verbNoun snake_case pattern, making the naming predictable and easy to navigate.
25 tools cover a wide range of Steam API features (store, player, achievements, workshop, inventory, partner actions). While comprehensive, a few tools are code samples rather than API calls, which slightly inflates the count.
The tool surface covers major Steam API areas including store details, player profiles, achievements, leaderboards, reviews, workshop, and partner operations. Missing aspects like friend lists are acceptable for a server focused on game and player data.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
One AI endpoint to search and call 22k+ MCP servers; 50+ hosted tools work instantly, no key.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
An MCP server that gives your AI access to the source code and docs of all public github repos
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TMHSDigital/steam-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
