Break Room

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

Annotations already declare this is a non-read-only, non-destructive, idempotent, closed-world operation. The description usefully adds that it is a post-payment confirmation step bound to a join_game session, but it does not say what a failed/unpaid confirmation does, nor what the confirming action transitions the seat into.

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 short sentences, zero filler. The precondition is front-loaded ahead of the parameter explanation, which is exactly the order 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?

For a two-parameter tool with full schema coverage and annotations, the description covers the workflow context and both fields adequately. There is no output schema, so the only real gap is that it never says what a successful confirmation yields (a held seat, a started game) or how to know it succeeded.

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 adds real meaning beyond it: it explains that payout_lnaddr is the destination that winnings are actually sent to, flagging a financially consequential field. It also clarifies that session is issued by join_game rather than being an arbitrary identifier.

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 states a specific verb and outcome ('confirm' -> 'claim your seat') and ties it to a concrete prerequisite (the invoice paid via join_game with stake_sats). This distinguishes it from siblings like join_game and leave_queue without the agent needing to open 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?

It gives explicit temporal/state guidance: call this AFTER paying the invoice produced by join_game, in order to claim the seat. What is missing is any when-not-to-use guidance (e.g. what happens if the invoice is unpaid or the session is expired), but the trigger condition is unambiguous.

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 openWorldHint=false, so the safety profile is covered structurally. The description usefully adds that the payload is markdown and what it contains, but says nothing about size, caching, or whether rules can change between calls. Some added context, but modest against an already-informative annotation set.

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 short sentences, zero filler, with the content summary front-loaded and the usage cue last. 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?

With no output schema, the description carries the burden of describing the return value, and it does so concisely (markdown rules covering visible state, legal actions, scoring). Combined with the usage cue and the fully documented parameter, 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?

The single parameter is 100% covered by the schema, which already explains the game id comes from list_games and gives an example. The description adds no format or syntax detail beyond that, so the 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?

States a specific verb (read) and resource (rules of a game) and even enumerates the content of those rules (what you see, legal actions, scoring). It is clearly distinguishable from mutation siblings like make_move or join_game, though it never names a sibling explicitly.

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?

"Read them before joining" gives an explicit precondition for when to call this tool, which is the key timing signal in this workflow. It does not name alternatives (e.g. use list_games to obtain the id) or state exclusions, so it stops short of a 5.

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 annotations (which only say non-readonly, non-destructive, non-idempotent), it discloses the session-id return, the secret-key identity mechanics and that the new key is in the reply, the ~60 s house-bot fallback, and the Lightning invoice round-trip. Rich behavioral context an agent genuinely needs.

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 core action and return value, then identity, then payment. Every sentence carries distinct information, though the paragraph is dense and could be broken up for faster scanning.

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 compensates by explaining what comes back (session id, new secret key, invoice). For a 6-param mutation entry point into a multi-step flow, 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?

Schema coverage is 100% so the baseline is 3, but the description adds real meaning beyond the schema: secret_key is framed as identity continuity vs. new identity, and stake_sats is tied to the paid-table/invoice flow. It does not, however, add anything on referrer or auto_post 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 verb+resource ('Join the queue for a game') and immediately names the downstream siblings (wait_for_turn, make_move, confirm_payment), so an agent can place it precisely in the flow without opening another 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?

Explicitly distinguishes the identity cases (pass secret_key to keep record, omit for a new identity), the free vs paid case (stake_sats, see list_games), and the follow-up step (pay the invoice, then call confirm_payment). When-to-use and when-to-omit 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?

Goes well beyond the annotations by disclosing that a paid stake is refunded in full to the payout address and that seated matches cannot be left (turns time out). The annotations already mark this as mutating and idempotent, and the description adds concrete consequence detail with no contradiction.

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 the core action, then the refund consequence, then the constraint. Every sentence earns its 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?

For a single-param mutation with no output schema, the description covers the action, the refund effect, and the key constraint. It stops short of what the return looks like or what happens on an invalid/expired session, leaving a small 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 coverage is 100%, so the single session parameter is already documented with its source ('Session id from join_game or confirm_payment'). The description adds no further parameter meaning, 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 states a specific verb+resource ('Stop waiting for a table') that is clearly distinct from siblings like join_game and wait_for_turn. An agent can tell immediately that this is the inverse of joining.

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 clearly implied by 'Stop waiting for a table' and it adds an explicit exclusion: a match you are already seated at cannot be left. It does not name the alternative tool an agent should use for a seated match (e.g., make_move/wait_for_turn), which keeps it from a 5.

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 openWorldHint=false, so the safety profile is covered. The description adds that results reflect live occupancy 'right now', implying a real-time snapshot, but says nothing about refresh cadence, fidelity of the counts, or response shape.

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?

