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?

No annotations are supplied, so the description carries the full burden and does: it discloses that an invalid page refuses the write with nothing saved, that force:true overrides, and that two specific problems are warnings that never block. It also reveals the ordering behavior (first page whose conditions hold runs) and the return shape.

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

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

Front-loaded with the core append action and scoped tightly to what an agent must know. It is dense — the second sentence packs ordering, validation, warnings and return shape into one clause chain — but every clause carries information, with little 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?

There is no output schema, and the description compensates by stating the return shape ({ troop, pageIndex, warnings? }) and by documenting the write/refuse/override paths. For a 6-parameter mutation tool with a nested page object, nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: position is semantically an insertion index that affects which page runs first, force bypasses structural refusal, and page is expected to come from build_troop_page. It does not explain dryRun or verbose beyond what the schema already says.

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

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

States a precise verb+resource ('Append one battle-event page ... to an existing troop') and immediately distinguishes itself from the sibling that produces the page ('e.g. the `page` from build_troop_page'). An agent can tell it apart from build_troop_page and insert_event_commands without opening any schema.

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

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

Names the alternative tools and the condition selecting each: build_troop_page to construct the page, add_troop_page to append it, insert_event_commands with target 'troop_page' to fill it further. It also explains the append-vs-position choice and why order matters when triggers overlap.

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 whole burden and does so richly: sequential id allocation enabling intra-batch references, default filling for omitted fields, exact return shape, warnings that never block, and an atomic all-or-nothing throw naming records[i]. This is far 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?

Front-loads the core purpose, then the alternative-routing, then return/error behavior. Slightly dense with the long sibling enumeration and parentheticals, but each clause conveys distinct information.

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

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

No output schema exists, so the description usefully specifies the return object and error contract. For a 3-param batch-mutation tool with no annotations, nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is already 100%, so baseline is 3, but the description adds real meaning: `records` entries take the create_* tool's fields with only `name` required for most types, and ids are allocated sequentially so earlier entries can be referenced later. The dryRun preview semantics are restated but consistent with 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?

Specific verb+resource ('Create many database records of one type in a single call') and explicitly positions itself as the batch sibling of the eight single create_* tools. An agent can distinguish it from any sibling without opening a schema.

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

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

Names the alternative ('Use this instead of N sequential create_* calls') and gives concrete triggering scenarios (authoring a cast, a loot table, a skill list). When-to-use is fully explicit.

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

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

No annotations are provided, so the description carries the full behavioral burden. It states read-only behavior and the return shape ({ command }), and explains the runtime effect of each command—e.g., enemy_appear reveals a hidden troop member, abort_battle forces the Battle Processing Escape branch. This is unusually thorough for a builder 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?

Front-loads the purpose and packs the three kinds into a single dense paragraph with parentheticals. It is efficient for the amount of information but the nested structure is less scannable than it could be.

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 command-builder with no output schema, the description supplies the return value, the intended event page context, and the semantics of every kind. Nothing an agent needs to select and invoke it correctly appears to be missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying that enemyIndex is a troop slot (not an enemy id) and by mapping the kind enum values to concrete command codes and effects.

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

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

States a specific verb ('Build') and resource ('an in-battle event command') and enumerates all three command kinds with their code numbers and semantics. This clearly distinguishes the tool from siblings like build_troop_page or 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?

Names related tools (build_troop_page / add_troop_page / insert_event_commands) and the target 'troop_page', and clarifies when each kind applies (summon/reinforcement, telegraph state, abort). It lacks explicit when-not-to-use guidance or a direct comparison to alternatives such as build_battle_processing.

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?

With no annotations provided, the description carries the full burden and does so well: it states "Read-only", "writes nothing", and gives the return shape { commands, warnings? }. It also discloses the non-blocking validation behavior (line overflow is "warned, never blocked"), which an agent needs to know before relying on warnings.

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?

It is front-loaded with purpose and every sentence carries actionable detail, but the wrap explanation is packed into one long clause-heavy passage that would read better as a distinct sub-point. Dense yet largely waste-free.

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-parameter event-command builder with no output schema, the description covers the essential gaps: the generated structure, insertion target, line-width constraints, wrap semantics, face source, and return/validation behavior. An agent has what it needs to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real value: it explains where face images come from (list_assets("faces")), clarifies the wrap modes and that escape codes like \C[n] don't count toward width, and ties the width constant to the line-length warning. That extra semantic context lifts 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 opens with a precise verb+resource ("Build a Show Text event-command sequence") and even specifies the internal structure it produces (101 setup + one 401 line per text line). Naming insert_event_commands as the consumer clearly distinguishes it from siblings like build_show_choices or add_event_command.

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

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

