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

No annotations are present, so the description carries the full behavioral burden. It does disclose that this resolves/consumes a pending ruling, is run once per turn, and falls back to the ruling's default strategy when no choice exists. It does not disclose side effects, failure modes, or what state changes occur after adjudication.

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 front-loaded with a one-line summary followed by a concise explanatory paragraph. Three sentences deliver runtime context, invocation cadence, and exclusion policy without padding.

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

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

For a runtime-internal tool, the domain context is well covered (who calls it, how often, default fallback). But with no output schema and no annotations, the description still omits return/error behavior and leaves one parameter (source) semantically empty, which is meaningful for a 3-parameter 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 must compensate for all three parameters. It conceptually maps 'choice' and 'pending_ruling' (ruling_id) via the example, but 'source' goes entirely unexplained — the meaning of 'model' vs. any alternative value is never stated, and coverage stays mostly undocumented.

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 first sentence gives a specific verb+resource ('Apply a fictional choice to an open pending ruling'), and the follow-up clarifies the ruling domain with a concrete example (which possession a demon stole). It distinguishes itself from the game/combat/character siblings by the explicit RUNTIME-ONLY marker, though RUNTIME-ONLY is never fully defined inline.

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

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

The description states when it fires (narrator engine's adjudicate step, once per turn) and that it is excluded from the narrator model's tool surface via policy.py, which effectively tells the model it should not invoke this directly. However, it names no alternative tool and gives no explicit when-not-to-use condition beyond the runtime-only framing.

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

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

With no annotations, the description carries the full disclosure burden, and it delivers: server verbatim recording, branch tagging, unratified outcomes until scene_commit, automatic application of Advantage/Disadvantage/conditions/Threat Level/Doom, Torn Veil behavior on sorcery critical failure, and combat action counting with turn advancement. It also states what the tool does not decide, the fictional cost, which is valuable boundary disclosure.

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 long but every sentence earns its place for a complex roll tool. It is front-loaded with the core purpose)Skip? Actually front-loaded: purpose, then usage, then stakes, then mechanics, then parameter notes, then combat caveats. The parameter list is easy to scan, and the prose paragraphs each cover one coherent behavioral topic. No filler or schema repetition.

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

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

Given the absence of annotations and output schema, this description is unusually complete: it explains when to roll, how to phrase stakes, how hidden stakes behave, what parameters mean, how special category handling works, the combat action economy, and what must never be promised in stakes. An agent has everything needed to select and invoke the tool correctly and to avoid forbidden patterns.

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, and it does for nearly every meaningful parameter: attribute values, stakes_success/stakes_failure semantics, stakes_hidden privacy, opponent_level meaning, call_on_doom condition, failure_mode options, and category behavior including the torn_veil_returned consequence. A few parameters like reason and character_id are not individually explained, but their purposes are largely self-evident from names and context.

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 first sentence names a specific operation: 'Roll one d20 roll-under attribute test with declared stakes.' It plainly identifies the resource (an attribute test) and the mechanic (d20 roll-under), and the surrounding text draws boundaries against siblings like group_test and combat_attack. An agent can tell this tool apart from the other roll-based siblings without opening their schemas.

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

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

The description gives an explicit trigger: 'Call this whenever an action has a meaningful chance and consequence of failure.' It also gives a concrete negative case ('Do not call it for an ordinary active search that simply succeeds'), a combat-use rule, and a direct routing instruction away from combat_defend for enemy actions. This is strong when-to-use and when-not-to-use guidance.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states it changes nothing, and it enumerates the return contents (active scene, party hit points and Doom dice, live NPCs, clocks, combat state, every valid identifier). This fully discloses the tool's read-only nature and what the agent can expect.

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-loaded with the purpose and immediately followed by a clear list of return contents and usage timing. Every sentence earns its place with 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?

For a no-parameter read-only tool, the description is complete. It states the exact scope of information returned, confirms non-mutation, and gives specific call timing. No output schema exists, but the description itself lists the key data fields, so the agent knows what to expect.

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

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

The tool has zero parameters and the schema coverage is 100% (empty schema). Baseline for 0 parameters is 4, and the description adds no parameter-specific details because none exist. It does clarify what the return provides, which is relevant but not parameter semantics.

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 reads the authoritative campaign state, with a specific verb (read) and resource (campaign state). It distinguishes itself from the many sibling tools by focusing on the overarching status and explicitly noting it changes nothing, which separates it from all mutation and action tools.

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 explicit usage guidance: call at the start of a consequential turn and after any tool error. It also states it changes nothing, implicitly telling the agent it is safe to call frequently. No alternatives are needed since it is the unique status-reading tool among siblings.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses exact effects (adds hit points, applies attribute increases and Gift, upgrades Doom die at level 10) and failure behavior ('rejects a choice... and writes nothing'), plus the Stories and combat eligibility gates.

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 front-loaded with the core action, then proceeds logically through usage conditions, effects, and parameter contracts. Each sentence adds operational value, and the parameter sections are organized so the agent can easily map rules to inputs.

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 state-changing tool with no annotations and no output schema, this description provides prerequisites, level-specific rules, failure behavior, and usage constraints. An agent has enough information to decide when to call it and how to populate every parameter correctly.

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

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

