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

Annotations already carry destructiveHint=true and readOnlyHint=false, and the description adds a concrete warning that changes consume resources and are not safe to repeat blindly. It also discloses the return shape and the dice-fill possibility for calendar-time recovery, going beyond the structured annotation data.

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?

Five sentences, front-loaded with the core update action, then prerequisites, return behavior, safety warning, and sibling routing. Every sentence earns its place, and the prose is remarkably compact for a tool with such a large 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?

Given the large union schema, rich annotations, and output schema, the description supplies the missing operating context: finalized/outside-Battle precondition, Play Session availability, one-kind selection rule, return behavior, dice-fill possibility, and non-idempotence. An agent has enough information to decide and invoke 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?

Schema description coverage is 100%, so the schema carries most parameter semantics; the description adds a useful grouping of operation kinds by intent ('setEquipmentLoadout for equipment, advanceClassLevel for advancement...') and stresses choosing exactly one kind with matching fields. It also calls out the non-obvious interrupted-long-rest segment submission behavior.

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 ('Update a finalized character outside Battle') and enumerates the kinds of state changes: equipment, levels, forms/companions, healing/rests, recovery time, and resource spend/convert. It also distinguishes from sibling groups by pointing to query, creation, and Battle 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?

Explicitly limits use to finalized characters outside Battle and requires affected Character Sessions to be available in the Play Session. It names alternatives: query_character_session for read-only projections, creation tools for drafts, and Battle tools for in-Battle actions, giving clear 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?

Annotations already establish readOnlyHint=false, destructiveHint=true, and idempotentHint=false. The description adds useful behavioral context on top: operations are atomic, add/remove is only valid while the battle is active, and swaps depend on ally willingness. No contradiction with the annotations is present.

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 one dense sentence with no filler and it front-loads the core action. It earns its length given the multiplexed operation, though it could be slightly easier to parse if split into separate conditions.

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 output schema exists, return-value documentation is not required. The description covers operation selection, key preconditions, atomicity, and the active-battle constraint. It does not enumerate failure modes, but the schema's enums and required fields convey much of that structure.

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 maps high-level intent to operation categories, which helps given the complex union schema. However, with roughly 50% schema coverage it only partially compensates for missing parameter-level guidance; it does not explain candidateWitness tags, admissionSource, or ammunitionStocks, leaving those details to the schema.

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

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

The description states a concrete action ('Apply one Battle lifecycle operation') and enumerates the distinct variants: initiative swap, finalize initial setup, and add/remove combatant. This clearly differentiates it from sibling lifecycle tools like end_turn, end_battle, and start_battle.

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 situational context: swaps require a willing ally, finalization applies to initial setup, and add/remove is scoped to active battles with supported or installed sources. It does not explicitly name alternative tools or when-not-to-use conditions, so it stops short of a 5.

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

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

Annotations only state coarse hints (not read-only, not idempotent, not destructive), so the description carries the burden of behavioral disclosure. It adds key behavior: omitting draftId creates a new draft each call, duplicate ids are rejected, and the call returns creation state plus finalization status. No contradiction with annotations exists.

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 deliver the core action, outputs, workflow, and idempotency nuance with no waste. The main function is front-loaded, and the workflow guidance is compact and actionable.

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 stateful creation tool, the description covers entry into the workflow, continuation steps, resume behavior, and id-reuse rules. Since an output schema exists, the description need not detail the return shape; nothing essential for correct invocation is missing.

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

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

Schema coverage is 100%, so the schema already documents both parameters well. The description adds genuine value beyond the schema by explaining the behavioral consequences of omitting draftId and that an already-used id is rejected, which strengthens the agent's understanding of draftId 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 opens with a specific verb and resource: 'Begin creating a character... by storing a new draft' and names the exact outputs (draftId, unanswered creation choices, revision, finalization status). It also distinguishes itself from sibling tools like fill_creation_holes, finalize_character, and discover_creation_holes, so an agent can tell them apart without inspecting 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 workflow: continue with fill_creation_holes, then finalize_character when ready, and use discover_creation_holes to resume an existing draft. It also explains the draftId behavior and duplicate rejection, giving clear conditions for correct invocation.

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 minimal (all false hints, indicating this is a mutating, non-idempotent operation), so the description carries the burden. It adds genuinely useful behavioral context: hosted creation requires authentication, is saved by default, and local creation lasts only for the server process. No contradiction with 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?

