Make any browser game multiplayer and host it at a share link. No account needed to start.
Scored across 10 tools
Most tools have clearly distinct purposes: game lifecycle, room definition, connection info, SDK reference, client snippet, publishing, and account claiming. The main possible confusion is claim_studio vs connect_account, since both relate to moving an unclaimed studio into an account, but their descriptions explicitly distinguish the deferred-link case from the active-session case.
All tool names use a consistent snake_case verb_noun pattern: claim_studio, connect_account, create_game, define_room_type, get_client_snippet, get_connection_info, get_sdk_reference, list_games, publish_game, set_game_name. No mixed casing or wildly different verb styles appear.
Ten tools is well-scoped for a multiplayer game platform MCP that covers account setup, game creation/listing/naming, room schemas, SDK/client scaffolding, and publishing. Each tool appears to earn its place without excessive overlap.
The surface covers the core build-and-publish lifecycle: account claiming, game creation, room type definition, connection/reference/snippet retrieval, listing, naming, and publishing. Minor gaps exist around destructive or update operations such as deleting a game or removing a room type, but most agent workflows can proceed.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond readOnlyHint/openWorldHint by disclosing what is returned (claim link, expiry, already-claimed flag) and what the link actually does for the user ('a free sign-up or log-in that moves the studio's games into their own account'). That is the key behavioral fact an agent needs to explain or hand off the link.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the premise and then the return payload, then the sibling routing. The parenthetical explaining sign-up/log-in is slightly long but carries real meaning, so only minor trimming is possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by naming the three return fields and their meaning, plus the prerequisite state (unclaimed studio with no account). Nothing an agent needs in order to call it or act on the result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so there is nothing to disambiguate; baseline 4 applies. The description correctly does not waste space on parameter talk.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Returns the claim link' for an 'unclaimed studio') and explains the underlying model in one clause ('This connection has no account: it builds into an unclaimed studio'). An agent can distinguish this from connect_account purely from the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes between alternatives: 'connect_account is the better way to keep the games when the user is here... the claim link is for later, or for someone else.' Both the use case and the exclusion are named, with the reason (session keeps working as their account).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| No | The user's email, to prefill the sign-in page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the annotations: returns a one-time url plus a matching code, the link expires in 10 minutes, the session's identity changes afterwards, and previously built games migrate in. That is exactly the side-effect context an agent needs, and it is consistent with readOnlyHint=false and destructiveHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is dense but nearly every clause is actionable (who does what, expiration, security rule), and the purpose is front-loaded in the first sentence. The procedural steps in the middle could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-param, no-output-schema tool, the description covers return shape (url + code), lifetime, required user interaction, and the post-call state change. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage the baseline is 3, but the description adds real meaning: the email is optional prefill that should be collected from the user *first* as part of the flow, which the schema field text alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — connect a keyless session to the user's own account — and anchors it with the `gh auth login` analogy, which immediately tells an agent how this differs from siblings like get_connection_info or claim_studio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear ordered procedure (ask for email, open url, relay code, user presses Connect) and a hard rule (never ask for a password in chat). It lacks an explicit 'use this only when the session is keyless / prefer get_connection_info if already linked' exclusion, so it falls short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | A human label for the game, e.g. 'N0RT arena'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-read-only, non-destructive, non-idempotent, closed-world operation. The description adds genuine context beyond that: the key relationship (publishable key derived from studio secret key), the exact return payload (publishableKey + wsEndpoint), and how to consume it. It does not warn that repeated calls mint additional distinct games, which is the main behavioral risk given idempotentHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the first defines the operation and its output, the second tells the agent what to do next. No filler, and the core definition is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-optional-param, no-output-schema tool, the description covers operation, auth model, and return values adequately. It leaves minor gaps: whether 'label' has a default, and whether a studio must exist before calling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single optional 'label' parameter is already documented in-schema with an example. The description mentions no parameters at all, so the schema does all the work — this is the baseline case rather than a value-add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource ('Mint a new game') with an immediate gloss that resolves ambiguity: a game is a publishable key issued under the studio's secret key. That definition alone separates it from siblings like list_games, publish_game, and set_game_name, which operate on existing games.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what to do *after* creation — point a client at the key or scope the MCP via the x-mp-game header — which implies when this tool is useful. However, it never states when to prefer create_game over publish_game or claim_studio, nor does it mention prerequisites such as needing an existing studio.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or replace the spec for a room (validation/types/defaults). Returns connection info. Omit fields entirely for a fully schemaless room.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game. | |
| spec | Yes | The room schema: name, optional maxClients, entities.players.fields, shared.fields. | |
| roomName | Yes | Unique room name under your key, e.g. 'dots-arena'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true; the description's 'Create or replace' corroborates rather than contradicts those hints, and adds that the call returns connection info. It stops short of warning that an existing spec is overwritten and what is lost on replace, which is the key behavioral fact for a destructive upsert.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with zero filler: operation, return value, and the schemaless edge case are each stated once and front-loaded. Nothing repeats the title or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully discloses the return ('connection info'), and it covers the schemaless case for a deeply nested spec object. The remaining gap is replace semantics — what happens to an existing room's state when the spec is overwritten — for a tool explicitly flagged destructive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description earns a bump by explaining that spec fields can be omitted entirely to produce a fully schemaless room — a non-obvious semantic given the nested required 'fields' objects. It does not address the game selector parameter, but the schema already documents that fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Create or replace the spec for a room') and clarifies the spec's role (validation/types/defaults), which is more precise than the title's 'multiplayer room type'. It does not explicitly differentiate itself from siblings like create_game or publish_game, which is the only thing keeping it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Create or replace' implies upsert semantics, so an agent can infer this is safe to re-run, and the final sentence gives one concrete usage condition (omit fields for a schemaless room). There is no explicit when-to-use-this-vs-alternative guidance (e.g., relative to create_game or publish_game), leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | 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 | Yes | The room name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false; the description adds the non-obvious fact that the tool does not write the file itself ('Write it to disk and open it') and that the binding target is stamped in a header comment, which helps the agent verify wiring. It does not state whether the snippet is deterministic across calls or how large the output is, which would be useful for token budgeting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the deliverable and its contents, followed by the action ('write it to disk and open it') and a helpful verification detail. No filler, though the final comment sentence could be folded into the first without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the return-value burden and does so well by describing the artifact's shape, its features, and how to confirm which game it was stamped against. For a two-parameter read-only fetch, nothing an agent needs in order to use the result correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters (game, roomName) are documented including the header/primary-game fallback chain. The description adds nothing about parameters, so baseline 3 applies – the schema carries this dimension entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Returns') and a well-scoped artifact: a complete single-file HTML game wired to the room, enumerating what's included (realtime movement, anonymous claimable player, datastore color, leaderboard). It is distinguishable from most siblings by resource type, but never contrasts with get_sdk_reference, the closest conceptual neighbor, so sibling differentiation is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Write it to disk and open it' implies the intended workflow, and the phrase 'wired to this room' implies the tool must be called after a room exists in the current game context. However, there is no explicit when-to-use guidance or instruction to prefer this over get_sdk_reference when the agent actually wants raw API documentation rather than a runnable file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | 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 | Yes | The room name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and closed-world behavior, but the description adds valuable context by listing the return fields, explaining adsPublisherId as a BYO Google Ads ID, and warning to verify the target game before shipping the key. It does not cover auth/permission requirements, but this is reasonable given the read-only annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, front-loaded with the returned fields. Each sentence earns its place: return shape, adsPublisherId detail, and the target verification warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description appropriately lists the main return fields and explains adsPublisherId. However, it mentions a returned target field that is not included in the enumerated return list, leaving a small inconsistency about the full response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented in the input schema. The description adds meaning around the returned adsPublisherId field but does not add further semantics for the game or roomName parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action and enumerates the returned fields (wsEndpoint, roomName, publishableKey, adsPublisherId) for wiring a client. It is clear on its own but does not explicitly distinguish itself from sibling tools like get_client_snippet or get_sdk_reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear usage context ("for wiring a client") and a caution to verify the returned target before shipping the key. It lacks explicit when-not guidance or named alternatives, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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), and durable shared MATCHES for asynchronous turn-based play. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description's job is added context — and it delivers the important consequence: snippets carry that game's publishable key inline, and 'shipping the wrong one silently pools your players into another game.' That failure mode is not derivable from annotations or schema. It does not hint at output size or token cost of a full markdown reference, which would matter for a large read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the verb and return type, then the coverage list, then the usage trigger, then the parameter warning. No filler sentences, and the highest-stakes detail (wrong key pools players) is placed last for emphasis. The coverage enumeration is dense but each item maps to a distinct SDK surface an agent might need.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one optional parameter and no output schema, the description appropriately characterizes the return as a full markdown reference and explains every surface it covers, so an agent knows what it will get. What's missing is guidance on output volume and whether the reference is meant to be read wholesale or section-by-section.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already explains the pk_/name resolution chain, so the baseline applies. The description still adds genuine meaning by explaining the stakes of the parameter — the wrong game key silently cross-pools players — which the schema does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'Returns the full SDK reference (markdown)' — and scopes it to ONE game's key/endpoints, then enumerates the covered surfaces (rooms, identity, datastore, leaderboards, UGC, matches). It implicitly separates itself from narrow siblings, but never names get_client_snippet or get_connection_info, which an agent could easily confuse with this broader reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear trigger condition: '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.' It also states when to supply the optional `game` argument (multi-game studios). It stops short of exclusions — e.g., when to prefer get_client_snippet or get_connection_info instead — so half the routing decision is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine context beyond that: the `primary` game is the fallback for unnamed calls, and the response identifies which game the current connection targets — non-obvious semantics an agent would otherwise have to discover empirically.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and resource, with the interpretive details (primary, connection target) following. No filler and nothing repeated from the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description covers the salient return contents: labels, per-game settings, primary designation, and connection target. Minor gaps remain — whether list ordering, archived games, or empty-studio behavior matters — but an agent can call this correctly with what is given.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so baseline is 4. The description correctly implies the tool is unfiltered and scoped to the current studio/connection, which is the only 'parameter-like' context that matters here, though it does not state whether archived or unpublished games appear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the games') plus a clarifying synonym ('publishable keys') and the owning scope ('under your studio'). It also describes what is returned conceptually (labels, per-game settings, primary marker), which separates it from create_game or publish_game without needing the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is the discovery step before create_game, set_game_name, or publish_game. There is no explicit 'use this when' statement and no exclusion naming a sibling such as get_connection_info, which overlaps on the 'current connection target' detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Host the game's files at a public share link, https://.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.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game. | |
| files | Yes | Every file of the game, including index.html. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already covering safety (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description still adds substantial non-structured context: re-publishing replaces all hosted files while the link/slug stays fixed, the 100-file / 5 MB limits, the key-ownership enforcement rule, and the visibility model ('nothing is listed publicly; only people with the link find it'). The one nuance is that a link open to anyone sits in slight tension with openWorldHint=false, but since the origin is platform-controlled this is a scope judgment, not a contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the outcome (the share URL) before mechanics, and nearly every sentence adds operational information: paths, encoding, key ownership, re-publish semantics, limits. It runs long and a few clauses ('paths relative to it', the parenthetical about how the server knows the build belongs) restate schema content and could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with no output schema this is close to complete: it covers inputs, the key-ownership precondition, size/count limits, idempotent replacement behavior, and post-action instructions (hand the URL to the user). The only omission is what the call returns on success or failure, which is a minor gap for a publish operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description earns above that by explaining the 'game' parameter's real semantics — it identifies which game the build belongs to and a mismatched key is actively refused — which the schema does not convey. It also restates the utf8/base64 split for 'encoding' and relative-path convention, but those largely duplicate existing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
A specific verb (host/publish) applied to a specific resource (the game's files) with the exact resulting artifact spelled out: a public share link at https://<slug>.play.multiplayeragent.com/. It is unmistakably distinct from siblings like create_game, set_game_name, or get_connection_info, so an agent can route here without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear situational guidance: send every file the game needs, re-run after every change, and give the user the URL. The prerequisite (files must carry this game's publishable key or the server refuses the build) is stated explicitly. What's missing is any explicit exclusion or named alternative — e.g. what to do before a game exists or how this relates to get_client_snippet — so it stops just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | 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 | Yes | Display name, e.g. 'N0RT Arena'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds real value on top: the target-resolution chain (argument → x-mp-game header → only game) and the explicit refusal behavior on ambiguity. It doesn't say whether an existing name is overwritten, though idempotentHint implies repeat calls are safe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the action and followed by rationale and edge-case behavior. Minor redundancy with the schema's `game` description, but nothing extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation tool with full schema coverage and annotations, the description covers purpose, trigger, targeting precedence, and the ambiguous-studio failure mode. With no output schema there is no return-value burden left unmet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents both the `game` fallback chain and the `name` format, so the description's restatement of the resolution order is reinforcement rather than new meaning. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Set a human-readable name for a game') and immediately clarifies what the name affects ('shows in your dashboard'). It is clearly distinct from siblings like create_game or list_games, which handle game lifecycle rather than naming.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call this when you start building so the game isn't unnamed' gives an explicit trigger for use, and 'Refuses to guess when the studio has several games and none was named' describes the failure condition. It doesn't mention create_game as an alternative place to set a name, but the usage context is otherwise clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
claim_studioconnect_accountcreate_gamedefine_room_typeget_client_snippetget_connection_infoget_sdk_referencelist_gamespublish_gameset_game_nameBuild, publish and update browser games with saves, leaderboards and realtime multiplayer built in.
Publish AI-made browser games and get a shareable URL. Update, test and read player feedback.
Publish, play-test and fix HTML5 browser games from your AI assistant. Own address, 70% ad share.
Publish, test and share browser games on PlayDrop from your AI agent.
Add one secure layer between your agents and this server.