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

With no annotations, the description carries full burden for behavioral disclosure. It honestly reveals key behaviors: validation of skillId existence, sorting by level, and a warning (never blocking) when the skill's stypeId lacks a required trait. It even explains the consequence of ignoring the warning (skill-type command never appears, actors cannot use the skill). This is exceptional transparency.

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

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

The description is compact, with the main purpose front-loaded in the first sentence and behavioral details efficiently packed into the second. The parenthetical about the trait is a bit dense but earns its place. No wasted words, though the long second sentence could be slightly 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?

Given the tool has 5 parameters, no annotations, and no output schema, the description adequately covers core behaviors: what it does, validation, sorting, and the important warning. It does not explicitly describe return values or exact error behavior on failed validation, but the description is sufficiently complete for an agent to invoke it correctly in most situations.

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 baseline is 3. The description does add some context for 'level' (sorted by level) and confirms the skillId existence requirement already in the schema, but it does not need to compensate for missing parameter info. It adds marginal value beyond the structured schema.

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

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

The description clearly states the action: 'Add a "learn skill at level" entry to a class'. It uses a specific verb+resource pattern and distinguishes itself from an alternative hack (attaching skills to actors via an Add-Skill trait), making its purpose unambiguous among many 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 provides clear usage context: it is the proper way to add skill learnings to a class, replacing a common hack. It also implicitly warns when not to use it or what prerequisite is needed (the Add Skill Type trait) for the skill to be usable. It does not explicitly name alternative tools, but the context is sufficient.

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

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

With no annotations provided, the description carries the burden of disclosing behavioral traits, and it does so well by stating that writes are refused (nothing saved) on structural invalidity and that force: true overrides this. This goes beyond the obvious 'add' action and covers a key failure mode. However, it does not mention the success-side behavior, return format, or the dryRun/verbose preview features, which are only present in 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 compact and front-loaded with the core action. Each sentence earns its place: the first states the purpose, the second explains the validation refusal behavior, and the third points to the force override. There is no wordy or redundant filler, making it easy to scan and act on.

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 essential validation behavior and force override, but it stops short of explaining the broader workflow: how to build a valid command object (sibling build_* tools), what the default response contains, or how dryRun/verbose affect the interaction. Given the absence of an output schema and the nested command structure, more contextual guidance would help an agent 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 100%, so the baseline is 3; the description adds only marginal parameter meaning beyond the schema. It references force: true and the wrong-parameter-count criterion, but the schema already documents force and all other parameters thoroughly. The description does not clarify command construction (e.g., the relationship to build_* tools), leaving the command object semantics 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 opens with a specific verb and resource: 'Add a command to an event page.' This clearly states the tool's function and differentiates it from sibling tools like insert_event_commands or set_event_page by focusing on adding a single command to a specific event page. The validation/force caveat further clarifies the primary action without muddying the 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 when to use the tool ('Add a command to an event page') and describes the validation gate, but it does not explicitly mention when not to use it or name alternatives among the many sibling tools. There is no guidance distinguishing it from insert_event_commands or noting that command objects should be constructed via build_* tools, leaving usage somewhat inferred rather than directed.

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 full burden, and it excels. It discloses atomic failure ('Throws — writing nothing at all'), sequential id allocation ('Ids are allocated sequentially from the current max'), the return shape (`{ type, count, created, warnings? }`), and warning behavior ('enemy battlerName misses are warnings, never blocked'). These are critical behavioral nuances beyond simple schema info.

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

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

Four dense sentences, each earning its place. The first sentence states purpose, the second explains record semantics and id behavior, the third gives usage guidance, and the fourth covers return/error behavior. 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?

This is a complex batch write tool with no output schema. The description covers return format, error conditions, atomicity, id allocation, and warning semantics. It also references sibling tools for record shape clarification. This is fully complete for an agent to select 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?

Input schema already covers 100% of parameters with descriptions, providing a strong baseline. The description adds meaningful semantics: each entry in `records` follows the matching create_* tool's field shape, only `name` is required for most, and omitted fields use defaults. It also explains how the `type` parameter relates to record shape. This goes beyond schema, though the schema already does much of the work.

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: 'Create many database records of one type in a single call and a single file write.' It explicitly identifies itself as the batch sibling of the single-record create_* tools, distinguishing it from those alternatives and clearly conveying its 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 provides explicit when-to-use guidance: 'Use this instead of N sequential create_* calls when authoring a cast, a loot table, or a skill list.' This also indicates the alternative approach (sequential calls) and the scenarios where batching is preferable.

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 well: it states 'Read-only: returns { command }', clearly disclosing that the tool has no side effects and returns a command object. It also explains how canEscape/canLose gate battle result branches, adding behavioral context 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 two sentences, front-loaded with the core purpose, and every clause adds value—purpose, parameter behavior, and read-only nature are all conveyed without redundancy.

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

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

Given the tool's moderate complexity, the description covers the essential points: what it builds, how it integrates with insert_event_commands, the key parameter modes, and the return shape ({ command }). The absence of an output schema is compensated by explicitly stating the return value.

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 meaningful semantics by explaining the three troop selection modes (direct id, variable, random) and how canEscape/canLose affect branches, going beyond the schema's per-parameter descriptions.

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

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

The description clearly states the tool builds a Battle Processing (301) event command, with a specific verb ('Build') and resource ('Battle Processing event command'). It also distinguishes this from sibling builders by naming the exact event command type and connecting it to insertion via insert_event_commands.

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 places usage in the context of insertion via insert_event_commands, providing clear context. However, it does not name alternatives or explicitly say when not to use this tool, falling 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?

With no annotations, the description carries the full burden and does well by disclosing read-only behavior, the return shape ('returns { command }'), and per-kind input variants. It does not cover validation or error behavior, but for a command builder that is acceptable.

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 and front-loads the purpose; each clause adds needed grouping or safety information. It avoids redundant restatement of schema fields and has 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 9-parameter tool with no output schema, the description covers return value, target types, and variant-specific required arguments. It leaves default flags like indent, showLevelUp, and allowKnockout to the schema, which is reasonable because the schema documents them.

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

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

Although the schema already describes every parameter (100% coverage), the description adds semantic grouping not present in the schema: hp/mp/exp/level use operand, state uses add/remove + stateId, and recover_all takes nothing extra. This helps the agent know which parameters apply to each kind.

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 ('Build') and resource ('actor stat-change scene command'), explicitly names the six command kinds (hp, mp, state, recover_all, exp, level), and states it is read-only. This clearly distinguishes it from sibling builder tools and event-command manipulators.

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 intended usage context ('for insertion via insert_event_commands') and enumerates all supported variants. It does not explicitly name alternative tools or exclusions, but the builder-for-insertion relationship 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?

