Connect

8 clients · secrets stay placeholders

JSON (mcpServers)Claude CodeCodexOpenCodeCursorVS CodeGemini CLIGoose

{
  "mcpServers": {
    "multiplayer-agent": {
      "type": "http",
      "url": "https://api.multiplayeragent.com/mcp?src=registry",
      "headers": {
        "Authorization": "Bearer ${MULTIPLAYER_AGENT_TOKEN}"
      }
    }
  }
}

claude mcp add --transport http multiplayer-agent https://api.multiplayeragent.com/mcp?src=registry --header "Authorization: Bearer ${MULTIPLAYER_AGENT_TOKEN}"

[mcp_servers.multiplayer-agent]
url = "https://api.multiplayeragent.com/mcp?src=registry"
bearer_token_env_var = "MULTIPLAYER_AGENT_TOKEN"

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "multiplayer-agent": {
      "type": "remote",
      "url": "https://api.multiplayeragent.com/mcp?src=registry",
      "enabled": true,
      "headers": {
        "Authorization": "Bearer {env:MULTIPLAYER_AGENT_TOKEN}"
      }
    }
  }
}

{
  "mcpServers": {
    "multiplayer-agent": {
      "type": "http",
      "url": "https://api.multiplayeragent.com/mcp?src=registry",
      "headers": {
        "Authorization": "Bearer ${MULTIPLAYER_AGENT_TOKEN}"
      }
    }
  },
  "deeplink": "cursor://anysphere.cursor-deeplink/mcp/install?name=multiplayer-agent&config=eyJ0eXBlIjoiaHR0cCIsInVybCI6Imh0dHBzOi8vYXBpLm11bHRpcGxheWVyYWdlbnQuY29tL21jcD9zcmM9cmVnaXN0cnkiLCJoZWFkZXJzIjp7IkF1dGhvcml6YXRpb24iOiJCZWFyZXIgJHtNVUxUSVBMQVlFUl9BR0VOVF9UT0tFTn0ifX0%3D"
}

{
  "servers": {
    "multiplayer-agent": {
      "type": "http",
      "url": "https://api.multiplayeragent.com/mcp?src=registry",
      "headers": {
        "Authorization": "Bearer ${MULTIPLAYER_AGENT_TOKEN}"
      }
    }
  }
}

{
  "mcpServers": {
    "multiplayer-agent": {
      "httpUrl": "https://api.multiplayeragent.com/mcp?src=registry",
      "headers": {
        "Authorization": "Bearer ${MULTIPLAYER_AGENT_TOKEN}"
      }
    }
  }
}

extensions:
  "multiplayer-agent":
    enabled: true
    name: "multiplayer-agent"
    type: streamable_http
    uri: "https://api.multiplayeragent.com/mcp?src=registry"
    headers:
      "Authorization": "Bearer ${MULTIPLAYER_AGENT_TOKEN}"
    timeout: 300

Placeholders to fill from your own secret store: ${MULTIPLAYER_AGENT_TOKEN}. The registry never accepts secret values.

Quality 80 / 100good

protocol75 · weight 25

warn
protocol.modernnewest supported version is 2025-11-25; 2026-07-28 not supported, older versions are deprecated until 2027-07-28
n/a
protocol.statelessonly applies to 2026-07-28 servers
pass
protocol.transportstreamable HTTP
n/a
protocol.list_ttlonly applies to 2026-07-28 servers

authorizationn/a · weight 15

n/a
auth.prm, auth.as_metadata, auth.cimdno remote uses OAuth
n/a
auth.secret_in_urlno templated URL

tool hygiene86 · weight 30

pass
tools.descriptionsevery tool has a description
warn
tools.description_length2 tools have descriptions over 1,024 characters, which crowds the context
pass
tools.schemasevery tool has an object input schema
pass
tools.annotations26 of 26 tools declare readOnlyHint or destructiveHint
warn
tools.directory_hints15 of 26 tools declare all four hints; missing: get_client_snippet (destructiveHint, idempotentHint); list_room_logic (destructiveHint, idempotentHint); get_connection_info (destructiveHint, idempotentHint); …
pass
tools.token_costabout 6,737 tokens to load every tool
pass
tools.api_dumptools are not a one-to-one API dump

stability75 · weight 15

warn
stability.changes18 tool changes in 30 days
pass
stability.rug_pullno tool changed its meaning under the same name

dependenciesn/a · weight 15

n/a
deps.known_vulns, deps.mcp_sdk_version, deps.resolvableno npm or PyPI package

