Which integrations are available for this server?

Provides tools to fetch data from a user's Steam game library via the Steam Web API, including owned games, recently played games, player summary, achievements, and vanity URL resolution.

How do I use Steam MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Steam MCP Server show me my recently played games" 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.

Steam MCP Server

by stianasoren

Overview Schema Related Servers Score Discussions

Python

Local

Steam MCP Server

A local MCP server that lets Claude fetch data from your Steam game library via the Steam Web API. All tools are read-only — the server never modifies your account.

Tools

Tool	What it does
`steam_get_owned_games`	Lists owned games with total playtime, sorted by playtime or name
`steam_get_recently_played_games`	Games played in the last ~2 weeks
`steam_get_player_summary`	Profile info: name, status, currently playing, account creation date
`steam_get_player_achievements`	Achievements for a specific game (requires appid)
`steam_resolve_vanity_url`	Converts a custom profile URL to a SteamID64

Related MCP server: steam-mcp

Prerequisites

Steam Web API key — get one for free at https://steamcommunity.com/dev/apikey (requires a logged-in Steam account; enter any domain, e.g. localhost).
Your SteamID64 — the 17-digit number for your account. Find it via your profile URL, or use steam_resolve_vanity_url if you have a custom URL.
Profile must be public — under Steam → Profile → Edit Profile → Privacy, "Game details" must be set to Public, otherwise library and achievement calls will return empty.
uv installed — curl -LsSf https://astral.sh/uv/install.sh | sh
Python 3.10+ (uv will manage this automatically).

Installation

uv sync

Connecting to Claude

The server uses stdio transport and runs as a local subprocess. It works with MCP clients such as Claude Desktop and Claude Code.

Claude Desktop

Open the config file (Settings → Developer → Edit Config) and add the server. Replace the paths and values with your own:

{
  "mcpServers": {
    "steam": {
      "command": "uv",
      "args": ["run", "--directory", "/full/path/to/steam-api-mcp", "src/steam_mcp.py"],
      "env": {
        "STEAM_API_KEY": "YOUR_API_KEY_HERE",
        "STEAM_ID": "YOUR_STEAMID64_HERE"
      }
    }
  }
}

STEAM_ID is optional. If set, you won't need to provide your own ID in every request — the tools fall back to this value. You can still pass a different steam_id to look at a friend's (public) profile.

Restart Claude Desktop after saving. You can then ask things like:

"Which 10 games have I played the most on Steam?"
"What have I played in the last two weeks?"
"How many achievements do I have in appid 570?"

Claude Code

claude mcp add steam uv run --directory /full/path/to/steam-api-mcp src/steam_mcp.py \
  --env STEAM_API_KEY=YOUR_KEY --env STEAM_ID=YOUR_STEAMID64

Testing Outside a Client

With MCP Inspector you can click through the tools manually:

STEAM_API_KEY=your_key STEAM_ID=your_id \
  npx @modelcontextprotocol/inspector uv run src/steam_mcp.py

Privacy and Limitations

The API only returns data a profile has made public.
Your key is stored in the client config / environment variables and is never sent anywhere other than Steam.
The Steam Web API has reasonable rate limits (approx. 100,000 calls/day). The server returns a clear 429 message if you hit a temporary limit.

Available Tools

5 tools

steam_get_owned_gamesA

Read-onlyIdempotent

List the games owned by a Steam user, with total playtime per game.

This is the core library tool. It returns each owned game with its appid, name, total playtime, recent (2-week) playtime, and last-played date. The target profile's "Game details" must be public for this to return data.

Args: params (OwnedGamesInput): Validated input containing: - steam_id (Optional[str]): SteamID64; falls back to STEAM_ID env var. - limit (Optional[int]): Max games to return after sorting (1-500, default 25). - sort_by (str): 'playtime' (default) or 'name'. - include_free_games (bool): Include launched free-to-play games (default True). - response_format (ResponseFormat): 'markdown' or 'json'.