With no annotations, the description carries the full burden. It explicitly states 'Read-only: returns { command }', disclosing that the tool does not mutate project state and what it returns. This is a useful behavioral disclosure beyond the schema, though it could further note that it only builds the command without inserting it (already implied) and may not validate operand-value consistency.

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 with no wasted words. The first sentence delivers the core purpose and the second adds the key behavioral trait (read-only) and return shape. It is well front-loaded and easily 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 tool has a nested operand object with conditional fields, no output schema, and no annotations. The description covers the main purpose, return shape, and read-only nature, but does not explain the conditional requirements of the operand sub-parameters (e.g., which fields are required based on type) or show an example output command structure. This leaves some gaps for correct invocation, but the simplicity of the operation and clear schema descriptions keep it adequate.

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% for all parameters, so the schema already documents operation (increase/decrease), operand type (constant/variable), value, and variableId. The description adds only a high-level summary ('increase or decrease party gold by a constant or variable amount') without clarifying conditional requirements (e.g., when type=variable, variableId is needed; when constant, value is needed). This matches the baseline of 3 for high schema coverage.

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 builds a specific Change Gold (125) event command, distinguishes it from the many other build_* tools (e.g., build_show_text, build_control_switch), and specifies its purpose of insertion via insert_event_commands. Verb 'build' plus resource 'Change Gold' gives a precise, unambiguous action.

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

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

The description explicitly situates this tool in the pipeline with 'for insertion via insert_event_commands', telling the agent when to use it (to generate a command before inserting). It does not explicitly name alternatives or exclusions, but the build_* family context plus the specific resource makes the appropriate use case 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 full burden. It explicitly states 'Read-only: returns { command }', which is essential behavioral information for an agent. It also discloses that includeEquip counts equipped copies when removing, giving insight into the tool's behavior beyond its basic function.

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 with no wasted words. The first sentence presents the core purpose and insertion mechanism, while the second adds a key edge case and the read-only behavior. This is appropriately sized and 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?

For a builder tool with no output schema and no annotations, the description provides complete context: it explains what is built, how it will be used (insert_event_commands), the relevant parameter nuance (includeEquip), and the return shape. Nothing essential is missing for an agent to correctly select and invoke this 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 100%, so the baseline is 3. The description adds value by summarizing the overall gain/lose semantics and clarifying the includeEquip parameter's behavior (equipped copies when removing), which goes beyond individual field descriptions. This additional context helps the agent understand how the parameters interconnect.

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 ('Build') and identifies the exact event commands ('Change Items (126), Change Weapons (127), or Change Armors (128)'), clearly distinguishing it from other build_* sibling tools. It states the action (gain/lose an item/weapon/armor) and the mechanism (constant or variable amount), making the tool's purpose 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 says this builds a command 'for insertion via insert_event_commands,' which gives clear context on when to use it. It also notes the includeEquip caveat for weapons/armors, but does not explicitly state when not to use it or alternatives. However, the build_* family is well-defined, and the purpose itself implies 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?

With no annotations provided, the description carries the full burden. It clearly states 'Read-only: returns { command }', disclosing that it doesn't mutate state and what the return value is. It also explains the initialize parameter's behavior (reset to initial state) for add operations. This is substantial but doesn't cover potential errors or 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?

Three sentences, all informative, no filler. Front-loaded with the core purpose, then adds necessary context. 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 tool with 4 params and no output schema, the description adequately explains the command type, usage context, and return format. It could be more detailed about the returned command structure, but it's sufficient for an agent to know 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?

Schema description coverage is 100%, so all parameters are already documented. The description adds a small clarification about initialize (add only) but largely repeats schema information, so it doesn't significantly go beyond the baseline.

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

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

The description clearly states the tool builds a Change Party Member (129) event command, specifying the verb 'Build' and the resource. It distinguishes from sibling tools by naming the event command ID and its purpose (add/remove actor from party).

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 says the command is 'for insertion via insert_event_commands', giving clear context for where the output goes. However, it doesn't explicitly state when not to use this tool or mention alternatives, 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only' and that it returns '{ command }', which are critical behavioral traits. It also adds the event command IDs (212/213) and character targeting context, but does not detail error behavior or side effects of the generated command when inserted.

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 long, front-loaded with the core purpose, and every phrase adds value. It efficiently packs the command types, insertion context, characterId mapping, and read-only behavior without 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?

The tool has 5 parameters and no output schema, but the description provides the essential context: it returns a command object for insertion, identifies the exact event commands, and explains characterId values. It does not detail the internal structure of the returned command, but for a builder that partners with insert_event_commands, this is 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 100%, so baseline is 3. The description mentions characterId semantics and the id's dual role, but these are already fully described in the schema. It adds no significant parameter-level meaning beyond what the structured schema already provides.

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 builds a Show Animation (212) or Show Balloon Icon (213) event command for insertion via insert_event_commands, specifying the exact verbs and resources. It distinguishes itself from sibling builders by naming the specific event command types and their target character scope.

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 mentions the intended use case ('for insertion via insert_event_commands') and clarifies the characterId semantics (player, this event, or event id). It implies the tool is for building these two specific command types among many sibling builders, though it does not name alternatives or 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 takes on the full burden and states 'Read-only: returns { commands }', which informs the agent that this tool has no side effects. It also discloses the block composition and termination behavior, adding useful behavioral context 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 a single dense paragraph that packs in the block structure, condition types, branch handling, insertion target, and read-only nature without any filler. Every sentence earns its place and key information 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?

Given the moderate complexity and rich schema, the description covers the essential usage pattern, return format, and side-effect profile. It could mention error cases or branch termination details more explicitly, but the provided text is sufficient for an agent to correctly select and invoke the 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?

The schema covers all parameters with descriptions, so the baseline is 3. The description adds extra meaning by explaining that branches are EventCommand arrays and that the elseBranch presence adds the 411 block, and clarifies the return shape. This supplements the schema with builder-pattern 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 description clearly states the tool builds a Conditional Branch block with specific command codes (111, 411, 412) and lists supported condition types. This distinguishes it from sibling builders like build_show_text or build_control_switch by naming the exact resource and structure.

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 the output is for insertion via insert_event_commands, which is the intended usage context. It also tells users to provide branches as EventCommand[] from other builders, but it doesn't explicitly contrast with alternatives or state when not to use it. Still, the insertion target and branch construction guidance provide clear 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 provided, the description carries the full burden, and it discloses the key behavioral trait: 'Read-only: returns { command }.' It also explains the behavior of both scopes and the inclusive range semantics, adding context beyond the function name.

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 concise sentences, front-loaded with purpose. It specifies both modes, the range behavior, and the read-only return value without any wasted words 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?

Given 100% schema coverage and no output schema, the description sufficiently explains the tool's modes, the range behavior, and the return shape. It doesn't discuss error cases or prerequisites, but for a read-only builder of this complexity, the information is adequate.

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 meaning by explaining that scope 'switch' sets a switch or inclusive range (switchId..endId) and scope 'self_switch' sets A–D, which enriches the understanding beyond the per-parameter schema descriptions.

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

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

