Server Quality Checklist

Tool Scores

• balatro_skip_packC
  2.1/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the annotations. While destructiveHint=true already flags destructive behavior, the description does not explain what skipping entails (e.g., pack discarded, irreversible) or whether it requires an opened pack.

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

  Conciseness3/5

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

  The description is extremely brief, making it concise in length, but this brevity sacrifices clarity. The single sentence is under-specified and does not earn its place as useful guidance.

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

  Completeness2/5

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

  Given the destructive annotation and the need to skip an opened pack, the description lacks essential details about consequences, prerequisites, or state management. With no output schema, the description should clarify expected behavior but fails to do so.

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

  Parameters3/5

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

  The description does not mention the expected_state_token parameter, but schema coverage is 100% and the schema already describes it as '最新 state_token；必填'. The description adds no extra semantic value beyond the schema.

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

  Purpose2/5

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

  The description '映射上游 pack {skip:true}' is cryptic and does not clearly state that the tool skips an opened pack. The title provides some clarity, but the description itself lacks a specific verb+resource action and does not distinguish from sibling tools like skip_blind.

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

  Usage Guidelines1/5

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

  No guidance is provided on when to use this tool versus alternatives. The description gives no context about prerequisites (e.g., having an opened pack) or scenarios where skipping is appropriate.

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

• balatro_choose_pack_itemB
  3.3/5.0
  Behavior3/5

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

  Annotations already mark the tool as destructive and not read-only. The description adds one behavioral constraint: the agent must not guess Tarot/Spectral target counts. But it does not say what gets consumed, what happens after the choice, or how expected_state_token is validated, so behavioral disclosure remains limited.

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

  Conciseness4/5

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

  The description is very short and contains no filler. However, the phrase '映射上游 pack {card, targets}' is cryptic and could be clearer; despite being brief, it sacrifices some clarity for compactness.

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

  Completeness3/5

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

  Given the destructive annotation and lack of an output schema, the description does not fully explain the consequences of choosing an item or the expected return. It gives one important operational warning but otherwise relies on the title and schema, making it adequate but with clear gaps.

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

  Parameters4/5

  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 meaning beyond the schema by warning not to guess Tarot/Spectral target counts, clarifying that target_cards must be explicitly provided and should not be inferred. This is useful extra semantics for the target_cards parameter, while item_index and expected_state_token are already well described in the schema.

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

  Purpose3/5

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

  The title clearly says 'Choose an opened pack item', but the description itself, '映射上游 pack {card, targets}', describes an internal mapping rather than explicitly stating the purpose. It is not as clear as a direct 'chooses the item at index N from the opened pack' and does not distinguish itself from skip_pack in the description.

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

  Usage Guidelines3/5

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

  The description includes '不猜测 Tarot/Spectral 目标数量', which implies the agent must provide exact target_cards when needed rather than inferring them. However, it gives no explicit 'use when' context, no exclusions, and no comparison to alternative actions like skip_pack.

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

• balatro_select_blindB
  3.3/5.0
  Behavior3/5

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

  The description adds the note '所有旧索引在动作后失效' (all old indexes become invalid after the action), which is a behavioral consequence not captured by the annotations. However, it does not elaborate on other side effects like state token consumption or irreversibility, with annotations already marking this as destructive.

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

  Conciseness5/5

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

  The description is exceptionally concise: two short sentences. The first states the purpose, and the second provides a necessary behavioral warning. No filler or redundant content exists.

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

  Completeness3/5

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

  For a one-parameter action with no output schema, the description provides the essential purpose and an invalidation note. However, it lacks context about game progression (e.g., what happens after selecting a blind) and does not mention when selection is appropriate versus skipping. It is minimally adequate but not thorough.

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

  Parameters3/5

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

  The schema description fully covers the only parameter expected_state_token ('最新 state_token；必填'), so the tool description adds no additional semantic meaning. Baseline 3 is appropriate given 100% schema coverage.

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

  Purpose4/5

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

  The description clearly states the action: '选择当前 Blind' (Select current Blind) with a specific verb and resource. It is distinguishable from the sibling 'balatro_skip_blind' by the explicit 'select' wording, though it does not explicitly differentiate itself from alternatives.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like balatro_skip_blind. The description assumes game context that an agent may not have, offering no conditions or exclusions.

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

