# Steamworks Release Assistant (pypi · steamworks-mcp)

Put a game on Steam: store page, achievements, Valve-rule checks, market data, Steamworks.

- Trust score: 76/100 (medium)
- Change this week: +7
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-10-17

## Components

- pypi · `steamworks-mcp`: 76/100 (this document), [markdown](https://verifymcp.io/servers/wazzapsenk-steamworks-mcp/steamworks-mcp.md), [page](https://verifymcp.io/servers/wazzapsenk-steamworks-mcp/steamworks-mcp)

## Channel facts

- Registry: `pypi`
- Package: `steamworks-mcp`
- Version: `0.3.2`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-10-17.

- **Supply Chain Security**: 100/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - Runs hatchling.build at install time, a recognised build step with no custom scripting around it.
  - 1 of 33 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 45/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 4 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 82/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 5326 tokens (~143/item across 37 items; 35 tools + 2 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 47/100
  - Stability observed for 14 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 71/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 0% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 35 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 37 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a current MCP spec version (2026-07-28).

## Install

### How do I install the Steamworks Release Assistant MCP server?

Steamworks Release Assistant runs locally as a PyPI package, launched with uvx steamworks-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add wazzapsenk-steamworks-mcp -- uvx steamworks-mcp
```

### Cursor

```json
{
  "mcpServers": {
    "wazzapsenk-steamworks-mcp": {
      "command": "uvx",
      "args": [
        "steamworks-mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "wazzapsenk-steamworks-mcp": {
      "command": "uvx",
      "args": [
        "steamworks-mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add wazzapsenk-steamworks-mcp -- uvx steamworks-mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "wazzapsenk-steamworks-mcp": {
      "type": "local",
      "command": [
        "uvx",
        "steamworks-mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add wazzapsenk-steamworks-mcp --command uvx --arg steamworks-mcp
```

### Hermes

```yaml
mcp_servers:
  wazzapsenk-steamworks-mcp:
    command: "uvx"
    args: ["steamworks-mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "wazzapsenk-steamworks-mcp": {
      "Transport": "stdio",
      "Command": "uvx",
      "Arguments": [
        "steamworks-mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add wazzapsenk-steamworks-mcp -t stdio -c uvx -a steamworks-mcp
```

### Other

```json
{
  "mcpServers": {
    "wazzapsenk-steamworks-mcp": {
      "command": "uvx",
      "args": [
        "steamworks-mcp"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-10-17 (score 76, +1)

No change was recorded against any check on this day. Stability & Change Management went from 43 to 47. That category is still filling its 30-day observation window: 13 days of observed history at the previous scan, 14 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-14 (score 75, +36)

- [security improvement] Injection markers: unverified → pass
- [functional improvement] Tool coverage: unverified → 100
- [functional improvement] Schema quality: unverified → 100
- [functional improvement] Stability: unverified → 0.37
- [functional improvement] MCP protocol: unverified → pass
- [functional] Package version: 0.3.1 → 0.3.2

### 2026-10-13 (score 39, +15)

- [security improvement] Malware scan: unverified → pass
- [functional] Package version: 0.3.1 → 0.3.2

### 2026-10-12 (score 24, −45)

- [security regression] Malware scan: pass → unverified
- [security regression] Tool safety: pass → unverified
- [security] Stability: Stability not yet verified: we do not have a sandbox capture of the MCP schema this version of the package serves yet.
- [functional regression] Capabilities: pass → unverified
- [functional regression] Tool coverage: 100 → unverified
- [functional regression] Schema quality: 100 → unverified
- [functional] Package version: 0.3.1 → 0.3.2

### 2026-10-04 (score 69, +15)

- [security improvement] Malware scan: unverified → pass

### 2026-10-03 (score 54)

First indexed and scored.

## MCP tools (35)

### `init_project` (~206 tokens)

Start tracking a game: create steamworks.yaml and .steam-mcp/ in `path` (existing files are kept, never
overwritten), then scan the game project unless `scan` is false.

Args:
    path: Folder for steamworks.yaml, usually the game project's root (relative to the workspace root).
    name: Product name as it will appear on Steam, if known.
    appid: The main game's Steam app id, if already created in Steamworks.
    scan: Run the project scanners (Unity, …) right away.
    source_dir: The engine project folder, when it is not `path` itself.

Returns created/existing files, .gitignore lines to suggest to the user (this server never edits the
project's own .gitignore), and the scan report when scanning.

Input parameters:

- `appid`
- `name`
- `path` (string, required)
- `scan` (boolean)
- `source_dir`

### `scan_project` (~117 tokens)

Scan the game project and merge what is found into steamworks.yaml as drafts (source "scan", with file and
line evidence and a confidence). Values the user approved are never overwritten: differences come back under
\`conflicts`. Read-only towards the game project; raw observations are kept in .steam-mcp/scan/.

Args:
    path: Folder that holds steamworks.yaml.
    source_dir: The engine project folder, when it is not `path` itself.

Input parameters:

- `path` (string, required)
- `source_dir`

### `status` (~100 tokens)

Start here. Without `path`: the games in the workspace (tracked ones and engine projects not tracked
yet). With `path`: how far the game is on each release step, its values (approved, drafts, to fill, done in
Steamworks), store text and translations, and the one thing to do next.

Args:
    path: The game's folder (the one with steamworks.yaml), relative to the workspace root.

Input parameters:

- `path`

### `gap_report` (~206 tokens)

What is still missing before each release gate, and how each item gets done.

Gates: 0 prerequisites, 1 store page review / Coming Soon, 2 build review, 3 release. For every blocking item
you get its status (fail, review = values waiting for the user's approval, todo = a manual step or an image
to produce, unknown), the fields involved, the execution mode (API, BROWSER, ARTIFACT, MANUAL), where it is
done in Steamworks and Valve's source page. `next_steps` says what to do first.

Args:
    path: Folder that holds steamworks.yaml.
    gate: Only this gate (0-3), in full. Default: every gate, with only the next open one in full.
    include_info: Also list the background notes (permissions, timings) that never block.

Input parameters:

- `gate`
- `include_info` (boolean)
- `path` (string, required)

### `start_interview` (~245 tokens)

Next questions for the user (at most `max_questions`, related ones together, earliest gate first), each with
a suggested answer to confirm or change. `confirm: true` means a value was found (e.g. by the scan): just ask
whether it is right.

Ask the user these questions in chat, then save the answers with set_field(values={question id: answer}).
Answers can be plain text ("yes", "a, b, c", "2027-05-12"); they are converted to the right type.
Store texts are not asked here: use generate. When the client supports forms (MCP elicitation) the questions
are shown as a form instead and the answers are saved right away; pass use_form=false to avoid that.

Args:
    path: Folder that holds steamworks.yaml.
    gate: Only questions for this gate (0-3).
    max_questions: 1-5, default 3.
    use_form: Show a form when the client supports it.

Input parameters:

- `gate`
- `max_questions` (integer)
- `path` (string, required)
- `use_form` (boolean)

### `set_field` (~178 tokens)

Write one value (`field` + `value`) or several (`values`) into steamworks.yaml, keeping its comments.

source="user" (the user's own answer or decision) stores the value as approved. source="generated" (text you
wrote) stores it as a draft for the user to review; generated store text that breaks Valve's store rules is
rejected. `from_draft` picks a saved draft for `field` and approves it. Field paths look like
store.short_description, achievements.ACH_WIN.name, apps.main.installation.launch_options.0.executable.
Setting a value to null removes it.

Input parameters:

- `field`
- `from_draft`
- `notes`
- `path` (string, required)
- `source` (string)
- `value`
- `values`

### `approve_fields` (~63 tokens)

Mark values as approved by the user (after showing them). Patterns work: "achievements.*.name".
A section approves everything under it: "apps.main.cloud". Never approve without the user's agreement.

Input parameters:

- `fields` (array, required)
- `path` (string, required)

### `mark_applied` (~88 tokens)

The user confirms something is done in Steamworks: a manual step ("checklist.<rule id>" from gap_report),
or approved values they entered there themselves. Only approved, unchanged values can be marked applied.
Never call this on your own: only when the user says it is done.

Input parameters:

- `fields` (array, required)
- `notes` (string)
- `path` (string, required)

### `get_spec_info` (~162 tokens)

Reference data (the tool equivalent of this server's resources, for clients that only use tools).

kind: "schema" (steamworks.yaml fields), "gates" (overview), "gate:<0-3>" (all rules of a gate),
"capabilities", "store_rules", "asset_specs", "events", "code_rules" (what check_code checks), "estimates"
(the rules of thumb of estimate_sales), "style_guide:<id>", "reference:<appid>"
(derived analysis of a reference game), "references" (catalog), "store_patterns" (what the store pages of
popular new releases look like, per Steam genre; numbers only), "store_patterns:<Steam genre>".

Input parameters:

- `kind` (string, required)

### `generate` (~221 tokens)

Produce drafts for a part of the release.

Text sections return a brief for YOU to write from (the server never invents marketing text itself):
  \- "store_short": write one variant per strategy the brief lists (fantasy, mechanic, situation_humor, and
    after a market study market_common and market_contrast), save each with save_draft.
  \- "store_long": stage "outline" first; after the user approved an outline, stage "text".
  \- "achievements": names, descriptions and icon briefs for achievements that lack them.
Deterministic sections write drafts into steamworks.yaml directly (never over approved values):
  \- "cloud" (quotas, enable), "builds" (a depot per OS; returns the SteamPipe scripts when depot ids exist),
    "requirements" (minimum system requirements from the engine, always to review), "code" (stats,
    leaderboards and achievements used in code).

Input parameters:

- `path` (string, required)
- `section` (string, required)
- `stage`

### `integration_code` (~211 tokens)

Steamworks SDK code for the game's engine that uses exactly the app id and the achievement, stat and
leaderboard names in steamworks.yaml: starting Steam (restart through Steam, checked init, callbacks,
shutdown), unlocking achievements and setting stats (StoreStats included), uploading leaderboard scores, and
where to save files for Steam Cloud. Written to .steam-mcp/exports/code/<target>/, never into the game.

Args:
    path: The game's folder (with steamworks.yaml).
    features: Which parts (default all): init, achievements, stats, leaderboards, cloud.
    target: unity-steamworks-net, unity-facepunch, godot (GodotSteam 4), unreal or cpp. Default: from the
        engine and the Steam wrapper the code already uses.
    source_dir: The engine project folder, when it is not `path` itself.

Input parameters:

- `features`
- `path` (string, required)
- `source_dir`
- `target`

### `save_draft` (~146 tokens)

Store a text YOU wrote as a draft (it does not change steamworks.yaml). The server rejects text that breaks
Valve's store rules or copies 8+ consecutive words from a reference game, scores it against the rubric, and
returns rubric findings plus questions for you to judge. strategy: fantasy | mechanic | situation_humor |
market_common | market_contrast | outline | text | revision | … . The user picks a draft with
set_field(path, field, from_draft=<id>).

Input parameters:

- `field` (string, required)
- `notes` (string)
- `path` (string, required)
- `strategy`
- `value` (string, required)

### `validate` (~149 tokens)

Review what is in steamworks.yaml (and the translations) without changing it.

section: "store" (Valve's rules in every language, the rubric, questions for you to judge), "achievements",
"localization" or "all" (adds every failing gate rule). For store text, judge the returned questions and call
again with llm_judgements=[{rule_id, field, outcome: pass|warn|fail, note}]; deterministic and judged results
are reported separately. To propose a fix, save a new version with save_draft(strategy="revision").

Input parameters:

- `llm_judgements`
- `path` (string, required)
- `section` (string)

### `check_code` (~223 tokens)

Check the game's own code, engine settings and SteamPipe scripts against Steamworks rules (read-only):
app ids (480, mismatches), the SDK start (result checked, restart through Steam, callbacks, shutdown),
stats and achievements (StoreStats, names that steamworks.yaml does not define), keys and Steam login files
in the project, build scripts (setlive default, missing paths, steam_appid.txt in builds), Steam Deck (fixed
resolution, no gamepad input, anti-cheat), saves (PlayerPrefs, Windows paths, BinaryFormatter) and networking
(old P2P API, unverified auth tickets). Every finding has a file, a line and a fix; a secret is never shown.

Args:
    path: The game's folder (with steamworks.yaml).
    source_dir: The engine project folder, when it is not `path` itself.
    rules: Only these rule or group ids (get_spec_info("code_rules") lists them).

Input parameters:

- `path` (string, required)
- `rules`
- `source_dir`

### `preview_store` (~84 tokens)

Write an HTML preview of the store text (current values, or the given drafts) to .steam-mcp/exports/,
with the estimated end of the first screen marked (an estimate; Steam's cut-off height is not documented).

Input parameters:

- `about_draft`
- `fold_px` (integer)
- `path` (string, required)
- `short_draft`

### `prepare_images` (~117 tokens)

Make every store, library and icon image from assets.key_art + assets.logo (or hand-made
assets.overrides) at the exact sizes Steam wants, plus achievement icons (256x256 JPG, with greyscale locked
versions). Crops around assets.key_art_focus, never stretches, reports upscaling, never generates artwork.
Output and a preview page go to .steam-mcp/exports/images/ for the user to upload.

Input parameters:

- `achievement_icons` (boolean)
- `only`
- `path` (string, required)

### `fetch_reference` (~82 tokens)

Fetch a successful Steam game's public data (on this machine, cached) and return derived measurements
only: description structure and length, media counts, categories, achievement count/style/distribution.
Its raw texts stay in the local cache, where the anti-copy check uses them.

Input parameters:

- `appid` (integer, required)
- `refresh` (boolean)
- `tags`

### `study_market` (~168 tokens)

Start a market study before writing the store text: find the game's closest popular Steam games (its most
specific store tags, on the Popular New Releases and Top Sellers lists, released in the last 3 years) and
return their short descriptions and About texts for YOU to read and label with the returned vocabulary.
Only their app ids are saved; the texts stay in the local cache, and drafts are checked against them. Then
call save_market_study.

Args:
    path: Folder that holds steamworks.yaml.
    tags: Steam store tag names to search with instead of store.tags, most specific first.
    games: How many games to study (3-15, default 10).

Input parameters:

- `games` (integer)
- `path` (string, required)
- `tags`

### `save_market_study` (~116 tokens)

Save your labels for the pages study_market returned: one note per page with appid, short_opening,
short_moves, about_shape, about_sections, tone (all from its vocabulary) and technique (one sentence in your
own words; a note that repeats 4+ consecutive words of the page is rejected). The study keeps labels, notes
and numbers, never page text; generate(store_short / store_long) builds on it from then on.

Input parameters:

- `notes` (array, required)
- `path` (string, required)

### `store_lookup` (~81 tokens)

Look a game up on the Steam store by name, app id or store link: price, review score, players right now,
release date, genres, modes (co-op, PvP…), Steam features, platforms, languages, achievements and DLC.
Public data, cached for a few hours; nothing is saved in the project.

Input parameters:

- `query` (string, required)

### `compare_games` (~111 tokens)

Compare games side by side: price, reviews, positive share, players right now, release, modes, and which
Steam features most of them use. Default: the games of the market study (study_market) plus this game once
it is on the store.

Args:
    path: The game's folder, to compare with its market study.
    appids: Games to compare instead (store_lookup finds app ids by name). At most 15.

Input parameters:

- `appids`
- `path`

### `price_brief` (~145 tokens)

What close games charge: their US full prices (median and middle half), and for each country store how
much they charge per US dollar, applied to this game's base price (pricing.base_price_usd, else their
median). Default games: the market study's. Nothing is saved; the user decides the price.

Args:
    path: The game's folder.
    appids: Games to compare with instead of the market study's.
    countries: Two-letter store codes (default us, gb, de, pl, tr, br, cn, jp, kr, in).

Input parameters:

- `appids`
- `countries`
- `path` (string, required)

### `estimate_sales` (~128 tokens)

Rough copies sold for close games, from their review counts, and, with `wishlists`, a first-week range
for this game at its base price and launch discount. Rules of thumb with every assumption listed, never a
forecast. Default games: the market study's.

Args:
    path: The game's folder (its market study and price).
    appids: Games to estimate instead.
    wishlists: This game's wishlists on release day, if the user knows them (Steamworks shows them).

Input parameters:

- `appids`
- `path`
- `wishlists`

### `study_reviews` (~159 tokens)

Start a review study: the most helpful positive and negative English reviews of the close games (default:
the market study's) or of any games, e.g. this game after launch. Read them and label each game with the
returned themes (what players praise and criticize), then call save_review_study. Only the app ids are saved;
the texts stay in the local cache and nothing about reviewers is fetched.

Args:
    path: The game's folder.
    appids: Games to study instead of the market study's.
    per_kind: Reviews per game and kind (positive, negative): 3-25, default 10.

Input parameters:

- `appids`
- `path` (string, required)
- `per_kind` (integer)

### `save_review_study` (~98 tokens)

Save your labels for the games study_reviews returned: per game appid, praised (1-4 themes, most important
first), criticized (0-4) and insight (one sentence in your own words; one that repeats 4+ consecutive words
of a review is rejected). Keeps labels and shares, never review text; the store-text briefs use it.

Input parameters:

- `notes` (array, required)
- `path` (string, required)

### `launch_watch` (~62 tokens)

After release: the game's review score and count, players right now and price, against the last check
(each check is kept in .steam-mcp/market/launch.jsonl). Call it again any day to see the trend.

Input parameters:

- `path` (string, required)

### `localization_status` (~70 tokens)

Per target language: how many player-facing texts (store page, Early Access answers, achievements, launch
options) are translated, missing, or stale (the source changed after translating; stale translations are
marked needs_review). `next` names the language to translate next.

Input parameters:

- `path` (string, required)

### `localization_pending` (~89 tokens)

Texts YOU should translate into `language` (Steam API code) from the source language, with context, length
limits and glossary terms (localization/glossary.yaml). Stale ones carry the previous translation to update.
Translate them, then call localization_set; repeat until nothing is pending.

Input parameters:

- `language` (string, required)
- `limit` (integer)
- `path` (string, required)

### `localization_set` (~92 tokens)

Save translations ({key: text}). Rejected: BBCode tags that differ from the source, a short description over
300 characters, store text breaking Valve's rules. Your translations are drafts until the user approves them
(approve_fields(["localization.<language>.*"])).

Input parameters:

- `language` (string, required)
- `path` (string, required)
- `source` (string)
- `translations` (object, required)

### `export_package` (~112 tokens)

Write everything needed to finish a gate by hand to .steam-mcp/exports/gate_<gate>/: correctly named
files (store localization JSON and per-language texts, store/library images and icons, SteamPipe scripts,
achievement icons and CSV) and a CHECKLIST.md that says, for every open item, which Steamworks page and
field it goes to and what to paste. Done items are ticked. Nothing is uploaded or published.

Input parameters:

- `gate` (integer, required)
- `path` (string, required)

### `apply` (~491 tokens)

Make Steam match the approved values of one section. Always call with dry_run=true first and show the user
the changes; write (dry_run=false, user_confirmed=true) only after they agreed. Nothing is ever published:
BROWSER writes are drafts the user reviews and publishes in Steamworks. The one exception is "store_tags":
Steam applies tags at once, so it also needs goes_live_now=true, and only after the user agreed to exactly
that.

Sections: "leaderboards" (Web API, publisher key), "build" (uploads the SteamPipe scripts with steamcmd),
and with the BROWSER mode: "cloud", "installation", "achievements" (main game), "store_text" (short and long
description in every approved language), "store_page" (the store page form: links, support info, legal
line, system requirements, platforms, language table, genres, categories, third-party DRM/accounts; empty
fields never clear Steam's), "store_assets" (uploads prepare_images' capsules and library images into the
slots Steam has no image for yet; never replaces one, and also sets the library logo position), "depots"
(OS, architecture and language of depots that already exist, through the Depots page's own Save),
"store_tags" (store.tags in order, through the Tag Wizard; live at once; community tags are never removed).
Every call saves a snapshot of what Steam had first.

Args:
    path: Folder that holds steamworks.yaml.
    section: What to apply.
    app: main, demo or playtest (each has its own app id).
    dry_run: Only show the differences (default).
    user_confirmed: The user saw the dry-run changes and agreed.
    remove_extra: Also delete rows that exist only in Steam. Only when the user explicitly asks for it.
    upload_icons: achievements: also upload the icons (prepared from achievements.*.icon).
    goes_live_now: store_tags: the user agreed that the tags go live on the store at once.

Input parameters:

- `app` (string)
- `dry_run` (boolean)
- `goes_live_now` (boolean)
- `path` (string, required)
- `remove_extra` (boolean)
- `section` (string, required)
- `upload_icons` (boolean)
- `user_confirmed` (boolean)

### `steamworks_inspect` (~154 tokens)

Read-only look at what Steam has now. With the publisher key: "builds" (recent builds and branches),
"leaderboards", "achievement_schema". With the BROWSER mode: "cloud", "installation", "achievements",
"store_text", "store_page", "store_assets" (which image slots are filled), "pending" (the unpublished changes
the Publish tab would show), and "checklist" (the
release checklists of the app's Steamworks landing page, each item linked to its gap_report rule).
"snapshots" lists the snapshots saved before writes (local).

Input parameters:

- `app` (string)
- `path` (string, required)
- `what` (string, required)

### `import_from_steamworks` (~152 tokens)

For a game that already exists in Steamworks: read what Steam has (store texts in every language,
achievements, Steam Cloud, installation, leaderboards, the landing page's release checklists) and fill the
EMPTY fields of steamworks.yaml with it, marked "applied". Never writes to Steamworks and never overwrites a
value in the file: differences come back as conflicts for the user to settle. Dry run first; save with
dry_run=false after the user agreed. Leaderboards need the publisher key, the rest the BROWSER mode.

Input parameters:

- `app` (string)
- `dry_run` (boolean)
- `path` (string, required)
- `sections`

### `set_build_live` (~124 tokens)

Set an uploaded build live on a beta branch (Web API, publisher key). Dry run first; set live only after
the user explicitly agreed. The default branch (what every player gets) is never set live by this tool: the
user does that in Steamworks Settings > SteamPipe > Builds.

Input parameters:

- `app` (string)
- `branch` (string, required)
- `build_id` (integer, required)
- `description` (string)
- `dry_run` (boolean)
- `path` (string, required)
- `user_confirmed` (boolean)

### `server_info` (~22 tokens)

Version, workspace root and which optional features are enabled (no secrets).

## Diagnostics

Captured diagnostic sections: Provenance, Install scripts, Dependencies. The full working is on the page: https://verifymcp.io/servers/wazzapsenk-steamworks-mcp/steamworks-mcp#diagnostics

## Score history

- 2026-10-17: 76
- 2026-10-16: 75
- 2026-10-15: 75
- 2026-10-14: 75
- 2026-10-13: 39
- 2026-10-12: 24
- 2026-10-04: 69
- 2026-10-03: 54

## Common questions

### What is the Steamworks Release Assistant MCP server?

Steamworks Release Assistant is an MCP server listed in the public MCP registry as io.github.wazzapsenk/steamworks-mcp. Put a game on Steam: store page, achievements, Valve-rule checks, market data, Steamworks. This page covers its PyPI package (steamworks-mcp).

### Is the Steamworks Release Assistant MCP server safe to use?

Steamworks Release Assistant scores 76 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 17 October 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Steamworks Release Assistant MCP server expose?

Steamworks Release Assistant exposes 35 tools: init_project, scan_project, status, gap_report, start_interview, and 30 more. Their descriptions and schemas cost roughly 4,972 tokens of context every time the server is loaded.

### Is the Steamworks Release Assistant MCP server still maintained?

Steamworks Release Assistant is still listed as active in the MCP registry. We last reached this channel on 17 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the Steamworks Release Assistant MCP server under?

Steamworks Release Assistant declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- PyPI project: https://pypi.org/project/steamworks-mcp/
- Socket report: https://socket.dev/pypi/package/steamworks-mcp
- Repository: https://github.com/wazzapsenk/steamworks-mcp
- Website: https://burakkaan.dev/steamworks-mcp
- Changelog RSS feed: https://verifymcp.io/servers/wazzapsenk-steamworks-mcp/steamworks-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/wazzapsenk-steamworks-mcp/steamworks-mcp.json
- HTML version of this page: https://verifymcp.io/servers/wazzapsenk-steamworks-mcp/steamworks-mcp