It establishes the workflow context — build here, then insert via insert_event_commands — and gives concrete usage rules (keep lines under ~55/~38 chars or pass wrap). However, it never explicitly contrasts when to choose this tool versus a sibling builder such as build_show_choices or build_flow_command, so it stops short of full alternative guidance.

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

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

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?

No annotations are provided, so the description carries the full burden and does so thoroughly: declares the tool read-only, specifies the return shape ({ page }), notes the end marker is appended, and explains timing semantics (turn 0 = battle start, page runs before actors act, turnEnd defers to after resolution). This is unusually rich behavioral disclosure for a builder 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?

Front-loads purpose and packs essential rules efficiently, with no obvious filler. The single dense paragraph, however, makes it harder to scan for specific guidance (span vs turnEnd vs landing) than a structured layout would; given the inherent complexity, it is acceptable but not optimal.

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

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

For a complex tool with nested trigger objects and no output schema, the description supplies everything an agent needs: trigger semantics, span timing rules, return shape, landing instructions, and command sourcing. No critical gap remains.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds meaningful cross-parameter context beyond the schema, especially for span ('moment' re-runs while condition holds – guard it with a switch) and the interaction between turn ranges and enemy action patterns. However, much of the per-key trigger explanation overlaps what the schema already states (e.g., enemyHpBelow 0-based troop slot), so it does not fully transcend redundancy.

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

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

States a specific verb (Build) and resource (troop battle-event page) and immediately distinguishes from the hand-built alternative. Names the landing tools (add_troop_page, create_troop/update_troop pages), so an agent can tell exactly where this fits among siblings.

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

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

Gives explicit when-to-use guidance: span selection rules (b > 0 requires 'turn' or a battle page fires once), turnEnd usage with a concrete telegraph example, and the routing to add_troop_page for landing the result. It also states that commands must come from build_* tools. This is near-complete operational 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 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, the description carries the full burden and does so well: omitted-field defaults (100 HP, one Attack action, no drops), next-free-id allocation, return shape `{ enemy, warnings? }`, warn-vs-block behavior for battlerName, throw conditions for dangling skillId/dataId references, and the Hit Rate trait gotcha.

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?

Dense but front-loaded: the core purpose and required-parameter note come first, then returns, then exception behavior, then the gameplay NOTE. Every sentence adds operational value, though the single long paragraph could be broken up for scanability.

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 11-parameter mutation tool with no output schema and no annotations, the description compensates fully by explaining defaults, id assignment, return shape, and failure modes. Nothing an agent needs to call it correctly appears missing.

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

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

Schema coverage is already 100% (baseline 3), but the description adds real semantic value beyond the schema: default values for omitted fields, the cross-reference validation semantics of actions[].skillId and dropItems[].dataId (item/weapon/armor by kind), and the imperative to pass a Hit Rate trait in `traits`.

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

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

States a specific verb (Create) and resource (new enemy) plus the exact target file data/Enemies.json. It clearly distinguishes itself from the sibling update_enemy and other create_* tools by describing creation semantics with id allocation.

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

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

Usage is implied through defaults, validation rules, and a practical NOTE, but the description never explicitly states when to choose this over alternatives (e.g., update_enemy, batch_create) or any when-not conditions. Guidance is present but not routing-oriented.

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 carries the full burden and does well: it discloses the write target, default field population, id allocation/return, and throws on effects that reference missing records with specific codes. It omits overwrite/duplicate-name behavior and any mention that dryRun avoids the write, leaving a few behavioral gaps.

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

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

Three tight sentences, front-loaded with the core action, then defaults, then error semantics. Every sentence earns its place and nothing is padded.

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, nested-object, annotation-free tool it covers the essentials: what it does, what to pass, defaults, return of the new id, and effect error modes. It leaves dryRun's preview semantics to the schema, which is acceptable but slightly under-explained given the complexity.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it tells the caller only name matters and that itypeId, consumable, and effects default to Regular Item / consumable / none. That maps directly to specific parameters beyond the schema text.

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

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

States a specific verb and resource plus the exact target file (data/Items.json), which is enough to tell it apart from create_weapon/create_armor. It never explicitly names those siblings as alternatives, so differentiation is inferential rather than stated.

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

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

Gives clear invocation context: 'Only name is worth passing' and that omitted fields fall back to editor defaults (Regular Item, consumable, no effects). It does not, however, say when to choose this over the other create_* database tools.

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

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

