Poker Bots All Stars

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

Annotations already declare readOnlyHint and openWorldHint, so 'Read-only' is redundant, but the description adds genuine value by disclosing the return shape (balance, cheapest buy-in, and the top-up page when short). That conditional 'when short' behavior is context the annotations cannot express, and no output schema exists to carry it.

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?

Three short sentences, front-loaded with what is shown, then when to call it, then what comes back. Nothing is padded and nothing is missing.

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 zero-parameter read tool with no output schema, the description covers purpose, invocation trigger, and return values, including the conditional top-up page. Nothing an agent needs in order to call it or interpret the result is absent.

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 tool takes zero parameters, which is the baseline-4 case. The description correctly says nothing about arguments and instead spends its words on behavior and return values.

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?

A specific verb and resource: show the user's chip balance plus the cheapest table's buy-in. That is clearly distinct from sibling tools like leaderboard, list_tables, or my_stars, and an agent can select it without opening the empty schema.

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?

Names two concrete triggers: a refused seat for lack of chips, or the user asking what they have. No alternatives or exclusions are stated, but the triggers are precise enough to route correctly in this toolset.

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

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

Beyond annotations (which only say it mutates, is open-world and non-destructive), the description discloses the refusal rule when a call's price rose unless `max_cost` covers it, that `max_cost` also caps any move, and exactly what comes back ('OK' with the move, then the next spot, or the end of the table). It does not address whether a submitted move can be withdrawn, but the critical failure mode is covered.

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 turn protocol, then the action/amount rules, then the return value — a sensible order for an agent. The line 'say and emote are optional flavour shown at the table' is mild redundancy against schema text but is the only wasted sentence.

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, so the description must describe the response — and it does, including the three possible outcomes. Combined with the turn precondition, amount convention and cost cap, an agent has everything needed 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%, so the baseline is 3, but the description earns extra credit with the worked numeric example (facing 100 with 0 in, raise to 300 means amount=300, not 200) that disambiguates the most error-prone field. The dual role of `max_cost` is restated, and `say`/`emote` are noted as optional flavour.

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?

States a specific verb-plus-resource: submit one turn's move and receive the next spot, so one turn equals one call. It explicitly separates itself from `wait_for_turn` and `view_table`, which are the only siblings with overlapping surface area.

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?

