Silicon Pantheon

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

With no annotations provided, the description fully discloses behavioral traits: both units may take damage, either may die, and the unit becomes DONE after attacking. It also mentions the return value includes damage dealt, counter-damage received, and kill status. These details go beyond the schema and annotations, though it doesn't discuss reversibility or concurrency.

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 concise at three sentences, with the key action word 'Mutating' front-loaded. Every sentence provides essential information: purpose, preconditions, behavior, and output. No unnecessary words.

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 adequately explains the return value (combat result with damage and kill status). It covers preconditions, effects, and post-state. The sibling tools 'simulate_attack' and 'get_legal_actions' complement the description, making it complete for an action 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?

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining status constraints for 'unit_id' (must be READY or MOVED) and range requirement for 'target_id', which are not fully captured in the schema descriptions. This adds value beyond the schema.

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

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

The description clearly states the tool's action ('Mutating. Attack an enemy unit, resolving combat and counter-attack immediately') and distinguishes it from sibling tools like 'simulate_attack' (preview) by emphasizing immediate execution. It also links to 'get_legal_actions' for range checking, providing specific verb and resource context.

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

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

The description provides clear preconditions for using the tool: the attacker must be in READY or MOVED status and the target must be within attack range. It explicitly advises previewing with 'simulate_attack' first, and notes that after attacking the unit's status becomes DONE. While it doesn't state when NOT to use it, the context is sufficient for selection.

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 full responsibility. It discloses that the tool is mutating, ends the match, records the result in the leaderboard, and notes post-match actions (download replay or leave). This is comprehensive behavior 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 concise with two sentences, no redundant words, and front-loads the core purpose and action. Every sentence adds value.

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 the tool's simplicity (1 parameter, no output schema), the description covers all necessary context: state requirement, effects, leaderboard recording, and alternative tool. It is complete for an agent to use 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 only parameter 'connection_id' has a schema description 'Your server session identifier.' The tool description does not add further meaning beyond that. With 100% schema coverage, a 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 clearly states the tool's action: 'Resign the match — the opponent wins immediately.' It specifies the verb (concede/resign) and resource (match), and distinguishes from the sibling tool 'leave_room' by explaining when each should be used.

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 states the requirement 'Requires state=in_game' and provides guidance on when to use the alternative 'leave_room' to combine conceding and returning to the lobby. This helps the agent decide between 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, the description discloses that the tool is mutating, auto-waits units in READY/MOVED status, immediately starts opponent's turn, and returns an error if misused. This fully covers behavioral traits.

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 concise with no redundant sentences. It starts with a key behavioral hint ('Mutating') and efficiently covers purpose, usage, and side effects in a few sentences.

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 one simple parameter and no output schema, the description is complete. It explains the action, necessary preconditions (after all commands), behavior (auto-wait), and error handling, leaving no essential information missing.

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

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

Schema coverage is 100% for the single parameter connection_id, which is well-described in the schema. The description does not add additional meaning to the parameter, so baseline 3 is appropriate.

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

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

The description clearly states the tool ends the turn and passes control to the opponent. It distinguishes from sibling tools (e.g., attack, move) by specifying it is the turn-ending action, not an in-turn command.

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 states when to call: exactly once per turn after all other commands. It also notes an error condition if it's not the agent's turn, providing clear usage boundaries.

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?

Declares 'Read-only' upfront, implying no side effects. Details returned data structure and control parameter last_n. With no annotations, the description fully discloses 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?

Two well-structured sentences. First sentence packs purpose and content. Second sentence adds usage guidance and alternative. No wasted words.

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 the tool's simple nature and full schema coverage, the description provides all necessary context: what is returned, why to use it, and when to choose an alternative. No output schema exists, but return fields are described.

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 baseline is 3. Description adds context: 'last_n controls how many actions to return (default 10, max 100)' and clarifies connection_id as server session identifier, going beyond schema descriptions.

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 'Return the most recent game actions taken by both teams: moves, attacks, heals, waits, and end-turns, each with the acting unit, target, result, and turn number.' It distinguishes from sibling tools like get_match_telemetry by specifying its focus on action 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 advises when to use: 'Use this at turn start to understand what the opponent did last turn, especially under fog-of-war.' Also provides alternative: 'For aggregate match statistics use get_match_telemetry instead.'

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?

