TikTikLuck

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds real behavior beyond them: the purchase consumes Luck Points and automatically equips the item. It still omits failure modes (insufficient Luck Points) and what happens to any currently equipped cosmetic.

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 that names the action, the cost, and the side effect with zero 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 one-parameter mutation with full annotation coverage and no output schema, the description covers the essentials (cost and auto-equip). Only edge-case behavior (insufficient funds, re-equip semantics) 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 description coverage is 100% and the single itemId parameter is documented as coming from list_cosmetics, so the schema carries the load. The description adds nothing about itemId syntax or format, making the baseline 3 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 and resource ('Buys a cosmetic item'), plus the currency (Luck Points) and a key side effect ('equips it'). This distinguishes it reasonably from the sibling equip_cosmetic, though it doesn't explicitly say how it relates to already-owned items.

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?

No when-to-use or when-not-to-use guidance, no mention of prerequisites such as having enough Luck Points, and no explicit routing to alternatives like equip_cosmetic. The only implicit hint is the schema note 'From list_cosmetics'.

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 destructiveHint=false, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds genuine behavioral value by disclosing the once-per-UTC-day rate limit, though it does not say whether a repeat claim errors or silently no-ops.

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 sentence that front-loads the action, the reward, and the constraint. No filler, no restatement of the title.

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, non-destructive, idempotent claim action, the description plus annotations cover what an agent needs. The only minor gap is not specifying the outcome of a same-day repeat claim, which the idempotentHint largely implies.

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 schema is trivially complete and there is nothing for the description to disambiguate. Baseline 4 applies for a no-parameter 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 ('Claim') and a concrete resource ('daily Luck Points bonus'), plus the scope constraint (once per UTC day). It is immediately distinguishable from nearby siblings like claim_link or game_status 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?

The daily cadence ('once per UTC day') implies when this tool is relevant, but there is no explicit when-not guidance and no mention of alternatives for related reward flows. Usage is inferable rather than stated.

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?

The description discloses the key side effect the annotations don't: generating a new link invalidates the old one, which is meaningful context for a non-idempotent, non-read-only operation. It doesn't say anything about auth requirements or rate limits, but the annotations already cover the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false).

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 the precondition stated first and the invalidation caveat parenthesized. Efficient and earns its place, though the phrasing 'a new claimUrl for your person' is slightly indirect for what is an action.

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 and no output schema, the description carries the return-value burden and does so by naming claimUrl as the result, plus the precondition and the invalidation behavior. An agent has what it needs to decide and call correctly, though nothing is said about what the URL must be used for afterward.

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 with 100% schema coverage, so the baseline is 4. There is nothing for the description to clarify about inputs, and it correctly adds none.

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 the concrete resource it produces (a new claimUrl for your person) and the state it applies to, which is enough to distinguish it from register_agent and get_me. It is slightly noun-phrase-heavy rather than a crisp verb+resource statement, but the effect is unambiguous.

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 an explicit precondition: you are an agent that signed itself up and has not yet been claimed. That effectively tells the agent when this applies, though it never names an alternative (e.g. register_agent) or says when not to call 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?

Annotations declare it is a non-readOnly, non-destructive, non-idempotent mutation, and the description usefully adds that the result is only a returned config with nothing published. It stops short of saying whether the design is persisted or what happens to an existing board when baseConfig is supplied.

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, no waste, with the core action and the 'nothing published' caveat front-loaded and the follow-up call 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?

No output schema exists, and the description compensates by stating the return is a config that is not yet published, plus the required next step. For a two-parameter tool this is nearly complete, though it omits any detail on config shape or the baseConfig nesting.

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. The description adds real semantic value by explaining the relationship between the two parameters: 'prompt' supplies the idea, while 'baseConfig' is a starting config the AI will modify as described.

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 ('designs a luck board') and clarifies the two input modes (from an idea, or by changing baseConfig). It also distinguishes itself from publish_luck_board and, implicitly, from get_luck_board by noting nothing is published yet.

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 workflow guidance — 'Then call publish_luck_board' — so the agent knows this is a pre-publish step. It does not, however, contrast with alternatives such as get_luck_board or say when re-designing vs. editing an existing board is appropriate.

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 carry the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=false), so the description usefully adds that the tool returns the config plus its playtest (important since there is no output schema) and that kind has an auto-selection default. It does not disclose cost, latency, or whether repeated calls with the same prompt produce different levels.

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 compact sentences with the core action front-loaded and no wasted preamble. The parenthetical kind list and the trailing 'People play skill games; agents can make them' are slightly promotional padding rather than operational 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?

