Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

Multiplayer Agent

REMOTE · API.MULTIPLAYERAGENT.COM

Make any browser game multiplayer and host it at a share link. No account needed to start.

+3 this week 65 Trust /100

Last scanned (21 hours ago)

Scores higher than 45% of remote servers

Unreachable for 1 day in a row. Last reached 3 Nov 2026.

Category Entertainment and Games

Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →

Endpoint Security11
Transport & Reachability0
Schema Quality & AI Usability0
  • Schema not yet verified: we couldn't read the endpoint's schema, or could read only part of its tool list.Unverified
Stability & Change Management0
  • Stability not yet verified: not enough scan history yet (needs a 30-day window).Unverified
Tool Coverage0
  • Tool coverage not yet verified: we couldn't read the endpoint's tools, or could read only part of the list.Unverified
Tool Safety0
  • Tool safety not yet verified: we couldn't read the endpoint's tools, or could read only part of the list.Unverified
Capabilities0
  • Capabilities not yet verified: we couldn't read the endpoint's capabilities.Unverified

Unverified: 5 categories

Categories scored 0 because we could not verify them: authentication we do not have, an unreachable endpoint, or not enough scan history. We only credit what we can confirm.

Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 4 Nov 26 0
    • Endpoint reachability: reachable → unreachable ▼ security
    • Authorization: fail → unverified ▼ security
    • HSTS header: fail → unverified ▼ security
    • Tool safety: fail → unverified ▼ security
    • Stability: 0.27 → unverified ▼ security
    • TLS certificate: pass → unverified ▼ security
    • Transport: pass → fail ▼ security
    • Schema quality: 100 → unverified ▼ functional
    • Capabilities: pass → unverified ▼ functional
    • Tool coverage: 100 → unverified ▼ functional
  • 3 Nov 26 +1
    • The server rewrote its instructions, which are the text every model session reads security
    • New prompt “remix” functional
  • 31 Oct 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 13 to 17. That category is still filling its 30-day observation window: 4 days of observed history at the previous scan, 5 at this one. The score rises as the window fills, whether or not the server changes.

  • 30 Oct 26 +1
    • The server rewrote its instructions, which are the text every model session reads security
    • New tool “rollback_room_logic”, which the server declares destructive security
    • New tool “set_player_scope”, which the server declares destructive security
    • Tool “publish_game” rewrote its description, which is the text the model reads security
    • Schema quality: 384 → 318 ▲ functional
    • New tool “set_highlight_webhook” functional
    • New tool “create_upload” functional
    • New tool “deploy_room_logic” functional
    • New tool “enable_login_provider” functional
    • New tool “get_room_logs” functional
    • New tool “list_login_providers” functional
    • New tool “list_room_logic” functional
    • New tool “verify_login_token” functional
    • “publish_game” added an optional parameter “mode” cosmetic
    • “publish_game” added an optional parameter “remove” cosmetic
    • “publish_game” reworded the description of “files” cosmetic
  • 28 Oct 26 +1
    • The server rewrote its instructions, which are the text every model session reads security
    • New tool “cancel_live_event”, which the server declares destructive security
    • Tool “get_sdk_reference” rewrote its description, which is the text the model reads security
    • Schema quality: 495 → 384 ▲ functional
    • New prompt “plan-live-ops” functional
    • New tool “get_live_ops” functional
    • New tool “list_starters” functional
    • New tool “remix_game” functional
    • New tool “schedule_live_event” functional
    • New tool “set_live_config” functional
  • 27 Oct 26 0
    • Stability: unverified → 0.03 ▲ functional
  • 26 Oct 26 61

    First indexed and scored.

Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 4 Nov 2026 · Probed https://api.multiplayeragent.com/mcp?src=registry

TLS unreached
DNSSEC insecure

Validation of api.multiplayeragent.com. — Not signed

Zone DS Keys Algorithms Outcome
. trust_anchor 20326, 38696 8, 8 Verified
com. present 19718 13 Verified
multiplayeragent.com. absent Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation
Authentication Inconclusive

We could not reach the endpoint well enough to judge its authorisation posture.

Result Inconclusive