Declares read-only nature and describes return values. Mentions error scenarios but doesn't elaborate on rate limits or detailed side effects. However, as a read-only tool, this is largely sufficient.

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

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

Four concise sentences front-loaded with purpose and outputs, followed by constraints and usage guidance. No redundant information.

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

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

Covers the returned types well, but given no output schema, it could briefly mention the format. Still, it adequately prepares the agent to use the tool correctly among many siblings.

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 description adds critical context: unit_id is from get_state and must be in READY/MOVED status, connection_id is server session identifier. Enhances schema 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 tool returns all legal actions for a unit, listing specific types (movable tiles, attackable enemies, etc.). It distinguishes from sibling action tools like attack or move by being a read-only query.

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 advises calling this before issuing move, attack, heal, or wait to avoid errors. Also specifies constraints: only works on own units in READY or MOVED status, and error conditions for enemy or already-acted units.

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, but description clearly declares read-only nature and availability during/after match. Could mention absence of side effects more explicitly, but current is effective.

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

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

Three concise sentences with front-loaded key info. No redundancy or unnecessary details.

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?

Simple tool with one parameter. Description explains return values, timing, and distinguishes from sibling. No gaps given complexity and no output schema.

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

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

Schema coverage is 100% with one parameter described as 'Your server session identifier.' Description does not add beyond schema, meeting 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?

Starts with 'Read-only. Return server-tracked match statistics for both teams...' clearly indicating verb+resource+scope. Distinguishes from get_history sibling. Highly specific and unambiguous.

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

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

Explicitly states 'Use this for post-game analysis or mid-game cost monitoring. For game-state history use get_history instead.' Provides when-to-use and alternative.

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?

Discloses read-only nature, fog-of-war hiding enemy units, and the scope of visible state. Minor omission: no mention of rate limits or authentication, but acceptable for a simple read 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?

Three sentences, front-loaded with 'Read-only', no filler. Every sentence adds value.

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?

Despite no output schema, description fully enumerates return contents (board, terrain, units, turn, active player, win progress) and handles fog-of-war. Complete for a single-parameter state query.

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?

Only parameter connection_id is described clearly in both schema and description. Schema coverage is 100%, and description adds context ('assigned at connect time'), which is helpful.

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 clearly states 'Return the full game state visible to your team' and lists all components. It distinguishes from sibling tools like get_legal_actions and get_tactical_summary by advising to call this first.

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 recommends use at turn start to orient before calling get_legal_actions or get_tactical_summary, providing clear when-to-use and alternative 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?

The description declares the tool as 'Read-only', which addresses the safety profile in the absence of annotations. It details the return content but does not mention potential side effects or state implications; however, given the read-only nature, this is sufficient.

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, front-loading the purpose and then providing usage alternatives. Every word serves a purpose, and it avoids 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?

Given the tool's simplicity (one required parameter, read-only, no output schema), the description thoroughly explains what the digest contains, when to call it, and how it differs from siblings. No gaps remain for an AI agent.

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% with a single parameter (connection_id) already described as 'Your server session identifier.' The description adds no additional semantics for this parameter beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly specifies the verb 'Return' and the resource 'a precomputed tactical digest for your turn', listing included components (attack opportunities, threats, pending units). It distinguishes the tool from siblings simulate_attack and get_threat_map by positioning it as a consolidated alternative.

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

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

The description explicitly states when to call this tool ('once at turn start instead of many individual simulate_attack or get_threat_map calls') and provides explicit alternatives: 'For raw threat data per tile, use get_threat_map; for individual attack previews, use simulate_attack.'

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?

Discloses read-only nature and fog-of-war filtering. No annotations exist, so description carries full burden; it adequately covers behavioral traits without contradictions, though it omits details like output format or performance 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?

Three compact sentences with zero fluff: first states purpose and read-only, second adds scope, third gives usage guidance. Information is front-loaded and efficiently presented.

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 low-complexity read query tool with one parameter and no output schema, the description fully covers what the tool does, its limitations (fog-of-war), and how it relates to sibling tools, leaving no essential gaps.

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 a single standard 'connection_id' parameter. The description does not add extra meaning beyond the schema, meriting baseline 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?

