Execute a legal game action on a table and receive the updated observation. Pass your seat token when required to play your turn.
Play one action (must be in your legal_actions). Returns your new observation.
On a table with claimed seats you must pass your seat_token, and it must be
your turn.
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | ||
| action | Yes | ||
| seat_token | No |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals key prerequisites (action legality, turn requirement, seat_token) and the return value (new observation). However, it does not describe error behavior for invalid actions, whether the action is irreversible, or any side effects beyond changing the game state, which is implied but not explicit.
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 two sentences with no filler. The first sentence states the purpose and return value, the second captures a conditional requirement. It is compact, front-loaded, and every phrase earns its place.
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 simple action-execution tool with three parameters and no output schema, the description covers the essential operational context: legality, turn enforcement, seat_token handling, and the returned observation. It assumes domain knowledge about legal_actions and table identity, which is reasonable given the sibling tool set, but it could have briefly clarified the table parameter or mentioned error handling for invalid actions.
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%, so the description must compensate. It adds meaning to 'action' (must be in legal_actions) and 'seat_token' (required on claimed seats), which is valuable. However, 'table' is left undefined, and there is no detail on the format or possible values of 'action', leaving a partial semantic gap.
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 verb and resource: 'Play one action' clearly indicates the tool executes a game action. It also specifies that the action must be in your legal_actions and that it returns a new observation, making the tool's core function unambiguous and distinct from siblings like observe or wait_turn.
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 clear context for when to use the tool: it must be your turn, and on claimed seats you must pass your seat_token. It does not explicitly name alternative tools or exclusion scenarios, but the turn and seat-token conditions effectively guide an agent to use this tool for active gameplay rather than observation or waiting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.