Returns: str: Markdown or JSON. JSON schema: { "total_games_owned": int, # total count in the library "returned": int, # number of games in this response "games": [ { "appid": int, "name": str, "playtime_hours": float, # total, all time "playtime_2weeks_hours": float, # last 2 weeks "last_played": str | null, # UTC timestamp "icon_url": str | null } ] } On error, an "Error: ..." string.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Adds context about privacy requirement and fallback beyond annotations; no contradictions.

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

Conciseness4/5

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

Well-structured with summary, args, returns; could be slightly more concise but not wasteful.

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

Completeness5/5

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

Covers return format, error handling, prerequisites, and fallback; complete for a read-only query tool.

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

Parameters4/5

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

Schema provides detailed descriptions; description summarizes with defaults and usage, adding slight value.

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

Purpose5/5

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

Clearly states the tool lists owned games with playtime, distinguishing it from siblings like steam_get_recently_played_games.

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

Usage Guidelines4/5

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

Specifies prerequisite (public profile), fallback to environment variable, but does not contrast with alternative tools.

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

steam_get_player_achievementsA

Read-onlyIdempotent

Get a player's achievements for a specific game.

Args: params (AchievementsInput): Validated input containing: - appid (int): The game's Steam application ID (required). - steam_id (Optional[str]): SteamID64; falls back to STEAM_ID env var. - only_unlocked (bool): Return only unlocked achievements (default False). - response_format (ResponseFormat): 'markdown' or 'json'.

Returns: str: Markdown or JSON with the game name, unlocked/total counts, and a list of achievements (name, unlocked flag, unlock time), or an "Error: ..." string. Some games have no achievements, which returns a note.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint, so basic safety is clear. The description adds value by detailing return formats (markdown/json), error handling ('Error: ...'), and a note for games with no achievements, which goes beyond annotation info.

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

Conciseness5/5

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

The description is well-structured with a clear main sentence, an 'Args' section listing parameters, and a 'Returns' section. Every sentence provides useful information without redundancy.

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

Completeness5/5

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

Given that an output schema exists but the description explains the return structure (markdown/JSON with game name, counts, list), and the tool is simple and read-only, the description is complete and sufficient for an agent to understand behavior and output.

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

Parameters5/5

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

Despite schema description coverage being 0%, the tool description thoroughly explains each parameter: appid (required, what it is), steam_id (fallback to env var), only_unlocked (filter), response_format (output type). This adds meaning beyond the schema's property descriptions, especially the fallback behavior.

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

Purpose5/5

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

The description clearly states 'Get a player's achievements for a specific game,' which is a specific verb+resource. It is distinct from sibling tools like steam_get_owned_games or steam_get_player_summary, which focus on different data.

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

Usage Guidelines2/5

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

The description does not provide guidance on when to use this tool versus alternatives. It lacks explicit context for when to choose it over siblings, and no when-not-to-use or prerequisite information is given.

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

steam_get_player_summaryA

Read-onlyIdempotent

Get profile summary information for a Steam user.

Returns display name, profile URL, avatar, online status, and (if public) the currently played game and account creation date.

Args: params (PlayerInput): Validated input containing: - steam_id (Optional[str]): SteamID64; falls back to STEAM_ID env var. - response_format (ResponseFormat): 'markdown' or 'json'.

Returns: str: Markdown or JSON describing the profile, or an "Error: ..." string.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds value by noting that some fields are only returned if the profile is public and that the response can be markdown or JSON. It also mentions error handling with 'Error: ...' strings.

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

Conciseness5/5

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

The description is concise, with a clear purpose sentence followed by a list of returned fields and an Args section. Every sentence adds value, and there is no unnecessary fluff.

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

Completeness5/5

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

Given the tool's simplicity, the annotations, and the presence of an output schema (not shown but noted), the description covers all necessary aspects: what is returned, privacy caveats, parameter details, and error format. It is self-contained and sufficient for correct usage.

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 contains descriptions for both parameters (steam_id and response_format), so the description repeats this information without adding significant new meaning. With high schema coverage, 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 clearly states the tool retrieves profile summary information for a Steam user, listing specific returned fields like display name, profile URL, and online status. This distinguishes it from siblings (owned games, achievements, etc.) by focusing solely on the user's profile summary.

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

Usage Guidelines4/5

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

The description provides clear context on when to use the tool, such as specifying the required steam_id with a fallback to an environment variable. It does not explicitly exclude alternatives but implies usage for profile lookup, which is adequate.

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

steam_get_recently_played_gamesA

Read-onlyIdempotent

List games a Steam user has played in roughly the last two weeks.

Args: params (RecentlyPlayedInput): Validated input containing: - steam_id (Optional[str]): SteamID64; falls back to STEAM_ID env var. - count (Optional[int]): Max games to return (1-50, default 10). - response_format (ResponseFormat): 'markdown' or 'json'.

Returns: str: Markdown or JSON listing recent games with 2-week and total playtime, or an "Error: ..." string.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral context such as the fallback to STEAM_ID env var and return of error strings. No contradiction with annotations.

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

Conciseness4/5

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

The description is well-structured with clear sections for arguments and returns, though the Args block is slightly verbose. Overall, it's concise and front-loaded with the main purpose.

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

Completeness4/5

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

Given the tool's simplicity, the description covers key aspects: input parameters, return format, and error handling. The presence of an output schema reduces the need to detail return values.

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

Parameters4/5

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

The description adds meaning beyond the input schema by explaining the steam_id fallback behavior and the default count. Schema descriptions already exist for other parameters, but the description organizes them usefully.

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

Purpose5/5

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

The description clearly states 'List games a Steam user has played in roughly the last two weeks,' providing a specific verb and resource. This distinguishes it from siblings like steam_get_owned_games (all owned) and steam_get_player_achievements (achievements).

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

Usage Guidelines4/5

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

The description implicitly guides usage by specifying the scope (recently played games) and parameters, but does not explicitly mention when not to use or provide alternatives.

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

steam_resolve_vanity_urlA

Read-onlyIdempotent

Resolve a Steam custom (vanity) profile URL name into a SteamID64.

Many Steam profiles use a custom URL like steamcommunity.com/id/ instead of a numeric ID. Other tools in this server need the numeric SteamID64, so use this first if you only have a custom URL name.

Args: params (VanityUrlInput): Validated input containing: - vanity_name (str): The custom URL name (without the full URL).

Returns: str: On success, the resolved SteamID64 and original name. On failure, an "Error: ..." string. If the name doesn't match a profile, returns a message saying no match was found.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds details on return value format (success: SteamID64 + name; failure: error string; no match: message), which goes beyond annotations. No contradictions.

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

Conciseness5/5

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

The description is concise with short paragraphs, front-loads the main purpose, and uses clear structure with Args and Returns sections. No unnecessary words.

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

Completeness5/5

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

Given the tool's simplicity, the description fully covers purpose, usage, parameter, and return value. Annotations and output schema handle the rest.

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

Parameters4/5

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

Despite the context claiming 0% schema description coverage, the actual schema includes a description for the parameter. The tool description further explains the parameter's meaning and gives an example, adding value beyond the schema.

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

Purpose5/5

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

The description clearly states it resolves a vanity URL to a SteamID64, using specific verb 'Resolve' and resource 'vanity profile URL name'. It differentiates from sibling tools by noting that other tools need numeric ID, so this tool is the prerequisite.

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

Usage Guidelines5/5

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

The description explicitly says to use this tool first when only having a custom URL name, implying alternatives are the sibling tools that require numeric ID. It also specifies what input is valid (only the name, not full URL).

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.1.0Jun 13, 2026
- First observedsteam_get_owned_games
- First observedsteam_get_player_achievements
- First observedsteam_get_player_summary
- First observedsteam_get_recently_played_games
- First observedsteam_resolve_vanity_url

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool serves a distinct Steam function: owned games, achievements, profile summary, recently played games, and vanity URL resolution. No two tools overlap in purpose.

Naming Consistency5/5

All tools follow a consistent 'steam_verb_noun' pattern in snake_case, with clear and predictable naming.

Tool Count5/5

With 5 tools, the server is focused and well-scoped, covering essential Steam user data queries without unnecessary bloat.

Completeness4/5

The set covers core user data (owned games, recent games, achievements, profile, vanity resolution). A minor gap is the lack of game detail retrieval, but it is reasonable for a focused server.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214
mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5361

Related MCP Servers

steam-mcp
Entertainment & Media Search App Automation
jkiley129
A
license
A
quality
D
maintenance
Connects Claude to your Steam library via the Steam Web API. Query your games, playtime, recently played history, and store metadata using natural language. Zero-config install via npx steam-mcp.
Updated 5 months ago (2026-03-23 15:07 UTC)
5
18
5
MIT
steam-mcp
Games & Gamification Entertainment & Media
stealthsrc
A
license
A
quality
B
maintenance
Exposes Steam Web API tools as MCP resources for Claude Code, Claude Desktop, and Gemini CLI, enabling profile lookups, game searches, achievement tracking, and more.
Updated 2 days ago (2026-09-04 10:44 UTC)
11
18
1
MIT
steam-mcp
Games & Gamification Entertainment & Media
matheusslg
A
license
A
quality
D
maintenance
MCP Server for the Steam Web API — access player profiles, game libraries, achievements, news, friend lists, and store search through Claude.
Updated 6 months ago (2026-03-02 18:24 UTC)
20
18
3
MIT
Steam Library MCP Server
Games & Gamification Entertainment & Media
jimsantora
F
license
Not graded
quality
C
maintenance
Provides access to your Steam game library data through Claude Desktop, enabling game search, filtering, details, recommendations, and statistics.
Updated a year ago (2025-07-24 03:54 UTC)
7
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/stianasoren/steam-api-mcp'

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