Schema description coverage is 0%, but the description compensates fully: attribute_increases lists allowed attributes, per-level counts, distinctness, and the below-18 cap, while gift_id specifies levels, source file, not-already-held condition, and empty default. character_id is self-evident from its name and required status.

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 opens with 'Advance one player character by exactly one level,' which names a specific verb, a clear resource, and an exact scope. It also states level-specific side effects, making it easy to distinguish from read-only sibling tools like character_sheet or character_options.

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 explicitly says 'Call this when the table levels a character up' and tells the agent to check eligibility with character_sheet or session_close first. It also covers when not to call it by saying the tool refuses during active combat, and it clarifies that advancing two levels requires two calls.

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

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

With no annotations, the description carries the full burden, and it delivers: it details rolls per attribute, background increases, HP=CON, Doom die set to d6, starting coins, Discord linking, and the atomic rejection of illegal backgrounds without writing. This prevents false assumptions about partial 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.

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

The description is front-loaded with a one-sentence purpose followed by compact bullet-like constraints. Every sentence earns its place, and the validation rules are scannable without unnecessary prose.

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 complex creation tool with eight parameters and no output schema, the description covers the mechanics and validation rules well. But it does not state what the tool returns, whether it requires an active campaign context, or whether creating again overwrites an existing character, leaving meaningful 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?

The description adds essential meaning for origin, backgrounds, and armour by giving allowed values and exact background constraints. However, schema_description_coverage is 0% and several parameters such as weapons, shield, language, name, and discord_user_id are not described beyond their titles/defaults, so the compensation is partial.

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?

Opens with 'Create one player character and write the sheet,' giving a specific verb-resource pair and a clear outcome. The 'player' qualifier distinguishes it from NPC-focused siblings, and the listed side effects make the intended operation unmistakable.

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 clearly frames when to use the tool: when the user wants to create a single player character and persist its sheet. It does not explicitly name alternatives or exclusions, but the core context is clear enough for an agent to select it over tools like character_advance or npc_create.

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

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

With no annotations, the description carries the burden, and it explicitly discloses the key behavioral trait: 'Changes nothing.' It also reveals that the returned data reflects constraints character_create enforces, giving useful behavioral context. It doesn't discuss failure modes or data source, but for a zero-parameter read-only menu tool the disclosure is strong.

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 with no waste. The key fact ('Changes nothing') is front-loaded, the detailed return contents are compactly enumerated, and the usage rule closes the description. Every sentence earns its place.

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

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

Despite lacking an output schema, the description exhaustively enumerates all returned data: origins with coins/languages/weapon tables, backgrounds with id/name/bonus/feature/unique flag, armour categories, and selection constraints. Combined with explicit usage guidance, an agent has everything needed to call and apply this tool correctly.

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

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

The tool has zero parameters, so the baseline is 4. No parameter explanation is needed or possible, and the description correctly focuses on return content rather than input semantics.

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 ('Read') and resource ('legal character-creation menu'), and explicitly says it changes nothing, clearly distinguishing it from mutation siblings like character_create and character_advance.

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

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

Explicitly instructs when to call it ('before guiding a player through character creation'), how to use the results ('offer only options it lists'), and provides an exclusion rule ('never recite origins or backgrounds from memory'). This fully routes the agent away from alternatives.

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 annotations absent, the description carries the burden. It explicitly states 'Changes nothing,' which indicates a read-only behavior and is useful. However, it does not disclose anything else like authorization requirements, error conditions, or the structure of the returned data, leaving gaps for an agent.

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 seven words and states the core purpose and the read-only nature upfront. It is maximally concise with no filler, and the key information is immediately visible.

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 one-parameter read tool, the description is minimally adequate, but it lacks context on return format, what 'authoritative' implies, and any edge cases. Given no output schema and no annotations, the description should provide more detail to fully prepare an agent, yet it remains borderline acceptable.

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 for the single parameter 'character_id'. The description does not reference the parameter at all, nor explain how to obtain it or what format it should take. The schema only provides type 'string', which is insufficient for an agent to correctly construct the call.

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

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

