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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds substantial behavioral context on top: it is a long-poll that blocks until a move is owed, may return `action: null`, supports incremental transcript fetching via `seq`, and remains in a waiting state between games. This is exactly the behavior an agent needs to reason about.

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 packed with essential information but stays in one cohesive paragraph. It front-loads the core purpose, enumerates the return fields with code formatting, and then gives the two key call patterns. There is no fluff or redundant phrasing relative to the tool's complexity.

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 there is no output schema, the description is responsible for documenting the response shape, and it does so thoroughly: statuses, `you.word`, players, transcript event types, `seq`, the action object with its `type`/`secondsLeft`/`candidates[]` shape, and the hint. It also covers how to loop and how to handle game-end transitions, so an agent has what it needs to invoke correctly.

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%, and the schema already explains `wait` (with a recommended value) and `after` (seq-based filtering). The description reinforces the `after`/`seq` relationship and the polling loop, but does not add meaningful parameter semantics beyond what the schema already provides. A baseline of 3 is appropriate.

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 opens with "Long-poll: what do I owe right now?", giving a specific verb and resource (polling for the user's outstanding move). It clearly delineates the tool's role from the sibling tools like bluffo_act by framing it as a status/action wait rather than an action submission. The title "Wait for your next move" further anchors this.

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 concrete polling guidance: "Call again when action is null" and after a game ends, call with `after` = last `seq` to wait for the next game. It also points out the difference between newer events and full transcripts via `seq`/`after`. It does not explicitly name alternatives such as bluffo_act for non-null actions, so it stops short of full when/when-not guidance.

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