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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'execute on-chain operation,' which indicates a state-changing action but does not mention gas costs, irreversibility, authentication requirements, or possible side effects such as emitting events or requiring a session. The vote-elimination mechanic is mentioned but not explained, leaving the agent unaware of the consequences.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single compact sentence with no filler, front-loading the core operation and listing the two types. It is concise and clear at a glance, though it achieves brevity by omitting behavioral context that would be useful. The structure itself is efficient.

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 on-chain state-changing tool with no annotations, no output schema, and 4 parameters, the description is incomplete. It does not cover return values, prerequisites, failure modes, or the practical impact of VOTE. The schema explains parameter syntax, but the description leaves the agent with little understanding of what happens when the tool is invoked or when it should be chosen.

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 all parameter meanings and the conditional requirements for target and content. The description adds no extra parameter details beyond what the schema provides, such as the 280-character limit or that target is only needed for VOTE. Baseline 3 is appropriate because 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?

The description clearly states a specific action - executing on-chain operations - and enumerates the two allowed operation types (CHAT to send a message, VOTE to vote someone out). This distinguishes it from sibling tools, most of which are about session/room/game management. It could be more explicit that this is a player action rather than an administrative one, but the core purpose is understandable.

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 guidance on when to use this tool versus alternatives like create_room, start_game, or settle_round. The description implies it is for sending chat messages or casting votes during a game, but it never states preconditions (e.g., being in a room, having an active session) or situations where this tool is inappropriate. An agent must infer the usage context from the parameter names 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?

With no annotations provided, the description carries the full disclosure burden and does substantial work: it reveals the async non-blocking nature (立即返回), continuous background autonomy (自主的后台), and the full set of side effects it triggers (voting, chatting, settling, reward claiming). It stops short of disclosing that the loop persists until explicitly stopped and gives no error-handling or rate-limit 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?

Two sentences with zero waste: the first delivers the core purpose and action list, the second delivers the critical async caveat and the monitoring route. Key information is front-loaded and every word 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?

