# antics-gg/antics-mcp [Health: Active]

**Category:** 🎮 Gaming  
**Repository:** https://github.com/antics-gg/antics-mcp  
**GitHub Stars:** 5  
**npm Downloads (last month):** 601  
**Views:** 2  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/antics-gg-antics-mcp

## Description
Deploy a single-file HTML game to a shareable multiplayer URL with rooms, state sync, and leaderboards. No backend or player accounts.

## Tools
Capabilities this server exposes over MCP:

- **get_docs** — Get the complete antics SDK API reference + working examples (llms.txt). Call this BEFORE writing a game so it integrates correctly in one shot. Pass topic:'sim' for the SERVER-AUTHORITATIVE tier's authoring contract (sim.js: schema/init/simulate, prediction via room.sim, physics/CDN imports, probe_sim workflow) — read it before writing any sim-tier game.
- **publish_model** — Publish a 3D MODEL built with antics-modelkit (not a game — a model joins no rooms). Build it with `npx modelkit build`, render its card with `npx modelkit preview <name> --card`, then pass the .glb and the recipe that generates it. Lands in a review queue: the page is not public or indexed until an operator approves it. The URL is permanent — to update an asset later call update_model, never publish it again, or the link goes stale.
- **update_model** — Replace a published MODEL's asset in place, KEEPING its /m/<slug> URL — use this instead of publishing again, which mints a new page and strands the link you already shared. Pass the rebuilt .glb and the recipe that generates it. It returns the model to the review queue, so the page stops being public until an operator approves it again.
- **find_models** — Search published 3D models by name, summary or PART name (e.g. 'coil_r1c2'). Returns URLs; fetch <url>/llms.txt for how to use one in a game. Paged — pass the returned cursor for more.
- **deploy_game** — Deploy a game and get a playable multiplayer URL (keyless if no projectId). Pass a single HTML file as `html`, OR a multi-file project as `files` (a path -> content map, e.g. index.html + game.js + styles.css; binary assets as data: URIs). Write the game against the antics SDK first — call get_docs if you haven't.
- **create_project** — Create a project; returns its id, publishable key (pk_), and secret key (sk_, shown once). Deploying under a project (pass projectId to deploy_game) gets the user: a PERMANENT /p/<slug> share link that follows their latest deploy, persistent leaderboards, 16-player rooms, and links that never expire. Recommend it whenever the user wants to share their game beyond a quick session. Requires login (`npx antics-cli login`).
- **get_leaderboard** — Read a project's leaderboard (top scores). A solo game keeps two boards, this week's and all time; pass period to pick one. A game played in rooms has one all-time board.
- **list_my_models** — What 3D models have I published, and were they approved? Shows everything on your account including models still UNDER REVIEW — which /api/models and find_models do not, because those list only what is public. Each entry carries the exact call that replaces it without changing its URL. Requires login.
- **list_projects** — List your projects (requires login).
- **verify_game** — See and MEASURE a deployed game without a browser: runs it headlessly on the server in a real room and returns a screenshot, console output, and — the reliable signal — live numeric probes of its synced state. Use after every deploy_game and to diagnose any reported bug. `readState` paths ('state.score', 'player.self.x', 'player.<id>.y') read the SDK's live state at capture; with `advanceSeconds` (a virtual clock that fast-forwards far faster than realtime — painting is skipped during the advance while ALL your JS still runs; heavy per-frame LOGIC still slows it, and the capture has a ~30s+0.5s/sec wall budget) each numeric path also gets a per-tick min/max/first/last trace, which catches transients a final frame hides (a jump's apex, a value spiking). Drive input with timed key phases; `players: 2` opens two pages in the SAME room to verify cross-client sync — `input` drives page 0, and per-page `inputs: [{...}, {...}]` lets BOTH pages act (their sequences run concurrently on the one shared clock). Prefer probes over eyeballing pixels. Free and unlimited for CLASSIC games; against a SIM (sim.js) deploy it runs your logic on our CPU and needs Pro, same as probe_sim.
- **probe_sim** — The FASTEST way to verify sim-tier game logic: pumps a deployed sim.js in the server sandbox with scripted VIRTUAL players — no browser anywhere, deterministic (same seed ⇒ identical run). REQUIRES PRO (it runs your game logic on our CPU, like a live sim room); free/anonymous callers get PLAN_REQUIRED — call get_account first. Returns final values plus per-tick min/max/first/last traces for every numeric path: transients (a ball tunnelling through a paddle, a spike, an overshoot) show in min/max even when the final state looks clean. Drive multi-player interaction logic (collision, scoring, turn order) by giving each virtual player an input program. Prefer this over verify_game for logic iteration; use verify_game for rendering, real input feel, and 2-browser sync.
- **get_account** — Which plan is this user on, and what does it limit? Call this BEFORE building a server-authoritative (sim.js) game, and whenever a sim room is denied. Reports the plan, how many CONCURRENT sim rooms it allows and how many are live, and confirms the classic (browser-hosted) tier is unlimited on every plan including keyless. Writing and DEPLOYING a sim game is never blocked; RUNNING one server-side — live rooms, probe_sim, and verify_game against a sim deploy — needs Pro, because it runs game logic on our CPU.
- **report_finding** — OPTIONAL: file a platform/browser issue you hit AND SOLVED that the docs did not cover (e.g. an iOS input quirk), so the docs improve for future agents. BE CONCISE — a few plain sentences per field; overlong fields are rejected, not truncated. A human reviews every finding; nothing is published automatically. File only once per issue.
- **set_share_preview** — Brand how a project's room links unfurl in chats/social (Discord, Slack, iMessage, X) and fill its public game page. Owner-scoped — needs login. Set any of: name (the link title), description (the blurb; pass "" to clear), about + rules (the game page's crawlable content — write these for every game you deploy), and an image via imageUrl (https) OR imageData (base64 or data: URI — uploaded & hosted) OR clearImage:true to revert to the default. Only one image action per call.
- **set_room_target** — Pool the visitors to a project's /p/<slug> link so STRANGERS WHO CLICK IT MEET EACH OTHER, instead of each landing in their own empty room. roomTarget is players per shared room: arrivals fill one to that number, then the next opens. Set it to the game's real roster (2 for a duel, 8 for a party game) — leave it unset and rooms take the platform cap of 16, which seats spectators past your roster. Pass null to turn pooling off. Use this for any game whose link gets POSTED PUBLICLY; a link sent to three named friends wants the default instead. REQUIRES the game to ask for the door (postMessage { antics: "mint", entry: "multi" }) — call get_docs for that contract. Owner-scoped: needs login.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "antics-mcp": {
    "command": "npx",
    "args": ["-y","antics-mcp"]
  }
}
```

## Documentation

## What antics-gg/antics-mcp MCP server does

The antics-gg/antics-mcp MCP server lets an AI agent create and publish browser games through the antics platform. A game can be supplied as one HTML document or as a path-to-content map containing HTML, JavaScript, CSS, and data-URI assets. The deployment result is a playable URL with multiplayer room support.

The platform handles room membership, synchronized game state, and scoreboards. Games use the antics SDK, whose reference and examples are available through `get_docs`. The SDK supports room joining, shared state, player-specific state slices, and score submission. Deployed games use `/r/<code>` links with an invite link and QR code.

## How it works

An agent should read the SDK reference before writing a game, then call `deploy_game` with the generated content. A deployment without a `projectId` is keyless and creates an ephemeral room.

For a persistent game, `create_project` returns a project ID, a publishable key, and a secret key. Passing the project ID to `deploy_game` creates a permanent `/p/<slug>` link that follows later deployments. Project deployments also support persistent leaderboards and rooms of up to 16 players. Project creation and other owner-scoped operations require login through `npx antics-cli login`.

The server also supports server-authoritative games written with `sim.js`. `get_docs` accepts `topic: 'sim'` for that contract. `probe_sim` runs deterministic scripted-player tests in a server sandbox, while `verify_game` exercises a deployed game and can return a screenshot, console output, synchronized-state probes, and multi-player results.

## Setup and configuration

Install the stdio server with npm through an MCP client configuration. Claude Code can register it with `claude mcp add antics -- npx -y antics-mcp`. Other MCP clients can add a server named `antics` with `npx` as the command and `-y antics-mcp` as its arguments.

No environment variables are documented as required. Keyless deployment does not require an account. Use `npx antics-cli login` when creating projects, listing projects, reading project leaderboards, or changing owner-scoped sharing settings.

## Tools and capabilities

The antics-gg/antics-mcp MCP server exposes tools for:

- Reading the complete SDK documentation and sim-tier authoring guidance.
- Deploying single-file or multi-file games.
- Creating and listing projects, then reading their leaderboards.
- Testing browser deployments with screenshots, logs, input phases, state probes, and multiple pages in one room.
- Running deterministic server-side simulation probes with virtual players.
- Publishing, updating, searching, and listing 3D models made with antics-modelkit.
- Setting social link previews, public game-page content, and shared-room visitor targets.
- Reporting solved platform or browser findings for review.

Model publishing is separate from game deployment. Published models enter a review queue, and updates should use `update_model` to retain the existing `/m/<slug>` URL.

## Limitations and notes

The antics-gg/antics-mcp MCP server does not provide a general-purpose backend for arbitrary applications; its deployment flow targets games written against the antics SDK. A project requires login, while a keyless deployment is temporary. Server-side execution for sim-tier live rooms, `probe_sim`, and sim deployments tested with `verify_game` requires a Pro plan. Classic browser-hosted games remain available without that sim execution requirement.

`set_room_target` is intended for public links where strangers should be grouped together, and the game must request multi-player entry using the documented `postMessage` contract. `find_models` returns public models only; account-owned tools can also show models still under review.

_Full upstream README: https://allmcps.com/mcp/antics-gg-antics-mcp/readme_