Discover playable browser experiences and manage creator-owned game uploads on Arcade.fun.
Scored across 8 tools
Each tool maps to a distinct resource or action: creation, status inspection, public listing, asset setting, versioning, and build upload. The only mild overlaps are create_experience vs. start_version (both 'open something new') and set_cover/set_entry/set_trailer, but the descriptions clearly separate drafts, version slots, and individual asset types.
Seven of eight names follow a clean snake_case verb_noun pattern (create_experience, set_cover, upload_build, start_version, list_experiences). experience_status breaks the pattern by dropping the verb, but it is still readable and unambiguous.
Eight tools is well within the sweet spot and each one earns its place in the publish pipeline. Nothing feels padded or missing at the tool-count level.
The create → build → review → publish lifecycle is well covered, including per-asset setters. However there is no way to list your own drafts or unapproved experiences, no update for experience metadata, and no delete/unpublish or version-removal operation, leaving a few dead ends.
Register a new experience and get its manage key. Returns game, key and the first version id. The key is shown only here and controls the listing forever — save it. This creates a draft; upload_build is what sends it for review.
| Name | Required | Description | Default |
|---|---|---|---|
| how | No | How to take part: the controls and how to begin. | |
| kind | No | 'sdk' if the entry page calls arcade.ready(), otherwise 'web'. Detected from the build too. | |
| Yes | Reviewer contact address. Players never see it. | ||
| terms | Yes | Confirm you agree to the arcade.fun terms and community guidelines. | |
| title | Yes | What the experience is called, 2 to 60 characters. | |
| aspect | No | Shape on screen. Empty fills the screen. | |
| author | Yes | The creator name players see, 2 to 30 characters. | |
| inputs | Yes | How people interact. At least one. | |
| rights | Yes | Confirm the experience is yours to share, including its art, music and code. | |
| wallet | Yes | Solana address that receives this listing's creator trading fees. Every public listing launches with its own coin. | |
| devices | No | Devices actually tested. Mobile requires touch, voice or camera among inputs. | |
| tagline | No | One line for the cabinet. | |
| releaseNotes | No | Public changelog notes, shown only after this build is approved. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, it discloses that the returned manage key is shown only once and controls the listing forever, and that the call creates a draft rather than submitting for review. This is important behavioral context for a mutation tool; annotations already cover non-readonly/non-destructive status, though auth/rate-limit behavior is not described.
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?
Four short sentences, front-loaded with the action and return values, then the critical key warning, then the draft-vs-review distinction. Every sentence contributes necessary selection or handling information.
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 13-parameter mutation with no output schema, the description supplies the key return fields and warns about the one-time manage key, while the fully described schema covers parameter details. It is largely complete, though it omits failure/permission behavior and other sibling context.
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 itself documents all 13 parameters including enums and nested releaseNotes. The description adds return-value context but no additional parameter semantics beyond what the schema provides, so baseline 3 applies.
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?
The description uses a specific verb and resource ('Register a new experience') and states the concrete outputs ('game, key and the first version id'). It also differentiates the draft-creation step from 'upload_build', so an agent can distinguish it from that sibling without opening 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?
It clearly says this creates a draft and that 'upload_build is what sends it for review', giving an explicit alternative and condition. It does not cover other siblings such as start_version or list_experiences, so it stops 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.
Where an experience stands: its details, its coin plan, any note from the reviewers, and every version with its status.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| game | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful output context by enumerating what is returned (coin plan, reviewer notes, version statuses), which goes beyond the annotations, but it says nothing about permissions, error behavior, or whether all versions are always included.
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?
A single front-loaded sentence that lists the returned data with no filler. It is efficient and appropriately sized for a simple read tool, though the leading clause 'Where an experience stands' is less informative than the list that follows.
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 helpfully enumerates the returned content, which is the main completeness win. But it leaves the two required parameters entirely unexplained, a significant gap for an agent trying to call the tool correctly, even though the tool's complexity is low.
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 0%: both required parameters 'game' and 'key' have no descriptions in the schema, and the description never mentions them or explains what identifies an experience. The description completely fails to compensate for the undocumented parameters.
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?
The description conveys that this returns an experience's status and associated data ('details, its coin plan, any note from the reviewers, and every version with its status'), so the resource is identifiable. However, 'Where an experience stands' is a vague noun phrase rather than a clear verb+resource statement, and it never explicitly distinguishes this read operation from siblings like list_experiences or create_experience.
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?
There is no statement of when to use this tool versus alternatives. With siblings including list_experiences (for listing) and create_experience, an agent might reasonably wonder whether this or list_experiences is the right call for inspecting an experience, and the description offers no routing guidance or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every approved experience currently playable on arcade.fun, with the origin games are served from. Needs no credentials.
| 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 the safety profile is covered. The description adds that no credentials are needed, which is useful behavioral context, and it indicates the returned origin information. It does not cover rate limits, ordering, or other return details, so it adds moderate value beyond annotations.
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?
The description is a single concise sentence with no wasted words. However, the phrase 'with the origin games are served from' is grammatically awkward and slightly reduces clarity, preventing a perfect score.
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 zero-parameter, read-only list tool with annotations covering safety, the description is largely complete: it states what is returned and that credentials are not required. It could mention ordering or return structure, but with no output schema and a simple contract, this is a minor gap.
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?
The tool takes zero parameters, so schema coverage is 100% and there is no parameter semantics to explain. A baseline of 4 is appropriate because the description does not need to compensate for any parameter documentation gaps.
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?
The description clearly states that it lists every approved experience currently playable on arcade.fun, including the origin games are served from. The verb 'list' is implied by the title and the read-only nature, and it is easily distinguishable from mutation-oriented siblings like create_experience or upload_build. However, it does not explicitly name sibling tools, so it stops short of 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?
The description provides no explicit guidance on when to use this tool versus alternatives such as experience_status. It only notes 'Needs no credentials,' which is a behavioral detail rather than a usage condition. There is no when-not-to-use or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload the square cover used for the cabinet, the sharing card and the coin image. PNG, JPEG, WebP or GIF up to 4 MB.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| game | Yes | ||
| image_base64 | Yes | The image, base64 encoded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the write/replace semantics are largely covered. The description adds real value with the accepted formats and the 4 MB ceiling, but does not say whether a non-square image is rejected or cropped, or whether an existing cover is replaced.
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 with no filler. The purpose and the usage surfaces come first, then the hard constraints, which is exactly the information an agent needs up front.
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 three-required-parameter mutation with no output schema, the description covers the payload constraints well but not the identifiers it requires (game, key) or the replacement behavior for an existing cover. It is adequate rather than complete.
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 only 33%: image_base64 is documented, but game and key are bare strings with no explanation anywhere. The description adds constraint detail for the image (PNG, JPEG, WebP, GIF, 4 MB) that goes beyond the schema, but leaves the two other required parameters completely unexplained.
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?
The description pairs a specific verb (upload) with a specific resource (the square cover) and enumerates the surfaces it feeds (cabinet, sharing card, coin image). That distinguishes it from the image-related siblings set_entry and set_trailer, though it never names those siblings directly.
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 implied: this is the tool for the cover image, as opposed to entries or trailers. There is no explicit statement of when to use it versus set_entry/set_trailer, and no prerequisites such as the game needing to exist first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Name the page that starts the experience, when a zip had several and no index.html.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| entry | Yes | A path the upload result offered, e.g. game/play.html. | |
| version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation is non-read-only, idempotent, and non-destructive. The description adds the zip-related condition but does not explain what setting the entry affects (e.g., which version/page users see) or what happens when the provided path is invalid. With annotations covering the safety profile, a 3 reflects adequate but limited extra behavioral context.
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?
The description is a single, front-loaded sentence with no wasted words. The key condition for use is stated immediately and nothing is repeated unnecessarily.
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 mutation tool with three parameters, no output schema, and low schema description coverage, the description is too thin. It omits important context such as the role of 'version' and 'key', what happens if 'entry' is not one of the offered paths, and how this affects the experience. Annotations cover safety but not the operational details an agent needs.
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 only 33%, and only the 'entry' parameter is documented in the schema. The description adds no information about 'key' or 'version', nor does it clarify how 'entry' relates to the paths offered by the upload result. With low coverage, the description should compensate but does not.
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?
The description states a specific action (naming the start page) and ties it to the experience entry point, which distinguishes it from siblings like set_cover and set_trailer. The condition 'when a zip had several and no index.html' further narrows its purpose. It is clear, though the verb 'name' is slightly less direct than 'set'.
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 gives an explicit precondition: use this when the uploaded zip had several pages and no index.html. This tells the agent when the tool is relevant, and implicitly when it is not needed. It does not name an alternative tool, but the condition is specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload the MP4 played when the experience's link is shared. Without one the platform builds an animated title card from the cover instead.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| game | Yes | ||
| video_base64 | Yes | The MP4, base64 encoded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare write (readOnlyHint=false), non-destructive, and idempotent, and the description adds genuine context by explaining what happens when no trailer exists (an animated title card is built from the cover). It does not disclose whether an uploaded trailer replaces an existing one, any size/duration/encoding limits, or permission requirements — notable gaps for an upload tool.
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 short sentences, front-loaded with the action and followed by the fallback behavior, with no filler. Slightly under-informative rather than bloated.
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 three-required-parameter upload tool with no output schema, the description covers purpose and default behavior but omits replacement semantics, constraints on the video itself, and what is returned after upload. With annotations covering the safety profile, this is adequate but not complete.
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 only 33%: video_base64 is documented in the schema, while game and key are undocumented anywhere. The description partially compensates by explaining what the MP4 is for (the shared-link playback video), but adds nothing about how game and key select the target experience.
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?
The description pairs a specific verb (upload) with a specific resource (the MP4 that plays when the experience's link is shared), which tells an agent exactly what asset this tool controls. It is distinguishable from set_cover because it names the cover only as the fallback, though it never uses the word 'trailer' that the tool name implies, leaving the mapping slightly implicit.
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 fallback sentence implies when to use it (when you want a real video rather than the auto-generated title card), but no explicit when-to-use, when-not-to-use, or alternative is named. There is no guidance on prerequisites such as whether the experience must exist first or how game/key identify the target.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a new version slot for an experience you already own. The live approved version keeps playing until the new one is reviewed.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | That game's manage key. | |
| game | Yes | The 12-character game id. | |
| releaseNotes | No | Public changelog notes, shown only after this build is approved. |
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 operation. The description adds genuinely useful state semantics beyond that: the currently approved live version keeps playing until the new one is reviewed, which tells the agent this call does not disrupt production.
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 short sentences with no waste. The action is front-loaded and the behavioral caveat follows immediately, so an agent can scan it in one pass.
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, a fully documented 3-parameter schema, and annotations covering the safety profile, the description is nearly complete. Minor gap: it does not say what the call returns (e.g., a version identifier) or that upload_build is the expected next step.
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%, including the nested releaseNotes object with its own field constraints, so the schema carries the parameter burden. The description adds no meaning about game id, manage key, or when release notes should be supplied, so the baseline 3 applies.
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: 'Open a new version slot for an experience you already own.' The phrase 'an experience you already own' implicitly separates it from create_experience, but the distinction is never made explicit by naming the sibling.
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 prerequisite ('an experience you already own') is implied as a usage condition, but there is no explicit when-to-use guidance and no mention of the natural follow-up siblings such as upload_build or experience_status. Usage has to be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send the browser build for a version and publish it. One HTML file, or a zip with index.html at its root. A build that passes the sandbox checks goes live immediately: the result has live: true and the play URL. Otherwise live: false and waiting says why, either a list of things to fix or that this arcade reviews that upload by hand. Also returns file count, size, engine and whether the arcade SDK was detected. If the zip has several pages and no index.html, the result asks which page starts it — answer with set_entry.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The game's manage key. | |
| entry | No | Start page inside a zip, if it is not index.html. | |
| threads | No | True if the build needs SharedArrayBuffer. Threaded builds open in their own tab and cannot use the SDK bridge. Omit to work it out from the files. | |
| version | Yes | Version id from create_experience or start_version. | |
| filename | Yes | The file's name, so the type is read correctly: e.g. index.html or build.zip. | |
| content_base64 | Yes | The .html or .zip file, base64 encoded. Up to 24 MB decoded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by describing the branching outcomes: a passing build goes live immediately with `live: true` and a play URL, a failing one returns `live: false` with `waiting` reasons, and some uploads are held for manual arcade review. It also discloses the extra returned metadata (file count, size, engine, SDK detection) and the no-index zip fallback flow. The only undisclosed trait is re-upload/idempotency behavior, which is minor.
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 core action and accepted formats, then details the result branches. Five sentences is on the long side, but each conveys actionable information about outcomes rather than restating the schema.
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 thoroughly: live flag, play URL, waiting reasons, review queue, and file metadata. Combined with the fully documented input schema, an agent has everything needed to call it and interpret the response.
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 all six parameters are already documented, including entry, threads, and the 24 MB limit. The description adds only a little beyond that — the notion that a no-index zip triggers a prompt answered via set_entry, which relates to the `entry` parameter. Baseline 3 is appropriate since the schema carries the load.
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 — send the browser build for a version and publish it — plus the accepted formats (single HTML or zip with index.html at root). It is clearly distinguishable from siblings like set_entry, set_cover, and create_experience.
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?
Explains the preconditions implicitly by naming the enclosing flow (version from create_experience or start_version in the schema) and routes the agent to set_entry when the zip lacks an index.html. It stops short of stating explicit exclusions or when another tool should be preferred for the initial upload.
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.
create_experience1 field changedInput schema / properties / releaseNotesAdded value: +{
+ "additionalProperties": false,
+ "description": "Public changelog notes, shown only after this build is approved.",
+ "properties": {
+ "changes": {
+ "items": {
+ "maxLength": 240,
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 12,
+ "minItems": 1,
+ "type": "array"
+ },
+ "title": {
+ "maxLength": 80,
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "changes"
+ ],
+ "type": "object"
+}start_version1 field changedInput schema / properties / releaseNotesAdded value: +{
+ "additionalProperties": false,
+ "description": "Public changelog notes, shown only after this build is approved.",
+ "properties": {
+ "changes": {
+ "items": {
+ "maxLength": 240,
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 12,
+ "minItems": 1,
+ "type": "array"
+ },
+ "title": {
+ "maxLength": 80,
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "changes"
+ ],
+ "type": "object"
+}create_experienceexperience_statuslist_experiencesset_coverset_entryset_trailerstart_versionupload_buildFind and play free games made by creators on Remix: puzzle, arcade, racing, sports and more.
Build, publish and update browser games with saves, leaderboards and realtime multiplayer built in.
Search Foundplay's directory of browser games: AI-made games, mashups and fan ports of classics.
Publish AI-made browser games and get a shareable URL. Update, test and read player feedback.
Add one secure layer between your agents and this server.