• balatro_use_consumableB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare destructiveHint: true. The description adds that target rules are 'ultimately subject to BalatroBot validation and rejection results,' disclosing a validation/rejection behavior not captured by annotations. However, it does not explain what is destroyed or what the target rules entail, so the added context is limited.

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

  Conciseness5/5

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

  Two short sentences, front-loaded with the purpose. The second sentence adds a necessary behavioral caveat without unnecessary detail. The description is concise and well-structured with no filler.

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

  Completeness2/5

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

  With no output schema, the description should clarify what happens when a consumable is used and what the tool returns. It only provides a vague validation caveat, leaving the overall effect and appropriate use cases unclear. The schema helps with parameters but not with behavioral context.

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

  Parameters3/5

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

  The input schema covers all three parameters with descriptive meanings: consumable_index (0-based index), target_cards (hand indices when needed), and expected_state_token (latest state token). The description adds no extra parameter semantics, and with 100% schema coverage the baseline of 3 applies.

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

  Purpose5/5

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

  The description states '使用消耗牌' (use a consumable card), which clearly specifies the verb and resource. This distinguishes it from sibling tools like play_cards and discard_cards by focusing on consumables. The caveat about validation does not obscure the primary purpose.

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

  Usage Guidelines2/5

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

  The description offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, contexts where a consumable should be used, or how it differs from other actions. The validation caveat is not a usage guideline.

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

• balatro_discard_cardsA
  3.6/5.0
  Behavior3/5

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

  Annotations already mark this as destructive (destructiveHint=true), so the mutation is transparent. The description adds a useful behavioral note about checking the remaining discard count before acting, but does not disclose other consequences like card removal or state token requirement beyond the schema.

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

  Conciseness5/5

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

  The description is a single concise sentence, front-loaded with the action and state, with no redundant information. It effectively communicates the essential guidance in one line.

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

  Completeness4/5

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

  For a simple discard tool with two well-described parameters, the description covers the necessary state (SELECTING_HAND) and a key precondition (checking discards). It could mention error handling or post-effects, but given the annotations and schema, it is adequately complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, and both parameters (cards, expected_state_token) are well-documented in the schema. The description does not add extra parameter meaning, 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.

  Purpose4/5

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

  The description clearly identifies the action as discarding ('弃牌') in the specific game state 'SELECTING_HAND', which distinguishes it from sibling tools like balatro_play_cards. The title also reinforces the purpose. However, it could be more explicit about what 'discard' results in.

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

  Usage Guidelines3/5

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

  The description provides some usage context by specifying '在 SELECTING_HAND 弃牌' and instructing to '先检查剩余弃牌次数' (first check remaining discard count). This implies a precondition but does not explicitly compare with alternatives or state when not to use, such as preferring play_cards.

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

• balatro_play_cardsA
  3.7/5.0
  Behavior4/5

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

  Annotations mark the tool as destructive and non-readOnly, but the description adds the crucial behavioral note that it 'does not automatically retry.' This goes beyond the annotations and is important for the agent to know that failed attempts won't be silently repeated. However, other behavioral details (e.g., state progression) are not disclosed.

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

  Conciseness5/5

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

  The description is exceptionally concise: two short sentences with no filler. The key information (action and phase) is front-loaded, and the no-retry note is a valuable addition without unnecessary length.

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

  Completeness3/5

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

  For a simple action with two well-documented params, the description is adequate but leaves gaps. It does not explain what happens after playing cards (e.g., state change, score evaluation, or the need to use the returned state token). Given the state-token mechanism, this missing information could be critical for the agent's next steps.

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

  Parameters3/5

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

  The input schema provides complete documentation for both parameters (distinct 0-based indices, required latest state_token), so the description does not need to add parameter details. It adds no extra parameter context beyond the schema, matching the baseline for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the action ('Play cards') and the context ('SELECTING_HAND'), distinguishing it from sibling tools like balatro_discard_cards. The title also reinforces the purpose, but it lacks detail on what 'play' entails in terms of game mechanics.

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

  Usage Guidelines3/5

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

  It explicitly mentions the phase SELECTING_HAND, which indicates when to use it. However, it does not explicitly contrast with alternatives or provide exclusions, such as 'use discard instead when you want to remove cards.' The phase implication is useful but not fully elaborated.

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

