Any other MCP client

TipTap is a standard remote MCP server. If your tool can talk to one of those, it can build games here — this page is the reference rather than a walkthrough, because your client's UI is the part we cannot describe. If it has no MCP support at all, skip to the handoff route, which needs nothing from your tool but a finished file.

The endpoint

https://mcp.tiptapgames.com/mcp

Two things about it that catch clients out:

• Streamable HTTP only. Requests must offer both application/json and text/event-stream in Accept. A client that offers only one gets a 406, and there is no way around it from our side.
• That hostname, exactly. The tool endpoint checks the host it was reached on and answers 403 to anything else — including older addresses this service used to answer on, whose /health still responds happily. A working health check on a 403-ing endpoint means you have the wrong host.

Authenticating

Pick whichever your client supports. Both identify the same account and grant the same access; they differ only in how the credential gets there.

1. 1

   Sign-in, if your client speaks OAuth

   Point it at the endpoint with no credentials at all. The first call returns 401 with a WWW-Authenticate header naming our metadata document. A capable client follows that, registers itself, and sends you to a consent screen on tiptapgames.com; you sign in, approve once, and it is connected.

   Dynamic client registration is supported and rate-limited to five registrations per hour per address. We return the issuer identifier on the authorization response as RFC 9207 requires, so a strict client validating iss is satisfied. Refresh tokens rotate — reusing a rotated one revokes the whole grant, by design, so let your client store what it is given.

2. 2

   Agent Key, if it only sends static headers

   Mint one in Create → Agents & access and send it as either header below, replacing ttg_agent_YOUR_KEY_HERE with the real token.

   Standard form

   Authorization: Bearer ttg_agent_YOUR_KEY_HERE

   Alternative — raw token, no Bearer prefix

   X-TTG-Agent-Key: ttg_agent_YOUR_KEY_HERE

   The second exists for clients whose config only offers user-defined headers and no literal Authorization field. Use one or the other: a request carrying both with different values is rejected outright rather than one being silently preferred.

   Screenshot coming soon

   The Mint key dialog on TipTap's Agents & access page, showing a freshly minted key with its value obscured.

   /docs/agents/shared/mint-key.png

Discovery documents

An OAuth-capable client walks these itself — they are listed so you can check them by hand when it does not. All three answer without a credential.

All three hang off the service origin:

curl https://mcp.tiptapgames.com/health
curl https://mcp.tiptapgames.com/.well-known/oauth-authorization-server

The issuer in that metadata must match the origin you fetched it from. If your client complains about an issuer mismatch, you are talking to the service on a hostname it does not consider its own — see the endpoint note above.

The prompt

Once tools are listed, this is a first message that takes an agent from nothing to a submitted game. Adjust the server name if your client calls it something other than tiptap.

You are building a game for TipTap Games, a vertical feed of instantly playable web
games. You will do it through TipTap's MCP server, which is connected to this
session as `tiptap`.

The game I want: a one-thumb arcade game of your choosing — pick something simple you can finish well

Build it end to end, autonomously:

1. Call create_build_session with a title and a one-paragraph brief for that game.
   Use the session_id it returns for every call after this one.
2. Call get_game_specification, then get_sdk_documentation. Read both before you
   write any code — the SDK is how the game reports score and handles pause,
   resume, and the leaderboard, and none of it can be guessed.
3. Call list_categories so you can set a real category at submit. Unknown slugs
   are dropped silently. Browse list_cookbook_recipes for proven patterns — the
   recipes are written so that following one produces a game that validates.
4. Write ONE self-contained .html file:
   - Inline every byte of CSS and JavaScript. No external scripts, styles, or fonts.
   - No network at runtime — fetch, XMLHttpRequest, and WebSocket are blocked by CSP.
   - No cookies and no localStorage; the game runs on an opaque sandbox origin and
     they throw.
   - Assets as data: or blob: URLs only. 5 MB maximum.
   - Portrait-first: it is played inside a phone-shaped frame in a vertical feed.
5. Declare the achievements with set_game_achievements before you validate, so
   validation can cross-check them against the code.
6. Call upload_game_draft with the HTML, then validate_game_draft. Fix every issue
   with severity "error" and validate again — read each issue's suggestedFix.
   Warnings are advisory.
7. Set a cover with set_game_thumbnail: a raster data URL (PNG, JPEG, WebP, or GIF)
   of 512 KB or less. SVG is rejected, so rasterize first.
8. Call submit_game once validation returns passed: true, then get_build_status to
   confirm it reached the review queue.

Do not put an API key or any credential in the game file — the validator blocks any
upload containing one, and game HTML is public to every player.

Do not declare the game complete until validate_game_draft returns passed: true.

submit_game sends the game for review. It is not live until a human moderator
approves it, so tell me "submitted for review", never "published".

Tell me every tool call you make and what it returned. If a tool fails, show me the
full error including its `code` and `guidance` fields rather than working around it.

To name the game yourself, type your idea into the starter prompt card on /create and copy the version it writes. Note step 1 either way: the agent opens the build session itself with create_build_session, which is the only way a session is made.

No MCP support at all

You can still build with an agent — you just carry the file across yourself, and it costs one extra step.

1. 1.Give the agent tiptapgames.com/sdk-agents.md. It is one self-contained document with the sandbox constraints, the full SDK, a working template and a pre-flight checklist — written for a model to read rather than a person. If the agent will end up connected after all, hand it tiptapgames.com/llms-full.txt instead: the same spec plus the complete tool reference, the build workflow, the validation error codes and the cookbook.
2. 2.Ask for one self-contained HTML file: everything inlined, no network at runtime, no storage, under 5 MB, portrait-first.
3. 3.Paste or drop it at /create/upload. Same validator, same review queue — you get the same errors an agent would, and you can hand them back to it verbatim.