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.

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.

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.

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); default all. include_info: Also list the background notes (permissions, timings) that never block.

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.

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.

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.

The user confirms something is done in Steamworks: a manual step ("checklist." 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.

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:", "reference:" (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:".

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).

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//, 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.

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=).

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").

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).

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).

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.

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.

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).

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.

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.

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.

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).

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).

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.

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.

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.

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.

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.

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..*"])).

Write everything needed to finish a gate by hand to .steam-mcp/exports/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.

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.

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).

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.

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.

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