• balatro_cash_outA
  3.8/5.0
  Behavior3/5

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

  Annotations already flag the tool as destructive and non-read-only, so the mutating nature is known. The description adds the ROUND_EVAL availability and shop transition, which is useful, but it doesn't detail what exactly is finalized or whether any actions become irreversible beyond the annotation. This is adequate but not rich.

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

  Conciseness5/5

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

  The description is a single compact sentence that front-loads the availability constraint and then states the action and result. There is no filler or redundant information, making it appropriately concise.

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

  Completeness4/5

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

  For a simple state-transition tool, the description covers when it can be used and what it does, and with annotations and schema covering safety and parameters, it is reasonably complete. It lacks output-format detail, but no output schema exists, so this is acceptable.

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

  Parameters3/5

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

  The only parameter, expected_state_token, is fully described in the schema as the latest state token and required. The description adds no parameter-level insight, but with 100% schema coverage, the baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description states the action clearly: 'settles rewards and enters the shop' and restricts it to ROUND_EVAL, which distinguishes it from siblings like play_cards or next_round. However, it does not specify what rewards are included (e.g., money, interest), leaving slight ambiguity.

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

  Usage Guidelines4/5

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

  The phrase '仅 ROUND_EVAL 可用' gives an explicit precondition for when the tool may be called, which is strong guidance. It doesn't name alternatives or exclusions beyond the state gate, but the context is sufficient for the agent to decide when to invoke it.

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

• balatro_buy_shop_itemA
  4/5.0
  Behavior4/5

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

  Annotations already mark this as destructive. The description adds valuable behavioral details: it performs validations (SHOP, index, funds, slot insufficiency) before buying. This goes beyond the annotations, though it doesn't describe the full side effects (e.g., item removal, money deduction).

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

  Conciseness5/5

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

  The description is a single, concise sentence in Chinese. It front-loads the primary action and adds a compact validation note. No wasted words.

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

  Completeness4/5

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

  For a straightforward shop-buy action with three parameters and no output schema, the description covers the core purpose and important preconditions. It lacks details about post-buy state changes, but the destructive annotation and game context make it sufficiently complete for the agent.

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

  Parameters3/5

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

  Schema description coverage is 100%, with each parameter (kind, index, expected_state_token) already documented. The description adds no parameter-specific meaning beyond mentioning 'index' and 'funds' in the validation context, which is not substantial.

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

  Purpose5/5

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

  The description states a specific verb and resource: '购买商店物品' (buy a shop item). It clearly distinguishes this from siblings like sell_item and discard_cards. The additional validation mention further clarifies the tool's scope.

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

  Usage Guidelines3/5

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

  The description implies usage when the agent wants to purchase a shop item, but provides no explicit guidance on when not to use it or alternatives. The validation note ('先校验 SHOP、索引、资金及明显的槽位不足') gives context about preconditions but not tool selection.

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

• balatro_capabilitiesA
  4/5.0
  Behavior4/5

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

  Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds useful context about filtering out disabled debug tools and returning 'required state', which are behavioral traits beyond the annotations. No contradictions found.

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

  Conciseness5/5

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

  The description is a single concise sentence that front-loads the core purpose and includes a relevant exclusion clause. No unnecessary words or repetition.

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

  Completeness4/5

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

  For a simple capabilities-discovery tool with no output schema, the description adequately states what is returned (parameters and required state) and what is excluded. The ambiguous phrase 'required state' is minor but the overall context is sufficient.

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

  Parameters3/5

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

  Schema description coverage is 100% with the 'refresh' parameter fully described. The tool description does not add parameter-level meaning, but the schema already carries that burden, so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool returns 'safe methods' parameters and required state, and explicitly excludes disabled debug tools. It distinguishes itself from sibling game-action tools by focusing on capability discovery.

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

  Usage Guidelines3/5

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

  The description implies usage for discovering safe methods but does not explicitly state when to use it versus alternatives or provide exclusions. The name 'capabilities' adds context, but the guidance is implicit rather than direct.

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