The description uses the specific verb 'Build' and clearly identifies both event command types (Control Switches 121 and Control Self Switch 123). It also ties the tool to 'insertion via insert_event_commands,' distinguishing it from other build_* tools and specifying its exact role.

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 clearly states the tool is for building event commands to be inserted via insert_event_commands, and explicitly differentiates the two scopes ('switch' vs 'self_switch'). It lacks explicit exclusions or alternative tool names, but the context is sufficient for an agent to understand when to use it.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It explicitly states 'Read-only: returns { command }', which reveals that the tool has no side effects and only returns a data structure. It also clarifies that the command is meant for insertion via insert_event_commands, implying it does not automatically apply changes. This goes beyond what the schema or annotations would provide.

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 primary purpose, and every piece of information contributes to understanding the tool's function. It avoids repetition of schema fields and wastes no words.

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

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

Given the tool's complexity (nested operand object, 5 parameters, no output schema), the description covers the core behavior, return shape, range semantics, and operand categories. It does not explain how to configure game_data parameters in detail, but that is partially handled by the schema and the 'see corescript' hint. Overall, it provides sufficient context for an agent to use the tool correctly in the majority of cases.

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 parameters are already documented. The description adds valuable semantics by explaining the inclusive variableId..endId range behavior, the supported operation types (set/add/sub/mul/div/mod), and the four operand sources (constant, variable, random, game_data). This exceeds the baseline and helps the agent map high-level intent to schema fields. Minor gap: game_data sub-parameters are not detailed in the description, but the schema references 'corescript'.

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 ('Build') with a concrete resource ('Control Variables (122) event command') and explicitly states its purpose ('for insertion via insert_event_commands'). This clearly distinguishes it from sibling builder tools like build_show_text or build_conditional_branch, which target different event command types.

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

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

The description provides clear context: this tool constructs a command for later insertion via insert_event_commands. It implies the tool should be used to prepare a command rather than directly modify the game. However, it does not explicitly mention when not to use it or name alternative tools for similar operations (e.g., build_control_switch for switches).

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 appropriately discloses 'Read-only' and the return shape '{ command }'. This communicates that the tool has no mutation side effects and gives a clear behavioral boundary, though it doesn't detail error cases or further 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 two sentences, front-loaded with purpose, and every element contributes: the four kinds, their IDs, the insertion relationship, and the read-only note. No filler 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?

