Skip to main content
Glama

Publish the game to its sandbox

publish_sandbox
Destructive

Publish this archive to the game’s sandbox — a public page anyone with the link can play, without moderation. Ask the developer first. Before calling, read get_sandbox_state with the same archiveId: its publish says whether this call would be refused, in the same words. A publish needs the build check PASSED (get_archive_status state), Playgama Bridge 2.2.0 or newer in the build, all three covers and a complete form. Answers outcome PENDING: the archive is built, then published, as a rule within minutes; url is the sandbox’s link, revision what is live until then (null before the first publication). Follow the PLAYGAMA_SANDBOX publication of get_publications, waiting its retryAfterSeconds between reads: PUBLISHED — the build is live, hand out url; FAILED — it did not go live and no reason is given: tell the developer, a new publish starts over. Until it is PUBLISHED or FAILED, another publish is refused with 409: wait and call again. Refusals (reason; relay message word for word): ARCHIVE_PENDING — if get_archive_status already says DONE, upload again; MULTIPLAYER — the sandbox has no player accounts: uncheck the flag only if the game plays single-player; PUBLISHED_ON_PLAYGAMA — the game is live in the catalog, its sandbox is closed for good; BLOCKED — Playgama blocked this sandbox, a publish cannot lift it; RATE_LIMITED — 15 publications per rolling hour, repeats included: wait; ORG_QUOTA — wait until resetsAt, do not retry. The rest name what to fix: the build check’s own reasons (get_bridge_sdk_docs has the SDK docs), ARCHIVE_FAILED, BRIDGE_VERSION_OUTDATED, BRIDGE_VERSION_UNKNOWN, FORM_INCOMPLETE (details: the fields to fill, the title included), COVERS_INCOMPLETE (emptySlots).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
archiveIdYesId of an archive of this game that is in its form, unpacked and past its build check (get_archive_status says `processing: DONE` and `state.status: PASSED`), built on Playgama Bridge 2.2.0 or newer (`analysis.bridgeVersion`)
updateNoteNoWhat a returning player will notice in this build, 80 to 500 characters, 1 to 4 sentences. Not a changelog: pick the one or two changes a player would actually feel (a new level, controls that work differently, a boss that got easier) and say them the way you’d tell a friend who played last week. Skip refactors, build settings and fixes nobody could see. If it fixes something players complained about, say so. Send it when this archive replaces the live one (get_sandbox_state `archiveChanged`); leave it out on a first publication and when a player would notice nothing. It is kept with this publication. Always write it in English, even when you talk to the developer in another language: translate, don’t switch. Write as the developer posting in the game’s chat, not as an announcement: first person, short sentences, contractions, plain words, one or two short paragraphs. Plain text only: no headings, lists, markdown, links, e-mail addresses or hashtags, and one emoji at most. Avoid ad words and AI tells: immersive, dive into, embark, journey, unleash, elevate, seamless, thrilling, "whether you’re…", "not just X but Y", lists of three, em dashes. Don’t open with the game’s title, "Welcome to" or "Hey everyone". Use only what you know from the game and from building it; never invent a backstory, feelings or numbers. Non-Latin letters and links are refused: fix the text or leave it out, and never let it block the rest of the call.
applicationIdYesApplication (game) id, as returned by list_applications

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / updateNote / description
      Previous value: -"What a returning player will notice in this build, 80 to 500 characters, 1 to 4 sentences. Not a changelog: pick the one or two changes a player would actually feel (a new level, controls that work differently, a boss that got easier) and say them the way you’d tell a friend who played last week. Skip refactors, build settings and fixes nobody could see. If it fixes something players complained about, say so. Send it when this archive replaces the live one (get_sandbox_state `archiveChanged`); leave it out on a first publication and when a player would notice nothing. It is kept with this publication: UNCHANGED saves nothing, this note included. Always write it in English, even when you talk to the developer in another language: translate, don’t switch. Write as the developer posting in the game’s chat, not as an announcement: first person, short sentences, contractions, plain words, one or two short paragraphs. Plain text only: no headings, lists, markdown, links, e-mail addresses or hashtags, and one emoji at most. Avoid ad words and AI tells: immersive, dive into, embark, journey, unleash, elevate, seamless, thrilling, \"whether you’re…\", \"not just X but Y\", lists of three, em dashes. Don’t open with the game’s title, \"Welcome to\" or \"Hey everyone\". Use only what you know from the game and from building it; never invent a backstory, feelings or numbers. Non-Latin letters and links are refused: fix the text or leave it out, and never let it block the rest of the call."New value: +"What a returning player will notice in this build, 80 to 500 characters, 1 to 4 sentences. Not a changelog: pick the one or two changes a player would actually feel (a new level, controls that work differently, a boss that got easier) and say them the way you’d tell a friend who played last week. Skip refactors, build settings and fixes nobody could see. If it fixes something players complained about, say so. Send it when this archive replaces the live one (get_sandbox_state `archiveChanged`); leave it out on a first publication and when a player would notice nothing. It is kept with this publication. Always write it in English, even when you talk to the developer in another language: translate, don’t switch. Write as the developer posting in the game’s chat, not as an announcement: first person, short sentences, contractions, plain words, one or two short paragraphs. Plain text only: no headings, lists, markdown, links, e-mail addresses or hashtags, and one emoji at most. Avoid ad words and AI tells: immersive, dive into, embark, journey, unleash, elevate, seamless, thrilling, \"whether you’re…\", \"not just X but Y\", lists of three, em dashes. Don’t open with the game’s title, \"Welcome to\" or \"Hey everyone\". Use only what you know from the game and from building it; never invent a backstory, feelings or numbers. Non-Latin letters and links are refused: fix the text or leave it out, and never let it block the rest of the call."
  2. Changed1 schema field changed
    • addedInput schema / properties / updateNote
      Added value: +{
      +  "description": "What a returning player will notice in this build, 80 to 500 characters, 1 to 4 sentences. Not a changelog: pick the one or two changes a player would actually feel (a new level, controls that work differently, a boss that got easier) and say them the way you’d tell a friend who played last week. Skip refactors, build settings and fixes nobody could see. If it fixes something players complained about, say so. Send it when this archive replaces the live one (get_sandbox_state `archiveChanged`); leave it out on a first publication and when a player would notice nothing. It is kept with this publication: UNCHANGED saves nothing, this note included. Always write it in English, even when you talk to the developer in another language: translate, don’t switch. Write as the developer posting in the game’s chat, not as an announcement: first person, short sentences, contractions, plain words, one or two short paragraphs. Plain text only: no headings, lists, markdown, links, e-mail addresses or hashtags, and one emoji at most. Avoid ad words and AI tells: immersive, dive into, embark, journey, unleash, elevate, seamless, thrilling, \"whether you’re…\", \"not just X but Y\", lists of three, em dashes. Don’t open with the game’s title, \"Welcome to\" or \"Hey everyone\". Use only what you know from the game and from building it; never invent a backstory, feelings or numbers. Non-Latin letters and links are refused: fix the text or leave it out, and never let it block the rest of the call.",
      +  "maxLength": 500,
      +  "minLength": 80,
      +  "type": "string"
      +}
  3. Changed1 schema field changed
    • changedInput schema / properties / archiveId / description
      Previous value: -"Id of an archive of this game that is in its form and unpacked (get_archive_status says `processing: DONE`); waiting for its `bridgeSdk` to leave PENDING is recommended"New value: +"Id of an archive of this game that is in its form, unpacked and past its build check (get_archive_status says `processing: DONE` and `state.status: PASSED`), built on Playgama Bridge 2.2.0 or newer (`analysis.bridgeVersion`)"
  4. Changed1 schema field changed
    • changedInput schema / properties / archiveId / description
      Previous value: -"Id of an archive of this game that is in its form and finished unpacking (get_archive_status says DONE)"New value: +"Id of an archive of this game that is in its form and unpacked (get_archive_status says `processing: DONE`); waiting for its `bridgeSdk` to leave PENDING is recommended"
  5. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare destructive=true, idempotent=false, openWorld=true, but the description adds far more: exact prerequisites (build check PASSED, Bridge 2.2.0+, three covers, complete form), the async PENDING outcome with url/revision semantics, the 409 on concurrent publish, and a rate limit of 15 publications per rolling hour with quota resetsAt behavior.

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 critical facts are front-loaded: what it does, the public/no-moderation nature, and 'Ask the developer first' lead the text. It is dense and reads as a single long paragraph, but the length is earned by the large refusal-code surface and the async publication flow rather than filler.

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?

With no output schema and a genuinely complex asynchronous mutation, the description carries the full burden and delivers: it documents the return shape (outcome, url, revision), the polling protocol, every refusal reason and its remediation, and the preconditions.

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?

Schema description coverage is 100%, and updateNote/archiveId are already exhaustively documented in the schema, so the baseline is 3. The description reinforces the archiveId prerequisites and updateNote timing but adds little that the schema does not already carry.

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?

States a specific verb (publish) and resource (this archive to the game's sandbox) and immediately qualifies the target as 'a public page anyone with the link can play, without moderation.' This distinguishes it clearly from read-side siblings like get_sandbox_state and get_publications.

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?

Explicitly says to ask the developer first, to read get_sandbox_state with the same archiveId beforehand, and to follow get_publications afterward. It names when-not conditions (PUBLISHED_ON_PLAYGAMA, BLOCKED) and routes to get_archive_status and get_bridge_sdk_docs for prerequisites, leaving nothing to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources