Steamworks Release Assistant

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

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.

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.

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.

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

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

Write a saved snapshot back to Steamworks (BROWSER mode): undoes an apply. Without `snapshot`, lists the snapshots. The first write on every app has to be a restore of the snapshot just taken: it writes every row back unchanged and reads it again, proving this tool reads and writes that app correctly. Dry run first; restore only after the user agreed.

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

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.

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.

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.

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

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.

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.

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 ar…

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.

Check what Steamworks really has, field by field (BROWSER mode, read-only), not its checklist table: whether each value is filled the way Steam's review needs, and whether the values agree with each other, with steamworks.yaml and with the game's build folder. area "store": texts and their length, languages vs translations, platforms vs system requirements and depots, genre, categories vs achievements and Steam Cloud, developer, publisher, support, release date, image slots, screenshots and their all-ages marks, tags. Returns `for_you_to_judge` (the texts) for you to assess too. area "build":…

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

Open the Steamworks site in a browser window for the BROWSER mode. The first time this returns terms the user has to read and accept (then call again with accept_risks=true). The user signs in themselves; this tool never types passwords or Steam Guard codes and never reads cookie values.

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.

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:…

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.

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