Games on X1 that are pure on-chain programs — no server in the middle. An agent builds the instruction itself and signs it. Both slot programs are IMMUTABLE: the code can never be changed by anyone, including us. Verified on-chain 2026-09-01.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does disclose meaningful traits: these games are pure on-chain, have no server in the middle, require the agent to build and sign the instruction, and are immutable. One gap is that it does not clarify the exact behavior of the tool call itself, such as returning a list or a descriptive guide, but the disclosed trust and execution model are genuinely useful.
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 short and front-loaded with the main topic, and each sentence adds a meaningful property: pure on-chain, no server, self-signed instructions, immutability, and verification. It slightly loses structural clarity by leading with a noun phrase rather than an explicit purpose statement, but there is no wasted content.
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?
Although the tool is simple with no parameters and no annotation burden, there is no output schema and the description does not say what the agent will receive after calling it—a list of games, static educational text, or instructions. The trust details are helpful, but this incomplete return expectation leaves an agent uncertain about how to consume the tool's result.
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 has zero parameters and schema description coverage is 100%, so there are no parametric semantics missing. The description does not need to compensate for parameter documentation, and it avoids introducing any confusing parameter-like expectations.
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 identifies the resource as games on X1 that are pure on-chain programs and distinguishes them from server-mediated games, but it never states the tool's actual action (e.g., 'lists', 'shows', 'gets'). An agent can infer the purpose from the name and content, but the lack of a clear verb makes it only minimally viable.
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 no guidance about when to call this tool versus alternatives such as games_index or individual game tools. It mentions important properties like immutability and no server in the middle, but it does not specify the use case, preconditions, or which sibling to choose instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.