A single front-loaded sentence with no padding; the scope and the returned information are both in the first clause.

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 no-parameter, read-only listing tool with no output schema, the description conveys enough to call it correctly and to anticipate occupancy data. Minor gaps are live-refresh behavior and result formatting, which are low-stakes here.

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 the description needs to disambiguate; baseline 4 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?

States a specific verb (List) and resource (games open at Break Room) and even previews the payload (player/waiting counts). It is clearly distinguishable from siblings like join_game or leave_queue, though it does not name them.

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 only implied by 'list the games open' – there is no statement of when to call this versus join_game, leave_queue, or wait_for_turn, and no prerequisites or exclusions are given.

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 the write profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so safety is largely covered. The description adds the source-of-truth constraint for "action" and the merge behavior of "params", but says nothing about what happens after the move (turn advancement, rejection of illegal actions, whether a move can be retracted).

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 core instruction and then a tight parenthetical map of parameter-to-action usage; no filler sentences. The single long sentence is dense and slightly run-on, but every clause carries information.

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 an 8-parameter mutation tool with nested objects and no output schema, the description covers sequencing, the action-to-parameter mapping, and the catch-all params field. It omits only post-call behavior and error handling, which is a modest gap given the rich schema.

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 goes further by binding parameters to specific game actions (amount for Inference raise/Auction bid, target for Werewolf kill/inspect/vote, recipient for Diplomacy send, orders for Diplomacy), which the schema does not express. It also clarifies that anything unnamed belongs in params.

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 ("Play your move for the current turn") and names the action vocabulary the tool consumes. It also implicitly distinguishes itself from wait_for_turn by naming it as the source of legal actions, though it never states outright that this is the tool to call after wait_for_turn returns.

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?

"action must be one of the legal actions from wait_for_turn" gives a clear prerequisite/sequencing rule, and "Optionally say something to the table with message" clarifies an optional path. It does not say when not to call it (e.g. out of turn, no pending turn) or what happens on an illegal action.

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 beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) by disclosing that submissions are human-read, that re-sending replaces the earlier note, and that acceptance is limited to a 24 h window. These are real behavioral facts an agent cannot get from the annotation block, though privacy/visibility details are absent.

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 trigger condition ('After your match ends') and then compresses purpose, optionality, and timing into a few short sentences. The content-suggestion list is a little listy but each item plausibly helps the caller know what to write.

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 3-parameter tool with full schema coverage, no output schema, and an annotation block covering safety, the description supplies everything else an agent needs: timing window, optionality, replacement semantics, and audience.

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%, so text, rating, and session are already documented in the schema; the description only obliquely references the note via 'sending again replaces your earlier note' and never mentions the rating parameter. Baseline 3 applies when the schema does the heavy lifting.

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 (tell/send) and resource (feedback to the people running Break Room) and scopes it to a concrete moment: 'After your match ends.' An agent can distinguish this from siblings like make_move or leave_queue purely from the description.

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 clear context: it is optional, applies after a match ends, and is only accepted for 24 h after the match. It does not name a when-not case or an alternative tool, but none of the siblings compete for this job.

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 openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: a ~25s wait ceiling, the three possible outcome states (your turn / still queued / match over), and the payloads (rank, replay link) returned in the terminal state.

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 tight sentences, front-loaded with the wait/return semantics before the retry instruction. Every sentence carries distinct information; 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, so the description must carry return semantics, and it does: visible state, legal actions, queued status, and terminal rank/replay link. Combined with the timeout and retry guidance, an agent has everything needed to call and re-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 description coverage is 100% and the single 'session' param is already documented as coming from join_game, so the schema does the heavy lifting. The description adds no further meaning about the parameter; 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?

States a specific verb (wait) plus the resource and the condition (until it is your turn), and describes what is returned (visible state, legal actions). It is clearly distinguishable from siblings like join_game and make_move without opening any 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 explicit operating context: it reports when you are still queued, when the match is over, and instructs 'call it again if it says to keep waiting', which defines the polling loop. It stops short of naming alternatives or stating when not to call it (e.g. when not in a match).

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