With no output schema, the description correctly covers the return value ('the config and its playtest') and the next step (publish_skill_game), and the only required parameter is explained. The unmentioned optional baseConfig and the lack of any indication of what the playtest contains leave 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 description coverage is 100%, so the baseline is 3, but the description exceeds it by enumerating the valid kind values that the schema leaves as a bare 'Skill game kind (optional)' with no enum. baseConfig is not mentioned at all, which keeps this from a 5.

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 ('Designs a skill-game level from your idea') and enumerates the kinds it can produce (runner, stack, catgrid, busjam, territory, trick, relicgrid, potionsort), which no sibling does. It also names the downstream sibling publish_skill_game, so an agent can separate this from design_luck_board, invent_game, and the play_* tools 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?

'then publish_skill_game' gives the explicit follow-up step in the workflow, and '(picked for you if left out)' tells the agent that kind is safe to omit. There is no when-not guidance (e.g. how this differs from invent_game or when to prefer design_luck_board), so it stops short of full alternative 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?

Annotations already declare this is a non-read-only, idempotent, non-destructive write, so the bar is lower. The description adds real value beyond them: the ownership precondition and the fact that passing null clears the slot, which tells the agent this operation is reversible rather than destructive.

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?

One sentence, front-loaded with the primary action, and the alternate null-clear behavior is appended compactly. Nothing is redundant and no clause 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?

For a 2-parameter tool with no output schema and rich annotations, the description covers the action, the slot domain, and the clear path. It could optionally say what happens when the item is not owned, but nothing essential for a correct call 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 description coverage is 100% and the enum for slot is fully enumerated, so the schema carries the parameter burden. The description's mention of 'itemId null' to clear duplicates the schema's 'Item id, or null' without adding format or lookup guidance, landing at the baseline.

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 (equips) and resource (an item you own) plus the affected slot domain (skin, trail, frame), and distinguishes itself from siblings like buy_cosmetic and list_cosmetics by implying ownership already exists. An agent can tell immediately this mutates the active loadout rather than the inventory.

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?

Implies usage by covering both modes — equip an owned item, or pass null to clear the slot — but never names an alternative tool or states prerequisites beyond 'you own'. There is no explicit when-not guidance (e.g., buy first, or use list_cosmetics to find ids).

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 safety is covered. The description adds genuine value by enumerating the possible outcomes (certifying / live / rejected with reasons), but says nothing about what a rejection reason contains or behavior before publication.

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 filler; the parenthetical about rejection reasons is the one useful elaboration. Terse but appropriately so for a simple status query.

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 read-only, single-param tool with no output schema, the description covers the essential outcome space. It is missing the linkage to how a board id is obtained (publish_* siblings) and which board types it covers, leaving the agent to infer 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?

One parameter at 100% schema coverage; the schema already documents configHash as the board id. The description adds no syntax, format, or sourcing detail beyond 'board id,' so it neither compensates nor detracts.

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 query purpose: report whether a published board's certification is still pending, live, or rejected. The resource is clear enough to separate it from fetch-style siblings like get_luck_board, though it never explicitly says which board family it applies to or how 'game_status' relates to the similarly named invent_status.

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?

No when-to-use, no prerequisites, and no alternatives named. Given siblings such as invent_status, verify_play, and get_luck_board, an agent gets no help deciding when this status check is the right call versus fetching the board itself.

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 of this lookup is covered. The description adds the useful detail that stake and outcome data are returned, giving a hint the game has an economic dimension, but it says nothing about missing/invalid ids, auth needs, or whether unpublished games are visible. Adds some value over annotations, not much.

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 with no filler, and the returned-content list is front-loaded ahead of the routing hint. The first fragment is noun-phrase shorthand rather than a full clause, which costs a little readability but not meaning.

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 usefully enumerates the returned fields, which is the main thing an agent needs to know before calling. It does not cover failure behavior for an unknown id, a minor gap for a one-parameter read tool whose safety profile is already in annotations.

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 is a single parameter (id) at 100% schema description coverage, and the schema already documents "The invented game's id". The description adds no format, source, or lookup guidance for that id, 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?

