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

Annotations already establish read-only, non-destructive, closed-world behavior. The description adds the meaningful behavioral distinction that this returns static argument syntax while dynamic availability lives elsewhere — a real trait not encoded in annotations.

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

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

Three short sentences: purpose first, then the omission behavior, then the scope caveat. Nothing is redundant and nothing is buried.

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

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

For a read-only, single-optional-parameter lookup with no output schema, the description covers what the tool returns and where authoritative state lives. It could note that the returned data mirrors the take_action argument schema, but the essentials are present.

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 0%, so the description must compensate. It explains the single parameter's role (an action name) and the meaningful default (omit to list all), but adds no format guidance beyond that; the enumerated action values live only in the schema's enum. Adequate but not additive.

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

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

States a specific verb and resource ('Get action names and required/optional parameters') scoped explicitly to take_action, so the agent knows this is documentation for that sibling rather than a state query. It also contrasts itself with get_game_state ('the current game state supplies the actual available choices and indices'), making the split 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?

Gives a concrete usage rule ('Omit action to see all supported gameplay actions') and clarifies when this tool is not what you want (live choices come from game state, not here). It stops short of explicitly saying 'call this before take_action to learn its syntax', which would be a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavior beyond that: it lists returned fields (state_id, detected mode, complete state), states that auto detects singleplayer/co-op, and notes the tool works at menus as well as during a run.

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 four short, front-loaded sentences with no filler. Each sentence contributes: what is read, what is returned, when to read again, and how mode/menu behavior works.

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 read-only tool with one optional parameter and no output schema, the description covers purpose, return contents, usage timing, and mode behavior adequately. It could say more about what state_id is used for, but that is a minor gap for this complexity level.

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 0% for the single mode parameter, so the description must compensate. It explains that 'auto' detects singleplayer/co-op, which adds meaning beyond the enum, but it does not clarify the explicit singleplayer or multiplayer values or when a caller should override the default.

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

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

The description uses a specific verb ('Read') and enumerates the resource precisely: current screen, player, cards, enemies, intents, and visible options. It also states what is returned, making the tool's scope immediately clear and distinguishable from action-oriented siblings like take_action.

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

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

It gives clear usage context: read again after each action and works at menus as well as during a run. However, it does not explicitly name when to use alternatives like take_action or health_check, so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds the useful scoping detail that it reads the *active* profile, but says nothing about return shape, caching, or rate limits.

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

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

One short sentence with the verb and scope front-loaded and no filler. It is efficient, though 'progress and discoveries' is doing vague double duty where a more concrete noun would be sharper.

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

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

With no output schema, the description carries the burden of explaining what comes back, and 'progress and discoveries' is too abstract to tell an agent what fields or structure to expect. For a zero-param read tool this is adequate but leaves a real gap.

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

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

The tool takes zero parameters, so there is no parameter semantics burden to carry; the baseline is 4. The description's mention of 'active' implicitly explains why no identifier argument is needed.

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

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

States a specific verb (Read) and resource (the active profile) plus the payload (progress and discoveries), so the operation is unambiguous. It does not, however, distinguish itself from the sibling get_game_state, which an agent might reasonably confuse it with.

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

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

There is no guidance on when to call this rather than get_game_state or health_check, and no prerequisites or exclusions stated. The only implied usage is that the profile must be 'active'.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the bridge-enabled condition, but says nothing about the return format or failure behavior; with annotations carrying the safety burden, a 3 is appropriate.

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

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

A single front-loaded sentence with no filler. Every word earns its place.

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

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

For a zero-param health check with annotations covering the safety profile, the core purpose is captured. However, with no output schema, the description should indicate what a successful or failed check returns (boolean, status, error) and none of that is present.

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

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

The tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate. No parameter semantics are needed.

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

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

States a specific verb (check) and a precise condition (whether Slay the Spire 2 is running with the STS2_MCP bridge enabled). This is clearly distinguishable from siblings like get_game_state, which fetches state rather than verifying connectivity.

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

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

No explicit when-to-use guidance or alternatives are given. An agent can infer it is a preflight connectivity check, but the description never says to run it before other tools or what to do if it fails.

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

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

