Official MCP RegistryListed
Multiplayer Agent
Make any browser game multiplayer and host it at a share link. No account needed to start.
First seen 26 Oct 2026. Evidence as of 12 Nov 2026.
26
Tools
From an anonymous probe
1
Source listings
Each with its own history
35
Recorded changes
Since first seen
Tools
| Tool | Description | Behaviour |
|---|---|---|
| cancel_live_event | Delete a scheduled event. If it is running, it ends in running rooms within ~15 seconds (its config overrides drop away; server logic gets onLiveOps with it in change.ended). To end it early but keep it listed, schedule the same id again with endsAt set to the current time. | Destructive |
| claim_studio | This connection has no account: it builds into an unclaimed studio. Returns the claim link to give the user (a free sign-up or log-in that moves the studio's games into their own account), when the studio expires, and whether it has been claimed already. connect_account is the better way to keep the games when the user is here (this session then keeps working as their account); the claim link is for later, or for someone else. | Read-only |
| connect_account | Connect this keyless session to the user's own account, the way `gh auth login` works. Ask for their email first and pass it (it prefills the page). Returns a one-time url and a code: open the url in their browser yourself and tell them the code. They sign up or log in ON THE PAGE (never ask for a password in chat), check the code matches, and press Connect. From then on this session acts as their account and the games built so far move in. The link lasts 10 minutes. | Changes data |
| create_game | Mint a new game (publishable key) under your studio (secret key). Returns its publishableKey + wsEndpoint. Point a client at the new key, or scope this MCP to it by passing the x-mp-game header. | Changes data |
| create_upload | Upload files straight from disk instead of pasting their bytes into a tool call: for images, audio, fonts, 3D models, and ANY file over ~50 KB (a tool call can't carry megabytes of base64). Give each file's hosted path and exact size in bytes; get back one URL per file. PUT each file to its URL with curl, from the game's folder: curl -sS -T <local file> "<url>" (Windows PowerShell: curl.exe). Each URL takes ONE PUT of exactly that many bytes and expires in 15 minutes, so upload right away. Then call publish_game with { path, uploadId } entries for these files (small text files can still go inline next to them), or deploy_room_logic with uploadId for a long logic file. An upload belongs to the game it was made for and is used up by the publish. Limits on this studio's plan: 100 files per call, 5 MB per game. | Changes data |
| define_room_type | Create or replace the spec for a room (validation/types/defaults). Returns connection info. Omit fields entirely for a fully schemaless room. | Destructive |
| deploy_room_logic | Deploy server-side game logic (JS source) for a room so it runs AUTHORITATIVELY: clients send inputs and the server computes state on a tick (anti-cheat by construction). Define handlers as functions over a global `state` (RoomStateView shape): onJoin(id), onLeave(id), onInput(id, input), onEvent(id, type, data), onTick(dt); emit(type,data)/emitTo(id,type,data) send events to clients. For TRUSTWORTHY persistence the client can't fake, call saveData(id, patch)/loadData(id) (the player's server-only save) and submitScore(id, board, score, mode), the server decides the values (the client passes its identity via MP.join({…, player})). Each deploy returns a version (roll back with rollback_room_logic; read runtime errors with get_room_logs). Limits: code <= 256KB, tickRate 1-60. The code runs in a locked-down isolate: handlers must be SYNCHRONOUS (no async/await/promises/timers), there is no network or require, console.* is a no-op, and state must stay JSON-serializable (no Map/Set/class instances). Call get_sdk_reference for the full contract. | Changes data |
| enable_login_provider | Let players sign in with a portal or federated account via player.loginExternal({ provider, token }). Self-serve providers: 'wavedash' (games on wavedash.com; token = (await Wavedash.getUserJwt()).data) and 'google' (Google Identity Services; token = the GIS ID-token credential). The server verifies every token against fixed, provider-published keys; you only supply public pins. wavedash: gameId is required = the gcid of the Wavedash game players sign in from (ask the user, or read claims.gcid off a token with verify_login_token, which works before wavedash is enabled). Playtest and production builds have different gcids: re-run with the production one before launch. google: clientId is required. Re-run to change the config (e.g. once the game id is known). Then verify with verify_login_token. | Changes data |
| get_client_snippet | Returns a complete client wired to this room. platform "web" (default): a single-file HTML game with realtime movement plus an anonymous (claimable) player, a saved color (datastore), and a click leaderboard; write it to disk and open it. platform "unity": one drop-in C# script for the Unity C# SDK (Unity 2021.2+) that boots itself on Play in an empty scene (realtime movement, remote smoothing, an event, reconnect hints). The game it is wired to is stamped in a comment at the top of the file. | Read-only |
| get_connection_info | Returns { wsEndpoint, roomName, publishableKey, adsPublisherId } for wiring a client. adsPublisherId is your BYO Google Ads id (embed it if set). Check the returned `target` names the game you meant before shipping the key. | Read-only |
| get_live_ops | Read a game's live ops: `now` (what players see right now: the merged config plus active and upcoming events), the base config, every scheduled event with its status (active / upcoming / ended), the highlight webhook (masked) and the 20 latest highlights with how each was delivered. Pass `at` to preview another instant (e.g. the middle of a weekend event) and `room` to see one room's view. Use it to verify every change you make. | Read-only |
| get_room_logs | Returns recent runtime errors from a room's deployed logic (newest first), so you can self-fix after a deploy without joining the room. Errors also surface in state.shared.__error. | Read-only |
| get_sdk_reference | Returns the full SDK reference (markdown) wired to ONE game's key/endpoints: realtime rooms, player identity (anonymous + claim/login), the datastore (saves/stats/inventory), leaderboards, player-created content (level sharing / UGC), durable shared MATCHES for asynchronous turn-based play, and live ops (live config, scheduled events, highlights). Read this before writing client code that uses logins, saved progress, leaderboards, shared player-made content, or any game a player closes and comes back to. Pass `game` when the studio has more than one: every snippet carries that game's publishable key inline, and shipping the wrong one silently pools your players into another game. Pass platform "unity" for the Unity / C# SDK variant (C# client code; server logic stays JavaScript). | Read-only |
| list_games | List the games (publishable keys) under your studio, with labels and per-game settings. Marks which game is `primary` (the one unnamed calls fall back to) and which one this connection is currently pointed at. | Read-only |
| list_login_providers | List the external login providers enabled on a game (names only, never secrets). selfServe=true ones you can reconfigure with enable_login_provider; the rest are operator-managed. | Read-only |
| list_room_logic | Returns the deploy history (version, tickRate, bytes, deployedAt) for a room's authoritative logic, newest first. | Read-only |
| list_starters | List the starter games: ready-made multiplayer games (many built in Multiplayer Agent's videos) to begin from with remix_game. Each shows its slug, title, summary, the video it came from, whether it's premium, and whether THIS studio has it unlocked (free starters: everyone; premium: a paid plan). | Read-only |
| publish_game | Host the game's files at a public share link, https://<slug>.play.multiplayeragent.com/ (the game's own origin; the slug comes from the game's name and never changes). The game needs an index.html at the root plus any JS/CSS/assets, paths relative to it. Send small text files (HTML, JS, CSS, JSON) inline as { path, content }. For images, audio, fonts, models and ANY file over ~50 KB, call create_upload first, PUT each file with curl, and pass { path, uploadId } here: the bytes never go through you. (Inline base64 with encoding: "base64" still works for a tiny binary.) The files must use THIS game's publishable key (it is how the server knows the build belongs to this game; a client wired to another game is refused). mode "replace" (the default) makes the files you send the whole game: anything not sent is removed. mode "patch" adds or replaces only the files you send and keeps the rest, and `remove` deletes paths: use it to fix one file without resending the art, or to put a big build up over several calls. Re-run after every change; the link stays the same. Limits on this studio's plan: 100 files and 5 MB per game, 25 MB across all its games. Give the user the url: anyone who opens it joins the same rooms. Nothing is listed publicly; only people with the link find it. | Changes data |
| remix_game | Start from a starter game (see list_starters): makes a NEW game in this studio (or, with `game`, reuses one of yours) and returns a link to the starter's source as a ZIP, valid for 5 minutes, plus the steps to unpack it, rewire it to the new game's publishable key, and publish it. Premium starters need a paid plan; a locked one returns the upgrade link instead, and nothing is created. | Changes data |
| rollback_room_logic | Roll a room's authoritative logic back to a prior version by re-deploying it as a new version (history stays intact). Omit toVersion to restore the previous version. | Destructive |
| schedule_live_event | Schedule (or, with an existing id, edit) a timed event: a window, optionally repeating daily or weekly, optionally limited to some rooms, carrying config overrides that apply only while it runs. It starts and ends on time in rooms that are already running, as data: nobody is kicked and nothing is redeployed. Clients see it in mp.live (active / upcoming / config) and mp.onLive(cb); server logic reads liveOps() and gets onLiveOps(live, change) when it starts or ends. Up to 50 events per game; check the result with get_live_ops (pass `at` to preview). | Changes data |
| set_game_name | Set a human-readable name for a game (the `game` argument, else the x-mp-game header, else your only game). The name shows in your dashboard: call this when you start building so the game isn't unnamed. Refuses to guess when the studio has several games and none was named. | Changes data |
| set_highlight_webhook | Set where the game's highlights post: a Discord channel webhook (Server Settings → Integrations → Webhooks → Copy URL) or a Slack incoming webhook. Server logic posts with highlight(type, text, data), e.g. highlight("hard-clear", "Mia cleared Level 9 on one life"); the server decided it happened, so players can't fake one. Sends a test post and saves only if it is accepted. The URL is a credential: ask the user to paste it, and it is only ever shown back masked. Pass null to stop posting. Limits: 6 highlights a minute per room, 60 posts an hour per game (the rest are still recorded; see get_live_ops). | Changes data |
| set_live_config | Set the game's live config: any JSON the game reads at runtime (drop rates, prices, difficulty, a banner, feature switches). It reaches rooms that are already running within ~15 seconds, with no redeploy and nobody disconnected; clients read it as mp.live.config, server logic as liveOps().config. Merges by default (a null value deletes a key); replace: true swaps the whole object. Active events' overrides apply on top. Max 8KB. | Changes data |
| set_player_scope | Choose whether players (and their data/leaderboards) are shared across all of your games ('account', the default) or isolated to one game ('project'). Set this ONCE at setup: it locks as soon as the game has any players, because changing it would split existing players and their leaderboards across two scopes. To use a different scoping, create a new game. IRREVERSIBLE: always name the target with `game`; this tool refuses to pick when the studio has several. | Destructive |
| verify_login_token | Check a real provider token against the game's login config exactly as player.loginExternal would, WITHOUT creating or linking a player. Returns { ok, uid, username, claims } or { ok: false, error }. Use it to confirm a provider works end to end, and to read what a token carries (e.g. Wavedash's gcid). Wavedash works before it's enabled (signature and issuer only, plus a note), so you can read the gcid that enable_login_provider needs. Ask the user to paste a token from their running build (Wavedash: (await Wavedash.getUserJwt()).data in the browser console). | Read-only |
Change history
- verify_login_token: description changed (+"Wavedash works before it's enabled (signature and issuer only, plus a note), so you can read the gcid that enable_login_provider needs.")
- get_sdk_reference: input schema changed (+platform)
- get_sdk_reference: description changed (+"Pass platform "unity" for the Unity / C# SDK variant (C# client code; server logic stays JavaScript).")
- get_client_snippet: input schema changed (+platform)
- get_client_snippet: description changed (+"client wired to this room. platform "web" (default): a" +"with" +"leaderboard; write")
- enable_login_provider: input schema changed
- enable_login_provider: description changed (+"is required" +"Wavedash" +"players sign in from")
- server instructions changed
- server instructions changed (+"The user can also start one themselves with the `remix` prompt (in the client's slash menu, e.g. /multiplayer-agent:remix chompchomp-io): mention it when they ask how to get a game from a video." -"make them guess at the menu. They can also ask for the tour themselves with the `whats-possible` prompt (it appears in the client's slash menu, e.g. /multiplayer-agent:whats-possible): mention it if they seem")
- verify_login_token: tool added
- set_player_scope: tool added
- set_highlight_webhook: tool added
- rollback_room_logic: tool added
- publish_game: input schema changed (+mode, +remove)
- publish_game: description changed (+"The" +"needs" +"Send small text files (HTML, JS, CSS, JSON) inline")
- list_room_logic: tool added
- list_login_providers: tool added
- get_room_logs: tool added
- enable_login_provider: tool added
- deploy_room_logic: tool added
- create_upload: tool added
- server instructions changed (+"providers, player scope" +"the highlight webhook:" +"tools are listed but answer "Connect an account first" until")
- remix_game: tool added
- list_starters: tool added
- server instructions changed (+"STARTER GAMES: ready-made multiplayer games to begin from instead of a blank page, many of them built in Multiplayer Agent's videos. When the user names one ("the slither game from the video"), asks for a template or an example to start from, or wants something close to one, call list_starters, then remix_game with its slug: it makes a new game in this studio and gives you a link to the source to download, rewire to the new game's key, and publish. Free starters are open to everyone; premium ones come with a paid plan (Indie and up), and a locked one tells you the upgrade link to pass on. A keyless session counts as the free plan until connect_account links an account on a paid plan." -"call create_game with a clear, human-readable label. One studio (secret key) holds many games; each game is one publishable key (pk_). 2. Name it first. Never leave a game unnamed: use create_game's label, or call set_game_name on the game you are building, before defining rooms. 3. Read get_sdk_reference fully before writing any client code: it documents every capability below with working snippets wired to this game's keys/endpoints. 4. Define each room/mode with define_room_type (a room name = a mode/level under the key; omit fields entirely for a fully schemaless room). Get paste-ready wiring with get_connection_info / get_client_snippet. 5. For server-authoritative games, deploy_room_logic; inspect with get_room_logs / list_room_logic; undo with rollback_room_logic. 6. Host it: publish_game uploads the game's files (index.html at the root, plus any assets) and")
- Repository changed from "https://github.com/natepac/multiplayer-agent" to "https://github.com/multiplayeragent/multiplayer-agent" (registry)
- set_live_config: tool added
- schedule_live_event: tool added
- get_sdk_reference: description changed (+"play, and live ops (live config, scheduled events, highlights)." -"and" -"play.")
- get_live_ops: tool added
- cancel_live_event: tool added
- server instructions changed
- server instructions changed
- MCP URL changed from "https://api.multiplayeragent.com/mcp" to "https://api.multiplayeragent.com/mcp?src=registry" (registry)
- Listed (registry)
| Source | Listing | First seen | Last seen | Versions |
|---|---|---|---|---|
| Official MCP Registry | com.multiplayeragent/multiplayer-agent | 26 Oct 2026 | 11 Nov 2026 | 3 |