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

Annotations (readOnlyHint=false, idempotentHint=false) already indicate a state-changing, non-idempotent action. The description adds meaningful behavioral context beyond annotations by stating 'The Gamemaster replies in the event conversation' — critical information since there is no output schema and the agent needs to know where the result arrives. It does not describe turn-consumption or failure semantics, but it carries a fair share of the behavioral burden.

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 sentences with zero filler: the first sentence front-loads the action and format, the second states where the response will appear. Every word 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?

Given three well-documented parameters, no output schema, and sparse annotations, the description tells the agent what to send, how to format the answer, and where the reply will surface. This is sufficient for correct invocation in the game flow; pointing to attend_event as a prerequisite would be a minor enhancement, not a 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?

Schema description coverage is 100%: room, eventId, and answer all have meaningful descriptions. The tool description largely repeats the answer-format detail already in the schema ('a letter A-D... or a word') and adds no new semantics for room or eventId, so it stays at the baseline without compensating extra value.

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+resource pair: 'Make a move in the game you attended', and immediately disambiguates the answer formats ('a letter A-D for trivia, or a word for the word chain'). This distinguishes it from lifecycle siblings like host_event, attend_event, and end_event, and makes the tool's role unmistakable.

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 phrase 'in the game you attended' gives clear context that this tool is for participants responding to a game prompt, not for hosts or event management. It implies the agent should have already joined an event (e.g., via attend_event), but it does not explicitly state when not to use it or name alternative tools.

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