The description clearly states the tool returns a board-wide map of enemy threat coverage per tile, specifying scope (visible enemies through fog-of-war) and explicitly distinguishes from sibling tools get_unit_range and get_tactical_summary.

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

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

Explicitly says when to use (identify safe tiles for positioning/retreat) and when not to, with direct alternatives: 'for a single unit's reach use get_unit_range instead; for a combined digest prefer get_tactical_summary'.

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?

Declares read-only, scope, error behavior, and lists return fields. Minor gap: no mention of side effects, but 'Read-only' suffices. No annotations provided.

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

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

Three efficient sentences: purpose+fields, scope+errors, usage alternative. No 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?

Fully explains inputs, outputs (fields listed), scope, errors, and usage strategy. No output schema needed; description covers everything.

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 covers both params 100%. Description adds example format for unit_id. Adds value beyond schema.

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

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

Clearly states it returns one unit's full details with specific fields, and distinguishes from bulk tool get_state via explicit preference.

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

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

Explicitly says when to use (after specific action) and when not (prefer get_state for bulk), plus scope (own and visible enemy) and error conditions (fog-of-war).

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?

Clearly marks as 'Read-only' (no mutation) and explains it works for own/enemy units. No annotations provided, but description covers scope and side-effect-free nature adequately.

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 focused sentences: first defines purpose, second gives usage context. No redundant information.

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

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

Describes output conceptually (two tile sets) despite no output schema. Context includes unit eligibility and practical use, sufficient for agent decision-making.

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 covers both parameters fully (100% coverage). Description adds minor context (unit_id example) but doesn't add meaning beyond schema.

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

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

Explicitly states it returns a unit's full threat zone (move and attack tiles) for any alive unit. Distinguishes from sibling like get_threat_map.

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

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

Provides clear when-to-use (plan positioning, evaluate enemy threat) and explicitly suggests alternative get_threat_map for board-wide overview.

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 provided, so description carries full burden. Discloses that healer's status becomes DONE after healing, mentions magic stat for healing amount, and states return values (amount healed, target's updated HP). No contradictions.

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?

Single efficient paragraph with every sentence adding value. No fluff or repetition. Well-structured and front-loaded with key information.

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

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

Despite no output schema, description covers return values, prerequisites, effect, post-action state, and suggests checking get_legal_actions. Comprehensive for a game action 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?

Schema has 100% coverage with descriptions, baseline 3. Description adds value beyond schema by clarifying that healer_id must have can_heal ability and be in READY or MOVED status, and that target_id must be adjacent and damaged.

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?

Clearly states 'Heal an adjacent allied unit' and specifies it's for units with the heal ability (typically Mages). Distinguishes from sibling tools like attack, move, etc., by focusing on healing only.

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

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

Provides explicit context: only for units with heal ability, healer must be READY or MOVED, target must be adjacent and damaged. References get_legal_actions to find valid targets. Does not explicitly mention when not to use, but context is sufficient.

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

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

The description discloses that the tool is mutating, changes unit status from READY to MOVED, and lists allowed subsequent actions. It also mentions error conditions. Without annotations, it provides sufficient behavioral context, though it could briefly note any additional side effects like triggering reactions.

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 well-structured single paragraph that front-loads the key action and conditions. Every sentence serves a purpose: mutation indicator, action, preconditions, parameter clarifications, post-move behavior, and error cases. No wasted words.

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?

Despite lacking an output schema, the description specifies that the tool returns the updated unit state and errors for invalid conditions. It references a sibling for range checking and explains the status change and remaining action possibilities, making it self-contained for an agent.

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 descriptions in the schema already explain dest, unit_id, and connection_id. The tool description adds little beyond restating precondition for unit_id and dest format, which are already in schema. 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 that the tool moves a unit to a destination tile, with specific preconditions (unit in READY status, destination within range). It distinguishes itself from siblings like attack, heal, and wait, which handle other 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 states when to use the tool (unit must be READY and destination within range) and references get_legal_actions for checking legality. It also explains the post-move status and restrictions, providing clear 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 provided, so description must carry full burden. It explicitly states 'Mutating' (state change), describes where the report is saved (replay, server log, debug file), and specifies required state. Good behavioral disclosure; could add more on side effects like whether it affects game flow.

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?