A single sentence that front-loads the purpose and packs the two mode behaviors efficiently. No wasted words, though the two clauses could arguably be split for readability.

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?

Complete for a zero-parameter creation tool that has an output schema present. It covers the key operational distinctions (auth requirement, persistence default, process-lifespan) that an agent needs to decide between modes.

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?

Zero parameters with 100% schema coverage trivially, so the baseline of 4 applies. There are no parameters to document, and the description appropriately does not invent any.

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 ('Create an isolated Play Session'), and the qualifier 'isolated' adds scope. It distinguishes itself from sibling create tools (create_character_draft, fill_creation_holes, start_battle) by targeting a distinct resource type, though it never explicitly names any sibling to contrast against.

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 guidance on when to use this tool versus alternatives. It explains the two creation modes (hosted vs local stdio) but does not say when to prefer this over read_play_session or other creation tools. The mode detail is behavioral context, not selection 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, idempotentHint=true, and destructiveHint=false, so the description's promise to 'Return' is consistent with the safety profile. However, the description adds no further behavioral context beyond what annotations provide, such as whether results vary or if any rate limits exist.

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, efficient sentence lists all the key output elements (workflow guide, fill shapes, result paths, intent aliases, recovery rules) with no filler. The primary action is front-loaded, and every word adds value.

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

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

Given the tool has no parameters and annotations cover safety, the description fully explains what the tool returns. The output schema exists but is not detailed in the prompt; however, the description explicitly names the result categories, so an agent can infer the structure. It lacks explicit when-to-use wording, but for a meta-descriptor, this is minor.

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, and the schema has no properties. The description doesn't mention parameters, but with zero parameters, there is nothing to explain. The baseline for 0-parameter tools is 4, and the description correctly avoids inventing unnecessary parameter details.

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 ('Return') and clearly enumerates the resource content: workflow guide, fill shapes, result paths, intent aliases, and recovery rules. This distinguishes it from all sibling tools, which focus on specific actions or entities (e.g., battles, characters, catalog) rather than a meta-guide.

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 or when-not-to-use guidance is provided, nor are alternatives mentioned. The purpose is self-evident (get an overview of this MCP), but the description does not state conditions like 'use when you need to understand the overall workflow' or 'not for specific entity details.'

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 read-only, idempotent, non-destructive behavior. The description adds sequencing guidance, conditional routing, and notes that it returns the same envelope as read_battle_state, which is useful beyond the annotations.

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

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

Three dense sentences with the core read operation front-loaded. Every sentence earns its place by adding actionable routing or sequencing guidance without 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?

Covers when to call, what to check, how to route follow-up actions, and an ordering constraint. With an output schema present and the return envelope identified, the agent has what it needs to call 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 coverage is 100%: the single playSessionId parameter is already fully described with type, pattern, and semantics. The description adds no additional parameter detail, so baseline 3 is appropriate.

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

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

States a specific verb and resource: 'Read the Battle's current checkpoint/frontier and available acts without changing state.' This clearly distinguishes discovery from mutating siblings like fill_battle_hole and resolve_battle_act.

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 explicit trigger conditions ('Call after start_battle or any Battle mutation'), conditional routing ('copy a returned subject exactly into resolve_battle_act when initialHoles is empty, otherwise use fill_battle_hole'), and an ordering constraint for pending holes or interrupt decisions.

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, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context by noting that all returned options are admitted by the server's active execution support profile, and by revealing that draft revision and finalization status are included.

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

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

Two concise sentences with no filler. The primary purpose is front-loaded, and the second sentence adds a meaningful constraint about the server's execution support profile without unnecessary elaboration.

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 has a rich output schema, full annotation coverage, and two fully described required parameters. The description is sufficient for an agent to invoke this read-only discovery tool correctly and understand what it returns.

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

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

