# Multiplayer Agent (remote · api.multiplayeragent.com)

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

- Trust score: 65/100 (medium)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-04

## Components

- remote · `api.multiplayeragent.com`: 65/100 (this document), [markdown](https://verifymcp.io/servers/com-multiplayeragent-multiplayer-agent/api-2.md), [page](https://verifymcp.io/servers/com-multiplayeragent-multiplayer-agent/api-2)

## Channel facts

- Endpoint: `https://api.multiplayeragent.com/mcp?src=registry`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.0.2`

## Trust breakdown

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. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-04.

- **Endpoint Security**: 11/100
  - TLS not yet verified: we couldn't open a connection to check the certificate.
  - Authorisation not yet verified: we couldn't confirm whether this endpoint requires it.
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS not yet verified: we couldn't read the response headers to check for it.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 0/100
  - Transport check failed: declared streamable-http, but we couldn't connect to verify it.
- **Schema Quality & AI Usability**: 0/100
  - Schema not yet verified: we couldn't read the endpoint's schema, or could read only part of its tool list.
- **Stability & Change Management**: 0/100
  - Stability not yet verified: not enough scan history yet (needs a 30-day window).
- **Tool Coverage**: 0/100
  - Tool coverage not yet verified: we couldn't read the endpoint's tools, or could read only part of the list.
- **Tool Safety**: 0/100
  - Tool safety not yet verified: we couldn't read the endpoint's tools, or could read only part of the list.
- **Capabilities**: 0/100
  - Capabilities not yet verified: we couldn't read the endpoint's capabilities.

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

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

### Claude

```bash
claude mcp add --transport http com-multiplayeragent-multiplayer-agent 'https://api.multiplayeragent.com/mcp?src=registry'
```

### Cursor

```json
{
  "mcpServers": {
    "com-multiplayeragent-multiplayer-agent": {
      "url": "https://api.multiplayeragent.com/mcp?src=registry"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "com-multiplayeragent-multiplayer-agent": {
      "type": "http",
      "url": "https://api.multiplayeragent.com/mcp?src=registry"
    }
  }
}
```

### Codex

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

### opencode

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

### OpenClaw

```bash
openclaw mcp add com-multiplayeragent-multiplayer-agent --url 'https://api.multiplayeragent.com/mcp?src=registry' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  com-multiplayeragent-multiplayer-agent:
    url: "https://api.multiplayeragent.com/mcp?src=registry"
```

### Netclaw

```json
{
  "McpServers": {
    "com-multiplayeragent-multiplayer-agent": {
      "Transport": "http",
      "Url": "https://api.multiplayeragent.com/mcp?src=registry"
    }
  }
}
```

### Vellum

```bash
assistant mcp add com-multiplayeragent-multiplayer-agent -t streamable-http -u 'https://api.multiplayeragent.com/mcp?src=registry'
```

### Other

```json
{
  "mcpServers": {
    "com-multiplayeragent-multiplayer-agent": {
      "type": "http",
      "url": "https://api.multiplayeragent.com/mcp?src=registry"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-04 (score 65, 0)

- [security regression] Endpoint reachability: reachable → unreachable
- [security regression] Authorization: fail → unverified
- [security regression] HSTS header: fail → unverified
- [security regression] Tool safety: fail → unverified
- [security regression] Stability: 0.27 → unverified
- [security regression] TLS certificate: pass → unverified
- [security regression] Transport: pass → fail
- [functional regression] Schema quality: 100 → unverified
- [functional regression] Capabilities: pass → unverified
- [functional regression] Tool coverage: 100 → unverified

### 2026-11-03 (score 65, +1)

- [security] The server rewrote its instructions, which are the text every model session reads
- [functional] New prompt “remix”

### 2026-10-31 (score 64, +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.

### 2026-10-30 (score 63, +1)

- [security] 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
- [functional improvement] 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”
- [cosmetic] “publish_game” added an optional parameter “mode”
- [cosmetic] “publish_game” added an optional parameter “remove”
- [cosmetic] “publish_game” reworded the description of “files”

### 2026-10-28 (score 62, +1)

- [security] 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
- [functional improvement] 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”

### 2026-10-27 (score 61, 0)

- [functional improvement] Stability: unverified → 0.03

### 2026-10-26 (score 61)

First indexed and scored.

## MCP tools (26)

### `create_game` (~78 tokens)

Create a new 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.

Input parameters:

- `label` (string): A human label for the game, e.g. 'N0RT arena'.

### `list_games` (~53 tokens)

List your 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.

### `set_game_name` (~128 tokens)

Name a game

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.

Input parameters:

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

### `define_room_type` (~123 tokens)

Define a multiplayer room type

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

Input parameters:

- `game` (string): Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
- `roomName` (string, required): Unique room name under your key, e.g. 'dots-arena'.
- `spec` (object, required): The room schema: name, optional maxClients, entities.players.fields, shared.fields.

### `get_connection_info` (~112 tokens)

Get connection info for a room

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.

Input parameters:

- `game` (string): Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
- `roomName` (string, required): The room name.

### `get_client_snippet` (~121 tokens)

Get a paste-ready client snippet

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.

Input parameters:

- `game` (string): Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
- `roomName` (string, required): The room name.

### `deploy_room_logic` (~413 tokens)

Deploy authoritative server 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.

Input parameters:

- `code` (string): JS source defining onJoin/onLeave/onInput/onEvent/onTick over a global `state`. Or, for a long file, pass uploadId instead.
- `game` (string): Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
- `roomName` (string, required): The room name to make authoritative.
- `tickRate` (integer): Server ticks per second (default 20).
- `uploadId` (string): 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.

### `list_room_logic` (~84 tokens)

List authoritative logic versions

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

Input parameters:

- `game` (string): Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
- `roomName` (string, required): The room name.

### `rollback_room_logic` (~112 tokens)

Roll back authoritative 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.

Input parameters:

- `game` (string): Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
- `roomName` (string, required): The room name.
- `toVersion` (integer): Version to restore (default: the previous version).

### `get_room_logs` (~111 tokens)

Get authoritative logic 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.

Input parameters:

- `game` (string): Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
- `limit` (integer): Max log lines (default 50).
- `roomName` (string, required): The room name.

### `get_live_ops` (~188 tokens)

Get a game's 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.

Input parameters:

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

### `set_live_config` (~180 tokens)

Set a game's 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.

Input parameters:

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

### `schedule_live_event` (~445 tokens)

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

Input parameters:

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

### `cancel_live_event` (~125 tokens)

Cancel a 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.

Input parameters:

- `game` (string): Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
- `id` (string, required): The event id (see get_live_ops).

### `set_highlight_webhook` (~219 tokens)

Post highlights to Discord or Slack

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

Input parameters:

- `game` (string): 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` (required): https://discord.com/api/webhooks/… or https://hooks.slack.com/services/…, or null to clear.

### `get_sdk_reference` (~188 tokens)

Get the 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.

Input parameters:

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

### `set_player_scope` (~170 tokens)

Set how players are scoped

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.

Input parameters:

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

### `enable_login_provider` (~276 tokens)

Enable a portal / federated login

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.

Input parameters:

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

### `list_login_providers` (~84 tokens)

List a game's 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.

Input parameters:

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

### `verify_login_token` (~184 tokens)

Dry-run a 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). Ask the user to paste a token from their running build (Wavedash: (await Wavedash.getUserJwt()).data in the browser console).

Input parameters:

- `game` (string): Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
- `provider` (string, required): The provider name, e.g. 'wavedash'.
- `token` (string, required): A real token from the provider's client SDK.

### `create_upload` (~258 tokens)

Get upload URLs for a game's files

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.

Input parameters:

- `files` (array, required): The files to upload.
- `game` (string): Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.

### `publish_game` (~436 tokens)

Host the game at a share link

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.

Input parameters:

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

### `list_starters` (~72 tokens)

List starter games

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

### `remix_game` (~184 tokens)

Start a new game from a starter

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.

Input parameters:

- `game` (string): 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.
- `label` (string): A name for the new game. Defaults to the starter's title.
- `starter` (string, required): The starter's slug, from list_starters, e.g. 'slither-arena'.

### `connect_account` (~135 tokens)

Connect this session to the user's 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.

Input parameters:

- `email` (string): The user's email, to prefill the sign-in page.

### `claim_studio` (~100 tokens)

Get the claim link for this unclaimed 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.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-multiplayeragent-multiplayer-agent/api-2#diagnostics

## Score history

- 2026-11-04: 65
- 2026-11-03: 65
- 2026-11-02: 64
- 2026-11-01: 64
- 2026-10-31: 64
- 2026-10-30: 63
- 2026-10-29: 62
- 2026-10-28: 62
- 2026-10-27: 61
- 2026-10-26: 61

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

## Links

- Remote endpoint: https://api.multiplayeragent.com/mcp?src=registry
- Repository: https://github.com/multiplayeragent/multiplayer-agent
- Website: https://multiplayeragent.com/mcp
- Changelog RSS feed: https://verifymcp.io/servers/com-multiplayeragent-multiplayer-agent/api-2.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-multiplayeragent-multiplayer-agent/api-2.json
- HTML version of this page: https://verifymcp.io/servers/com-multiplayeragent-multiplayer-agent/api-2