Playgama Developer Console MCP Server

Publish and manage your HTML5 games on Playgama straight from your AI agent — Codex, Claude Code, Cursor or VS Code. Full guide: Playgama wiki.

The server is hosted by Playgama. There is nothing to install or run and no token to copy — you give your client the endpoint below, sign in to the console in the browser it opens, and allow the connection.

• Publish in minutes — ask your agent, get a public playable link back.
• Get the audience — the game takes its first players from the Playgama network, and Playgama DSP can send more the day it goes live (beta). The agent can start that campaign itself with start_sandbox_traffic; share the game first and the boost is free.
• Start monetization — rewarded, interstitial and banner ads switch on through Playgama Ad once the game clears the session threshold (access by request).
• Improve a game from telemetry — the agent can instrument the game, inspect compact preaggregated event, trend and session views, and use the evidence to find progression or performance problems. Playtime, retention and revenue reports remain in the developer dashboard; payouts start at 100 USD.

You need a Playgama developer account with the sign-up finished. A connected agent reaches the games of your own organization and nothing else. It stays connected while it keeps using the server; revoke it on the same page and it is refused on its next call.

Every game needs the Playgama Bridge SDK integrated — the sandbox included. If your game does not have it yet, the agent integrates it before the first upload: get_bridge_sdk_docs serves the docs, starting with their required steps, and get_game_checklist serves the numbered Game Requirements every game and its archive must meet. A build in which the SDK was not detected is not published, and the sandbox takes Playgama Bridge 2.2.0 or newer only.

Questions: developer.success@playgama.com

Every client below opens the browser the first time it connects. Sign in to the console if you are not signed in, check the account and the agent, and allow it.

codex mcp add 'playgama-developer-console' --url 'https://developer.playgama.com/api/mcp'

claude mcp add --transport 'http' 'playgama-developer-console' 'https://developer.playgama.com/api/mcp'

Then run /mcp in Claude Code and choose the server to sign in.

~/.cursor/mcp.json:

{
  "mcpServers": {
    "playgama-developer-console": {
      "type": "http",
      "url": "https://developer.playgama.com/api/mcp"
    }
  }
}

.vscode/mcp.json:

{
  "servers": {
    "playgama-developer-console": {
      "type": "http",
      "url": "https://developer.playgama.com/api/mcp"
    }
  }
}

Settings → Connectors → Add custom connector, with the endpoint https://developer.playgama.com/api/mcp.

If your config still sends an Authorization header with a pgm_mcp_ token, it keeps working for now. Remove the header and connect again as above.

The authoritative list is what the server answers to tools/list. As of version 1.9.0:

Every write tool is annotated destructiveHint: true; clients decide how to use that hint when requesting confirmation.

For a launch workflow, agents start with get_launch_steps and read it again after each step. A request only to read data does not authorize game changes, publication or a traffic campaign.

1. Read get_game_checklist and check the game and the zip against each requirement by its number; fix what fails before uploading. The agent reads the requirements and the SDK required steps once already, when it starts work on the game.
2. start_archive_upload answers uploadUrl and headers.
3. PUT the zip to uploadUrl with exactly those headers, e.g. curl -T game.zip -H "Content-Type: application/zip" "<uploadUrl>".
4. confirm_archive_upload, then poll get_archive_status until state.status is no longer CHECKING. Only a PASSED build can be published; on PROBLEM or NOT_CHECKED pass state.message on to the developer word for word and fix the build — publish_sandbox and a submit to moderation both refuse it (get_bridge_sdk_docs has the SDK integration docs). The sandbox also refuses a build on a Playgama Bridge older than 2.2.0 (BRIDGE_VERSION_OUTDATED) or one whose version the check could not read (BRIDGE_VERSION_UNKNOWN): update the SDK and upload a new archive. If processing is FAILED, upload a corrected zip.
5. A sandbox publish also needs all three covers and a complete form. Without them publish_sandbox is refused with COVERS_INCOMPLETE, which names the empty slots in emptySlots, or FORM_INCOMPLETE, which names the fields in details: upload the covers or fill the fields with update_application_form, then publish again.
6. publish_sandbox answers PENDING: the build is built, then published, as a rule within minutes. Follow the PLAYGAMA_SANDBOX publication in get_publications, waiting its retryAfterSeconds between reads, until it leaves IN_PROGRESS; once it is PUBLISHED, hand out the url from the publish answer. FAILED means the build did not go live. While a publication is in progress, another publish is refused with 409.