Schema description coverage is 100%, and both parameters are already well documented in the input schema. The description does not add additional parameter-level detail, so it relies appropriately on the structured schema definitions.

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 ('Return') and names the exact resource ('current supported fillable creation holes, draft revision, and finalization status for a stored character draft'). It clearly contrasts with the sibling fill_creation_holes, which performs a mutation rather than discovery.

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 makes the usage context clear: call this to obtain the currently supported fillable options and draft status before proceeding. It does not explicitly name fill_creation_holes as the follow-up alternative, but the read-only discovery intent is unambiguous from the wording.

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 mark this as destructive and non-read-only, and the description adds meaningful context: finalizing the battle also transfers character-owned facts like current HP back into durable character session state. It does not contradict the annotations and gives a useful picture of the mutation's 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?

One tightly written sentence, with the primary action front-loaded and the key side effect immediately following. Every clause adds information; there is no padding or 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 single-parameter tool with a rich pattern-validated schema, a full output schema, and annotations covering destructive and idempotent behavior, the description is nearly complete. The only gap is the lack of explicit routing guidance relative to end_turn and resolve_battle_act, but that is minor 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?

The single parameter is fully documented in the schema, including its format, source (create_play_session), and purpose. With 100% schema description coverage, the baseline of 3 is appropriate; the tool description adds no additional parameter-level detail.

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 ('Finalize') and a specific resource ('stored battle session'), and clearly explains the post-battle side effect of handing HP and other facts to durable character state. This distinguishes it from sibling tools like start_battle, end_turn, and read_battle_state.

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

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

The description implies usage at the end of a battle when post-battle facts must be persisted, but it does not explicitly state when not to use it or name an alternative such as end_turn for mid-battle progression. Usage context is present but left 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?

Annotations already give destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds useful behavioral context beyond those flags: the operation applies end-of-turn effects, stores the result, and may require hole fills or reaction decisions before play advances. This explains the mutable, non-final nature of the operation without contradicting the annotations.

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

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

The description is compact, front-loaded with the action and precondition, and every sentence delivers distinct information: what the tool does, how to select the right actor, what side effects occur, and how to proceed or use the sibling tool. There is no redundant or filler content.

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 moderate complexity, the rich schema, the presence of an output schema, and the annotations, the description covers the necessary operational context: when to act, what the result may contain, and the follow-up path (fill_battle_hole or end_battle). Nothing needed for correct invocation is missing.

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

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