Background: How OAuth 2.1 works in the 2026 MCP spec →

Transports 2 probes
Transport URL Outcome Status Location
streamable-http https://api.multiplayeragent.com/mcp?src=registry Unreachable
http (plaintext) http://api.multiplayeragent.com/mcp?src=registry HTTPS enforced
MCP tools · 26 exposed · ~4,579 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
cancel_live_event ~125

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.

NameTypeReqDescription
gamestring–Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
idstringyesThe event id (see get_live_ops).

No output schema declared.

No examples provided.

claim_studio ~100

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.

Input schema present but exposes no named parameters.

No output schema declared.

No examples provided.

connect_account ~135

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.

NameTypeReqDescription
emailstring–The user's email, to prefill the sign-in page.

No output schema declared.

No examples provided.

create_game ~78

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.

NameTypeReqDescription
labelstring–A human label for the game, e.g. 'N0RT arena'.

No output schema declared.

No examples provided.

create_upload ~258

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.

NameTypeReqDescription
filesarrayyesThe files to upload.
gamestring–Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.

No output schema declared.

No examples provided.

define_room_type ~123

Create or replace the spec for a room (validation/types/defaults). Returns connection info. Omit fields entirely for a fully schemaless room.

NameTypeReqDescription
gamestring–Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
roomNamestringyesUnique room name under your key, e.g. 'dots-arena'.
specobjectyesThe room schema: name, optional maxClients, entities.players.fields, shared.fields.

No output schema declared.

No examples provided.

deploy_room_logic ~413

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.

NameTypeReqDescription
codestring–JS source defining onJoin/onLeave/onInput/onEvent/onTick over a global `state`. Or, for a long file, pass uploadId instead.
gamestring–Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
roomNamestringyesThe room name to make authoritative.
tickRateinteger–Server ticks per second (default 20).
uploadIdstring–Instead of code: the uploadId of a .js file you created with create_upload (for this game) and PUT with curl. For logic too long to send inline.

No output schema declared.

No examples provided.

enable_login_provider ~276

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.

NameTypeReqDescription
clientIdstring–google only: the OAuth client id (…apps.googleusercontent.com).
gamestring–Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
gameIdstring–wavedash only: the production Wavedash game id, pinned against the token's gcid claim.
providerstringyesWhich provider to enable.

No output schema declared.

No examples provided.

get_client_snippet ~121

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.

NameTypeReqDescription
gamestring–Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
roomNamestringyesThe room name.

No output schema declared.

No examples provided.

get_connection_info ~112

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.

NameTypeReqDescription
gamestring–Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
roomNamestringyesThe room name.

No output schema declared.

No examples provided.

get_live_ops ~188

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.

NameTypeReqDescription
atstring–ISO-8601 instant to preview (default now).
gamestring–Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
roomstring–Resolve for this room (events limited to other rooms drop out). Default: game-wide.

No output schema declared.

No examples provided.

get_room_logs ~111

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.

NameTypeReqDescription
gamestring–Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
limitinteger–Max log lines (default 50).
roomNamestringyesThe room name.

No output schema declared.

No examples provided.

get_sdk_reference ~188

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.

NameTypeReqDescription
gamestring–Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.

No output schema declared.

No examples provided.

list_games ~53

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.

Input schema present but exposes no named parameters.

No output schema declared.

No examples provided.

list_login_providers ~84

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.

NameTypeReqDescription
gamestring–Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.

No output schema declared.

No examples provided.

list_room_logic ~84

Returns the deploy history (version, tickRate, bytes, deployedAt) for a room's authoritative logic, newest first.

NameTypeReqDescription
gamestring–Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
roomNamestringyesThe room name.

No output schema declared.

No examples provided.

list_starters ~72

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

Input schema present but exposes no named parameters.

No output schema declared.

No examples provided.

publish_game ~436

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.

NameTypeReqDescription
filesarrayyesThe files: in replace mode every file of the game, including index.html; in patch mode just the ones to add or replace.
gamestring–Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
modestring–'replace' (default): these files become the whole game. 'patch': add or replace just these, keep everything else hosted.
removearray–Patch mode only: hosted paths to delete.

No output schema declared.

No examples provided.