The description names the specific resource (an invented game) and enumerates exactly what the response contains: description, how to play, outcomes and stake menu. That content is distinguishable from list_games, and it names play_invented_game and rooms, so the agent can tell which sibling handles play. It lacks an explicit verb ("get"/"returns"), but the resource and payload are unambiguous.

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 partial routing by stating luck games are played with play_invented_game or in rooms, implying this tool is for inspecting rather than playing. However, it never states when to call get_invented_game versus list_games or my_games, nor any prerequisite (e.g. needing a valid id first). Usage is implied rather than specified.

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 genuine behavioral value by enumerating what a read returns (outcomes, live multipliers, stake limits, stake menu, certification), which matters because no output schema exists. It does not mention pagination or error behavior for an invalid configHash.

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, and the payload contents are front-loaded ahead of the usage cue. Every clause carries 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?

With no output schema, the description correctly compensates by listing the return contents, and annotations cover the read-only nature. It is nearly complete for a single-parameter read, missing only failure behavior for a bad configHash.

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 configHash parameter is documented in-schema as the board's id, so the schema does the heavy lifting. The description adds no format or constraint detail beyond what the schema already provides, which is the expected baseline.

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 the resource (a luck board) and enumerates the specific data returned: outcomes with current multipliers, stake limits, stake menu, and certification. This clearly distinguishes it from siblings like play_luck_board or publish_luck_board, though it relies on an implicit 'get' verb rather than stating retrieval 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?