• balatro_rearrangeA
  4/5.0
  Behavior4/5

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

  Annotations already declare destructiveHint=true and readOnly=false, so the safety profile is known. The description adds valuable behavioral context by stating that 'order 不得缺失、重复或越界' (order must not be missing, duplicate, or out of bounds), which specifies the exact validation constraint. It does not elaborate on reversibility or effects, but the destructive flag covers the main concern.

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

  Conciseness5/5

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

  The description is one concise sentence that states the action and the key constraint, with no wasted words. It is appropriately front-loaded and serves as a minimal yet effective summary.

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

  Completeness4/5

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

  For a simple reorder tool with full schema coverage and clear annotations, the description is sufficiently complete. It covers the core operation and the critical ordering constraint, though it does not mention failure cases or return values. The absence of an output schema reduces the need for return value documentation.

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

  Parameters3/5

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

  Schema description coverage is 100%, with detailed descriptions for all three parameters: area enum, order as a full permutation, and expected_state_token. The description repeats the permutation constraint but does not add new parameter semantics beyond the schema's existing coverage.

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

  Purpose5/5

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

  The description states a specific action: '重新排序指定区域' (reorder the specified area), with a clear verb and resource. This clearly distinguishes it from sibling tools like play_cards, discard_cards, or use_consumable, as reordering is a unique operation.

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

  Usage Guidelines3/5

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

  The description implies usage for reordering a card area, but does not explicitly state when to use this tool versus alternatives. It does not mention prerequisites or conditions, though the required expected_state_token is implied by its presence in the schema. The guidance is only implied, not explicit.

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

• balatro_reroll_shopA
  4/5.0
  Behavior4/5

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

  Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds a meaningful side-effect disclosure: '商店索引在刷新后全部失效' (all shop indices become invalid after refresh), which is behavioral context beyond annotations. No contradiction detected.

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

  Conciseness5/5

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

  The description is extremely concise—one short sentence with two clauses—and every part earns its place: availability condition and invalidation side-effect. It is front-loaded and free of filler.

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

  Completeness4/5

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

  This is a simple tool with one parameter and no output schema. The description covers the critical constraints (SHOP-only usage and index invalidation) and is adequate for an agent to use it correctly. A slight additional statement about what rerolling actually does (e.g., refreshes items) would make it fully complete, but the title provides that.

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

  Parameters3/5

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

  The single parameter expected_state_token is fully documented in the schema (100% coverage), so the description does not need to add parameter details. The baseline of 3 applies because the schema carries the burden and the description does not contradict or add extra parameter meaning.

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

  Purpose4/5

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

  The title 'Reroll the shop' clearly identifies the action and resource, distinguishing it from siblings like buy/discard/sell. The description adds availability context but does not explicitly restate the core purpose, relying on the title for that.

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

  Usage Guidelines4/5

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

  The description states '仅 SHOP 可用' (only available in SHOP), providing clear context for when the tool is applicable. It does not mention alternatives or explicit exclusions, but the condition is a useful usage guideline.

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