remix_game ~184

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.

NameTypeReqDescription
gamestring–Reuse one of your games instead of making a new one (its pk_ or exact name): e.g. to fetch a fresh link after one expired.
labelstring–A name for the new game. Defaults to the starter's title.
starterstringyesThe starter's slug, from list_starters, e.g. 'slither-arena'.

No output schema declared.

No examples provided.

rollback_room_logic ~112

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.

NameTypeReqDescription
gamestring–Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
roomNamestringyesThe room name.
toVersioninteger–Version to restore (default: the previous version).

No output schema declared.

No examples provided.

schedule_live_event ~445

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

NameTypeReqDescription
configobject–Overrides deep-merged over the live config while the event runs (null deletes a key), e.g. { xpMultiplier: 2, rules: { lives: 1 } }.
descriptionstring–Player-facing blurb for an events window.
durationMinutesnumber–Length of each occurrence, instead of endsAt.
endsAtstring–ISO-8601 end. Or give durationMinutes. Neither = open-ended (until cancelled; not for repeating events).
gamestring–Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
idstring–Stable id (a-z, 0-9, - _). Defaults to a slug of the title. Scheduling an existing id EDITS that event.
repeatstring–Repeat the same window every day or week from startsAt (default none).
repeatUntilstring–ISO-8601: no occurrence starts at or after this. Omit = repeats forever.
roomsarray–Only these room names. Omit = every room of the game.
startsAtstring–ISO-8601 start, e.g. "2026-11-01T18:00:00Z", or "now" (the default).
titlestringyesPlayer-facing name, e.g. 'Double XP Weekend'.

No output schema declared.

No examples provided.

set_game_name ~128

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.

NameTypeReqDescription
gamestring–Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
namestringyesDisplay name, e.g. 'N0RT Arena'.

No output schema declared.

No examples provided.

set_highlight_webhook ~219

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

NameTypeReqDescription
gamestring–Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
url–yeshttps://discord.com/api/webhooks/… or https://hooks.slack.com/services/…, or null to clear.

No output schema declared.

No examples provided.

set_live_config ~180

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.

NameTypeReqDescription
configobjectyesJSON object to merge (or, with replace, to store).
gamestring–Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
replaceboolean–Replace the whole config instead of merging (default false).

No output schema declared.

No examples provided.

set_player_scope ~170

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.

NameTypeReqDescription
gamestring–Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
scopestringyes'account' = org-wide players; 'project' = per-game.

No output schema declared.

No examples provided.

verify_login_token ~184

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

NameTypeReqDescription
gamestring–Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
providerstringyesThe provider name, e.g. 'wavedash'.
tokenstringyesA real token from the provider's client SDK.

No output schema declared.

No examples provided.

Install

How do I install the Multiplayer Agent MCP server?

Multiplayer Agent is a hosted endpoint at https://api.multiplayeragent.com/mcp?src=registry, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

remote · api.multiplayeragent.com

# add to Claude Code
claude mcp add --transport http com-multiplayeragent-multiplayer-agent 'https://api.multiplayeragent.com/mcp?src=registry'
Common questions

What is the Multiplayer Agent MCP server?

Multiplayer Agent is an MCP server listed in the public MCP registry as com.multiplayeragent/multiplayer-agent. Make any browser game multiplayer and host it at a share link. No account needed to start. This page covers its hosted endpoint (https://api.multiplayeragent.com/mcp?src=registry).

Is the Multiplayer Agent MCP server safe to use?

Multiplayer Agent scores 65 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the Multiplayer Agent MCP server expose?

Multiplayer Agent exposes 26 tools: create_game, list_games, set_game_name, define_room_type, get_connection_info, and 21 more. Their descriptions and schemas cost roughly 4,579 tokens of context every time the server is loaded.

Does the Multiplayer Agent MCP server require authentication?

Its publisher declares no required credentials for Multiplayer Agent. We have not been able to confirm that against the live endpoint, and a server can require authorisation without declaring it here.

Is the Multiplayer Agent MCP server still maintained?

Multiplayer Agent is still listed in the MCP registry, though our most recent checks did not reach this channel. We last reached this channel on 3 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.