respond_to_drawAccept or decline a draw your human offered. This is your own real decision — weigh the actual position however you see fit.
| Name | Required | Description | Default |
|---|---|---|---|
| accept | Yes | ||
| game_id | Yes | ||
| agent_token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral details. It mentions that the decision is the agent's own and to weigh the position, but it fails to mention that accepting will end the game in a draw or that declining continues play. This is a significant omission for a state-changing 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?
The description is remarkably concise, packing the core functionality into a single clear sentence and a brief advisory statement. There is no wasted verbiage, and the front-loaded action is easy to parse.
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?
As a mutation tool with no annotations or output schema, the description needs to set expectations for what happens after the call. It does not explain the consequences of accepting or declining, error conditions, or prerequisites (e.g., a pending offer). The description is adequate for a simple boolean action but lacks the completeness expected for a state-changing 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?
The input schema has no descriptions, and the description does not elaborate on the parameters. It only hints at the 'accept' parameter through 'accept or decline', leaving game_id and agent_token unexplained. With 0% schema coverage, the description should have provided at least some guidance on these 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 clearly states the action (accept or decline) and the object (a draw offer from the human), using a specific verb. It naturally distinguishes from sibling tools like offer_draw, which would be for initiating a draw offer, by specifying that this is a response to an existing offer.
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 establishes the context: responding to a draw offer from the human opponent. It doesn't explicitly list alternatives or exclusions, but the wording implies this tool is only for when a draw has been offered, making the usage clear enough. A more explicit mention of not using this to initiate draws could have improved it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct action or resource: game lifecycle, board queries, move execution, chat/reactions, draw handling, and event waiting. The only near-neighbors — get_game_state vs get_legal_moves and offer_draw vs respond_to_draw — are clearly separated by their descriptions.
The set overwhelmingly follows a verb_noun snake_case pattern like create_game, get_game_state, and send_chat. Two single-word exceptions, heartbeat and resign, deviate slightly but remain clear and unlikely to cause confusion.
14 tools is well within the ideal range and each one covers a concrete need: setup, state, moves, communication, presence, and event handling. There are no redundant tools or filler entries.
The surface covers the full game lifecycle: create/join, legal moves, move execution, draw offer/response, resignation, and chat/reactions. The wait_for_event loop ties the asynchronous experience together, and get_game_state includes move and chat history, so no major gap is apparent.