• balatro_sell_itemA
  4/5.0
  Behavior4/5

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

  Annotations already mark the tool as destructive and not read-only. The description adds a specific behavioral constraint (Eternal Joker rejection) that is not captured in structured data. It does not contradict annotations, and the extra detail provides useful context beyond the basic safety profile.

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

  Conciseness5/5

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

  The description is a single concise sentence that front-loads the main action and includes a key caveat. Every word is informative, with no filler or repetition relative to the schema/annotations.

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

  Completeness4/5

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

  For a simple destructive action with full schema coverage and no output schema, the description covers the crucial operation and the main behavioral exception. It could optionally mention the outcome of a successful sale (e.g., removal and monetary gain), but the core context is sufficient for correct invocation.

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

  Parameters3/5

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

  Schema description coverage is 100%, and parameter descriptions in the schema are clear (kind, index, expected_state_token). The description adds no additional parameter-level meaning, so the baseline of 3 is appropriate because the schema already carries the semantic load.

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

  Purpose5/5

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

  The description clearly states the action ('出售' = sell) and the resource ('Joker 或消耗牌' = Joker or consumable), making the tool's purpose unambiguous. It also distinguishes itself from sibling tools like 'use_consumable' by specifying the selling action, not just using.

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

  Usage Guidelines3/5

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

  The description does not explicitly compare with alternatives or state when to use selling vs. using. However, the note that 'Eternal Joker 会提前拒绝' provides a clear exclusion condition (don't attempt to sell Eternal Jokers), giving some usage guidance. Overall usage context is implied but not fully articulated.

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

• balatro_get_stateA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context: it should be invoked before every action and the decision view returns a state_token plus valid indices, going beyond the structured annotations without contradicting them.

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

  Conciseness5/5

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

  Two short sentences, front-loaded with the core purpose, and no redundant words. Every sentence adds value: the first states the action and timing, the second describes the return contents.

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

  Completeness4/5

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

  Given the simple tool, rich annotations, and full schema coverage, the description provides enough context: when to call it, what the decision view returns, and that full retains all upstream fields. It doesn't detail the full output structure, but there's no output schema and the description adequately compensates for typical use.

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

  Parameters4/5

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

  The schema fully describes the 'view' parameter (100% coverage), and the description enriches it by explaining that 'decision' returns state_token and all valid 0-based indices, while 'full' retains upstream fields. This adds practical meaning beyond the enum names.

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

  Purpose4/5

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

  The description clearly states the tool reads the latest state and explicitly says to call before each action. It also specifies that the decision view returns state_token and valid 0-based indices, distinguishing it from action-oriented siblings like balatro_available_actions, though it doesn't explicitly contrast with them.

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

  Usage Guidelines4/5

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

  Provides clear when-to-use guidance via '每次动作前调用' (call before every action), which is strong contextual direction. It does not mention when not to use it or name alternative tools, so it falls short of a 5.

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

• balatro_available_actionsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safe read-only nature is covered. The description adds context beyond this: it lists both allowed and disallowed operations, not just a whitelist, and it returns the latest state_token. This gives the agent useful behavioral expectations not present in the structured fields.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that states the core action (list), the subject (allowed/disallowed write operations), the conditions (stage, resources, index range), and the return value (state_token). Every element is necessary, with zero waste or fluff.

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

  Completeness4/5

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

  For a simple, parameterless query tool with strong annotations and no output schema, the description adequately conveys what the tool returns: a list of legal/illegal write operations and a state_token. It does not specify the exact output format (e.g., plain names vs. structured objects), but that is not essential given the tool's simplicity and the absence of an output schema.

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

  Parameters4/5

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

  This tool has zero parameters, and schema description coverage is 100% (vacuously). With no parameters to document, the description is not expected to add parameter details. The baseline for 0 params is 4, and the description does not need to compensate for any schema gaps.

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

  Purpose5/5

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

  The description uses a specific verb ('列出' / lists), identifies the resource ('允许及不允许的写操作' / allowed and disallowed write operations), and states the criteria (current stage, resources, index range). This clearly distinguishes it from sibling action tools like balatro_discard_cards or balatro_play_cards, which perform actions rather than list them.

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

  Usage Guidelines3/5

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

  The description implies usage context: it is relevant to the current stage, resources, and index range, and it returns a state_token. However, it does not explicitly state when to use this tool versus alternatives like balatro_get_state, nor does it provide exclusions (e.g., 'use this before any action to verify legality'). Guidance is only implied, not explicit.

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

• balatro_healthA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the notable behavior of returning macOS repair commands when offline, which is useful context 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.

  Conciseness5/5

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

  The description is a single sentence that is front-loaded with the action and targets, with zero wasted words.

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

  Completeness4/5

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

  For a zero-parameter, read-only diagnostics tool, the description provides adequate context: what is checked and the offline repair-command behavior. It does not explain the output format, but no output schema exists, so the description carries that burden lightly; minor ambiguity about what 'offline' refers to.

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

  Parameters4/5

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

  The tool has zero parameters and the schema is empty, so there is nothing for the description to add. With no parameters, a baseline of 4 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool checks MCP, BalatroBot, rpc.discover, and current game state, distinguishing it from sibling action tools. The verb '检查' (check) and specific resources make the purpose unambiguous.

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

  Usage Guidelines3/5

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

  The description implies use for health diagnostics and mentions offline behavior with macOS repair commands, but it does not explicitly contrast with overlapping siblings like balatro_capabilities or balatro_get_state, nor state when not to use it.

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

• balatro_next_roundA
  4.2/5.0
  Behavior4/5

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

  Annotations already mark this as destructive (destructiveHint=true) and read-only=false, so the mutating nature is known. The description adds that it is only available in the shop and that it leads to the next Blind selection, providing useful behavioral context beyond annotations.

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

  Conciseness5/5

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

  The description is one short sentence that states the availability and outcome, with no wasted words. It is appropriately sized for a simple navigation action.

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

  Completeness4/5

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

  Given the simple action, the description provides sufficient context (shop-only, next Blind). No output schema exists, but for this tool the return value is not critical. It could mention irreversibility, but annotations already signal destructiveness.

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

  Parameters3/5

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

  The schema covers 100% of the parameter with description '最新 state_token；必填' (latest state_token; required). The tool description adds no extra parameter details, but since schema coverage is full, baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states '仅 SHOP 可用，进入下一次 Blind 选择' (only available in shop, proceed to next Blind selection), specifying the action and resource. It distinguishes from sibling tools like select_blind and skip_blind by its scope (leaving the shop).

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

  Usage Guidelines4/5

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

  The description explicitly states '仅 SHOP 可用' (only available in SHOP), giving a clear condition for use. It doesn't explicitly name alternatives, but the context and sibling list make it obvious that this is for leaving the shop phase rather than selecting/skipping a blind directly.

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

• balatro_skip_blindA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate destructiveHint=true, but the description adds the key behavior that Boss Blind is rejected locally. This is valuable context beyond the annotations, warning the agent that attempting to skip a Boss Blind will fail. It does not elaborate on other side effects, but the added rejection behavior justifies a 4.

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

  Conciseness5/5

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

  The description is a single, compact sentence that fully conveys the tool's purpose and a key behavioral exception. No filler words, and all necessary information is front-loaded.

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

  Completeness4/5

  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 and no output schema, the description covers the essential scope (non-Boss blinds) and the rejection behavior. It doesn't mention return values, but the presence of get_state and other sibling tools makes that less critical. Overall, adequate for reliable invocation.

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

  Parameters3/5

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

  The input schema fully describes the only parameter (expected_state_token) with its purpose and requirement. The description adds no extra meaning about the parameter, so the baseline of 3 is appropriate given 100% schema coverage.

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

  Purpose5/5

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

  The description clearly states the action: 'Skip Small/Big Blind', with a specific verb and resource. It also distinguishes from sibling tools by excluding Boss Blind. The title reinforces the non-Boss scope, making the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description implies when to use this tool: when the current blind is a Small or Big Blind. It explicitly notes Boss Blind will be rejected, which serves as an exclusion. While it doesn't name alternatives like 'select_blind', the context is clear enough for an agent.

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

• balatro_start_runA
  4.3/5.0
  Behavior5/5

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

  Despite destructiveHint=true, the description discloses a key behavioral nuance: it will not overwrite or reset an existing game. It also adds a state restriction (MENU only). These details go well beyond the annotations and help the agent predict side effects.

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

  Conciseness5/5

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

  The description is one compact sentence that states two crucial constraints without any redundancy. It is front-loaded and easy to parse.

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

  Completeness3/5

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

  The description covers availability and non-destructive behavior, but since there is no output schema, it doesn't explain what the tool returns or how expected_state_token relates to the call flow. It's adequate for a simple action but leaves some operational context implicit.

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

  Parameters3/5

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

  The schema already provides descriptive text for all 4 parameters (100% coverage), so the description doesn't need to repeat parameter details. The description itself adds no parameter-specific guidance, which matches the baseline for high schema coverage.

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

  Purpose5/5

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

  The tool name and title clearly state 'Start a Balatro run', and the description adds scope by specifying it only works in MENU and won't overwrite an existing game. This differentiates it from all in-run sibling tools (play, discard, buy, etc.).

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

  Usage Guidelines4/5

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

  The description gives an explicit when-to-use condition: '仅 MENU 可用' (only available in MENU). It also clarifies it won't reset an existing run. It doesn't name alternatives, but no sibling tool serves the same purpose, so this is a clear contextual guideline.

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