Description is concise with no fluff. Front-loaded key information ('Mutating', purpose). Each sentence adds value: categories, limits, requirements. Well-structured for quick parsing.

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

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

Covers purpose, categories, requirements, and persistence. No output schema, but description doesn't mention return value or confirmation. For a reporting tool, this is mostly complete; a minor gap is what the function returns (if anything).

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%, but description adds value by specifying character limits (summary max 500, details max 10,000), clarifying category meanings, and stating that state=in_game is required. This goes beyond simple parameter descriptions.

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 starts with 'Mutating. Report a problem or observation encountered during gameplay.' It specifies the verb 'report', the resource 'problem/observation', and context 'gameplay'. This clearly distinguishes it from sibling tools like report_tokens.

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 states 'Requires state=in_game.' Provides detailed explanations for category values and distinguishes between 'imbalance' and 'scenario_issue'. Missing explicit when-not-to-use, but context is sufficient for an AI agent.

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. It discloses that the tool is 'Mutating' (side-effect), that the value is stored server-side, and that it is visible via another tool. This is sufficient for a simple logging function, though it could mention any destructive potential (none implied).

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 concise (3 sentences), front-loaded with a functional label ('Mutating'), and every sentence adds value. No redundancy or filler.

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

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

For a simple reporting tool with no output schema and full param coverage, the description covers purpose, usage timing, caller, and data visibility. It is complete given the tool's low complexity.

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

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

The schema has 100% coverage with descriptions for both parameters. The description adds the note that 'tokens is a positive integer representing the total token count for this turn's inference,' which provides slightly more clarity than the schema alone. 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 uses specific verbs ('Report the number...') and clearly identifies the resource (LLM token count) and purpose (track cost statistics). It distinguishes this tool from sibling game-action tools by framing it as a telemetry/reporting function.

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 states that this tool is 'called by the client harness after each agent turn; not typically called by the agent itself.' This provides clear context on when and by whom the tool should be used, though it does not discuss alternatives or 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.

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

With no annotations, the description carries full burden. It explicitly declares the tool as 'Read-only' and states it does not change game state. It discloses the behavior (simulation of attack) and the return values. It could be improved by noting any limitations or authorization requirements, but overall it is 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 three sentences long, each serving a distinct purpose: stating the core function, clarifying parameters, and providing usage guidance. It is front-loaded with the key information and contains no redundant or irrelevant words.

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 simulation tool without an output schema, the description adequately explains what is returned (damage, counter-damage, death status). It provides necessary context about the parameters and usage. It could be more complete by describing error cases or the return format, but it suffices for typical use.

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?

Although the input schema has 100% description coverage, the tool description adds value by explaining the source of attacker_id and target_id (from get_state) and the use case for from_tile (evaluating move-then-attack). This extra context raises the score above the baseline 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?

The description clearly states the tool's purpose: it predicts attack outcomes without changing game state. It specifies the output (expected damage, counter-damage, death status) and distinguishes itself from the sibling 'attack' tool by being read-only. The verb 'simulate' and resource 'attack' are explicit.

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 advises using this tool 'to compare attack options before committing with the attack tool,' providing clear context for when to use it. It also explains the optional from_tile parameter for move-then-attack sequences. However, it does not explicitly state when not to use it or list alternatives, though the context is strong.

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, description carries burden. It states mutating effect and status change. Could be more explicit about undo-ability or other side effects, but is transparent enough for a game action.

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?

Concise three-sentence description. Front-loaded with verb and effect. No wasted words, well-structured.

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 and simple mutation, the description covers action, conditions, and turn flow integration completely.

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 schema descriptions already explain each parameter. The description adds minimal extra meaning beyond restating unit_id's role.

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 tool ends a unit's turn without attacking or healing, setting status to DONE. It distinguishes from siblings like attack, heal, and move.

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

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

Provides explicit when-to-use: when a unit has no useful attack/heal targets but you want to finalize position after moving. Also notes prerequisites (unit must be READY or MOVED) and context (call end_turn after all units DONE).

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