Annotations already establish it as a safe, non-destructive, closed-world read. The description adds a genuine behavioral constraint not in the schema: only 'discovered' items are searchable in the 'active game profile', which tells the agent results may be incomplete. It omits matching semantics (exact vs fuzzy) and result shape.

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

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

A single front-loaded sentence with no filler; the verb and subject lead, and every word contributes to the meaning.

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

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

With three parameters, no output schema, and 0% schema description coverage, the description is too thin. An agent gets no help on filtering, result limits, or ranking behavior — the core concerns of a search 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 description coverage is 0%, so the description carries the burden, yet it only implies the query is name-based ('by name'). It says nothing about the limit parameter or the item_type filter (all/card/relic), which are undocumented except for the raw enum values.

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

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

The description states a specific verb ('look up'), a specific resource ('card/relic rules text'), and a scope ('by name in the active game profile'). This clearly separates it from the action/state siblings like take_action and get_game_state, though it doesn't name any sibling explicitly.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives among the six sibling tools. The agent must infer the use case entirely from the tool name and upstream context.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and openWorldHint=false, so the description is not the sole source for the safety profile. It still adds genuinely useful context beyond the annotations: actions are serialized and never retried (so failures must be handled by the caller), each call returns a fresh game state, and expected_state_id acts as an optimistic-concurrency guard against stale decisions.

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

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

Front-loaded purpose sentence, then routing, then compact examples, then the two behavioral cautions. No filler, no restatement of the name or schema, and the most decision-relevant constraint (serialized, never retried) is stated plainly.

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 29-action dispatcher with no output schema, the description covers the essentials: return payload, parameter lookup path, per-action examples, and staleness handling. It leaves the 'mode' parameter and any error/retry semantics undocumented, which the caller would have to discover elsewhere.

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 0%, so the description carries the burden, and it partially does: it supplies concrete payload shapes for play_card, end_turn, choose_map_node and menu_select, explains expected_state_id's purpose, and names get_action_help as the authoritative source for the remaining action parameters. The freeform 'parameters' object is otherwise undocumented, and the 'mode' enum is never explained — hence not a 5.

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

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

States a specific verb and resource — 'Perform one game action and return the result plus a fresh game state' — and the return payload is named up front. It distinguishes itself from the read-only sibling get_game_state and the reference sibling get_action_help by routing explicitly to the latter for parameter names, though it never states outright that it is the sole mutation entry point.

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?

Clear context: call get_action_help for parameter names, use current state indices and target IDs, and optionally supply expected_state_id from get_game_state to reject stale decisions. That routing and the staleness precondition are actionable guidance, but there is no explicit statement of when NOT to use this tool or a named alternative for read-only inspection.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), yet the description adds real behavioral detail: it blocks/polls, returns ready=false with the last state on timeout, and warns that a visible screen does not imply every action is legal. The timeout-return behavior is particularly useful since there is no output schema, though the cap on timeout_seconds is not mentioned.

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

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

Four short, front-loaded sentences with no filler. The core behavior comes first, then timeout semantics, then the read-only scope, then the legality caveat. Every sentence carries information an agent needs.

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

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

With no output schema, the description partially compensates by describing the timeout failure shape (ready=false + last state) and the no-gameplay-action scope. However, the success return shape is only implied, and the two input parameters (mode enum, timeout) are entirely unexplained, leaving meaningful gaps for a blocking/polling 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 description coverage is 0% and the description mentions neither parameter. The meaning of mode values ('singleplayer', 'multiplayer', 'auto') and especially what 'auto' detects is never explained, nor is the effect of timeout_seconds or its 0-30 bound. The tool's own text does not compensate for the schema gap.

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

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

The description states a specific verb and resource: 'Poll through enemy turns/loading until a player screen is available.' This clearly separates it from get_game_state (immediate read) and take_action (mutating), though it never names a sibling explicitly. An agent can identify the tool's role without opening the schema.

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

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

Usage is implied by the polling semantics (use it while enemy turns/loading are in progress), but there is no explicit when-to-use vs get_game_state guidance and no statement of when not to call it. The 'Performs no gameplay actions' line hints at the boundary with take_action, but only obliquely.

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