ArcadeIndex

Play a game in the chat

play_game

Read-onlyIdempotent

Play an ArcadeIndex game right inside the chat. Pass game_id (an id, {slug}-{id}, or a game's url from search_games, trending, games_like or new_games results) or query (the top search hit is played; a game that only plays on its developer's site comes back as link_out). Hosts that support MCP Apps show a player with Next game and More like this (mode player); some chat apps do not allow the game frame, and then the player offers the game on arcadeindex.io in a new tab, so do not tell the user the game is running in the chat unless they say so. Games that cannot be framed here (listing-only, not checked in the last 8 days, or a site the chat app does not allow) return mode link_out with link_out.url and the reason: give the user that link. Hosts without MCP Apps get the same data as text: link play_url. Errors: NOT_FOUND, INVALID_ARGUMENT.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "play_game"
  }
}

Input Schema

Name	Required	Description	Default
`query`	No	Instead of game_id: a title or request; the top search_games hit is played.
`game_id`	No	A 6-char game id, the {slug}-{id} segment, or the game's ArcadeIndex page URL (from search results).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/idempotent annotations it discloses the two response modes (player vs link_out), the conditions producing link_out (listing-only, not checked in the last 8 days, disallowed site), the host capability dependency, and even a caution not to claim the game is running in chat. It also names the error codes NOT_FOUND and INVALID_ARGUMENT.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The key behavior is front-loaded, but the body is a dense run-on built from stacked parentheticals that takes effort to parse. Every clause carries information, yet the packaging makes it read as a wall of text rather than a structured set of rules.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a present output schema, the description need not explain return values, yet it still covers modes, host limitations, link_out handling, and error codes. An agent has everything needed to call this correctly and to relay the right result to the user.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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. The description restates the accepted formats ({slug}-{id}, URL, 6-char id) and the query-as-top-hit behavior, but adds little syntax or precedence detail beyond what the schema says. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Play an ArcadeIndex game right inside the chat') and immediately names the sibling tools (search_games, trending, games_like, new_games) whose output feeds it. An agent can distinguish this play tool from get_game or search_games without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states two calling paths (game_id vs query) with the rule 'the top search hit is played', and explains the fallback when a game cannot be framed. It does not explicitly say when to prefer get_game or random_game over this, but the play-vs-lookup distinction is clear from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All ArcadeIndex tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?