'Use before place_bet' gives a concrete sequencing cue that tells the agent when to reach for this tool. It stops short of naming alternatives or exclusions, but the pre-flight framing is clear enough to route the agent correctly.

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 useful behavioral context by enumerating the returned fields, but says nothing about authentication context or freshness/timing of the check-in flag.

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 compact sentence with no filler, front-loaded on the returned data. It is slightly fragmentary but 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 tool with no output schema, the description is nearly self-sufficient because it itemizes the return content. Only the meaning/freshness of the check-in status flag is left unexplained.

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 accepts zero parameters, so there is nothing to document and the baseline is 4. The description correctly implies no inputs are needed by describing only returned data.

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 the specific returned resource fields (handle, Luck Points balance, today's check-in status), which distinguishes it from siblings like game_status or invent_status. It lacks an explicit verb but the content is unambiguous enough that an agent knows it retrieves the caller's own account state.

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?

There is no statement of when to call this versus alternatives such as game_status or get_luck_board, nor any prerequisite or exclusion. The agent must infer eligibility from the tool name alone.

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 (readOnlyHint=false, idempotentHint=false, destructiveHint=false) cover the safety profile, and the description adds rich non-structured behavior: 1–3 minute runtime, a 50 s wait then jobId return, and the polling cadence. The luck-template pay-weight explanation (relative weight, not LP, priced from measured odds) is genuinely valuable context beyond annotations, though the certification.outcomes[].multiplierX100 reference is terse.

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?

Despite being information-dense, everything is front-loaded: purpose first, then timing/async contract, then the pay caveat last. Not a wasted sentence — each clause answers a question the agent would otherwise have to guess at.

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?

Covers invocation, latency, async handoff, follow-up tools, and a subtle output semantic; no output schema exists but the description explains the return (jobId). The one gap is sibling differentiation among the design_* tools, which leaves some ambiguity about when this is the right choice.

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 the schema already explains base, baseId, change, description and multiplayer. The description only adds the multiplayer room-size detail (up to 20 live rooms); otherwise it restates the schema's edit-vs-create semantics. Baseline 3 applies when structured fields do 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?

Starts with a specific verb+resource: 'The AI invents a new kind of game from your description ... writes its code and tests it.' It also scopes the modes (luck or skill, solo or multiplayer live rooms) so the agent can tell what output type to expect.

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 operational sequencing: call this, poll invent_status every ~10 s, then publish_invented_game, and notes via base/baseId that it doubles as an edit path. It does not explicitly contrast against design_skill_game or design_luck_board, which look like adjacent alternatives an agent might confuse it with.

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 cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds real value beyond them: it discloses what each state returns and clarifies that outcomes[].pay are relative weights while multiplierX100 is the actual x100 payout. It does not mention polling cadence, expiry, or auth needs, but the return semantics are unusually well explained.

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 dense sentences, front-loaded with the state enumeration and followed by the exact field-semantics clarification. No filler; every clause carries information the agent would otherwise have to guess.

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 and one simple parameter, the description takes on the job of describing the response and does so well via the state list and pay/multiplier semantics. Minor gaps remain around polling expectations and jobId lifetime, but nothing essential to a correct call 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 description coverage is 100% (jobId is documented as 'From invent_game'), so the baseline is 3. The description reinforces the origin of the job but adds no format, validation, or lifecycle detail 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 and resource ('Checks an invent_game job') and enumerates the three terminal/transient outcomes, so it is distinguishable from the related invent_game and get_invented_game. It stops short of explicitly naming those siblings as alternatives, so it is clear but not fully differentiated.

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 three-state breakdown (pending/ready/failed) implies this is a polling endpoint for a job started elsewhere, but the description never says 'call this after invent_game' or contrasts it with get_invented_game/game_status. Usage is inferable but not stated.

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 destructive=true and idempotent=false, but the description earns credit by disclosing the actual cost model (staking the seat price), the payout structure (pot to winner minus a small rake), and that agents count as players. It does not disclose failure behavior when the round is closed or the stake cannot be paid, so a 4 rather than 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?

Four short sentences, front-loaded with the action and its cost before the follow-up hint. 'Agents count as players' is a policy note rather than mechanics, but it is short and answers a real ambiguity for an agent caller.

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?

The mutation profile and economics are covered, and follow-up navigation is provided, but with no output schema the description should indicate what a successful join returns (seat confirmation, round id, pot state) and what an error looks like. That return-side gap leaves it merely adequate for a wagering mutation.

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 game, aimTurn and clientSeed are already documented in the schema; the description adds only indirect meaning via the seat-price concept. Baseline 3 is appropriate when the schema carries the parameter burden.

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 ('takes a seat in the room's open round') and adds the stake mechanic in Luck Points, so it is immediately distinguishable from leave_room and from the play_* tools. An agent knows exactly what state change is requested without opening the 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 tells the agent what to do afterwards ('follow the round with room_state or wait_for_round'), which is genuine routing guidance. It stops short of stating preconditions (round must be open, sufficient Luck Points balance) or when to prefer this over play_luck_board/play_invented_game, so it is clear but not exhaustive.

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 non-read-only, idempotent, non-destructive behavior. The description adds the outcome that the stake is refunded, which is genuinely useful context, but says nothing about failure modes such as leaving a closed round or 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?

One compact clause pair with the action first and the payoff second; there is no filler and nothing is buried.

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-parameter, non-destructive action with full annotation and schema coverage and no output schema, the description supplies the essential action plus the stake-return outcome. Only edge-case behavior is unstated, which is minor 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?

Schema description coverage is 100% for the single 'game' parameter, so the schema already documents that it accepts a gameHash or "arena". The description contributes nothing further about the parameter, which is the expected baseline.

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 ('gives up your seat'), which an agent can distinguish from join_room by polarity alone. It does not explicitly name the sibling or use the tool's own subject 'room', but the intent is unambiguous.

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 clause 'while the round is still open' establishes the condition under which leaving is appropriate, implying the round-closed case is out of scope. No alternative tool is named, so it stops just short of full routing guidance.

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?

With no output schema, the description usefully discloses what comes back – item list with prices plus ownership and equipped flags – which is real context beyond the readOnlyHint/openWorldHint annotations. It doesn't mention auth needs or ordering, but for a zero-arg read that's a minor gap.

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 compact sentence covering items, prices, ownership, and equipped status with no filler. It is a sentence fragment rather than a directive verb phrase, which slightly weakens the front-loading.

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 parameterless, read-only catalog listing with no output schema, the description covers both the item categories and the notable return fields. Missing only edge details like ordering or pagination, which is acceptable at this complexity.

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 parameters, so the baseline is 4; nothing about argument meaning needs explaining and the description correctly spends no words on inputs.

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 fragment names the resource precisely (cosmetic items: skins, trails, frames) and its scope (Luck Point prices, owned, equipped), which distinguishes it from buy_cosmetic and equip_cosmetic. It lacks an explicit verb like 'list', but a zero-parameter catalog read is unambiguous in 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?

Usage is only implied: listing prices and owned/equipped state suggests checking the shop before calling buy_cosmetic or equip_cosmetic, but no sibling is named and no when-to-use condition is stated. Adequate but leaves routing 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 only cover readOnlyHint and openWorldHint, and the description adds genuine context beyond them: the meaning of 'live games,' the item shape (kind + id), and which sibling resolves each kind. It does not discuss pagination behavior, but the added data-model and routing context is substantive.

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 purpose, then progressively adds taxonomy and routing. Efficient overall, though 'kind' is revisited in two consecutive sentences, producing mild redundancy.

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 read-only listing tool with no output schema and 7 fully documented optional parameters, the description covers purpose, filtering semantics, and result routing adequately. Minor omissions (pagination expectations) are already handled by the 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 baseline is 3. The description adds meaning beyond the raw enum by explaining that kind=luck spans both luck boards and invented luck games and kind=skill spans skill games, clarifying a filter whose values do not map 1:1 to item kinds. It adds no detail for the other six 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+resource ('Browse live games') and explicitly routes to siblings get_luck_board and get_invented_game, so an agent can distinguish this discovery tool from the single-game getters. The taxonomy explanation (kind=luck vs item kind=luck|invented|skill) is accurate but slightly muddles the otherwise crisp purpose.

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?

Provides clear alternative routing: 'use get_luck_board for luck boards and get_invented_game for invented games,' so the agent knows this tool lists but does not fetch a specific game. It also gives agent-specific guidance ('agents play only the luck ones'). No explicit when-not-to-use statement beyond the routing, so not 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 clear. The description adds that rooms are for multiplayer games and how to join, but it does not describe the return format or any other behavioral details beyond what annotations cover.

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, front-loaded with the tool's domain, and no wasted words. The second sentence adds useful context about joining without bloat.

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 simple, no-parameter tool with read-only annotations, the description is mostly adequate. However, it does not explicitly state that the tool returns a list of live rooms or what information is included, which is a gap since no output schema exists.

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 the baseline is 4 per the rubric. No parameter information is needed, and the description appropriately does not attempt to document any.

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 the domain (multiplayer games with live rooms) and categorizes them (luck boards, invented games), and it differentiates from join_room by directing joining there. However, it lacks an explicit verb like 'list', leaving the action slightly implied.

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 provides clear context by naming the alternative join_room and explaining how to use it (with gameHash or 'arena'), but it does not state when not to use list_rooms or mention other siblings like room_state.

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. The description adds that results include other people's plays and Luck Points split between players and house bots, which is genuinely useful return-content context since no output schema exists. It says nothing about result limits, ordering, or pagination, though.

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?

One sentence with no filler, and the core resource is front-loaded. The trailing parenthetical about Luck Points from players versus house bots is slightly convoluted but does carry 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 a zero-parameter read tool with no output schema, the description should carry the return contract; it partially does by naming games, plays, and a Luck Points breakdown. It stops short of saying whether all games are returned, how results are ordered, or whether plays are nested per game.

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 of 4 applies. There is no parameter surface for the description to clarify or omit.

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 identifies a specific resource and scope — the games the caller created — which implicitly separates it from the sibling list_games (all games) and my_plays (plays rather than games). However, it is a noun phrase with no verb, and it never names an alternative sibling, so the differentiation is inferred rather than stated.

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?

There is no when-to-use guidance, no prerequisites, and no mention of the closely related list_games, get_invented_game, or my_plays tools. An agent must infer from the phrase 'you created' alone that this is the personal-scope variant, which is weak routing guidance in a 28-tool namespace.

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 behavioral context beyond that: ordering (newest first), inclusion of lifetime totals, and the pagination cursor convention, though it says nothing about rate limits or result size ceilings.

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 what the tool returns before moving to the verify hand-off and pagination. Every sentence carries distinct information; nothing is padding.

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 describe the return shape, and it does: play entries with stake, payout and state, plus lifetime totals, plus the `verify` token for luck-board plays. An agent has enough to call the tool and consume the response 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 schema already documents both `limit` (1..100, default 20) and `before` (last play's `at` for the next page). The description repeats the `before` semantics without adding format or edge-case detail, so it does little beyond the structured field.

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 resource with scope ('Everything you've played, newest first') and enumerates exactly which play types are returned (luck boards, invented games, skill runs, Arena and room seats). This clearly distinguishes it from the sibling my_games, which covers games you authored rather than played.

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 concrete workflow guidance: pass a luck-board play's `verify` to verify_play, and paginate by passing the last play's `at` as `before`. It lacks any explicit when-not-to-use statement or a named alternative for other play queries, but the routing advice is actionable.

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 destructiveHint=true and non-idempotent, so the safety profile is covered. The description adds real value beyond that: the commit-then-settle flow and the specific 403/skill_game_people_only refusal behavior for skill games. It stops short of describing failure modes for insufficient stake or the returned round outcome.

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 compact sentences, front-loaded with the core action before the routing and refusal caveats. Every sentence carries distinct information, though the parenthetical '(commit, then settle)' is slightly terse.

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 covers the action, routing, and a key error case, and annotations cover the destructive/non-idempotent profile. It could say more about what the round returns or minimum-stake failures, but nothing essential to calling 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 description coverage is 100%, so id, stake, and clientSeed are all documented in the schema itself (including the 'on its stake menu' note). The description adds no syntax or format detail beyond what the schema provides, 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 (plays), resource (invented luck game), and scope (one round, solo, for Luck Points). It also distinguishes itself from the multiplayer sibling (join_room) and from skill games, so an agent can differentiate it without opening 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 routes multiplayer invented games to join_room and states that skill games are refused (403, skill_game_people_only). The conditions that select this tool versus its alternatives are stated outright, leaving little 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?

No output schema exists, so the description carries the full return-value burden and does so: it explains the commit/reveal provably-fair flow and defines multiplierX100, paidMultiplierX100 (0 loss, 100 void refund), and net/netLp as payout less stake. With destructiveHint and non-idempotent annotations already flagged, this adds genuinely new behavioral 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?

Front-loaded with the action and outcome in the first clause, then the read-out semantics. The long run-on sentence listing return fields is dense but each definition is load-bearing given the absent output schema.

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 4-param mutation with no output schema the description covers the flow, stake constraints and result fields. It omits error/failure modes and any prerequisite that the board must be published and the agent registered, which would round it out.

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 the baseline is 3; the description goes beyond it by constraining stake to whole LP values on the board's stake menu and clarifying that 0 means a free round, plus tying clientSeed to settlement.

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+scope: 'Plays one round of a luck board for Luck Points, backing one outcome.' An agent can distinguish it from design_luck_board, publish_luck_board, get_luck_board and verify_play 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 a real precondition ('The stake must be on the board's stake menu if it has one (0 = a free round, where offered)') and describes the commit-then-settle flow, but never names alternatives such as verify_play or get_luck_board as the route for inspecting boards or verifying results.

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 write/non-readonly behavior, and the description adds meaningful context beyond them: it saves the template for reuse, publishes the game to the feed, and notes checks rerun with a possible one-minute delay. It does not cover failure modes or return behavior, but the added side-effect and timing context is useful.

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 tightly packed sentences with no wasted text. The core action and side effects are front-loaded, followed by timing and the stakeOptions constraint.

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 non-readonly, non-idempotent mutation with a nested template object and no output schema, the description covers the main side effects, timing, and one critical parameter constraint. It leaves some gaps around what is returned or what happens on failure, but it is broadly complete enough to call 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 75%, so most parameters are already documented. The description adds important semantic detail for stakeOptions: only 0 or 10..1000, up to 6 values, in increasing order, specifically for solo luck games, which goes beyond the schema's bare integer array type.

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: publishes an invented game, and clarifies the two side effects: saving its template and putting the game live in the feed. This distinguishes it from pure invention/status tools, though it does not explicitly contrast with sibling publishers like publish_skill_game or publish_luck_board.

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: the schema notes template comes 'From invent_game / invent_status' and the description explains publication effects, but there is no explicit when-to-use guidance or comparison against sibling alternatives such as publish_skill_game and publish_luck_board.

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 cover the safety profile (not read-only, not idempotent, not destructive), and the description adds genuinely new behavior: certification runs thousands of simulated rounds, publication typically takes under a minute, the call blocks up to 45 s, and passing maxPlayers also opens multiplayer rooms. The async/timeout and side-effect disclosure is valuable beyond the annotations.

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 action and outcome, then packs stake/multiplayer constraints and the timeout fallback into two tight sentences 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 mutation tool with no output schema, it covers timing, blocking behavior, side effects (multiplayer rooms), parameter constraints, and the recovery path via game_status. It does not say what the call returns on success, but the async handling makes it largely self-sufficient.

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 constraints the schema lacks: stakeOptions allows up to 6 amounts in increasing order, each 0 or 100..5000. maxPlayers and replaces are already documented in the schema, so only stakeOptions genuinely benefits.

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 ('publishes a board config') and adds what publishing means (certification, going live). It implicitly contrasts with design_luck_board via the config source, but never names the sibling publish tools (publish_invented_game, publish_skill_game) so an agent must infer which publish variant applies.

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 (certify then live, usually within a minute) and an explicit fallback: if still certifying after ~45 s, check with game_status. It does not state exclusions or when to prefer this over the other publish_* tools, so it stops short of full routing guidance.

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 generic flags (not read-only, not idempotent, not destructive), while the description adds real behavioral context: the config is playtested and goes live immediately, and `replaces` updates your own game within a 24-hour window. It still omits what happens if playtesting fails and whether a publish can be undone, so it is not fully transparent.

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 compact sentences, front-loaded with what the tool does and its immediate effect, then the value constraints. The `stakeOptions` rules are dense but each clause carries needed information; nothing is padding.

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 non-idempotent publish mutation with no output schema, the description covers the effect and the stake constraints, but says nothing about validation failure behavior, permissions, or what the caller receives on success. Adequate, but short of what an agent needs to call it confidently the first time.

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?

With 67% schema coverage, the description carries worthwhile weight: it fully documents `stakeOptions` (allowed values 0 or 10..500, max 6 entries, increasing order, only for kinds that take stakes) where the schema gives no description at all. It adds little for `config` beyond what the schema already says ('From design_skill_game').

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 (publishes a skill-game config) and the immediate effect, which separates it from design_skill_game (which only produces the config) and from publish_luck_board / publish_invented_game (different game kinds). Sibling differentiation is implied by the resource name rather than explicitly stated.

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 implies the workflow (you publish a config that came from design_skill_game, and use `replaces` to update your own game within 24 h), but never states explicitly when to choose this over publish_invented_game or publish_luck_board, nor that a design step 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 by disclosing concrete side effects and constraints: an API key shown only once, a claimUrl for a person, play restrictions until an 18+ person claims the account, the Bearer auth format for reconnection, and an address-based rate limit. Annotations only say it is non-destructive and non-idempotent; the description supplies the operationally important 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?

Front-loads the trigger ('No key yet?') and then packs payoff, auth, restriction and rate limit into a few dense sentences. All sentences earn their place, though the density makes it slightly heavier than a crisper two-liner.

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, but the description itself explains what registration returns (Luck Points, API key shown once, claimUrl), plus the auth mechanism, restriction and rate limit. Nothing an agent needs to call this 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 description coverage is 100%, so both parameters are already documented in the schema (name format/handle, about shown on claim page). The description adds no syntax or format detail beyond what the schema provides, so the baseline 3 for schema-covered parameters 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 ('Sign yourself up' → your own player account) and enumerates the concrete outputs: Luck Points, API key, claimUrl. An agent can immediately distinguish this from siblings like claim_link (claims an existing agent) or start_here (orientation).

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?

'No key yet? Sign yourself up' gives a clear entry condition, and the description discloses the post-signup restriction (can only play luck games until claimed) and a rate limit (a few sign-ups a day per address). It stops short of naming a specific alternative tool for agents who already hold a key, so it is strong but not fully explicit about when-not.

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 safety is covered. The description adds one genuinely useful behavioral nuance: that revealed seeds and the winner appear only after the round locks, implying the payload changes over time. It does not mention polling behavior versus wait_for_round or what an idle room returns.

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?

One compact, front-loaded sentence with no filler. The trailing clause 'and after it locks the revealed seeds and the winner' is slightly awkward and grammatically tangled, but it still earns its place by exposing time-dependent content.

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 read-only, single-parameter tool with no output schema and its safety profile already in annotations, the description is nearly sufficient: it names the returned fields and the lock-dependent reveal. The only omission is behavior when no round is active, which is a minor 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?

With a single parameter and 100% schema coverage, the schema carries the full burden and does so well, documenting the accepted value as a gameHash from list_rooms or the literal "arena". The description adds nothing about the parameter, 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?

States a specific resource (the room's current round) and enumerates the returned content: phase, seats, pot, timings, revealed seeds, and winner. An agent can tell this is a point-in-time state read, though it never explicitly contrasts itself with siblings like wait_for_round or game_status.

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 offers no when-to-use guidance and no routing away from alternatives such as wait_for_round or game_status. The only chaining hint ('gameHash from list_rooms, or "arena"') lives in the schema, not the description.

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 and openWorldHint, so the safety profile is covered. The description adds genuinely non-obvious behavior: the response content branches on authentication state (balance/capabilities/next steps vs. site overview and signup path), which the schema cannot express.

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 hook ('New here? Call this first.') followed by two tightly parallel clauses covering the auth branches. No filler sentences; every clause adds 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?

With no output schema, the description carries the burden of describing returns, and it does so for both auth branches. It stays at summary level (lists of what you receive) rather than exact fields, which is acceptable for an orientation tool but leaves slight ambiguity about response shape.

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 schema-clearing baseline of 4 applies. There is no parameter semantics for the description to add or omit.

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 clear role: an orientation/onboarding call that returns different content depending on whether the caller has a key. It distinguishes itself from the game-play and publish siblings by being the 'first call' entry point, though the mapping is implicit rather than naming a specific alternative.

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?

'New here? Call this first' gives an explicit ordering directive, and the with-key vs without-key branches tell the agent which variant of output to expect. It does not name alternative tools for specific needs, but the 'call this first' framing is unusually strong guidance for a catalog this large.

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 cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds real context beyond that: it enumerates what is checked (server-seed hash commitment, client seed, nonce, result) and asserts determinism ('No play with that server seed on the board fails'). It stops short of describing the response shape, but adds meaningful behavioral value over the annotations.

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 core action ('Re-runs a settled luck-board round...') before the parenthetical details, and every clause carries information. It is a single dense paragraph rather than a poor-fit, but slightly heavy with nested parentheticals.

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 tool with no output schema, the description covers what is verified and where the input comes from, and annotations handle the safety profile. The one gap is that it never states the returned result (e.g., a pass/fail or validity indication), leaving the agent to infer the response.

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 the schema already documents each parameter, giving a baseline of 3. The description adds context by mapping the play's `verify` object from my_plays to the input set, but provides no per-parameter syntax or format detail beyond what the schema states.

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: re-runs a settled luck-board round from its seeds and checks it against the recorded play. This clearly distinguishes it from play_luck_board (which plays a round) and my_plays (which lists plays), so an agent can select it without consulting siblings.

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 usage context by naming the input source: 'a play's `verify` from my_plays is exactly the input', routing the agent to my_plays to obtain arguments. It also notes an external alternative (@luckloop/core's verifyPlay), but offers no explicit when-not-to-use guidance.

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 readOnlyHint and openWorldHint=false; the description adds genuinely useful behavior: a bounded 45-second wait, the two values returned, and the re-call pattern on timeout. It stops short of saying what exactly comes back when the wait expires unsettled, which is the one remaining unknown.

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 tight sentences with no filler; the wait semantics, the duration bound, and the retry rule are all front-loaded in order of importance.

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 correctly carries the return contract (winner and revealed seeds) and the timeout bound. The only gap is the exact return shape when the round is still running, which the agent must infer from the retry instruction.

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 'game' parameter (gameHash or "arena") is fully documented there. The description only alludes to it indirectly via "the room's current round", adding no format or selection meaning beyond the schema, 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 and resource (wait for the room's current round to settle) plus the observable outcome (winner and revealed seeds). The blocking-until-settled scope clearly distinguishes it from polling siblings like room_state or game_status.

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?

"Call again if it's still running" gives concrete retry guidance for a blocking call, which is the main operational question here. It does not, however, name alternatives (e.g. use room_state if the round is already settled) or state when not to call it.

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