Skip to main content
Glama
Grinv

Steam MCP Server

by Grinv
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get global achievement rates

get_global_achievements
Read-only

Check how rare each achievement is in a Steam game by appid. Returns global unlock percentages, sorted from most to least common, capped at 200 achievements.

Instructions

Get the global unlock percentage of each achievement in a game by appid — how rare each achievement is across all players. Returns each achievement's internal name and its unlock percent (no display names/descriptions — for those, use get_game_achievements), most-common first, capped at the first 200 (check returned vs count — most games have far fewer). An unknown appid, or one with no achievement schema (e.g. a DLC/soundtrack), comes back as an empty list rather than an error, the same as get_game_news. Get the appid from search_games. No API key required.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appidYesSteam application id (appid). Get it from search_games.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYes
returnedYes
achievementsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.14.0
    • removedOutput schema / properties / achievements / items / properties / percent / anyOf
      Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedOutput schema / properties / achievements / items / properties / percent / type
      Added value: +[
+  "number",
+  "null"
+]
  2. Changed1 schema field changedv0.12.1
    • addedInput schema / additionalProperties
      Added value: +false
  3. Addedv0.10.4
  4. Removedv0.9.0
  5. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses several behavioral traits beyond the readOnlyHint and openWorldHint annotations: results are capped at 200, ordered most-common first, empty list is returned instead of an error for unknown appids, and no API key is required. This gives the agent a clear model of what the tool will do in practice.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence earns its place: purpose, output format, ordering, cap, edge-case behavior, alternative tool, appid source, and auth requirement. It is front-loaded with the core purpose and remains readable despite covering many details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and the annotations cover safety, the description fills all remaining gaps: it explains the return fields, the cap, the ordering, the empty-list behavior, the appid source, and the lack of auth requirements. Nothing an agent needs to call this tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully documents the single appid parameter with 100% coverage, including the instruction to get it from search_games. The description reinforces this but adds little new semantic meaning beyond what the schema provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Get the global unlock percentage of each achievement in a game by appid' and clarifies what that means ('how rare each achievement is across all players'). It also explicitly distinguishes itself from get_game_achievements by noting it returns internal names and unlock percents, not display names/descriptions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear when-to-use guidance and names the alternative: 'no display names/descriptions — for those, use get_game_achievements'. It also tells the agent where to get the appid ('Get the appid from search_games') and explains edge-case behavior for unknown appids, which helps the agent decide when this tool is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools