Playgama MCP - Publish & Manage HTML5 Games

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 its PLAYGAMA_SANDBOX publication in get_publications; once PUBLISHED, hand out url and offer the post and links of get_sandbox_share. Until it ends, another publish is refused with 409: wait and call again. Refusals (reason): ARCHIVE_PENDING — if get_archive_status already says DONE, upload again; 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 or fix, the title included: empty or with non-Latin letters), COVERS_INCOMPLETE (emptySlots).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "applicationId": "<applicationId>",
      "archiveId": "<archiveId>"
    },
    "name": "publish_sandbox"
  }
}

Input Schema

Name	Required	Description
`archiveId`	Yes	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`)
`updateNote`	No	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. Write it in the voice `story` of update_application_form describes. Non-Latin letters and links are refused. Fix a refused note or leave it out; it never blocks the publication.
`applicationId`	Yes	Game id from list_applications

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 4, 2026

changedInput schema / properties / applicationId / description

Previous value: -"Application (game) id, as returned by list_applications"New value: +"Game id from list_applications"

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. 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. Write it in the voice `story` of update_application_form describes. Non-Latin letters and links are refused. Fix a refused note or leave it out; it never blocks the publication."

Changed1 schema field changedOct 12, 2026

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

Changed1 schema field changedOct 5, 2026

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"
+}

Changed1 schema field changedSep 28, 2026

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

Changed1 schema field changedSep 16, 2026

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"

First observedSep 11, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only declare a destructive, non-idempotent, open-world write; the description goes far beyond by disclosing the async PENDING outcome, the minutes-long build-then-publish window, the meaning of url/revision (null before first publication), the 409 refusal while a publish is in flight, and concrete limits (15 per rolling hour, ORG_QUOTA with resetsAt). The unmoderated public exposure is called out explicitly, which is exactly the risk an agent needs before invoking a destructive tool.

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

Conciseness3/5

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

The purpose and the "anyone with the link can play, without moderation / ask the developer first" warning are correctly front-loaded, and most sentences carry real operational value. However, the body is a dense run-on of em-dashes and semicolons covering the async flow, 409s, and a long refusal-code catalog, which is hard to scan and would benefit from structure even if little could be cut.

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?

For a destructive, async, no-output-schema tool this is thorough: it explains what the call returns (outcome, url, revision), how to track completion, how to handle concurrent calls, and enumerates refusal reasons with the action each implies. An agent has everything needed to decide whether to call, interpret the result, and recover from failures.

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 coverage is 100%, so the schema already documents archiveId, applicationId and the lengthy updateNote rules; the description adds little beyond tying archiveId to the get_sandbox_state pre-check. It never mentions updateNote itself, so parameter meaning is almost entirely carried by the structured schema, making the 3 baseline correct.

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 and resource — publish this archive to the game's sandbox — and immediately defines what that means: a public page anyone with the link can play, without moderation. That definition also distinguishes it from catalog publication, which the description later says closes the sandbox for good.

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?

Gives explicit preconditions (build check PASSED, Bridge 2.2.0+, three covers, complete form), a mandatory pre-flight check via get_sandbox_state with the same archiveId, a human-confirmation step ("Ask the developer first"), and a follow-up path through get_publications and get_sandbox_share. It also names conditions where the call is pointless, such as PUBLISHED_ON_PLAYGAMA closing the sandbox permanently.

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

All Playgama MCP - Publish & Manage HTML5 Games tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?