Gives an explicit precondition (only when a spot from `wait_for_turn` or `view_table` says it is your turn), an explicit when-not (while it is someone else's turn, call `wait_for_turn` instead), and the allowed-action constraint ('Pick an action the spot lists'). Nothing is left to inference.

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

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

Annotations already establish that this is a non-read-only, open-world, non-destructive operation. The description adds useful behavior beyond that: the star gets a random look, accounts have limited slots, and the result is a name and id ready for `join_table`. It does not explain failure behavior when slots are exhausted or any permission requirements.

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 three tight sentences with no wasted text. It front-loads the core action, then gives usage constraints and return-value context in a logical order.

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?

Although there is no output schema, the description explicitly states that it returns the new star's name and id, ready for `join_table`. Combined with the fully documented input schema and annotations, it gives an agent enough context to invoke the tool 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 fully documents `name`, `model`, `base`, and `archetype`, including enum meanings. The description only indirectly references randomization and does not add parameter-level meaning beyond the schema, so the 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 gives a specific verb and resource: create a new star, defined as a 3D poker character owned by the user. It clearly distinguishes the tool from `my_stars` and `join_table` by explaining its role in the account/table workflow.

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?

It explicitly says to use this only when `my_stars` shows none or the user asks for another, and it names the limited star-slot constraint. This gives an agent a direct condition for choosing this tool over checking existing stars.

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

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

Annotations already say this is a non-read-only, open-world, non-destructive operation, but the description adds important consequences: it consumes buy-in from the user's account, marks the star ready, and returns a live link plus seat/table details. It also discloses the already-seated behavior, all beyond what the annotations provide.

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 action is front-loaded, and the sentences are dense but useful: default selection, return payload, next step, and already-seated case. There is little wasted text.

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 mutation tool with no output schema, the description names the return payload (table, seat, live link), the account-cost behavior, and the follow-up call. It covers enough of the operational context for an agent to invoke 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 description coverage is 100%, and all three parameters already have inline descriptions, so the baseline is 3. The prose restates the `table_id` default behavior but does not add meaningful explanation for `min_open_seats` beyond the schema.

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?

States a specific action and resource: seat one of the user's stars at a live table and mark it ready. It also names relevant sibling tools (`wait_for_turn`, `leave_table`) and the already-seated condition, so an agent can distinguish it from adjacent actions.

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?

Explicitly covers the no-`table_id` case and the already-seated case, directing the agent to use `leave_table` first when moving. It also tells the agent what to do after joining: give the user the live link, then call `wait_for_turn`.

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

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

Annotations declare readOnlyHint=true, so safety is already covered; the description adds that the tool is 'public' and describes the return format (rank, account name, winnings per line, plus a link to the full board). It does not mention rate limits, tie-breaking, or whether the top ten is cached, leaving minor gaps beyond the annotation baseline.

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?

Three front-loaded sentences: purpose, usage/routing, then return behavior. No redundant or filler content; every clause 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 zero-parameter read-only tool with no output schema, the description supplies everything needed: ranking basis, return shape, public/read-only nature, and a link to the full board. Nothing an agent needs to call it correctly is missing.

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 tool takes zero parameters, so the baseline is 4. The description correctly implies no input is required, but there is nothing further to add about parameter semantics.

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?

States a specific verb+resource ('Show the top ten accounts ranked by total chip winnings across all their stars') with clear scope and ranking criterion. An agent can distinguish it from `account` and `my_stars` without inspecting schemas.

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?

Explicitly names when to use it ('how they rank or who is winning overall') and routes to the correct siblings otherwise: `account` for the user's own balance and `my_stars` for their characters. When-not and alternatives are both covered.

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

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

Annotations only declare the operation is non-read-only, non-destructive and open-world. The description goes well beyond that by disclosing the concrete outcomes: the seat reopens pre-start, the current hand is folded and the player removed before the next hand during play, and chips are returned to the user's account.

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 action is front-loaded in the first two words, followed by consequential detail in a compact sentence. It is slightly clause-dense but no sentence is wasted.

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?

Outcome and timing behavior are fully described, which matters for a state-changing, open-world tool with no annotations covering side effects. The only gap is the vague 'Returns what happened' — with no output schema, a hint about the result shape would help, but it is a minor omission for a zero-argument action.

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 schema has zero parameters, so there are no per-parameter semantics to explain and the baseline of 4 applies. The description correctly implies this is a no-argument action tool.

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?

States a specific verb and resource ('Leave your table') that directly names the counterpart of the sibling tool join_table. An agent can immediately distinguish this from joining or viewing a table.

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?

Explicitly covers the two live cases (before the table starts vs. during play) and states an exclusion: 'Not needed when a table ends: the seat is released by itself.' That is an explicit when-not-to-use rule, which is rare and valuable.

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

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

Beyond the readOnlyHint annotation, the description discloses the return shape: one line per open table with name, open agent seats, blinds, and a table id for `join_table`, plus up to eight live tables with browser links. These are concrete behavioral details about output content and result limits that the annotations do not provide.

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 front-loaded with the core action, then routes the agent to `join_table`, then summarizes the return format. Every sentence adds useful information, and there is no filler.

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?

There is no output schema, and the description fills that gap by explaining what each returned line contains and that live tables include browser links. For a zero-parameter list tool with read-only annotations, this is complete enough for an agent 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?

The tool takes zero parameters, so there is no parameter semantics to explain. The baseline of 4 applies; the description does not need to compensate for any schema gaps here.

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 a specific verb and resource: listing tables that can be joined now and tables currently playing. It explicitly differentiates from `join_table` by noting that `join_table` picks a table itself, so an agent can immediately tell these tools apart.

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?

It states exactly when to use this tool ('before `join_table` to choose a table') and when to skip it ('if any table will do, since `join_table` picks one itself'). This is explicit routing guidance with a named alternative and a clear selection condition.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces read-only while adding useful behavioral context: the duplicate-creation risk and the specific fields returned. It does not discuss auth or rate limits, but for a simple listing tool with annotations, this is strong added context.

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?

Three tightly written sentences, front-loaded with the core purpose. The sequencing guidance and return-value summary each earn their place with no filler.

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, so the description carries the return-value burden and does so adequately: name, id, model, and playing style. Combined with clear usage sequencing and annotations covering safety, nothing needed to call it correctly is missing.

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?

There are zero input parameters, so the baseline is 4. The description still adds value by explaining that the returned id should be passed as star_id to join_table or playbook.

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 a specific verb and resource: list the user's saved poker characters. It clearly distinguishes this from the sibling create_star tool and explains what a 'star' is in this context.

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?

Explicitly says to call it first in a session and always before create_star to avoid duplicates. It also tells the agent to pass the returned id as star_id to join_table or playbook, giving concrete alternative-tool routing.

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

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

It restates read-only but adds value beyond the annotations: it discloses the return shape (notes as text, or an explicit 'none' case) and warns that the content is owner guidance rather than server instructions — meaningful prompt-injection context. It does not cover failure modes (e.g. invalid star_id), so not 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?

Three short sentences, front-loaded with purpose, then timing, then return/trust caveat. Nothing redundant and the most decision-relevant information comes first.

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?

One optional parameter, annotations present, no output schema, yet the description covers when to call, what is returned, and how to treat the content. An agent has everything needed to invoke 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 the single optional `star_id` already documents its default in the schema. The description adds nothing about star_id semantics, so baseline 3 applies.

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 names a specific verb ('Read') and resource ('the user's coaching notes for a star') and explains the content ('standing orders on how to play'). No sibling tool in the list covers player-authored notes, so it is clearly distinguishable.

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?

It states explicit timing and ordering: call once after `join_table`, before the first hand. It also says what to do with the result ('follow them'), which is the intended usage contract, and names the sibling that must precede it.

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

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

Goes well beyond the annotations: declares no chip movement, no effect on anyone's turn clock, a confirmation return, and an explicit next step ('then call `wait_for_turn`'). None of this is derivable from readOnlyHint/destructiveHint/openWorldHint, so it adds real sequencing and side-effect context.

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?

Four short sentences, front-loaded with the purpose, then the alternative, then side effects, then follow-up. Every sentence carries distinct information with no filler.

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 2-optional-param, non-destructive social action with no output schema, the description supplies everything needed: when to use it, what it does not affect, and what to call next. No meaningful gap remains.

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%, with both `text` (max 200 chars, in character) and `emote` (with a listed enum set) documented in the schema. The description adds no further parameter nuance such as length limits or emote semantics, so baseline 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?

States a specific verb+resource ('Say something at the table, in character') plus the timing constraint ('when it is not your turn'), and explicitly distinguishes it from the sibling `act` by naming where in-motion speech belongs. An agent can pick between `say` and `act` without opening either schema.

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?

Gives the exact condition for use (not your turn, e.g. answering another player) and names the alternative with its selection rule ('To talk while moving, use the say field of `act` instead'). Both when-to-use and when-not-to-use are present.

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

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

Annotations already declare `readOnlyHint=true`, so safety is covered, but the description adds useful behavior: it returns without waiting, enumerates what state is shown, and notes that legal moves appear only on your turn. The main gap is that it does not discuss possible response size or error behavior, though this is minor for a read-only state view.

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 tight sentences, front-loading the immediate value: "Show the current state ... now, without waiting." Every clause adds useful information about contents, usage, or the alternative tool.

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?

With no parameters, no output schema, and read-only annotations already covering safety, the description still clearly explains what the tool returns and when to use it. It is complete enough for an agent to invoke correctly without further context.

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 tool has zero parameters, so there is no parameter semantics to explain. The schema is empty and the description correctly does not invent parameter details.

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, "Show," and names the exact resource: the current table state, including cards, board, pot, stacks, recent action, and legal moves. It also distinguishes the tool from the sibling `wait_for_turn`, so an agent can tell it apart from adjacent tools.

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?

It explicitly says when to use the tool: to re-read the spot, for example after `act` refused a call. It also names the alternative for a different need: "to wait for your turn use `wait_for_turn`."

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

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

Goes well beyond the readOnly/openWorld annotations: it discloses the ~40 second wait bound, the three possible return shapes (full spot, quoted speech line, or 'not your turn yet'), and that only table-over/bust messages end the session. This is exactly the operational context an agent needs for a long-poll tool with no output schema.

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-loaded with the action and timeout, then the return variants, then the session-end caveat. Three sentences, each carrying distinct operational information with no repetition.

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?

With no output schema, the description must explain return values and it does so precisely, including the normal-repoll case that could otherwise confuse an agent. Session-ending conditions are also covered, leaving no material gap for correct invocation.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly spends no words on nonexistent 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?

States a specific verb and resource ('Wait until it is your turn at your table') and an explicit bound ('up to about 40 seconds'). It is clearly distinguishable from siblings like view_table or act because it describes a blocking poll rather than a state query or an action.

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?

Explains the polling loop clearly ('not your turn yet', which is normal: call it again) and routes chat replies to `say`. It doesn't formally name alternatives like view_table or act, but the context for when to call it and how to respond is clear.

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