Given the tool's moderate complexity and 100% schema coverage, the description provides sufficient context. It explains what is built, the available kinds, the insertion workflow, and the return shape, while relying on the schema for detailed parameter syntax.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by mapping numeric command IDs to each kind ('wait (230...'), clarifying that label/jump_to_label take a 'named jump target', and indicating 'N frames' for wait. This ties the parameters to actual usage beyond the schema's basic field descriptions.

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

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

The description clearly states the tool's verb ('Build'), resource ('flow-control event command'), and purpose ('for insertion via insert_event_commands'). It enumerates the four specific command kinds with numeric IDs, distinguishing it from sibling builders like build_show_text or build_conditional_branch.

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 explains that this tool builds commands for later insertion via insert_event_commands, providing clear context for when to use it. It doesn't explicitly list when not to use it, but the 'flow-control' scope plus the named sibling alternatives imply the differentiation.

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 disclosing behavior. It explicitly states 'Read-only: returns { command },' which tells the agent this tool has no side effects and produces a command object for further use. This adds key behavioral context beyond the tool name.

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, well-structured sentence with an em-dash clarifying the purpose, followed by a short note on return type. Every word adds value—no redundancy or irrelevant detail.

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 builder tool with 3 params, no output schema, and no annotations, the description covers the key aspects: what it builds, how it will be used, its read-only nature, and the returned shape. It could elaborate on the command structure, but the provided information is sufficient for selection and 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% and each parameter already has a semantic description (e.g., actorId: 'The actor whose name is entered'). The description adds no extra meaning beyond the schema, 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 states the tool's function: 'Build a Name Input Processing (303) event command for insertion via insert_event_commands — open the name-entry screen for an actor.' This identifies the specific verb (build), resource (Name Input Processing event command), and purpose, distinguishing it from other sibling builder 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 phrase 'for insertion via insert_event_commands' provides explicit context on how to use this tool: generate a command, then insert it. It does not list alternatives or exclusions, but the workflow is clearly implied. This counts as clear context without exclusions, meeting the '4' criterion.

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 of behavioral disclosure and does well: it states the tool is read-only, returns a { command } object, and explains both show and erase behavior. It could add more about error handling or validation, but for a builder utility this is sufficient.

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

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

The description is two sentences, front-loaded with the primary purpose, and uses a compact semicolon structure to convey show vs. erase behavior. No redundant words.

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

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

Given 11 parameters and no output schema, the description covers the key context: insertion via insert_event_commands, read-only nature, return shape, and mode differences. It relies on the schema for parameter details, which is appropriate, though it omits broader context like example usage or constraints beyond schema.

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

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

Schema coverage is 100%, so baseline is 3. The description adds a concise grouping of show-related parameters and clarifies that erase clears the slot, but it mostly restates per-parameter 'show:' hints already present in the schema.

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

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

The description clearly states that the tool builds Show Picture (231) or Erase Picture (235) event commands for insertion via insert_event_commands. It distinguishes from sibling build_* tools by specifying the exact command codes and listing the relevant parameters for show and erase.

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

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

The description provides clear usage context by stating the output is meant for insert_event_commands and that it is read-only. It does not explicitly name alternative tools or when not to use this tool, but the purpose is unambiguous enough to guide selection.

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

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

Since no annotations are provided, the description carries the full burden. It openly discloses a key behavior: warns (never blocks) when the name is not a known audio asset for that channel. It also states the return shape ({ command, warnings? }). This is valuable beyond the schema and covers important edge-case behavior, but it does not mention other potential behaviors like validation of numeric ranges or interaction with the project state.

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 core purpose, and every sentence earns its place. It includes essential behavioral details without padding, making it appropriately sized and well structured.

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

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

The tool has six parameters and no output schema, but the description compensates by stating the return format ({ command, warnings? }) and the insertion pathway. It also notes the asset-checking behavior. Given that the schema covers all parameter semantics, the description is nearly complete for an AI agent to select and invoke the tool correctly, though it could mention prerequisite project state or validation of numeric fields.

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 input schema provides 100% parameter coverage with descriptions for all six parameters, so the baseline is 3. The description adds some context about kind values (BGM/BGS/ME/SE) and name checking, but these are also implied in the schema. It does not materially enhance parameter understanding beyond schema fields.

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 builds a Play BGM/BGS/ME/SE event command for insertion via insert_event_commands. It specifies the resource (audio play command) and distinguishes it from sibling builder tools like build_show_text or build_conditional_branch by naming the exact command and insertion path.

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

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

The description provides clear context for when to use the tool: to build an audio play event command for later insertion. It mentions checking against list_assets, which implies a precondition, but does not explicitly state alternatives or when not to use it. This is clear context without exclusions, scoring a 4.

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 of behavioral disclosure. It states 'Read-only: returns { command }', explains wait semantics, and differentiates parameterless vs parameterized effects. It does not discuss validation or error behavior, but the read-only and return-shape disclosure is solid.

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 dense sentences, front-loaded with the core purpose, and every clause adds meaningful information—commands, parameters, wait behavior, and read-only status. No filler 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?

Covers all effect types, parameter relevance, wait behavior, and the return shape ({ command }). Minor ambiguity: 'wait holds the event until it finishes' could be misread as applying to all kinds, whereas the schema restricts it to tint/flash/shake. Overall, it is complete enough for a builder tool with rich schema.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds command codes and groups parameters by kind, but the schema already documents per-parameter applicability (e.g., tint/flash color arrays, shake power/speed). The added value is marginal, not enough to raise the 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?

Description uses a specific verb ('Build') and resource ('screen transition/effect event command'), enumerates the exact command kinds (fadeout/fadein/tint/flash/shake) with command codes, and explicitly mentions insertion via insert_event_commands, distinguishing it from other build_* 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 frames the tool as a builder for insert_event_commands and explains which parameters apply to which effect kind, giving strong contextual guidance. It does not explicitly state when not to use this tool or name alternatives, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden. It clearly states this is read-only and returns { commands }, and discloses the event structure (302 + one 605 row per extra good) and the effect of purchaseOnly. This is strong behavioral disclosure, though it could detail error handling or edge cases.

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: the first states purpose and output, the second explains pricing, the third covers purchaseOnly and read-only behavior. It is front-loaded and every sentence provides useful information 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?

Given the tool's complexity (nested goods array, multiple options), the description covers purpose, parameters, output shape, and the need to use insert_event_commands. It lacks an output schema but compensates by specifying the return value. It is complete enough for an agent to select and invoke correctly, though a bit more detail on exact command structure would elevate 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 100%, so baseline is 3. The description adds slight context by explaining that `price` overrides the database price and that purchaseOnly hides the sell tab, but this largely echoes the schema. It does not add substantial new meaning beyond what the schema already provides.

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 ('Build') and resource ('Shop Processing event-command sequence'), then clarifies it generates a 302 event plus one 605 row per good. This clearly distinguishes it from other build_* tools like build_battle_processing or build_show_text.

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 the output is 'for insertion via insert_event_commands', giving clear usage context. It also explains how each good is priced and what purchaseOnly does, but does not mention alternative tools or when not to use it, so it lacks explicit 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 provided, the description carries the full behavioral disclosure. It clearly states 'Read-only' and specifies the return shape '{ commands }'. It also warns about branch termination details, giving agents the structural knowledge needed to predict output.

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 sentences deliver the core purpose, structure, usage pointer, and return info. No filler; the information 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?

For an 8-param builder with full schema coverage and no output schema, the description covers the essential missing pieces: the block's internal structure, insertion workflow, and return value. It's sufficient for an agent to 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?

Schema description coverage is 100%, so the baseline is 3. The description adds cross-reference value by explaining the `branches` parameter can come from build_show_text and that each branch is an EventCommand[], reinforcing the relationship. This is a modest enhancement over 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 opens with a specific verb ('Build') and names a distinct resource ('Show Choices block'), then enumerates the exact command structure (102, 402, 403, 404), differentiating it from sibling builders like build_show_text and build_conditional_branch.

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 this block is 'for insertion via insert_event_commands' and suggests using build_show_text to create branch bodies, offering concrete workflow context. It doesn't list when-not scenarios, but the usage context is unambiguous within the tool family.

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 explicitly states that the tool is read-only and returns { commands, warnings? }, writes nothing, which is critical behavioral transparency given no annotations exist. It also discloses the non-wrapping behavior and character limits, including that long lines are warned but never blocked.

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 core purpose, and packs in usage, behavioral warnings, and return format without redundancy. 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 provides a complete picture for a relatively complex builder tool: purpose, output structure, key constraints, and read-only safety. The schema covers parameter details, and the description adds the operational context needed to use it correctly, especially the word-wrap limitation and the list_assets reference.

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 descriptions already cover all 7 parameters, so the baseline is 3. The description adds meaningful context: lines should be kept under ~55 chars (~38 with a face), faceName should come from list_assets('faces'), and the background/position/speaker parameters map to the mentioned features, enhancing beyond the schema.

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

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

The description clearly identifies the tool as building a Show Text event-command sequence, with a specific construction detail (101 setup + 401 lines) and a stated downstream use (insertion via insert_event_commands). This distinguishes it from sibling build_* tools like build_show_choices or build_conditional_branch.

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 that the output is intended for insertion via insert_event_commands, and it provides context for when to use this tool (creating Show Text commands). It mentions supported features (face, background, position, speaker) and a critical constraint (MZ word-wrap), but does not explicitly contrast with alternative tools, so it falls short of full explicit 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 provided, the description carries the transparency burden. It explicitly states 'Read-only: returns { command }', disclosing a key behavioral trait beyond the tool's name. It also explains runtime resolution of variable IDs for mapId/x/y when designation='variable'. This is valuable, though it could disclose more about error handling or validation behavior.

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

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

The description is only two sentences, front-loaded with the tool's primary purpose, and every clause adds information. It covers the main action, the insertion context, variable mode, and read-only behavior without waste.

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 builder tool with 7 parameters and no output schema, the description adequately explains the tool's function, read-only nature, and variable-resolution mode. It identifies the returned object as { command }. It does not elaborate on all parameter defaults or edge cases, but the schema covers parameter details, and the description provides sufficient high-level 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?

Schema description coverage is 100%, so the baseline is 3. The description adds a brief note that mapId/x/y are variable IDs resolved at runtime when designation is 'variable', which largely reiterates the schema. No additional parameter semantics are provided beyond what the schema already describes.

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

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

The description clearly states the tool's purpose with a specific verb ('Build') and resource ('Transfer Player (201) event command'), and it distinguishes itself from sibling build_* commands by specifying it moves the party to (x, y) on a map. It also mentions the intended downstream use ('insertion via insert_event_commands').

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

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

The description provides clear context for when to use the tool: it builds a specific event command for later insertion. It also explains the variable designation behavior, which affects how parameters are interpreted. However, it does not explicitly mention alternatives or when not to use this tool, 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?

With no annotations provided, the description carries the full burden. It discloses that the tool validates existence of the common event, is read-only, returns `{ command }`, and writes nothing. This clearly conveys the safety profile and return behavior.

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

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

The description is two concise sentences with no filler. The first sentence states the primary purpose, the second clarifies behavior and integration, making it 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 builder tool with two parameters and no output schema, the description covers purpose, usage, validation, side effects, and return format. There are no significant gaps that would leave an agent uncertain.

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 value by explaining that commonEventId must reference an existing event (validation) and that the result composes into a command array, which gives the parameter context beyond the schema's basic description.

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 explicitly states the tool builds a 'Common Event' event command (code 117), specifies the target resource, and notes it is for insertion via insert_event_commands. This clearly distinguishes it from other build_* siblings by naming the specific command type and its composition context.

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

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

It states the tool is used to generate a command for insertion into an event page, and that the return shape matches build_* tools for composing into thenBranch/commands arrays. While it does not explicitly name alternative tools or exclusions, the context is clear enough for an agent to know when to use it.

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

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

With no annotations provided, the description shoulders the full disclosure burden. It declares 'Read-only' and explains the layered evaluation order, output fields, and optional direction behavior, giving the agent a complete picture of side effects and return semantics.

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, front-loaded with the primary purpose, and each sentence adds necessary detail about procedure, output, and read-only nature. It is dense but not wasteful, though it could be slightly tighter around the return value list.

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

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

Given no output schema and no annotations, the description fully compensates by listing all return values (per-direction booleans, terrain tag, stacked tile ids, optional passable), explaining the algorithm, and stating read-only behavior. There are no factual gaps for selecting/invoking the 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?

Although the schema has 100% coverage with descriptions for all four parameters, the description adds meaningful context by explaining how x/y are used in the tile stack lookup, how the optional direction alters the return value, and what the mapId refers to ('Reads the map's tileset flags'). This exceeds the schema's minimal descriptions.

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

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

The description opens with a clear action ('Check whether a map cell can be walked onto') and specifies the exact scope (layered passage rule per direction). It distinguishes itself from tile-reading tools like get_tile_flags by detailing the algorithm and output.

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 clear context by explaining that this tool reproduces the engine's layered passage rule and reads tileset flags, implying it is the correct choice for movement/passability checks. However, it does not explicitly name alternatives or state when not to use it.

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

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

With no annotations, the description discloses several important behaviors: only `name` is required with default values for class, level, equips, and traits; it allocates and returns the next unused actor id; and it includes a detailed caveat about the Hit Rate trait causing missed physical actions. This goes beyond a simple one-liner.

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 the first establishing the core purpose and the second covering required fields, defaults, and return value. The final sentence is a dense but valuable caveat; no filler or repetition is present.

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 15 parameters and no output schema, the description provides a substantial amount of context: required field, defaults, return value, and a critical trait behavior warning. However, it omits details about several parameters (e.g., profile, faceName, characterIndex) and does not describe the response shape beyond the allocated id, leaving some gaps.

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

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

Schema coverage is low (7%), so the description compensates by stating which fields are optional and what defaults apply ('class 1, level 1-99, five empty equip slots, no traits'). It also clarifies the traits behavior with the Hit Rate note, but it does not explain individual parameter formats for many fields, leaving some semantics to inference from names.

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 clear verb-object pair ('Create a new actor in data/Actors.json'), specifying both the action and the target file. It distinguishes itself from sibling creation tools (create_chest, create_enemy) and update_actor by focusing on the creation of actors.

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 does not explicitly compare this tool to alternatives like update_actor, nor state when not to use it. Usage context is implied by the verb 'Create', but no exclusions or alternative references are provided.

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 of disclosure. It reveals important behaviors: omitted fields get defaults (Shield equip slot, no stat bonuses), param format, and that it allocates and returns the next unused armor id. These go beyond the schema but do not mention potential side effects like dryRun behavior or error conditions.

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

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

Three compact sentences, front-loaded with the main action and file target. No redundant wording; every sentence provides essential information (purpose, defaults, param semantics, id allocation).

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 10 parameters and no output schema, the description gives sufficient context for correct use: it explains defaults, key parameter semantics, and the return value (next unused id). The schema covers the remaining parameter details, making this complete for a creation 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 100%, so baseline is 3. The description adds value by clarifying defaults for omitted fields and reinforcing the meaning of `params` and `etypeId` with the exact stat order and equip slot mapping. It goes beyond just restating the schema.

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

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

The description clearly states the tool creates a new armor in data/Armors.json, using a specific verb and resource. It distinguishes from siblings like update_armor and create_weapon by specifying the armor data file and the creation context.

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

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

Provides clear usage context: only `name` is required and omitted fields use editor defaults. This implicitly guides when to use the tool (creating a new armor) but does not explicitly contrast with update_armor or other alternatives, so it lacks explicit 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?

No annotations are present, so the description must carry the behavioral disclosure burden. It only states 'Create a buff skill (simplified)' and omits side effects, write behavior, validation, or the existence of a dryRun preview mode. This is a significant gap for a creation tool.

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 short sentence, which is commendable for brevity, but it leans toward under-specification. 'Simplified' hints at a reduced feature set without explaining what is omitted, making the sentence less informative than it could be while staying 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?

With 7 parameters, no annotations, and no output schema, a one-line description is insufficient. The agent learns the core purpose but lacks context about return values, side effects, and how this simplified version relates to the full create_skill tool. More behavioral and usage context is needed.

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%, with every parameter (including buffType, scope, and dryRun) having a concise description in the input schema. The description text adds no additional parameter semantics, 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?

Description specifies 'Create a buff skill' with a clear verb and resource, distinguishing it from sibling skill creators like create_damage_skill, create_healing_skill, and create_state_skill. The 'simplified' qualifier adds differentiation but is vague about what simplification entails.

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 is provided on when to use this tool versus alternatives such as create_skill or other skill-type creators. There is no mention of prerequisites, suitability, or exclusions, leaving the agent without decision support.

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 behavior: it details the event page structure (action-button, priority-same, optional text, gives contents, flips self switch), the opened page behavior, and error handling (throws on invalid id, warns but never blocks on unknown characterName or no graphic). It even explains the RTP sprite direction defaults. This is exemplary transparency.

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

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

The description is four sentences long, front-loaded with the core purpose, and every sentence provides substantive detail. It is dense but well-structured, covering purpose, mechanism, parameter semantics, and error behavior without redundancy or 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?

For a tool with 15 parameters, no output schema, and no annotations, the description is remarkably complete. It explains the event structure, the payout kinds, the default directions, and the error behavior. It leaves little ambiguity about what the tool will do, making it adequate for an agent to 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?

The input schema already covers all 15 parameters with descriptions (100% coverage), so the baseline is 3. The description adds extra meaning beyond the schema by explaining the relationship between `kind` and `id`, the direction row defaults for `closedDirection`/`openedDirection` on the !Chest sheet, and the two-page idiom. This is a meaningful addition, so a 4 is warranted.

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

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

The description clearly states the tool's function: 'Create a complete, placed treasure chest on a map in one call'. It identifies the specific resource (treasure chest), the action (create/place), and the key implementation detail (two-page self-switch idiom) that distinguishes it from generic event-creation tools like create_map_event or create_npc.

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 this tool by emphasizing the 'two-page self-switch idiom done correctly' and 'so the chest can never be looted twice', implying it should be used instead of manually constructing the event pages. It also gives context for the `kind` parameter. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of a perfect score.

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 transparency burden and excels: it discloses defaults (EXP curve, no traits/learnings), the allocation behavior, dryRun preview, and two serious behavioral pitfalls (missing Hit Rate trait causes misses; missing Add Skill Type trait hides skill commands). This goes well beyond basic expectations.

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 but every sentence earns its place: purpose/defaults, then two crucial warnings. It is front-loaded with the core action and free of fluff, making it appropriately sized for 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?

The description covers purpose, defaults, side effects, and pitfalls, which is comprehensive for a create tool with no output schema. However, it only partially specifies the return value (says it returns the next unused id but doesn't clarify whether the full created class object is also returned), leaving a minor gap.

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

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

Although schema coverage is 100%, the description adds significant meaning: it explains the default EXP curve values, the default maxLevel of 99, and the specific trait codes required for combat readiness (code 22) and skill-type visibility (code 41). This goes beyond the schema descriptions and materially helps 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 clearly states the tool's function: 'Create a new character class in data/Classes.json.' It uses a specific verb and resource, and the mention of allocating a new id distinguishes it from sibling tools like update_class or add_class_learning.

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

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

The description provides clear context on how to use the tool (only name required, defaults for omitted fields) and important caveats about traits for combat-readiness. However, it does not explicitly name alternative tools or state when not to use it, though the creation purpose is evident from the description and sibling names.

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 burden. It discloses the file destination, default field values, allocation of the next unused id, and the refusal-to-write behavior for invalid command lists with force override. This is substantial, though it could mention potential side effects or prerequisites like a loaded project.

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, front-loaded with the core purpose, and every sentence adds meaningful information (defaults, id allocation, validation/force). 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?

For a tool with 7 parameters and no output schema, the description plus schema cover creation, defaults, validation, force, and return id. It lacks explicit mention of project dependency or duplicate-name behavior, but these are minor gaps given the overall richness.

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 baseline is 3. The description adds value by explaining defaults for omitted fields (empty command list, trigger 0, switchId 1) and the force override behavior, which are not fully captured in the schema. This elevates it above baseline.

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

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

The description clearly states the tool's function: 'Create a new common event (reusable event-command list) in data/CommonEvents.json.' It uses a specific verb ('Create') and resource ('common event'), and distinguishes itself from sibling tools like update_common_event and call_common_event by focusing on new creation.

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

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

Provides clear usage context: only `name` is required, omitted fields use defaults, and `force: true` overrides validation. However, it does not explicitly mention when to use this instead of update_common_event or other alternatives, so it stops short of full when/when-not guidance.

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

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

With no annotations provided, the description must disclose behavioral characteristics but only says 'Create a damage-dealing skill (simplified)'. It does not mention whether this writes to disk, requires permissions, or how it differs from other skill-creation tools. The inclusion of 'simplified' is a hint but not an explanation of side effects or 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 a single, concise sentence with no redundant words. However, it is under-specified, making it efficient but not fully informative. It earns a 4 because it is 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?

For a tool with 7 parameters, no output schema, and no annotations, the description is too sparse. It lacks any mention of return values, side effects, or the relationship to other skill creation tools. The schema covers parameter meanings, but the tool-level context is insufficient for an agent to fully understand when and how to use 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?

The input schema already provides descriptions for all 7 parameters (100% coverage), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already documents, and it does not mention that 'dryRun' allows previewing changes, which is only in the schema.

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

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

The description clearly states the tool's function with a specific verb ('Create') and resource ('damage-dealing skill'). The word 'simplified' hints at a specialized variant, distinguishing it from sibling tools like create_skill or create_healing_skill, though it doesn't name them explicitly.

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

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

No guidance is provided on when to use this tool versus alternatives such as create_skill or create_healing_skill. The description neither mentions prerequisites nor offers exclusions, leaving the agent to infer usage from the tool name alone.

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 fully carries the transparency burden. It discloses the default values (100 HP, one Attack action, no drops), id allocation, return shape '{ enemy, warnings? }', warn-by-default for battlerName, throw conditions for invalid references, and the critical Hit Rate trait pitfall—far exceeding typical transparency.

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

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

The description is concise at five sentences and front-loaded with the core action and file target. Every sentence adds necessary information—defaults, id allocation, return shape, validation, and a critical combat pitfall—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?

Despite having no output schema or annotations, the description covers the tool's purpose, defaults, id assignment, return value, warning behavior, validation errors, and a common usage mistake. For a mutation tool with 11 parameters and reference-checking complexity, this is highly 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 100%, but the description adds significant value beyond schema descriptions: it clarifies that omitted fields use editor defaults, explains validation failure for nested references, and flags the battlerName warning and Hit Rate trait issue. This supplements the schema's per-property descriptions with behavioral guidance.

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 'Create a new enemy in data/Enemies.json' uses a specific verb and resource, clearly stating the tool's purpose. It also distinguishes itself from sibling tools like update_enemy and search_enemies by emphasizing creation and file location.

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 that only 'name' is required and defines defaults for omitted fields, giving clear entry conditions. It does not explicitly name update_enemy as the alternative for modifying existing enemies, but the 'Create a new enemy' phrasing and id-allocation behavior make the intended use unambiguous.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention that the tool writes to disk, creates a skill in the project, or what 'simplified' means. The dryRun parameter hints at write behavior, but the description itself adds no transparency.

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

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

The description is a single concise sentence with no wasted words. It earns its place by indicating the tool's purpose, though it could be more informative without becoming bloated.

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 create tool with no output schema and many sibling creation tools, the description is too minimal. It does not explain the tool's role in the project, the meaning of 'simplified', or how it relates to create_skill. The schema provides some context, but the description alone is insufficient.

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

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

The schema has 100% parameter description coverage, so the baseline is 3. The description adds no extra semantic meaning beyond what the schema already provides, such as examples or relationships between 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 'Create a healing skill (simplified)' clearly states the verb and resource, and 'healing' distinguishes it from sibling tools like create_damage_skill or create_buff_skill. However, 'simplified' is vague and does not clarify what simplification entails.

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 no guidance on when to use this tool versus alternatives such as create_skill or create_damage_skill. No context, exclusions, or prerequisites are mentioned.

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 burden and excels. It discloses ID allocation ('Allocates and returns the next unused item id'), default behavior for omitted fields, and specific error conditions for effect references. This is valuable operational context 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 compact and front-loaded, with every sentence delivering useful information: purpose, default behavior, ID allocation, and error cases. No redundant phrasing.

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 17-parameter schema with full per-parameter descriptions and no output schema, the description covers what's missing: usage simplicity, return value, and failure modes. It is complete enough for an agent to correctly invoke the tool.

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

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

Schema coverage is 100%, giving the baseline of 3. The description adds meaningful guidance by advising that only `name` is worth passing and explaining that omission yields Regular Item, consumable, no effects. This clearly adds value beyond the schema's per-parameter descriptions.

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

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

The description clearly states the tool's function: 'Create a new item in data/Items.json.' This is a specific verb+resource, and the file path adds precision. It naturally distinguishes itself from siblings like update_item or search_items.

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

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

The description provides clear guidance: 'Only `name` is worth passing; omitted fields use the editor's new-item defaults.' This tells the agent which parameters are important and what to expect if omitted, though it doesn't explicitly contrast with update_item or mention when to use an alternative.

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

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

With no annotations, the description shoulders the transparency burden. It discloses side effects: writes a new file, registers in the map tree, allocates the next unused ID, and returns it. It also notes tiles are unpainted. This is clear about the persistent mutation and return value.

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

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

Three concise sentences: action and side effects, return value, and follow-up guidance. Every sentence earns its place with no redundancy or 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?

For a creation tool with 6 parameters, no output schema, and no annotations, the description covers the essential context: what is created, where it's stored, what is returned, and what to do next. It doesn't explain defaults or all parameter relationships, but the schema handles those details.

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 baseline of 3 applies. The description does not add parameter-specific semantics, but it does provide context (e.g., blank map implies no initial tiles, ID allocation). This is acceptable given the schema's thoroughness.

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

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

The description clearly states the tool's purpose: 'Create a new blank map' with specific resources (data/MapNNN.json, MapInfos.json). It distinguishes itself from sibling map tools like update_map, delete_map, and resize_map by specifying creation and registration behavior.

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

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

Provides explicit follow-up workflow: 'Paint tiles afterward with paint_tiles/fill_area' and 'add events with create_map_event/create_npc.' This implies the tool is for initial map creation and guides subsequent steps. It lacks explicit 'when not to use' statements, but the context is strong.

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

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

With no annotations, the description carries the full burden and excels. It exposes default page values, deep-merge behavior, empty-list handling, validation refusals, and the facing-trigger pitfall, all of which are critical behavioral specifics 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?

Every sentence contributes unique operational detail; the text is front-loaded with purpose, uses an inline example, and ends with a structured field list. For a tool with 8 parameters and complex merge semantics, the length is justified and there is no waste.

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 supplies complete context. It covers defaults, enums, merge rules, validation behavior, page attributes, and sibling-tool alignment, enabling an agent to invoke the tool correctly without external documentation.

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 input schema only gives generic descriptions like 'Event pages', but the description adds concrete field formats including image parameters, trigger/priorityType/moveType enums, conditions, and list termination. This goes far beyond the schema and is essential 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?

Description opens with 'Create a new event on a map' and immediately defines the tool's scope via the merge model. It also distinguishes from the sibling create_npc by explicitly recommending that tool for talking NPCs, so the 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?

Provides direct when-to-use guidance: 'For the common "talking NPC" case prefer create_npc' and explains when priorityType:1 is required for action-button pages. It also covers validation refusal and the force override, so the agent knows the failure modes and how to handle 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 states 'Read-only' and the return shape '{ moveRoute, warnings? }'. It does not elaborate on limits or error cases, but for a read-only builder this is adequate and exceeds the baseline.

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 purpose and key characteristics, then immediately provides usage context. Every sentence earns its place with no 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?

Despite having 7 parameters and no output schema, the description explains the tool's role, output shape, and two integration methods. Combined with thorough schema coverage, this provides a complete context for an agent to select and 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% with detailed per-parameter descriptions, so the baseline is 3. The description does not add extra parameter-level meaning beyond the schema, but it does reinforce the 'pattern' parameter and the overall approach, which is acceptable.

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 'builds a movement route from a named pattern', specifying the verb (build), resource (movement route), and scope (from pattern vs raw codes). It also distinguishes itself from raw move-command codes and references sibling tools, making its purpose 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 clear guidance on how and where to use the output (as an autonomous moveRoute in update_map_event or fed to set_movement_route). It says 'instead of raw move-command codes', implicitly showing when to prefer this tool, though it does not explicitly mention exclusions or alternative build tools.

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

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

No annotations provided, so the description carries the burden. It discloses that unknown characterName or missing graphic only warns, never blocks; that an NPC without characterName is invisible in-game; and that commands wins over text. This is substantial behavioral context, though it does not mention return values or side effects on success.

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

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

Four sentences, front-loaded with the core purpose, each sentence adds distinct information (modes, defaults, warnings, alternative). No 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?

For an 18-parameter tool with no annotations and no output schema, the description covers purpose, modes, defaults, edge cases (invisible NPC), and alternative tools. It lacks only an explicit description of return value or success/failure response, but overall is quite 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?

All 18 parameters have schema descriptions (100% coverage), so baseline is 3. The description adds value by explaining the relationship between `text` and `commands` (commands wins), how `text` is built into Show Text with optional face/speaker, and defaults for trigger, priority, direction. This exceeds baseline.

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

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

The description uses a specific verb+resource ('Create a complete, placed NPC event on a map in one call') and clearly distinguishes from sibling create_map_event by noting the invisibility issue and explicitly referencing it for intentionally-invisible triggers. The 'one-shot' primitive characterization further clarifies its scope.

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 versus create_map_event ('use create_map_event for an intentionally-invisible trigger'), and explains the precedence of `commands` over `text` when both are given, plus defaults like action-button trigger and solid priority. This is clear guidance.

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

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

With no annotations provided, the description fully carries the burden of disclosure. It details read-only behavior, return shape { command, warnings? }, validation against actual plugin annotations, warn-by-default policy (never blocks), and args normalization to string-valued shape. 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?

The description is two sentences, front-loading the core purpose in the first sentence and packing validation, normalization, return shape, and side-effect-free behavior into the second. Every sentence earns its place; there is zero waste.

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 5 parameters, nested objects, and no output schema, the description covers all critical aspects: what it builds, how it validates, warning behavior, return value, and that it writes nothing. This is complete for an agent to select and 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 already documents all 5 parameters with 100% coverage, so baseline is 3. The description adds meaning by explaining that args are normalized to the editor's string-valued shape and that validation may produce warnings for unknown or disabled plugins, which affects how parameters are interpreted.

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 'Build an RPG Maker MZ plugin command (event command code 357)' for insertion via add_event_command, providing a specific verb and resource. It distinguishes itself from siblings by focusing on creation/building, not listing or inserting, making its role 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 clear context: the tool is used to build a plugin command for later insertion via add_event_command. It doesn't explicitly mention alternatives or when-not-to-use, but the sibling list and the phrase 'via add_event_command' imply the workflow clearly enough.

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 transparency burden. It discloses error behavior for missing record references (codes 21/22, 43, 44), which is useful, but it does not mention that the tool writes to disk, requires a loaded project, or what side effects creation entails.

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 with no filler. The first sentence defines the action; the second provides a compact, highly specific error mapping. Every part 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?

Given 12 parameters and no output schema, the description is modest. It adds error-handling context but does not explain return values (e.g., new skill ID), prerequisites, or typical usage flows. The rich schema compensates for parameter detail, but broader context 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 input schema has 100% description coverage for all 12 parameters. The description adds no additional meaning to the parameters; it only refers to effects indirectly via the error message. Schema descriptions already handle 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 states 'Create a new skill with custom properties' with a specific verb and resource. The phrase 'custom properties' distinguishes this generic creator from specialized siblings like create_healing_skill and create_damage_skill.

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 is the general-purpose skill creation tool, but it does not explicitly name alternatives or state when to use this over specialized creators. No exclusions or comparative guidance is provided.

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 performs excellently. It discloses that omitted fields use editor defaults, specifies those defaults (no restriction, priority 50, no auto-removal, 1-turn duration), and states that it allocates and returns the next unused state id. This is highly transparent about behavior and 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 three brief sentences, each with a distinct purpose: what the tool does, default behavior, and return value. No redundancy or filler.

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

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

Despite the tool's complexity (24 parameters, no output schema), the description covers essential contextual aspects: creation target, required fields, defaults, and return ID. This is sufficient for an agent to use 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?

All 24 parameters have schema descriptions, giving 100% coverage. The description adds value by explaining the defaults for omitted fields, which the schema does not convey, thus supplementing the schema meaningfully.

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 creates a new state (status condition) in data/States.json, with a specific verb and resource. However, it does not explicitly contrast with sibling tools like update_state, so it does not fully distinguish from alternatives.

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 explains that only name is required and omitted fields use editor defaults, providing clear usage context. It does not mention when to use this versus update_state or other alternatives, but the creation purpose is straightforward and no exclusions are stated.

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, so description carries burden. It discloses a key failure mode (throws on nonexistent stateId) and the dependency on States.json. However, it doesn't mention whether dryRun skips validation, what the return value is, or how new skills are allocated, leaving gaps in behavioral expectations.

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; first defines the tool's purpose with examples, second conveys critical dependency and error condition. No wasted words, 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?

For a 7-parameter create tool with no annotations and no output schema, description is relatively complete. It clearly states purpose, primary failure mode, and prerequisites. It omits return value details and any notes on parameter interactions beyond stateId, but schema covers parameter descriptions. Given CRUD sibling family, this is adequate.

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?

Input schema has 100% coverage for parameter descriptions, giving baseline 3. Description adds semantic constraint that stateId must refer to an existing state and throws otherwise, which is not in the schema. This enhances understanding of the stateId parameter beyond its type/range.

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 uses specific verb 'Create' targeting 'state-inflicting skill' with examples (poison, sleep), distinguishing it from sibling create_skill, create_damage_skill, create_healing_skill, create_buff_skill. It clearly identifies the resource and 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?

States prerequisite: throws if stateId does not exist in States.json, and explicitly directs to create_state first. This provides when-to-use context and points to an alternative/related tool. However, it doesn't explicitly contrast with other skill creation tools, leaving some ambiguity for which skill type to choose.

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 fully carries the burden of behavioral disclosure and does so excellently. It discloses that the tool 'Throws if the destination map does not exist; warns if the destination tile is outside that map, if the characterName is unknown, or if the event can never fire'. It also explains the behavioral difference between idioms (priority same vs below, visible vs invisible), the effect of 'force' and 'dryRun', and default behaviors for direction and fade. This is rich, honest context.

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 well organized: it opens with the main purpose, then explains the two idioms in a structured way, and closes with behavioral caveats. Every sentence provides essential information, and the length is appropriate for the tool's complexity. No filler 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?

Given the high complexity (14 parameters, no output schema, no annotations), the description is remarkably complete. It covers what the tool creates, how to choose the idiom, default behaviors, and failure/warning modes. It also explains the safety mechanisms (force, dryRun). This is sufficient for an agent to select and invoke the tool 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 already covers all 14 parameters (100% coverage), so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining the practical consequences of 'idiom' choices, the meaning of 'direction' and 'fade', and the validation behavior associated with 'force'. It does not describe every parameter individually, but it significantly enriches the key behavioral ones, justifying a score above baseline.

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

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

The description clearly states the tool's function: 'Create a complete, placed map-transfer event in one call'. It distinguishes itself from generic event creation tools by emphasizing the one-call placement and the two idioms, and it specifically covers the map-transfer domain. The verb 'create' and resource 'map-transfer event' are precise and differentiate this from siblings like create_map_event or build_transfer_player.

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 guidance on when to use each idiom: 'action_button' for solid landmarks and 'player_touch' for interior exits and map-edge gaps. It also clarifies defaults and error/warning conditions, giving clear context. However, it does not name alternative tools or explicitly state when not to use this tool in favor of a sibling, so it falls short of full 'when/when-not/alternatives' coverage.

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 burden of disclosing behavioral traits. It does disclose defaults, write location, validation refusal, and the force override. It does not mention the dryRun or verbose return behaviors, though those are covered in the schema descriptions. This is strong but not exhaustive.

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 of dense, front-loaded information with no filler. Every clause contributes meaning: creation target, defaults, validation constraint, and override behavior. This is an exemplar of concise, well-structured documentation.

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 6-parameter create tool with no output schema, the description plus rich schema descriptions paint a complete picture. The description covers creation behavior, defaults, validation failure handling, and an override path. The schema even explains return summary via the `verbose` parameter. No significant gaps remain.

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 input schema has 100% coverage, so the baseline is 3. The description adds value beyond the schema by clarifying that `name` is required, stating default values for `members` and `pages`, and specifying the referential integrity constraint for `member.enemyId`. This goes beyond what the schema provides.

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 action ('Create') and the resource ('a new troop (enemy battle group) in data/Troops.json'). It distinguishes itself from sibling tools like create_enemy by explicitly identifying troops as enemy battle groups, and from update_troop by focusing on creation.

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 useful usage context: it notes that `name` is required, that `members` must reference existing enemies, and that a structurally invalid battle-event page will refuse the write unless `force: true` is passed. However, it does not explicitly mention when to prefer this over related tools like create_enemy or create_battalion, 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?

No annotations are provided, so the description carries the full burden. It discloses the write target (data/Weapons.json), default behavior for omitted fields, the stat bonus array order, and the id allocation behavior. This is meaningful context beyond the schema, though it doesn't mention the dryRun preview parameter.

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 at four sentences, each serving a purpose: main function, defaults, params format, and return behavior. No redundant text.

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 essential aspects: target file, required field, defaults, param structure, and return value. Given 10 parameters and no output schema, it provides sufficient context, though it omits mention of the dryRun parameter, which is documented in the schema.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining that `name` is the only required field, what defaults apply to omitted fields, and explicitly defining the `params` array order and length, exceeding the baseline.

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

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

Clearly states 'Create a new weapon in data/Weapons.json' with a specific verb and resource. The mention of allocating the next unused id distinguishes it from sibling tools like update_weapon and other creation 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 clarifies that only `name` is required and that omitted fields use editor defaults, providing clear context for when to invoke this tool. It doesn't explicitly name alternatives like update_weapon, but the creation context is self-evident.

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. It discloses key side effects: reparenting direct children to the parent (preventing subtree deletion) and not touching System.json. This goes beyond a simple 'delete' statement, though it omits irreversibility and permission requirements.

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 action, and every sentence adds value. It efficiently explains the deletion mechanics and the important exception about child reparenting without redundancy or 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 the tool has only two parameters and no output schema, the description covers the main behaviors well. However, it does not mention return values on success/failure or error conditions (e.g., what if mapId doesn't exist). For a destructive operation this is a minor gap, but overall it provides sufficient context for most usage.

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%, with both parameters (mapId, dryRun) clearly described. The tool description adds no extra parameter-specific meaning beyond the schema, so the baseline of 3 applies.

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