26 tools, about 6,737 tokens to load them all · tool set 798cbcdf0123 · tools last changed 2026-10-30 · checked 2026-11-07 17:28 UTC

Tool changes

2026-10-30publish_gamechangeddescription, input schema
before
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). Send every file the game needs: an index.html at the root plus any JS/CSS/assets, paths relative to it. Text goes as utf8 content; images, audio and other binaries as base64 with encoding: "base64". 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). Re-run after every change: it replaces the hosted files and the link stays the same. Limits: 100 files, 5 MB in total. Give the user the url: anyone who opens it joins the same rooms. Nothing is listed publicly; only people with the link find it.
after · 56% of words in common
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.
2026-10-30create_uploadadded
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.
2026-10-30verify_login_tokenadded
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). Ask the user to paste a token from their running build (Wavedash: (await Wavedash.getUserJwt()).data in the browser console).
2026-10-30list_login_providersadded
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.
2026-10-30enable_login_provideradded
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: pass gameId = the gcid of the user's PRODUCTION game (ask them; or read it off a production token with verify_login_token); without it, tokens from any Wavedash game (incl. playtests) are accepted. google: clientId is required. Re-run to change the config (e.g. once the game id is known). Then verify with verify_login_token.
2026-10-30set_player_scopeadded
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.
2026-10-30set_highlight_webhookadded
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).
2026-10-30get_room_logsadded
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.
2026-10-30rollback_room_logicadded
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.
2026-10-30list_room_logicadded
Returns the deploy history (version, tickRate, bytes, deployedAt) for a room's authoritative logic, newest first.

Showing the latest 10. Full history: list_changes · trend: quality JSON.

Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed. How it is computed.

Trust 100 / 100

provenance100

liveness100

freshness100

hygiene100

+repository +namespace-matches-repo +dns-namespace +website +reachable +uptime-100% +updated-11d-ago

Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed. How it is computed.

Endpoints

remote	auth	reachable	uptime 30d	p50	protocol	last ok
`https://api.multiplayeragent.com/mcp?src=registry` streamable-http	none	yes	100%	426 ms	2025-11-25	2026-11-07

Tools (26)

`cancel_live_event`destructive	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.
`claim_studio`read-only	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.
`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.
`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.
`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.
`define_room_type`destructive	Create or replace the spec for a room (validation/types/defaults). Returns connection info. Omit fields entirely for a fully schemaless room.
`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.
`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: pass gameId = the gcid of the user's PRODUCTION game (ask them; or read it off a production token with verify_login_token); without it, tokens from any Wavedash game (incl. playtests) are accepted. google: clientId is required. Re-run to change the config (e.g. once the game id is known). Then verify with verify_login_token.
`get_client_snippet`read-only	Returns a complete single-file HTML game wired to this room: realtime movement plus an anonymous (claimable) player, a saved color (datastore), and a click leaderboard. Write it to disk and open it. The game it is wired to is stamped in a comment at the top of the file.
`get_connection_info`read-only	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.
`get_live_ops`read-only	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.
`get_room_logs`read-only	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.
`get_sdk_reference`read-only	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.
`list_games`read-only	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.
`list_login_providers`read-only	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.
`list_room_logic`read-only	Returns the deploy history (version, tickRate, bytes, deployedAt) for a room's authoritative logic, newest first.
`list_starters`read-only	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).
`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.
`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.
`rollback_room_logic`destructive	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.
`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).
`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.
`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).
`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.
`set_player_scope`destructive	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.
`verify_login_token`read-only	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). Ask the user to paste a token from their running build (Wavedash: (await Wavedash.getUserJwt()).data in the browser console).

Schemas: list_tools.

Similar MCP servers

Official server.json

{
  "name": "com.multiplayeragent/multiplayer-agent",
  "title": "Multiplayer Agent",
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "remotes": [
    {
      "url": "https://api.multiplayeragent.com/mcp?src=registry",
      "type": "streamable-http",
      "headers": [
        {
          "name": "Authorization",
          "isSecret": true,
          "description": "Optional. Bearer <secret key>: the studio secret key, starting sk_, from https://multiplayeragent.com/dashboard/key. Without it, the agent connects the session to an account through a browser sign-in, or builds in an unclaimed studio."
        }
      ]
    }
  ],
  "version": "1.0.2",
  "repository": {
    "url": "https://github.com/multiplayeragent/multiplayer-agent",
    "source": "github"
  },
  "websiteUrl": "https://multiplayeragent.com/mcp",
  "description": "Make any browser game multiplayer and host it at a share link. No account needed to start."
}