The description covers the essentials — what the loop does, that it returns immediately, and how to track progress — and the schema richly documents all six parameters. Gaps remain: with no output schema, it never states what the immediate return value contains, and it omits prerequisites (e.g., an active session/room) and the fact that the loop runs until stop_auto_play is called.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with every parameter documenting its default, range, and behavioral effect (settleEnabled explicitly says it invokes settleRound; both enums spell out choices and defaults). The description itself adds no parameter-level meaning, which is acceptable under the high-coverage 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 states a specific action (启动/start), a clear resource (自主的后台游戏循环/autonomous background game loop), and enumerates the concrete behaviors it performs (自动投票、聊天、结算轮次和领取奖励). The immediate-return note and the get_auto_play_status reference distinguish it from sibling tools like stop_auto_play and get_auto_play_status without ambiguity.

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 second sentence explicitly routes the agent to get_auto_play_status for monitoring after invoking this tool, establishing clear context for how the tool fits into the workflow. However, it does not state when to prefer this automation over the manual per-action siblings (action_onchain, settle_round, claim_reward) or give explicit when-not-to-use conditions.

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 annotations are provided, so the description carries the full behavioral burden. It accurately conveys the core read/check behavior (inspecting wallet address, USDC balance, and session state), but it never explicitly states that the operation is side-effect-free, nor does it disclose what happens when the session is inactive (error vs. returned flag). Given the absence of annotations, a 3 is appropriate.

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 wasted words. The first sentence states what the tool does; the second states when to use it. Both sentences earn their place and the most decision-relevant information (purpose) is front-loaded.

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 status-check tool, the description is nearly complete: it names what is checked and when to use it. The only gap is that, with no output schema present, it does not describe the return format (e.g., whether balance is returned as a string, whether session status is a boolean). This is a minor gap for such a simple tool.

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 and the schema is an empty object, which triggers the baseline of 4. The description correctly requires no parameter information because there is nothing to configure.

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 clearly states a specific action (check) on a specific resource (current wallet's address, USDC balance, and session active state). It is distinguishable from sibling status tools like get_arena_status or get_round_status because it focuses on wallet/session state, though it does not explicitly name those siblings to draw the contrast.

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 explicitly tells the agent WHEN to use this tool: 'before taking action to verify the session is active.' This is a clear, actionable trigger context. However, it does not name alternatives or exclusion conditions, which would have made it 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return values but does not disclose the state-changing nature of claiming, whether it is one-time, whether prior settlement is required, or what happens on failure. This is a meaningful gap for a financial claim operation.

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 states the action, condition, and return values with no wasted words. The key information is front-loaded and easily parsed.

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 a single simple parameter, the description covers the basics: when to use it, what it does, and what it returns. However, it omits important context such as whether claim_reward must follow settle_round, whether it can only be called once, and what happens if the reward is unavailable.

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 only parameter, roomId, is already described as '房间 ID 号'. The description adds no additional parameter-level detail, 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 clearly states a specific action — claiming a USDC reward after a game ends — and describes what the tool returns (reward amount and transaction hash). This distinguishes it from siblings like mint_test_usdc or settle_round.

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 a clear usage context: '游戏结束后' (after the game ends). However, it does not explicitly mention when not to use it or name alternatives such as settle_round, so it falls slightly 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 annotations provided, the description carries the full behavioral burden. It does well by disclosing important side effects: the creator automatically joins, an entry fee is charged, and a new room ID is returned. It does not go deeper into lifecycle or failure behavior, but the key consequences of invoking the tool are 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?

The description is composed of four short, purposeful clauses: purpose, behavior, tier semantics, and return value. There is no filler or redundancy, and the most important information is front-loaded. Every sentence 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?

Given no output schema, the description appropriately states that the tool returns a new room ID. The parameter details are fully covered by the schema, and the behavioral side effects are disclosed. It could mention next steps like starting the game, but that is not required to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds some semantic value by explaining tier pacing ('Quick = fast rounds, Standard = balanced, Epic = long game'), but this largely mirrors the schema's enum labels. It does not add meaning for name, maxPlayers, or entryFee beyond what the schema already provides.

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 clearly states the verb and resource: '创建一个新的游戏房间' (create a new game room). It also distinguishes the tool from siblings by explaining that the caller becomes the room creator and automatically joins, which is unique among tools like match_room or get_arena_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 implies when to use it: when you want to create a new game room. However, it does not explicitly contrast with alternatives such as match_room or start_game, nor does it state when not to use it. The usage context is clear but exclusions are absent.

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 verb '获取' and the purpose '了解' (understand) imply a read-only observation with no state changes. It also discloses the real-time nature of the data. However, with no annotations, it doesn't explicitly state side effects, permissions, or error behavior, but for a getter this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence structured with a colon-leading enumeration of returned data, followed by a short usage instruction. Every phrase contributes information with no fluff, and the core purpose appears first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description compensates by listing the key return categories (room status, players, chat, votes, elimination history). It also places the tool in the workflow ('before taking action'), making it complete for an agent to decide and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: the only parameter, roomId, is described as '房间 ID 号'. The tool description does not add any additional semantics about how roomId is used or its format, so the baseline score of 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 ('获取' / get) and resource ('大逃杀房间的实时上下文' / battle royale room real-time context). It enumerates the exact data (room status, players with humanity scores, recent chat, current round votes, elimination history), which distinguishes it from siblings like get_round_status and get_game_history.

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 instructs to use the tool '在采取行动前' (before taking action) to understand the complete game situation, providing clear context for when to call. It does not list exclusions or alternative sibling tools, 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?

With no annotations, the description carries the full burden. It clearly indicates a non-mutating inspection action ('检查' / 'check') and reveals the concrete data the caller can expect. It could further state that this read has no side effects on the auto-play loop, but the field list already provides meaningful behavioral detail beyond the tool name.

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 resource and immediately lists the relevant metrics. Every part of the description earns its place, with no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter status read with no output schema, the description sufficiently covers what the tool returns and the general domain. It could be slightly more complete by clarifying behavior when no auto-play loop is active, but overall it provides enough context for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. There is nothing for the description to explain about parameters, and the empty schema is fully consistent with the tool's status-check purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'check the current auto-play loop progress' and enumerates the exact reported fields (rounds, humanity score, votes cast, messages sent, errors). This clearly distinguishes it from siblings like auto_play, stop_auto_play, and get_round_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 gives no guidance on when to use this tool versus sibling tools such as check_session_status or get_round_status. The intended context is implied by the name and description but not explicitly stated, and there are no exclusions or alternative routing hints.

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 annotations provided, the description carries the full burden. It transparently describes the read-only nature of retrieving history and adds useful behavioral context about what data is returned and when it is appropriate to call. It does not explicitly state side-effect-free behavior or error conditions, but the get semantics and content enumeration are sufficiently clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with no filler. The core purpose and contents are front-loaded, and the usage timing is stated second. Every word 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 simple tool with one parameter, no output schema, and no annotations, the description covers the main things an agent needs: what the tool returns and when to use it. It could optionally describe the output format or behavior when no finished game exists, but the current description is sufficient for correct selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the single required parameter roomId is already documented in the schema. The tool description adds no extra meaning beyond implying that history is scoped to a specific room, so the baseline score 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 uses a specific verb (获取/get) and resource (完整的游戏历史), and enumerates exactly what is included: all votes per round, elimination order, and game results. This clearly distinguishes it from sibling tools like get_round_status or get_arena_status, which target current state rather than full history.

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 explicitly says the tool is best used after a game ends or for reviewing past games, giving clear timing context. It does not explicitly contrast with alternatives or state when not to use it, so it stops short of a perfect 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?

There are no annotations, so the description carries the full burden. It does disclose the output contents (round number, vote status, blocks left) and the verb '获取' implies a read-only operation. However, it does not explicitly state that there are no side effects, nor does it address possible errors, prerequisites, or authentication requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the primary action and then lists specific data points. There is no redundant or filler content, making it optimally concise.

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 no annotations, the description is the only source of return-value information and it covers the key fields clearly. Minor gaps exist around data types or error conditions, but for a simple status check with one parameter, the description is largely complete.

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% for the only parameter (roomId), so the schema already fully documents it. The description adds no additional meaning about roomId, which is acceptable since the schema handles it; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('获取') and resource ('详细的轮次信息'), and enumerates the exact data returned: current round number, whether the user voted, and blocks remaining until settlement. This level of detail distinguishes it from sibling tools like get_arena_status or get_game_history, even without naming 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?

The description gives no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The only signal is the tool name and the 'round information' phrasing, which implies usage but does not state when to choose it over get_arena_status or check_session_status.

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 annotations are provided, so the description takes on the full behavioral burden. It usefully discloses that the wallet will sign all chain operations, but it does not mention whether an existing session is overwritten, how the private key is stored, or any security/side-effect implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences that front-load the primary purpose and then add a consequential behavioral detail. There is no redundant or filler content, and 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 simple single-parameter tool with full schema coverage and no output schema, the description adequately covers what the tool does and its key behavioral effect. It omits return-value details and session-overwrite behavior, but these are less critical given the tool's simplicity and the explicit signing side effect.

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 privateKey parameter is already fully documented in the schema. The description only repeats that a private key is passed in, adding no new semantic detail beyond what the schema provides.

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 action ('initialize') on a specific resource ('wallet for the game') and clarifies that the wallet will sign all on-chain operations, which distinguishes it from sibling tools like check_session_status or create_room. The purpose is unambiguous and non-tautological.

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 word 'initialize' implies this should be called before other on-chain operations, and the mention of signing all operations suggests a session prerequisite. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or compare with sibling tools.

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 annotations provided, the description carries the full burden of behavioral disclosure. It discloses that leaving is only possible before start, that a creator leaving triggers refunds for all players and room cancellation, and that the entry fee is refunded in USDC. It does not fully specify non-creator refund behavior or failure conditions, but the provided behavior 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?

The description is two sentences long, front-loads the core action and constraint, and every sentence contributes useful information: when the tool applies, what the creator case does, and the refund currency. There is no redundant wording.

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 single-parameter tool with no output schema and no annotations, the description covers the main use case, the timing restriction, and the creator-specific cancellation and refund behavior. It is slightly incomplete in that the non-creator consequence is only implied and no return or failure behavior is mentioned, but it is generally adequate.

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%: the single roomId parameter is already described as '房间 ID 号'. The description adds no additional parameter-level detail, so a baseline score of 3 is appropriate since the schema already documents the parameter sufficiently.

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 ('leave'), a resource ('room'), and a clear temporal scope: '尚未开始的房间（仅等待阶段）'. This clearly differentiates the tool from siblings like create_room, match_room, and start_game, which involve different phases or actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly restricts usage to the waiting phase ('仅等待阶段') and specifies the creator vs. non-creator context. It does not name alternative tools or state explicit when-not-to-use conditions beyond the waiting-phase restriction, 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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It explains the happy-path behavior—scanning and joining—but does not disclose side effects, such as what happens if the user is already in a room, whether the operation is reversible, what errors may occur, or what the response contains. This is a significant gap for a state-changing join operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: it states the core behavior first, then the availability check, then the fallback. Every sentence earns its place, and there is no redundant wording.

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 description covers the main workflow and fallback, which is enough for basic invocation. However, with no output schema and no annotations, it omits useful context about the response format, failure behavior, or whether joining affects an existing room membership. It is adequate but not complete.

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 all six parameters are already documented. The description adds no extra parameter-specific meaning, but it does not need to because the schema handles parameter semantics. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific action and resource: scanning available rooms and joining the first matching waiting room. It also clearly distinguishes match_room from create_room by stating that create_room is the fallback when no room matches.

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 provides clear context for when to use the tool: when the user wants to match into a waiting room automatically. It explicitly recommends create_room if no room matches, which gives an alternative. However, it does not mention when to avoid match_room or use other related tools like get_arena_status first.

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 annotations, the description carries the full burden. It discloses that this is a minting operation, the destination wallet, and the supported environments, which is useful. However, it does not explain network prerequisites, whether the operation is irreversible, or what happens if used outside the supported environments.

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 contain zero filler. The first sentence states the action and environment, and the second gives the concrete use case, making the description easy to scan and act on.

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 mint tool with no output schema, the description covers the core context: what it does, where it works, and when to use it. It could be slightly more complete by describing failure behavior or prerequisites, but nothing essential blocks an agent from calling 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 schema already describes the only parameter ('amount') with type, min/max, and an example, so description coverage is 100%. The tool description adds no additional meaning about the parameter beyond what the schema provides, meriting the baseline score of 3.

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?

Description uses a specific verb ('铸造/mint') with a clear object ('测试 USDC') and target ('你的钱包'), stating exactly what the tool does. It also differentiates itself from the sibling game-management tools by naming its funding purpose and the test-network environment.

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 states when to use it ('在加入游戏前为你的机器人提供资金') and explicitly limits it to local Anvil or MockUSDC testnets. It does not name an alternative tool or list exclusion cases beyond the environment, so it falls just short of fully explicit 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?

由于没有任何注解，描述承担了全部行为披露责任。它披露了关键副作用“触发淘汰得票最多的玩家”、开放调用权限以及区块时间约束，这些信息超出工具名称本身能推断的内容，对代理预判状态变更很有价值。但未说明平票处理、调用是否可逆或失败时的行为，存在少量信息缺口。

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?

三句话各司其职：第一句说明核心用途，第二句说明调用条件，第三句说明副作用。没有任何冗余文字，关键信息前置，结构紧凑高效。

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?

对于单参数且无注解的工具，描述已覆盖用途、调用条件、调用者权限和主要游戏状态影响，搭配 100% 的参数 schema 覆盖，整体足够支持代理正确调用。缺失点在于平票或无效轮次等失败场景的处理方式，以及无输出 schema 时未提及返回值信息，但考虑到兄弟工具 get_round_status 承担状态查询职责，此为轻微缺口。

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 描述覆盖率为100%，roomId 已在 schema 中被解释为“房间 ID 号”，描述本身没有为参数增加任何超出 schema 的语义信息，因此按高覆盖率基准评为3分。

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?

描述使用具体动词“结算”和资源“当前轮次”，并说明目的是“推进游戏”，让代理清楚这是一个推进游戏状态的行动型工具。它与 get_round_status（只读）和 start_game（开始新局）在语义上可区分，但没有显式点名任何兄弟工具来划清边界，因此未达到5分。

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?

描述明确给出调用条件：“任何人都可以”以及“经过足够的区块后”，这在权限和时间维度上都是可操作的指导，帮助代理判断何时能安全调用。但未说明何时不应调用（如轮次已结算或票数平局时）也未列出替代工具，缺少排除性指引。

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 annotations provided, the description carries the full burden of behavioral disclosure. It does reveal two important behavioral constraints: only the room creator can call it, and a minimum of 3 players is required. However, it does not disclose what happens after a successful call (e.g., game state transition to active), what errors occur if conditions are not met, or any side effects. This is a minimum viable level of transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences with no redundant information. The action is stated first, followed by the key constraints. Every part contributes to understanding the tool's purpose and usage.

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 description covers the essential preconditions for calling the tool, but given the lack of an output schema and annotations, it does not explain the return value or expected behavior after starting the game. For a simple single-parameter tool, this is a noticeable but not critical gap, making it adequate but incomplete.

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 parameter roomId is already documented in the schema. The description adds no additional meaning or syntax detail beyond what the schema provides. The baseline of 3 is appropriate here because the description does not enhance parameter understanding.

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 clearly states the action ('start a game') and the specific resource ('a game in the waiting phase'), distinguishing it from sibling tools like create_room or match_room. It also adds concrete conditions (creator-only, at least 3 players) that define the tool's scope precisely.

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 provides clear context for when the tool should be used: when the room creator intends to start a game that is in the waiting phase and has at least 3 players. However, it does not explicitly mention alternative tools (e.g., 'use create_room to create a new room'), so it lacks explicit exclusion 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?

No annotations are provided, so the description carries the full burden of disclosing behavior. It does state the terminating effect and that final statistics are returned, but it omits details such as what happens if no loop is running, whether the stop is reversible, or any side effects beyond termination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no redundant words. It front-loads the primary action ('stop') and immediately follows with the expected return value, making it easy to parse.

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 tool with no output schema and no annotations, the description provides the essential behavioral contract: it stops the loop and returns final statistics. The return value is described only vaguely, but in context this is sufficient for an agent to select and invoke the tool appropriately.

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 input schema is empty (0 parameters), so the description has no obligation to explain parameter meanings. Per the rubric, zero-parameter tools receive a baseline of 4, and the description does not introduce conflicting or redundant param information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('stop') and a specific resource ('the running auto-play game loop'), and clearly states the outcome ('return final statistics'). This distinguishes it from siblings like auto_play and get_auto_play_status without needing to open their definitions.

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 phrase '正在运行的' (running) signals that the tool should only be used when an auto-play loop is active, providing clear context. However, it does not explicitly name alternatives or state when not to use it, which keeps it just below a top score.

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