With no annotations, the description 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 does so thoroughly: it explains the blank-page merge model, that omitted `list` becomes code-0-terminated, that structurally invalid command lists are refused (nothing written) unless force:true, that the invisible-wall case is only warned, and that the upper-layer action-button idiom is exempt. This is exactly the validation/refusal/side-effect context an agent needs before writing.

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

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

Front-loaded with purpose, then construction rules, then usage routing, then a field legend — a sensible order. It is a single dense paragraph, however; the validation rules and the page-field legend would scan faster as separate short blocks, and a few clauses are packed tightly enough to slow reading.

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

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

For a complex creation tool with no annotations and no output schema, the description covers creation semantics, merge defaults, validation outcomes, override paths, the advised sibling, and the full page-field vocabulary. An agent has what it needs to both select and correctly invoke 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?

Top-level params are already fully documented in the schema, but the nested `pages` items are typed as `additionalProperties: {}` with no property descriptions — the description supplies that missing meaning, enumerating trigger, priorityType, moveType, direction, and image subfields with their numeric values, plus merge behavior for `image`/`conditions`. It adds real value beyond the schema, though it does not cover every top-level field.

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

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

Opens with a specific verb+resource ('Create a new event on a map') and immediately distinguishes itself from siblings by naming create_npc as the preferred tool for the talking-NPC case. An agent can tell this apart from update_map_event, set_event_page, and create_npc without opening any schema.

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

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

Explicit routing guidance ('For the common "talking NPC" case prefer create_npc'), concrete trigger scenarios ('an action-button page meant to fire from facing... needs priorityType: 1'), and a clear statement of when the tool refuses vs. warns vs. exempts. Alternatives and conditions are all named.

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?

With no annotations, the description carries the burden and does well: it discloses defaults (solid, action-button, facing down), that warnings never block, that an NPC with no characterName is invisible in-game, and the override precedence for commands. It doesn't cover permissions or return format, but for this domain that is minor.

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

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

Front-loads the core purpose before detailing the text/commands branch, and each sentence carries load (composite construction, override rule, defaults, warnings, alternative tool). It is dense but not padded, though a reader must parse several clauses packed into two long sentences.

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

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

For a 19-parameter mutation tool with no annotations and no output schema, the description covers the salient behavior (defaults, non-blocking warnings, invisibility pitfall, text/commands interplay). Remaining parameter detail is fully documented in the schema, so an agent has what it needs to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning beyond the schema: how `text` is compiled into a Show Text sequence, how `wrap: true` reflows into 4-line boxes, and that `commands` overrides `text`. These relationships are not derivable from the flat 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?

States a specific verb (create) and resource (a complete, placed NPC event on a map) plus the composite nature of the call (graphic + trigger + talk list). It also explicitly distinguishes itself from the sibling create_map_event, so an agent can tell them apart without opening a schema.

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

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

Names an alternative (create_map_event) and the condition selecting it (intentionally-invisible trigger), and explains the text-vs-commands choice with a tie-breaker ('commands wins if both given'). It stops short of enumerating when other event-creation siblings apply, but the common cross-roads are covered.

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 full burden and does real work: it spells out default values for omitted fields (stypeId 1, scope 1, occasion 1) and the exact derivation rule for hitType, plus the failure behavior when an effect references a missing record (codes 21/22/43/44). It does not disclose persistence/ID-allocation behavior or how dryRun interacts with the call, which keeps it from a 5.

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

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

Front-loaded with the core purpose, then the defaults and error semantics. It is dense and every clause carries information, though the hitType derivation sentence is long and hard to parse on first read.

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 22-parameter mutation tool with no annotations and no output schema, the description covers defaults and error cases well. It omits what the call returns (e.g., the created skill's id) and gives no information about dryRun outside the schema, leaving gaps for an agent that must reason about the write's outcome.

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, but the description adds meaning beyond the schema by specifying the exact default-derivation algorithm for hitType and the concrete fallback defaults for stypeId/scope/occasion, which the schema only states partially.

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

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

States a specific verb+resource: 'Create a new skill with custom properties.' An agent immediately knows this is the generic skill-creation entry point. However, it never distinguishes itself from the many specialized siblings (create_damage_skill, create_healing_skill, create_buff_skill, create_state_skill, update_skill), so sibling routing is left to inference.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of the alternative creator tools. The only contextual information is about field defaults and error conditions, not about selecting this tool over its siblings.

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

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

With no annotations, the description carries the full 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.