The description clearly states a specific verb ('Read') and resource ('authoritative character sheet'), making the tool's purpose unambiguous. However, it does not explicitly differentiate from sibling tools that might also involve reading character data, such as character_options, though the word 'authoritative' hints at a canonical source.

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

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

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g., whether the character must exist), and no exclusions. The description gives no context for an agent to decide between this and other character-related tools beyond the bare purpose.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It details critical rules (maximum base damage plus one die), doom roll mechanics, hit point updates, death marking, turn advancement, out-of-turn refusal, and the exact effects of optional flags like runic, poisoned, and target_unaware. It even explains edge-case behaviors such as the Assassin's unaware strike window and the interactions of weapon_effect types. This is exceptionally 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?

While lengthy, the description is structured logically: core mechanics first, then optional flags, then explicit exclusions. Every sentence delivers essential information without redundancy. It is front-loaded with the basic resolution flow, then progressively adds detail on special cases. For a tool with this complexity, the length is appropriate and no sentence wastes the reader's time.

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 absence of an output schema and annotations, the description must provide complete operational context. It does: it tells the agent to read turn_advanced, next_actor, combat_over, and next_step from the result, warns about turn advancement, and explains the positioning rule. All functional aspects—including error conditions (refusals), state changes, and return values—are covered. The description leaves no gap the agent needs to guess about.

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%, yet the description compensates completely. It explains attack_type (melee vs ranged, which attribute to test), weapon_effect (all seven options and their consequences), runic (damage source and on-kill effects), one_handed_blade (Sword master DEX substitution), target_unaware (Assassin's damage replacement and conditions), and poisoned (requirements and damage addition). It even clarifies nuanced parameter interactions, such as poisoned being refused with runic or non-damaging effects. The description effectively documents nearly every parameter and its gameplay impact.

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 opens with a precise statement of the tool's purpose: 'Resolve one player attack against one NPC.' It clearly distinguishes from sibling tools like combat_move, combat_defend, and attribute_test by specifying exactly what game action this covers. The resource (attack) and verb (resolve) are concrete 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?

The description provides explicit usage guidance, including when not to use it: positioning movements are not attacks and should use attribute_test instead. It also explains the interaction with turn mechanics (spending last action advances turn, dropping last enemy ends fight) and cautions against calling combat_end_turn. It names alternatives (attribute_test, combat_end_turn) and clearly states the conditions that trigger them.

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

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

With no annotations provided, the description carries the full burden and does so well. It discloses that the call 'succeeds and reports the actions left without resetting anything' and that it refuses calls for non-active actors, revealing both side-effect absence and authorization-style constraints.

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 sentences with no filler. The purpose is front-loaded, and each following sentence adds a necessary behavioral edge case: normal auto-opening, success behavior, and refusal behavior.

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

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

For a single-parameter, mostly no-op confirmation tool with no output schema, the description covers purpose, alternatives, side effects, and error behavior. It even reports what the call returns ('actions left') in sufficient detail for an agent to invoke it correctly.

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

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

The schema has 0% description coverage, but the prose ties the sole required parameter to the active actor: calls 'for the active actor' succeed and calls 'for anyone else' are refused. It does not explicitly name actor_id as the parameter or say where to obtain it, but it supplies meaningful behavioral constraints beyond the bare 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 opens with a specific verb and resource: 'Confirm the active actor's turn is open' and immediately clarifies the key nuance that turns already open themselves. It distinguishes the tool from combat_start by explaining that combat_start opens the first turn, so an agent can tell them apart.

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

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

The description explicitly says this call is 'normally unnecessary' and explains why: combat_start and resolved actions already open turns. It also gives clear success/refusal conditions: calling for the active actor succeeds, calling for anyone else is refused, because only the active actor may act.

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

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

With no annotations, the description carries the burden and it does disclose key effects: it clears the active actor, performs the same post-combat bookkeeping as a decisive combat_end_turn, and refuses when no combat is active. It falls just short of 5 because 'same post-combat bookkeeping' depends on knowledge of another tool and the return/confirmation behavior is not addressed.

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 with front-loaded purpose, followed by distinction from the sibling and then side effects/failure behavior. Every sentence adds information and none repeats the schema.

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

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

For a one-parameter mutation tool with no output schema, it covers when to use it, what it does, its side effects, and its error condition. The brief indirect reference to combat_end_turn's bookkeeping and lack of any return-value note keep it just shy of complete.

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

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

Schema coverage is 0%, so the description must explain the lone required 'reason' string, and it does: it enumerates valid reasons (fleeing, surrendering, truce, any mutual disengagement) and explicitly excludes elimination. It doesn't specify free-form vs format constraints, but that is a minor gap for a single string parameter.

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 first sentence states an exact verb and resource: 'Close an active combat for any reason other than elimination.' It immediately distinguishes itself from combat_end_turn by naming the sibling and specifying the boundary, so an agent can select it correctly without inspecting other tools.

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 routes decisions: combat_end_turn is only for when one side is empty, while fleeing, surrendering, truces, and mutual disengagement all go through combat_close. It also gives a negative condition ('Refuses when no combat is active'), telling the agent when it should not be invoked.

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

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

With no annotations provided, the description carries the full burden and delivers richly. It discloses action-economy effects (defender loses no action, enemy spends its action), automatic turn advancement, next_actor/next_step reading, shield-breaking on critical failure, critical-failure armour bypass, and the optional incoming_damage behavior. These are exactly the non-obvious behavioral traits an agent needs.

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 dense but every sentence earns its place: purpose, action economy, turn-advancement, defensive options, shield mechanics, and damage fallback. It is front-loaded with the core purpose and then structured into rules that directly affect how the agent should invoke and interpret the call.

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 combat-resolution tool with no output schema and no annotations, the description covers side effects, turn state, defensive rules, and parameter fallback behavior. It even tells the agent to read next_actor and next_step from the result. This is sufficient for a competent agent to call the tool correctly without inventing assumptions.

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 does for method (parry vs dodge), ranged (dodge only), shield (advantage and break on critical failure), advantage, and incoming_damage (omit to use NPC recorded damage). However, it does not explicitly explain the disadvantage parameter or clarify how attacker_id relates to the recorded-damage fallback.

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 opening sentence states the exact operation: 'Resolve one player defence against an incoming attack.' This clearly distinguishes it from attack, movement, and turn-management siblings. It also adds a key scoping detail: enemy attacks resolve through this tool, so the player always rolls.

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

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

The description gives concrete when-to-use guidance: use it for incoming enemy attacks, with dodge mandatory against ranged and parry requiring a held object. It also warns against narrating enemy attacks outside their own turn ticks. It stops short of explicitly naming alternative sibling tools, so it misses the top bar for this dimension.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains the effects: ending the turn early, incrementing the round after the last actor, ending combat under specific conditions (no enemy alive or no player character standing), and rolling each participant's held reusable marvel Usage Die upon combat finish. This is rich, specific, and covers multiple 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.

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

The description is longer than a single sentence but each sentence earns its place. It front-loads the core action, then adds context about automatic advancement, specific effects, and end-of-combat behavior. No filler or redundancy; it is well-structured and readable.

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

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

The tool is well explained in terms of behavior and usage, but the parameter is completely undocumented. The agent would not know how to correctly set actor_id (or if it can be left empty). The description covers most operational details but leaves a critical gap in parameter semantics, making it incomplete for an agent trying to invoke the tool correctly.

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

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

The description does not mention the actor_id parameter at all. With 0% schema description coverage, the description was expected to compensate, but it never explains what actor_id refers to, whether it is required, or what the default empty string implies. The term 'active actor' hints at the parameter's role, but the connection is not made, leaving the agent to guess.

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 ('End the active actor's turn early') and immediately distinguishes it from automatic turn advancement. It clearly differentiates from siblings like combat_begin_turn and combat_attack by explaining that turns advance automatically when actions are spent, making this tool's unique purpose obvious.

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: 'only for a combatant who stops acting with actions left' and gives concrete examples (holding back, hesitating, enemy not attacking). It also implies when not to use it ('Turns advance themselves when the last action is spent'), effectively ruling out normal turn progression. No explicit alternative is named, but the logic is clear.

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 behavioral disclosure burden. It does well by stating the action cost, the exact effect (one band closer), the one-move-per-band limit, and that ranges are tracked per opponent. Minor omissions like what happens if already at close range or whether any roll is required are not fatal but prevent a perfect score.

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 efficiently structured: the core mechanic is front-loaded in the first sentence, followed by concise tactical rationale and the per-opponent nuance. Every sentence contributes to understanding what the tool does and when to use it, with no redundant 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 two-parameter action tool with no output schema and no annotations, the description is largely complete: it defines the action cost, the directional effect, the magnitude, and the single-target scope. It only lacks explicit mention of return behavior or edge-case handling, but an agent has enough context to invoke it correctly in a combat turn.

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 meaningfully explain the two required IDs. It partially does: target_id is implied as an 'NPC' and character_id as the acting 'character' who spends the move action. However, the mapping is left to inference rather than explicitly tied to the parameter names, and no validation or format guidance is provided.

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 opens with a specific action and resource: 'Spend one action to close one range band toward a target NPC.' It also gives a concrete combat context — melee needs close range and a fight often opens at nearby — which makes clear this is the tool for repositioning before a melee strike. This distinguishes it from attack, defend, and other combat sibling tools.

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 clearly implies when to use the tool: when a character wants to engage in melee and needs to close the range band first. It explains the tactical situation ('A fight often opens at nearby') and the move's purpose, but it does not explicitly name alternatives or state when not to use it. This is clear context without formal exclusions.

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

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

With no annotations, the description carries the full burden and does well: it discloses state changes (combat opens, first actor's turn is already open), dice outcome effects, and a critical ordering rule about not resolving an attack before the opposition acts. It does not cover edge cases like repeated calls, but it is substantially 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 efficiently structured and front-loaded with the core action. The initiative outcomes and follow-up handling earn their place, though the multiple paragraphs could be slightly tightened without losing information.

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

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

For a combat-start tool with no output schema and no annotations, the description covers the essential invocation context: prerequisites, return behavior (first turn open), initiative consequences, and how to handle the opposition acting first. The main omission is the meaning of the optional stakes and reason parameters, but core usage is complete enough.

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 usefully explains initial_ranges values and implies pc_ids/npc_ids, but the reason and stakes_* parameters remain entirely unexplained, leaving a meaningful semantic gap for optional parameters.

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

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

The opening sentence, 'Open combat and roll initiative,' states a specific verb and resource while clearly separating this tool from siblings like combat_begin_turn and combat_close. It also describes the initiative mechanism, making the tool's purpose unmistakable.

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

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

The description gives concrete workflow guidance: create NPCs first, follow next_step when the first turn opens, and use combat_defend when the opposition acts first. It does not explicitly contrast with alternatives like combat_attack or combat_begin_turn, but the sequencing and branch behavior are clear.

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 are absent, so the description carries the burden of disclosing side effects. It clearly explains the consequences of a depleted die (character becomes Doomed, testing everything at Disadvantage until long rest) and that call_on_doom always steps down and returns a value to subtract. It doesn't describe return formats or error behavior, but for a dice-rolling tool the key side effects are well covered.

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 and front-loads the core purpose, then explains modes and usage guidance. However, given missing parameter semantics, a bit more space could have been used to mention key parameters like 'disadvantage' and 'reason', making it slightly under-sized but not verbose.

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 complex tool with 7 parameters and no output schema, the description covers the mechanics and usage routes but lacks parameter explanations. It doesn't define what the return value looks like for each mode (though no output schema exists), so agents may not know what to expect. Overall adequate for triggering but incomplete for full invocation confidence.

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%, meaning none of the 7 parameters are documented in the schema. The description explains the 'mode' parameter's values but does not explain 'reason', 'character_id', 'disadvantage', or the stakes_* parameters. With a high parameter count and low coverage, the description must compensate, but it leaves most parameters unexplained.

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 defines the tool as managing a Doom die with three specific modes (roll, call_on_doom, restore), each explained with distinct behavior. It distinguishes itself from sibling tools by naming attribute_test and combat_attack as already handling doom rolls, so an agent can easily identify when this tool is appropriate.

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 when to use this tool ('only for other triggers') and names the specific siblings that already handle doom rolls, preventing duplicate calls. The three modes are each given a clear condition, leaving no ambiguity about invocation 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?

There are no annotations, so the description carries the full burden. It discloses the hidden mechanics: personality-to-ability mapping, the 2d6 INT roll, the immediate session test, table announcement, and the one-weapon-at-a-time refusal. This is thorough behavioral disclosure.

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?

Every sentence adds necessary information: purpose, personality mechanics, immediate roll behavior, follow-up actions, and a constraint. The description is dense but front-loaded and free of fluff.

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 annotations, no output schema, and zero schema descriptions, the tool definition covers essentially everything an agent needs: valid personality values, mechanical consequences, roll behavior, related tool calls, and a hard limitation. The only minor gap is explicit parameter naming, but it does not impair invocation.

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

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

Schema coverage is 0%, so the description must compensate. It does a strong job for personality by listing all allowed values and their effect, and character_id and name are reasonably inferable from context. A fully explicit statement that name is the weapon's name would push this to 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?

The description names a specific action and resource: 'Grant a sentient runic weapon a character finds in play (a rare event).' It also differentiates from nearby siblings by pointing to combat_attack and inventory_update for subsequent actions, so the tool's role is unambiguous.

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

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

It states when the tool applies ('a character finds in play') and when it refuses ('A character holds one at a time'). It also gives explicit routing for related operations: attack via combat_attack with runic true, and removal via inventory_update remove_weapons.

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

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

With no annotations provided, the description must carry the behavioral burden, and it does a solid job: it defines the group success threshold, stakes_success and stakes_failure semantics, hides stakes_hidden from players, and clarifies that category edges only the affected participant's roll. It does not cover side effects or result shape, but the core behavioral contract is clear.

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

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

The description is compact and well organized: main behavior first, then group mechanics, stake requirements, and category behavior. Each sentence contributes, though the parameter gap makes it feel incomplete rather than merely concise.

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

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

For a tool with 10 parameters, 0% schema coverage, no annotations, and no output schema, the description is not complete enough. It gives useful group-roll context but omits meaning of several required inputs and the shape of the returned group result, leaving an agent to guess when invoking it.

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, but it only explains stakes_success, stakes_failure, stakes_hidden, and category. It leaves character_ids, attribute, reason, opponent_level, advantage_character_ids, and disadvantage_character_ids mostly undefined, and does not say what values they accept or how opponent_level affects the roll.

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

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

The description names a precise operation: roll one attribute test per character and return the group result. This clearly distinguishes it from the sibling attribute_test, which handles a single character's roll, and from other roll tools like usage_roll or doom_roll.

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 explicitly says to use this for coordinated actions such as a whole party crossing unseen, giving a concrete situational cue. It does not explicitly state when to use a single-character test instead, but the distinction is strongly implied by the presence of attribute_test as a sibling.

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 fully discloses the random d6/d4 outcomes, HP restoration, the death result, and the carer's gating test. This gives the agent a clear model of consequences before invoking.

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 three short paragraphs front-load purpose and timing, then mechanics, then optional carer behavior. No sentences are redundant.

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 annotations or output schema, the description covers when to call, what happens, and how the optional parameter changes the roll. This is sufficient for a caller to invoke the tool correctly.

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

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

The description richly explains character_id (the downed character) and carer_id (treating ally with a tending effect). The optional reason parameter is not explained, but it has a safe default and is not required for correct invocation.

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

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

The description names a specific verb and resource: rolling the Helpless table for a player character at 0 hit points. This clearly separates it from generic sibling rolls like usage_roll or doom_roll.

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 explicit call timing: 'once the fight ends or the character reaches safety.' It also provides the exact condition for passing carer_id, so an agent knows when to include the optional parameter.

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

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

With no annotations, the description carries the full burden, and it excels: it reveals that changes are audited, that inventory is mechanical state like hit points, that the tool validates before writing and refuses on invalid removals or negative coins, and that runic weapons leave with their kill verdict. This is far beyond the minimum.

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 front-loaded with the core purpose, then moves through usage, exclusions, and data-source guidance. Every sentence adds operational value; there is no repetition 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?

Despite no output schema or annotations, the description covers when, how, safety, exclusions, and post-call data sourcing. The only notable gap is that it references 'this tool's own result' without describing what that result contains, and the purpose of the required 'reason' parameter is left unexplained.

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

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

The schema has 0% description coverage, so the description must compensate. It clearly explains coins_delta as signed and item names as exact, and gives special semantics for remove_weapons with runic weapons. However, it never explains the required 'reason' parameter or individually maps all add/remove fields, so it is not fully complete.

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

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

The description names a specific verb and resource ('Apply one audited change to a character's coins, equipment, or weapons'), making the tool's scope immediately clear. It also distinguishes itself from the broader character and campaign tools, and further narrows behavior by excluding negotiated merchant purchases.

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

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

The description gives explicit when-to-use guidance ('Call it whenever the fiction moves a possession') and explicit when-not-to-use guidance ('Never use this for a negotiated merchant purchase: the trade confirmation flow owns those'). It also tells the agent where to answer inventory questions from, which directly prevents misuse.

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?

Without annotations, the description carries the full burden and meets it: it discloses runtime-only scope, policy exclusion, and the precise side effects (waived outcomes persist in campaign state history and audit log; only the pending scene entry is skipped). This gives an agent a clear model of what calling the tool does and does not change.

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 tightly structured: a one-line purpose statement, a concise runtime/policy warning, and a parameter note. Every sentence carries distinct information with no filler.

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

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

For a single-parameter, no-output-schema internal tool, the description covers what it does, what side effects it has, who is allowed to call it, and what the parameter means. Nothing essential is missing for correct invocation.

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

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

With schema description coverage at 0%, the description compensates by explaining the reason parameter's content and length ('one or two sentences on why no scene entry is needed'). It could add examples or validation hints, but it is sufficient for a single self-named string parameter.

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 ('Clear') and resource ('the unratified-outcome ledger') and immediately qualifies the behavior ('without writing a scene entry'). This clearly distinguishes it from siblings like scene_commit, which the surrounding tool list includes.

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 explicitly states when the tool runs ('during its settle step'), who may call it (only the narrator engine), and when it must never be reachable (from a game-master prompt, excluded by policy.py). This is stronger than most usage guidance and leaves no ambiguity.

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 present, so the description carries the behavioral disclosure burden. It does explain useful mechanics, such as level setting hit points and damage and armour adding hit points rather than reducing damage, but it does not disclose persistence, side effects, required permissions, or what happens after creation.

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 tight and front-loaded, with three short sentences earning their place: purpose, level behavior, and parameter advice. There is no fluff or repeated information from the schema.

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

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

With 7 parameters, no annotations, and no output schema, the description covers core creation rules but still leaves gaps. It does not clarify the role of location_id, present_in_scene, or the expected result of the creation, so the tool definition is not fully self-sufficient.

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

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

Schema description coverage is 0%, so the description must compensate for the input schema. It meaningfully clarifies level, armour, motive, and named-action constraints, which helps the agent. However, name, location_id, and present_in_scene are left without semantic explanation even though they are important creation parameters.

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

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

The description clearly states the verb and resource: 'Create one quick NPC from the level table.' It conveys a specific, simplified creation task, but it does not explicitly distinguish itself from sibling tools like character_create, relying on the 'NPC' naming to make that separation.

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 explicit guidance on when to use this tool over alternatives. The word 'quick' implies a lightweight creation path, but no exclusions or comparisons to character_create or other character/NPC tools are provided, so the agent must infer the appropriate usage 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?

With no annotations, the description carries the full burden and discloses substantial behavior: the tool enforces rest limits itself, can refuse for campaign-state reasons, trusts safe_environment without verification, and grants durable recovery if safe_environment is set. It also warns against restating an earlier answer instead of making a fresh call.

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 longer than typical but organized into clear paragraphs and front-loaded with the core action. Some redundancy exists among 'do not refuse it yourself,' 'a declaration reaches this tool directly,' and 'deliver it in fiction,' but the length is largely earned given the subtle hallucination and safe-environment pitfalls.

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 annotations and no output schema, this is complete enough: it covers when to call, what each meaningful parameter does, how the tool behaves including refusal and trusted safe_environment, and how to translate results into fiction. An agent can invoke it correctly without additional context.

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

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

The schema has 0% description coverage, so the prose must compensate. The description explains character_ids, rest_type, and safe_environment, including the long-rest-only and trusted semantics. However, it never explains the optional reason parameter, leaving one of four parameters undocumented.

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 opening line states a specific verb and resource: 'Resolve a party's short- or long-rest declaration.' It reinforces the scope by instructing to call it for every rest declaration, short or long, including repeats, which distinguishes it from the combat, character, and scene sibling tools.

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

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

The description gives explicit when-to-use guidance: call it for every rest declaration, and the tool's response is the only source of truth, not memory. It also gives exclusions: do not pre-refuse, do not add a confirmation step, and set safe_environment true only when the fiction has earned 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 provided, the description carries the full burden of behavioral disclosure. It thoroughly explains side effects: durable changes to campaign files, the distinction between visible_changes, hidden_changes, and party_secrets, the fact that retire_facts stops a fact from being current but keeps it in history, and how persons are allocated IDs and can be promoted via npc_create. It also clarifies that party_secrets are the party's own knowledge and should be answered freely. This is comprehensive and 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 long (~350 words) but every sentence adds value. It is well-structured with paragraphs for each concept, front-loading the purpose and when-to-call instructions. There is slight redundancy: party_secrets vs hidden_changes is explained twice, once in the visible_changes paragraph and again in the party_secrets paragraph. This could be consolidated, but the overall structure is logical and the length is justified by the tool's complexity.

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

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

For a tool with 18 parameters, no annotations, and no output schema, the description is remarkably complete. It covers the purpose, usage conditions, all major parameter semantics, interactions with other tools (npc_create, rest), and the distinction between party knowledge and hidden facts. The only missing elements are the semantics of a few less-critical parameters (exits, new_hooks, resolved_hooks, in_game_time_delta_minutes), but these are either self-explanatory or have defaults. An agent would be able to call this tool correctly in nearly all scenarios based on this description alone.

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 18 parameters with 0% description coverage, so the description must compensate. It does an excellent job for the most critical parameters: visible_changes, hidden_changes, party_secrets, new_clocks (with format), clock_updates (mapping to signed segment changes), environment_tags (replaces tags, affects rest mechanics), persons (with role optional), departed_persons, refs, retire_facts (exact quoting), and present_npcs (contrasted with persons). However, it leaves exits, new_hooks, resolved_hooks, in_game_time_delta_minutes, and scene_title unexplained. Given the high parameter count and zero schema coverage, this is a minor gap but prevents a perfect score.

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 opens with a specific verb and resource: 'Commit a durable fictional change to the campaign files.' It immediately lists concrete triggering events (discovering an entrance, alarming a faction, moving to a new location, learning a secret) and explicitly states what the tool does NOT do ('never changes hit points, Doom, inventory...'), which distinguishes it from sibling tools like combat_start, inventory_update, and rest. This is a clear, unambiguous purpose that an agent can act on.

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 explicit when-to-use guidance ('Call this after the party discovers an entrance...') and when-not-to-use guidance ('This tool never changes...'). It also gives detailed routing instructions: 'Pass present_npcs, not persons, for anyone npc_create already created,' and notes that a move to a new location_id automatically carries persons and located NPCs. It even explains the timing for environment_tags relative to rest mechanics. This is exemplary usage guidance.

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

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

With no annotations, the description fully carries the behavioral burden. It discloses a wide range of side effects and the refusal logic, plus the guarantee that accepted closes still record debt. This exceeds typical transparency requirements and gives an agent a precise model of what happens when the tool is invoked.

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

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

The description is a single paragraph with a list of actions, front-loaded with the main purpose. Every sentence adds unique information (side effects, refusal condition, debt behavior). It is a bit long but not bloated; the structure is clear and scannable.

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

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

The description covers the tool's effects and refusal condition thoroughly but omits explicit guidance on several optional parameters and does not describe the return value (no output schema exists). For a complex 6-parameter tool, an agent would still need to infer the purpose of open_hooks, next_intention, and character_stories_awarded, making completeness only partial.

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 6 parameters, so the description must compensate. It explicitly explains accept_uncommitted and hints at public_summary (via 'writes a dated summary') and session_title (implied by name), but leaves open_hooks, next_intention, and character_stories_awarded unexplained. This is a significant gap for a tool with many parameters, and the parameter semantics are not adequately resolved.

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 main action 'Close the session' and enumerates all the specific side effects (writes summary, awards Stories, clears conditions, re-rolls, creates backup, opens next log). It differentiates from related siblings like scene_commit by explicitly referencing the refusal and the need to call scene_commit 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?

It provides explicit usage context: when to close a session, and a clear condition for refusal (unratified outcomes) with an escape hatch (accept_uncommitted=true). It also names the alternative (scene_commit) and the consequence of using the flag (debt is never silently dropped). This leaves little to inference.

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

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

With no annotations, the description carries the full burden. It discloses that the tool mutates the named resource, steps down the die on 1-2, depletes at d4, and always enters a downgrade into the unratified-outcomes ledger. It also explains stakes semantics. However, it does not explain how advantage/disadvantage affect the roll or what stakes_hidden does, leaving some behavioral gaps.

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 well-structured with a front-loaded purpose, clear line breaks separating mechanics, and no fluff. It is appropriately detailed for the complexity without being verbose, though it could be slightly tighter in the stakes explanation.

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 8 parameters, no output schema, and 0% schema coverage, the description is incomplete. It explains the core dice mechanics but omits details on several parameters (advantage, disadvantage, reason, owner_id, stakes_hidden) and does not describe the return value or any additional side effects. An agent would need to guess or seek external docs for these.

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 only explains stakes_failure and stakes_success (via the stakes semantics) and implies resource_id via 'named resource'. It leaves advantage, disadvantage, owner_id, reason, and stakes_hidden unexplained. This is a significant gap for an 8-parameter tool, making correct invocation difficult without external knowledge.

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

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

The description clearly states the verb 'Roll' and the resource 'Usage Die for a tracked resource', with detailed mechanics (step-down grades, d4 depletion). It differentiates from generic dice tools by specifying the usage-die behavior, though it does not explicitly name sibling alternatives like attribute_test or doom_roll.

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

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

It provides context that this is for tracked resources with usage dice, implying when to use it. However, it does not explicitly state when not to use it or compare with alternatives, such as attribute_test for standard tests or doom_roll for doom dice. The guidance is implicit rather than explicit.

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 present, the description carries the full behavioral burden. It discloses side effects: spending resources, entering/dropping stances, recording standing declarations, and immediately consuming a prepared dose with target semantics. It also explains the effect of omitting target_id, which is meaningful behavioral detail 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.

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

The description is dense but every sentence earns its place: purpose, source of legal values, mode semantics, and choice/target semantics are each clearly separated. The structure front-loads the core action and uses examples to clarify edge cases without wasted prose.

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 multi-mode complexity, lack of annotations, zero enum information, and no output schema, the description is remarkably complete. It covers all parameter semantics, legal-value discovery, mode behavior, passive-effect exclusion, and target resolution in enough detail for an agent to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate for all five parameters. It explains ability_id (from the character sheet), mode (the three values and their meanings), choice (for intent vs dose abilities), and target_id (receiver vs caller). character_id is sufficiently implied as the character whose ability is being used.

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 opening line uses specific verbs ('Activate, deactivate, or spend') with a clear resource ('a character's activatable ability'), and the rest of the description distinguishes this tool from passive effects, which require no call. It is unambiguous and separates the tool from sibling tools like ability_apply_ruling.

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

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

The description gives explicit mode-by-mode usage instructions: 'use' for bounded resources, 'activate'/'deactivate' for toggle stances, and explicit non-usage guidance for passive effects ('need no call'). It also tells the agent where to find legal ability_id values, making the invocation path clear.

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