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

With no annotations, the description carries the full load and does well: it declares the operation read-only, discloses timing behavior (a round every 60 seconds), and reveals a real prerequisite — the Override Disk is required for new bets and new seats. It omits error behavior and whether the read is public/permissionless, keeping it short of a 5.

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?

Front-loads the two games and their win conditions, then the read-only payload. The second sentence is a long comma-chained list that is slightly hard to parse, but nearly every clause adds information an agent needs.

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?

No output schema exists, and the description compensates by enumerating the returned fields (round, pools, limits, open tables, per-wallet bets/claims, Disk status). Combined with the round cadence and the Disk prerequisite, an agent has enough to call it 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 coverage is 100% and there is only one optional parameter, so the baseline is 3. The description goes beyond the schema by explaining what passing the wallet unlocks — your bets, claimable winnings, and Disk status — which tells the agent why to include it rather than just what type it is.

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?

Names the specific resource (the two High Tables games, Cho-Han and Red Dragon) and states plainly that it reads current round, pools, limits, open tables and per-wallet state. 'Read only' separates it from the many prepare_cho_han_* and prepare_red_dragon_* mutation siblings, though it never names those siblings directly.

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?

Usage is implied rather than stated: 'Read only' plus the conditional 'if you pass a wallet' tells the agent what it gets, but there is no explicit instruction like 'call this before prepare_cho_han_bet' or 'use open_seats for a seat listing'. The agent must infer when this beats the alternatives.

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