Covers work the same way, one slot per call: a PNG or JPEG of exactly 800×800 (square), 1080×1920 (portrait) or 1920×1080 (landscape). All three are required for a sandbox publish and for a submit to moderation.

A game already live in the Playgama catalog can take an update without moderation; a first publication and every other platform still go through moderation, which the developer submits in the console.

1. get_submission_state with the build's archiveId and reviewType: AUTO says whether the update would be refused, and why.
2. The agent tells the developer the game, the build and that every catalog player gets it with no moderator checking it first, and goes on only on their explicit yes to this update.
3. send_playgama_catalog_update takes the build and a required updateNote — what players will notice — and answers PENDING with a releaseId. Follow the PLAYGAMA publication with that releaseId in get_publications until it leaves IN_PROGRESS: PUBLISHED — the update is live; FAILED — players keep the previous build.

Before finishing a game, the agent reads get_game_telemetry_guide and adds the relevant product progression events and performance sample. Telemetry is guidance, never an upload or publication gate.

After a release has collected traffic, the agent starts with get_game_telemetry_analytics. It uses get_game_telemetry_event_analytics only for one relevant event or field, get_game_telemetry_timeseries for event volume or sampling reach over time, and get_game_telemetry_session_facts for a filtered product-event order question. FPS, frame-time and stutter summaries for performance_sample come from event analytics. Timeseries points do not contain those field values, and repetitive core_ping and performance_sample events are intentionally absent from session facts, so the current views do not support per-session FPS claims. The tools return dynamic preaggregated JSON, not raw events and not a server-generated conclusion. The agent inspects the response's schema version, period, freshness, sample size and pagination, treats missing or null fields as unavailable rather than zero, and requests another page only when it can change the current conclusion.

The overview event inventory defaults to 50 event types and accepts up to 100. Its events_page.next_cursor is passed back as eventCursor; agents do not exhaust the inventory preemptively. The full parameter and response guidance is in the Tools reference.

Two separate traffic bonuses can start a sandbox campaign:

• A referral bonus comes from get_referral_program and is passed to start_sandbox_traffic as bonusId; it needs no social post. Every organization member can share the returned invitation.url. Apply only a developer-provided invitation, before the invited organization's first sandbox publication. An accepted invitation grants the invited studio $3 of traffic; its first sandbox publication grants the inviter another $3 of traffic. These are campaign budgets, not cash.
• The share bonus follows a post about the game on any platform. The developer publishes the post and pastes its link to the agent, which passes one to three public HTTPS post links to start_sandbox_traffic in postUrls; one is enough. The bonus is once per game, for up to three games per organization over its lifetime. Earlier free launches without sharing do not use this bonus. get_sandbox_share has the ready post and share links. Paid traffic is available in the console; MCP does not purchase it.

• Build archive: up to 300 MB per zip.
• Cover: up to 10 MB per file.
• Sandbox: 15 publications per rolling hour per game; every publication counts, the same build included.

These stay human actions in the console:

• submitting a game to moderation;
• deleting anything — leaderboards, or archives and covers from the form;
• rolling a game back to its latest release;
• reading payouts;
• uploading screenshots, videos and other assets.

The rest of the Playgama stack picks up where this server stops:

• Playgama Bridge SDK — required in every game you upload (see above), and the same integration carries the game further: one API for ads, leaderboards, payments and platform SDKs when you publish the same game across platforms. Open source, npm i @playgama/bridge.
• Playgama Ad — monetizes web games with rewarded, interstitial and banner formats through a single lightweight JS SDK, with gaming-focused demand, Google Ad Manager MCM support and reporting. Access by request.
• Playgama Wrap — turns the same game into a standalone site on your own domain, with hosting, player accounts, in-game purchases, PWA install and indexable SEO pages. Early access.
• Playgama DSP — brings the first players to a freshly published game. Beta.

MIT