Schema description coverage is 100%, and both actorId and playSessionId already have detailed schema descriptions. The tool description reinforces 'Use actorId for the current actor in the returned Battle state,' but it does not add meaningful parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description states a specific verb ('End'), a precise resource ('the current combatant's turn in an active Battle'), and a precondition ('after all pending fills are resolved'). It also differentiates this tool from the sibling end_battle by clarifying scope: end_turn advances a turn, end_battle finishes the entire Battle.

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 tells the agent when to call this tool (after pending fills are resolved), how to identify the correct actorId (from the returned Battle state), and what to do next if the response requires follow-up ('Continue from the returned frontier with fill_battle_hole when required'). It also names the alternative end_battle for the full Battle, covering the main routing decision.

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

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

The description goes beyond the destructiveHint annotation by stating that MCP retains the base session, subject, and accepted fills while the battle runtime advances the checkpoint/frontier envelope. It reveals that the call mutates battle state and preserves prior fills, which is useful context not present in the annotations.

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

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

The description is only two sentences: the first states the operation, the second gives the most important state-retention and side-effect context. It is front-loaded and contains 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?

The rich input schema (including exact subject-copy instructions and fill construction rules) and output schema cover most invocation details, so the short description is sufficient to accompany them. It lacks explicit workflow ordering or alternative routing, but the parameter and output schemas largely compensate.

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

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

Schema description coverage is 100%, so the schema already fully documents all three parameters. The tool description itself adds no parameter-level detail beyond referring to 'accepted fills,' so it earns the baseline 3 rather than more.

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

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

The description uses a specific verb and resource: 'Fill one hole for a selected battle act subject.' This clearly places it in the battle-act workflow and distinguishes it from the sibling fill_creation_holes through the 'battle act subject' qualifier, though it does not explicitly name that alternative.

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

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

The intended use is implied: fill one hole after a battle act subject is selected. There is no explicit when-to-use/when-not-to-use guidance or named alternative, though the phrases 'selected battle act subject' and 'accepted fills' suggest the surrounding discover-and-fill workflow.

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 flag destructive and idempotent behavior, and the description adds valuable specifics: the batch is atomic, accepted batches replace the stored draft, and rejected batches leave it unchanged. This goes beyond the annotations without contradicting them.

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

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

Two information-dense sentences with no filler. The first sentence states the action, resource, and data source; the second conveys the key atomic replacement semantics. Everything 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 destructive mutation with an output schema present, the description supplies the essential outcome guarantee and atomicity. The schema fully documents all four required parameters, so an agent has what it needs 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 coverage is 100%, so the schema already documents every parameter, including holeId, optionIds, expectedRevision, and playSessionId. The description adds only general guidance about using option ids from current holes, which is helpful but not substantially beyond the schema.

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

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

The description names a specific action—submitting an atomic batch of creation fills—for a specific resource (a stored draft), and clarifies the required data source: option ids returned by its current holes. This clearly distinguishes it from siblings like discover_creation_holes and fill_battle_hole.

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 the context clearly: filling a stored draft using options ids from its current holes, and describes acceptance/rejection outcomes. It does not explicitly enumerate when not to use it or compare it with sibling tools, but the workflow context is strongly implied.

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 indicate destructive and idempotent behavior, and the description adds the exact side effects: the draft is removed and the resulting in-play record is stored. This directly discloses what gets destroyed, which is the key behavioral information 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?

Three tight sentences with no filler. The core action and side effect are front-loaded, and the Druid-specific requirement is placed last as a conditional addendum.

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 a complete input schema, an output schema, and annotations covering destructive/idempotent behavior, the description adds exactly the missing context: the mutation semantics and the conditional Wild Shape requirement. 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?

Schema description coverage is 100%, so the schema already documents all parameters. The description's Druid Wild Shape note largely restates the schema's own conditional requirement and adds little semantic value beyond it.

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 ('Finalize a complete supported character draft') and then states the concrete effect: it stores the resulting in-play record by characterId and removes the active draft. This makes the tool's function unambiguous and distinguishes it from draft-creation and session-query siblings.

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 signals when to use the tool: only for a 'complete supported' and 'ready' draft. It also gives a crucial conditional for Druid Wild Shape drafts requiring Beast Stat Block ids. It does not explicitly name alternatives or state when not to use it, but the context 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description need not repeat those. It adds valuable context: the returned JSON is the canonical authored detail but does not guarantee source executability. This caveat goes beyond the structured metadata and helps the agent understand the data's limitations.

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 and front-loads the core purpose. The second sentence adds a necessary caveat but is somewhat densely worded; overall it is efficient 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 read-only tool with an output schema, the description covers the essential points: what is returned, the parameter meaning, and a key caveat. Since the output schema exists, the lack of explicit return-format explanation is acceptable. The only minor gap is the absence of explicit guidance on how to discover catalog ids.

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 clarify that unitId is the catalog id, which gives the parameter meaning beyond the schema's pattern constraint. However, it does not explain how to obtain a valid id or whether the format has any special restrictions beyond what the schema already encodes.

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 ('Return') and a specific resource ('canonical installed redistributable SRD Unit record') for a single catalog id. This distinguishes it from the sibling list_catalog_units, which presumably returns multiple units. The caveat about executability adds nuance without clouding the core purpose.

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

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

The description implies this tool is for retrieving a specific unit when you have a catalog id, but it does not explicitly mention when to prefer this over list_catalog_units or how to obtain the id in the first place. No exclusions or alternative routing are provided, leaving usage context to be inferred.

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 disclose read-only, idempotent, non-destructive behavior. The description adds useful context by clarifying that the response contains the canonical stored session plus build-derived facts, rather than a live or purely computed view. No contradiction with 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?

The description is a single, dense sentence with no filler. It front-loads the verb and object and then enumerates the precise result fields, making it easy to parse quickly.

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 inspection tool with full schema coverage, clear annotations, and an output schema, the description adequately conveys what the call returns. The only notable gap is the absence of usage context distinguishing it from similar session-related sibling tools.

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

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

Schema description coverage is 100%, and both characterId and playSessionId have meaningful descriptions explaining where the values come from. The tool description itself adds no parameter-level detail, so the baseline of 3 applies.

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

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

The description clearly identifies the action ('Inspect'), the target ('one selected Character Session'), and the scope of the result (canonical stored session plus core build-derived HP, Hit Dice, Spell Slots, Pact Slots, and resource facts). It is specific but does not explicitly differentiate from the sibling query_character_session.

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 when-to-use guidance is provided. It does not mention when to pick this over query_character_session, read_play_session, or other sibling session tools. The word 'selected' hints at prior selection but offers no actionable instruction.

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 readOnly, idempotent, and non-destructive behavior. The description adds meaningful context by scoping the result to catalog presence and clarifying that it is not authoritative for legal/executable sources, which goes beyond the structured 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?

Two short sentences communicate both the operation and a crucial limitation with no filler. The main action is front-loaded and the caveat follows immediately.

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

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

For a zero-parameter, read-only list tool with an output schema and complete annotations, the description covers everything an agent needs to call it correctly and interpret its scope. No meaningful information is missing.

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

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

The tool has zero parameters and the schema fully documents this (100% coverage), so no parameter explanation is required. The baseline of 4 for a no-parameter tool applies.

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

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

The description names a specific verb ('List'), a precise resource ('installed redistributable SRD Unit id'), and the grouping ('by kind'). This distinguishes it from sibling tools like inspect_catalog_unit and list_stat_blocks, whose purposes are different.

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 caveat 'reports catalog presence only; legal and executable sources still come from the consuming workflow's canonical discovery result' tells the agent when this tool is insufficient and what to rely on instead. It does not explicitly name an alternative tool, but the guidance is clear enough to route usage.

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 readOnly and idempotent, and the description adds behavior beyond that: only finalized characters are returned, drafts are excluded, Battle participants are marked unavailable, and available rows include mutable sheet state and resources such as HP, Hit Dice, spell slots, Pact Slots, and feature resources.

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 carry the purpose, the inclusion/exclusion rules, the available fields, and the exact follow-up tool routing with no filler. The most important scoping information ('all finalized characters') is front-loaded.

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

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

With an output schema present and annotations covering safety and idempotency, the description supplies everything an agent needs to call correctly: scope, filters, availability semantics, and how to use the returned characterIds. No important behavioral gap remains.

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

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

Schema coverage is 100% and the single playSessionId parameter is already documented with a pattern and meaning. The description adds the scoping phrase 'in this Play Session,' but no extra syntax or edge-case detail is needed because one fully documented parameter exists.

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: 'List all finalized characters in this Play Session' and enumerates the payload fields (characterId, Battle availability, build-derived facts). It distinguishes itself from sibling list tools such as list_stat_blocks and list_catalog_units by scoping to Play Session characters and by explicitly excluding unfinished drafts.

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 conditions for inclusion ('finalized', 'unfinished drafts are excluded', 'characters in Battle are marked unavailable') and routes follow-up use to 'inspect_character_session for stored details or query_character_session for a calculated projection.' This gives an agent explicit when-to-use and which-alternative 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, idempotentHint, and destructiveHint, covering safety. The description adds useful context about the return content (ordered procedure summaries, retained text-only entries) and the caveat about executability across workflows, which goes beyond annotations.

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

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

The description is two sentences, efficient and front-loaded with the main purpose. The caveat sentence adds important context without excessive verbosity. Slightly more could be said about use cases, but it remains compact.

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

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

Given the tool's simplicity (no parameters) and the output schema providing return structure, the description covers all necessary aspects: what items are listed, their attributes, and a critical caveat about executability. It's complete for an agent to decide and invoke correctly.

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

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

With zero parameters, the schema provides no parameter information, so the description's detailed listing of what the tool returns serves as the semantic content. This fully compensates for the absence of parameters, providing clear expectations.

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 it lists every installed redistributable SRD Stat Block with specific attributes (ids, names, summaries, attacks, defenses, damage modifiers). It distinguishes itself from siblings like list_catalog_units and inspect_catalog_unit by focusing on stat blocks specifically.

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

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

The description implies its use for discovering available stat blocks before selecting one, but it doesn't explicitly address when not to use it or which sibling to prefer. The phrase 'Catalog presence does not imply executable' adds caution, providing some guidance on interpretation.

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, idempotentHint, and non-destructive behavior, lowering the burden. The description reinforces this with 'without changing its state' and adds operational context: the character must be finalized, outside Battle, and available in the current Play Session. It does not contradict the annotations and adds modest context beyond them.

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 dense sentences with no filler: purpose is front-loaded, the query-kind guidance is centralized, the prerequisite is stated, and alternative tools are named. 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?

For a complex polymorphic read tool, the description is complete: it covers what the tool reads, the precondition, the query-kind selection, and sibling routing. The detailed variant schemas and output schema carry the remaining specification, so nothing essential is missing.

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

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

Schema description coverage is 100%, so the parameters are already well-documented. The description adds useful high-level guidance—'Choose query.kind' and 'supply only that variant's fields'—but this mostly restates the discriminated-union structure already expressed in the schema's required fields and additionalProperties constraints.

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: 'Read one calculated result for a finalized character outside Battle without changing its state.' It also enumerates the query domains and explicitly contrasts this tool with inspect_character_session and apply_character_session_operation, making sibling differentiation clear.

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 the core use case—computed results for finalized characters outside Battle—and the prerequisite that the character must be available in the Play Session. It explicitly routes to inspect_character_session for stored/core sheet facts and apply_character_session_operation for mutations, leaving no ambiguity about 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds value by specifying the exact content returned (checkpoint/frontier envelope and session summary), which goes beyond the annotations and clarifies the tool's output nature. There is no contradiction with 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?

The description is a single, front-loaded sentence that directly states the action and the objects returned. No extraneous words or filler. It is highly efficient and easy to parse.

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

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

For a simple read-only tool with one parameter, an output schema present, and annotations covering safety, the description sufficiently communicates the purpose and return content. It could mention when to use this over related read tools, but that gap is minor given the low complexity and clear resource naming. Overall, the agent has enough 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?

Schema coverage is 100%: the playSessionId parameter is thoroughly documented with a regex pattern and a clear description. The tool description adds no additional meaning about the parameter. Since the schema fully handles parameter semantics, the baseline score of 3 is appropriate.

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

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

The description states a specific verb ('Return') and a concrete resource ('battle-runtime checkpoint/frontier envelope and MCP session summary'). It clearly identifies the tool's focus on battle state, distinguishing it from siblings like read_play_session which targets play session data. The phrasing is unambiguous and specific.

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

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

The description implies the tool is for retrieving battle state, but it does not explicitly state when to use it versus alternatives such as read_play_session or describe_mcp_workflow. No exclusions or conditions are provided, leaving the agent to infer usage based on the resource name. This is adequate but lacks explicit routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is established. The description adds useful context beyond that: the 'accessible' prerequisite and the fact that persistence status is returned, alerting the agent that sessions may exist in different persistence states. No contradiction with 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?

A single sentence front-loads the action ('Resume') and object ('Play Session'), then packs the output categories without filler. Every phrase 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 one-parameter, read-only tool with a rich schema, detailed annotations, and an output schema, the description covers what the tool does, what it returns, and the accessibility precondition. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, and the schema already explains that playSessionId is a handle returned by create_play_session for follow-up calls. The description adds no new parameter details, so the baseline of 3 is appropriate.

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

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

The description names a specific action and resource ('Resume an accessible Play Session') and enumerates the precise return categories: persistence status, current projection, unresolved inputs, and next operations. This is enough to distinguish it from create_play_session and from sibling read tools targeting other entities (characters, battles).

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 wording implies use after a session has been created and when the caller needs to pick up state ('Resume... return... next operations'). It gives clear context but does not explicitly state when not to use it or name alternative tools, so it stops short of 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 mark the operation destructive and non-read-only; the description adds that the act applies effects and resource costs, stores the updated Battle, and may return further input or reactions. The 'do not repeat' warning reinforces non-idempotence with practical guidance beyond the annotations.

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

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

The description is dense but compact, front-loading the core execution condition before adding prerequisites, alternatives, and warnings. Every sentence carries decision-relevant information, though the final clause about creatureFalls is slightly intricate.

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 high complexity of nested reactionSpellTargetFacts, the creatureFalls variant, and the playSessionId linkage, the description covers prerequisites, alternatives, parameter sourcing, and non-idempotency. The presence of an output schema means return-value details need not be restated.

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

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

Schema description coverage is 100%, so the input schema already documents each parameter thoroughly. The description mostly restates schema guidance about exact subject sourcing and reactionSpellTargetFacts rather than adding substantial new parameter-level meaning.

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 ('Execute'), resource ('Battle act'), and condition ('initialHoles is empty'), while naming the exact source for the subject: discover_battle_acts. This clearly distinguishes the tool from fill_battle_hole and discover_battle_acts.

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 directs the agent to fill_battle_hole for acts that require input and requires an active Battle with no pending fills. The warning against blindly repeating a successful call further narrows the appropriate use case.

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 all false, so the description carries the full burden, and it delivers: deterministic non-cryptographic DRDice, advancing the Play Session's dice sequence, returning raw faces, and explicitly excluding hole-reading, derivation, and filling. No contradiction exists.

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 dense sentences with no fluff: the first states the core action, the second the side effect, the third the boundaries. 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?

The description is complete for this tool's complexity: independent sampling, deterministic behavior, side effect on the session, and exclusions are all present. An output schema exists for return values, so omitting a return description is fine.

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 50% because the `groups` property lacks a direct description, though its item schema details dice and dieSize. The description adds the 'ordered, non-empty batch' framing and maps to the play-session sequence, but it doesn't explain the group fields themselves. It partially compensates for the coverage 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 names a specific verb ('Sample'), a precise resource ('ordered, non-empty batch of structured dice groups'), and a clear output ('visible raw faces'). It also distinguishes itself from battle-hole and fill tools by explicitly stating it never reads Battle Holes or fills a Hole.

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 clear when-not guidance: it never reads Battle Holes, derives modifiers/outcomes, or fills a Hole, and tells the agent to copy faces into an ordinary typed fill only when the runtime Hole supplies the required facts. It stops short of naming a specific sibling alternative, so it loses a point.

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 communicate mutability and destructiveness, so the bar is lower. The description adds useful behavioral context by stating it stores only the Stat Block id in the MCP session, which clarifies the scope of state change. No contradiction with the annotations is present.

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

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

Two short sentences accomplish the task: the first states the primary action and context, the second clarifies the precise persistence behavior. There is no filler or repetition.

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

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

For a simple two-parameter selection tool with an output schema and rich annotations, the description is nearly complete. It could optionally mention the expected workflow position, but the schema already supplies the key prerequisites, so nothing essential is missing.

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

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

Schema coverage is 100%, and both parameters already have rich descriptions: statBlockId is sourced from list_stat_blocks and playSessionId is tied to create_play_session. The description itself adds no parameter-level detail, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Select') and resource ('SRD Stat Block'), and adds the context 'for the battle session' and the side effect of storing only the id. This clearly distinguishes it from browsing tools like list_stat_blocks or inspection tools like inspect_catalog_unit.

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

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

The phrase 'for the battle session' gives clear context for when this tool applies, and the side-effect clarification helps distinguish selection from mere listing. It does not explicitly name alternatives or exclusions, but the intended use case is evident from the description and sibling 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 destructiveHint=true and readOnlyHint=false, so the mutating nature is known. The description adds useful stateful context about keeping the SDK-owned Initiative setup open for the battle_lifecycle surface, but does not describe specific side effects or what is destroyed, which is acceptable given the annotation bar is lower.

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

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

The description is three sentences with no filler: purpose, conditional Size guidance, and Initiative/mode requirements are each front-loaded and useful. 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?

For a stateful creation tool, it covers prerequisites, source types, Initiative requirements, and mode consequences, and an output schema exists so return values are not a gap. It omits companionAdmissions as a third admission path, which the schema covers but the prose does not surface.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds cross-tool meaning by tying Size selection to list_stat_blocks alternatives and clarifying that Initiative is required for every combatant and why initialSetup matters. It does not mention companionAdmissions, but the schema already fully documents that 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 names a specific action (start), a specific resource (battle session), and the two valid source types (finalized Character Builds and SRD Stat Blocks). It clearly distinguishes itself from mutation/read siblings like end_turn, end_battle, and read_battle_state.

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 clear context: it requires finalized characters, selected stat blocks, caller-provided Initiative scores, and explains when to use initialSetup. It does not explicitly enumerate when not to use this tool or contrast it directly with sibling tools, but it is strong enough for the starting-battle scenario.

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