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

With no annotations, the description carries the full burden; it does disclose real behavior — commands are generated automatically, message boxes split every 4 lines, and content is inserted before the page's end. However it says nothing about whether it requires a changeset/begin_changeset, whether existing dialogue is preserved or overwritten, or what the call returns, which matters for a mutation tool with zero annotation coverage.

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

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

A single tight sentence with the resource and the auto-construction behavior front-loaded and zero filler. Every clause — mechanism, splitting rule, insertion point — carries information an agent needs.

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

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

For an 8-parameter mutation tool with no annotations and no output schema, the description covers the core action and the one non-obvious behavior (4-line splitting) but omits prerequisites, effects on existing commands, and return shape. Adequate to call it, not adequate to call it safely.

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

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

Schema coverage is 50%: the schema documents lines, faceName, position and background, while faceIndex, pageIndex, mapId and eventId are bare. The description only reinforces the 4-line splitting rule already stated in the schema and never explains face selection, position, background modes, or page selection, so it does not compensate for the coverage gap.

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

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

Names a specific verb+resource ('Add spoken dialogue to an event page') and immediately explains the mechanism (auto-builds Show Text 101 and text-line 401 commands). It also distinguishes itself from the lower-level sibling by noting the insertion behavior is 'like add_event_command', so an agent can place it relative to the raw command tool 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?

Usage is implied rather than stated: use this instead of hand-writing 101/401 commands. There is no explicit when-not guidance and no routing to alternatives such as build_dialogue_tree, add_event_command, or update_event, which all plausibly overlap. An agent can infer intent but must guess at boundaries.

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 full burden. It explains the insertion position (before terminator or at index) and handles multi-line constructs. However, it omits details on error handling, side effects, idempotency, or whether the operation is reversible.

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

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

The description is concise (3 sentences) and front-loaded with the core purpose. It could be slightly more structured, but every sentence adds value without unnecessary verbosity.

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 insertion logic, but the description lacks information about return values, error cases, or constraints. Without an output schema, the description should at least hint at what the operation returns or what happens on failure.

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 60%, missing descriptions for mapId and eventId. The description adds meaning for 'commands' (multi-line constructs) and 'index' (position), but does not compensate for the missing parameter descriptions or clarify the role of required parameters.

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

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

The description clearly states it inserts commands into an event page's command list, specifying the action 'insert' and the resource. It mentions avoiding resending the whole event, which hints at its targeted nature, but does not explicitly distinguish from sibling tools like update_event.

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 some context by noting 'without resending the whole event', implying use when only adding commands. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., update_event), and does not mention prerequisites or conditions.

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 exist, so the description carries the full disclosure burden. It usefully reveals the file-existence failure mode, but says nothing about whether registration is idempotent, whether it overwrites an existing entry with the same name, or what permissions/state effects registering has.

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 tight sentences, zero filler, with the core action front-loaded and the routing hint following immediately.

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

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

With no annotations, no output schema, and three undocumented parameters including a nested object, the description leaves too much for the agent to guess about what registering does with status and parameters. It is complete on purpose and error behavior but not on configuration or result.

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

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

Schema description coverage is 0% across 4 parameters, and the description only implicitly explains 'name' via the file path. 'status', 'description', and especially the nested 'parameters' object (string-valued additionalProperties) are entirely opaque, which a low-coverage schema requires the description to compensate for.

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 ('Register an existing js/plugins/<name>.js file in the plugin list'), including the exact file-path shape the name parameter refers to. It explicitly contrasts with create_plugin, so an agent can distinguish the two without opening either 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?

Gives a clear precondition ('Fails if the file does not exist') and names the correct alternative for that case ('use create_plugin to make a new one'). It does not address where configure_plugin or remove_plugin fit in the lifecycle, so routing is clear for the main fork but not exhaustive.

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 exceptionally: it spells out the over-approximation model (switches only turn on, items never lost, branches ignored), enumerates exactly what it cannot see (355/356, variable transfers, battles, plugins), and explains how each gap degrades confidence. This is exactly the behavioral context an agent needs.

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

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

It is dense and long, but front-loads the core question, then the model, then limitations, then outputs — a logical flow where nearly every sentence adds information. Slightly verbose in the limitations enumeration, but no sentence is pure 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?

There is no output schema, yet the description fully enumerates the return surface (reachableMaps, unreachableMaps, deadEndMaps, deadPages with first unmet condition, switch/variable usage, edges, notes, summary, names) plus truncation caveats and staged-changeset behavior. Nothing an agent needs to interpret results 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; the description goes further by explaining that goal (one of switch/mapId/event) yields a verdict with up to 10 blockedBy reasons, that includeGraph emits a Mermaid flowchart, and crucially that limit truncates lists while summary counts stay exact and 'truncated' also flags analysis caps.

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

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

The opening sentence gives a precise verb and resource — a static reachability/dead-code proof over the whole project without running the game. It is immediately distinguishable from execution-oriented siblings like simulate_event, playtest_start, and validate_project.

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 frames the mode of use ('without running the game') and gives explicit trust rules: only rely on 'unreachable'/'dead' when confidence is 'high', and treat 'reachable' as merely 'not ruled out'. It doesn't name specific sibling alternatives (e.g. simulate_event) as the fallback, so it stops short of 5.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses scanned vs. notScanned scope, audio extension rules, caseMismatch implications across platforms, and 200-entry truncation behavior with omitted counts.

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

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

The description is front-loaded with the core check and then supplies dense but relevant detail about scanned categories and caveats. The exhaustive enumeration is lengthy but earns its place for a complex audit operation; structure could be slightly more 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?

No output schema exists, so the description must explain enough about return behavior, and it does: it names notScanned, caseMismatch, truncation, and omitted counts. For a one-parameter audit tool, this is complete enough for an agent to call and interpret 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. The description adds useful semantic context for includeUnused by explaining that unused results can include files referenced only by plugins or scripts, which helps interpret that parameter's output.

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

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

The description states a specific verb and resource: checks that every referenced image and audio file exists on disk, with an optional unused-file listing. It also enumerates scanned reference types, making the scope highly distinguishable from general asset-listing or reference-checking siblings.

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

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

The tool's intended use is clear from the purpose and the includeUnused option, and it warns that 'unused' may include plugin- or script-only assets. It does not explicitly name alternatives such as check_references or validate_project, so it lacks full when-to-use/when-not guidance, but the context is clear.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that all numbers are averages ignoring variance, crits, misses, states, items and elements beyond skill/trait specs, and that it emits warnings for unevaluable formulas, downward curves, one-hit-kill or immune enemies. That is precisely the behavioral context needed to trust or discount the 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?

The numbered enumeration of the four report sections is front-loaded and easy to scan, and nearly every clause adds information. It is a dense run-on paragraph in places (especially the long final sentence about averages), which costs it a point on 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?

There is no output schema, but the description effectively substitutes for one by describing the four result tables and the trailing warnings block. With five all-optional parameters and defaults stated, an agent has everything needed to call it correctly and interpret what comes back.

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 by mapping parameters to output sections and restating the key defaults (attackers default to the starting party, reference enemy defaults to median HP). It stops short of explaining how attackers' classId vs actorId interact, which the schema leaves largely implicit.

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 ('Measure the game's balance from its data') and then enumerates the four concrete report sections it produces (class curves, damage-by-level, attacker/enemy matrix, enemy threat). An agent can distinguish it from sibling analysis tools like analyze_progression or simulate_battle without reading the schema.

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

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

It explicitly names the alternative and the condition that selects it: 'use simulate_battle for a full fight', contrasted with this tool's averaged, no-variance/no-crit/no-miss approximation. Defaults for attackers, levels and reference enemy are also stated, so the agent knows when inputs can be omitted.

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 it discloses the key traits: edits are staged in memory, nothing hits disk until commit, commit is all-or-nothing, commit is reversible via undo, reads reflect staged state, and only one changeset may be open at a time. It also flags the hard environmental prerequisite that the RPG Maker editor must stay closed — exactly the kind of context an agent would otherwise get wrong. The description adds no contradicting claims.

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?

Purpose is front-loaded in the first clause, then the paragraph unfolds into staging semantics, lifecycle alternatives, and constraints in a logical order. Every sentence carries new, decision-relevant information — there is no filler or restatement of the title.

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

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

For a stateful transaction-start tool with no annotations and no output schema, the description covers what an agent needs: side effects, visibility of staged data, commit/discard/undo paths, concurrency limits, and prerequisite conditions. The only minor gap is that it does not describe what the tool returns on success, though with no output schema that is a small omission.

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 the single `label` parameter already has an example in the schema, so the description is not required to expand on it. The description never mentions `label` or how it is used, so it adds nothing beyond the schema — the baseline 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 first sentence, "Start a transactional batch of edits," names a specific verb and resource and immediately distinguishes this tool from the many edit siblings by framing it as a transaction boundary rather than an edit. The phrase "stages its result in memory" further pins down what "start" means operationally.

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 routes the agent through the whole lifecycle: commit_changeset to write, discard_changeset to drop, undo_changeset to roll back. It also states exclusions the agent could not otherwise infer — restore_backup is refused, set_project discards the changeset, and playtests see only committed edits.

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

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

With no annotations, the description carries the full behavioral burden and does it well: unknown keys rejected, nesting capped at 8 levels for choices/if/battle bodies, any invalid node fails the whole call and nothing is written, insertion positions inside branch markers or continuation lines are refused, and the return shape { commands, inserted?, problems, preview? } with preview only for dry runs or trees up to 40 commands. That is exactly the destructive/mutation context an agent needs.

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

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

Front-loaded with purpose and insertion semantics, then organized into three labeled node groups with worked examples, which is the right structure for this vocabulary. It is very long and does repeat some schema-enumerated bounds (1-6000, 0-255, etc.), which is wasted text, but the bulk of the length is load-bearing node semantics.

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, yet the description documents the return object and when `preview` appears. Given the enormous input schema and absence of annotations, the description supplies the missing pieces: failure atomicity, insert-position refusals, depth limits, and node vocabulary with examples. Nothing essential to calling it correctly is absent.

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 semantics the schema cannot: 60 frames = 1 second, defaults for volume/pitch/pan/frames/power, that a repeating move route never finishes so wait: true is rejected, that weapons/armors only change inventory not equipped gear, and that 'initialize' resets an added actor. These are real behavioral defaults, not restatements of ranges.

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 (compiles) and resource (nested tree of nodes → indented event commands), plus insertion scope. The opening line 'so you never hand-write indents, block terminators or move-route rows' plus the explicit comparison to add_event_command separates it from the sibling command-insertion tools.

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

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

Explicitly defines the two operating modes: with mapId + eventId commands are inserted at indent 0 (or at `index`) like add_event_command; without them or with dryRun nothing is written and output goes to `preview`. That is clear routing context, but it never states when an agent should prefer this over add_event_command or add_dialogue for a single-line case, so no true exclusions are given.

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 burden and does so well: it discloses the default dry run, the requirement to pass `dryRun=false` to write, the preview/diff behavior, and the atomic failure guarantee ('If any record fails, nothing is written'). These are critical operational details for a bulk mutation 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 dense but front-loaded: purpose, example, selection behavior, operations, and the dry-run warning all appear in a logical order. Every sentence contributes operational information without redundant restatement.

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 six-parameter mutation tool with no annotations and no output schema, the description covers selection, operations, dry-run safety, preview limits, and atomic failure. It does not describe the exact shape of the returned diff, but that is a minor gap given the otherwise rich behavioral coverage.

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

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

The description adds substantial meaning beyond the 67%-covered schema: it explains how `ids` and `where` combine, clarifies that all `where` conditions must match, gives field-path syntax examples, and defines each operation including rounding and min/max clamps. Although not every schema parameter is restated, the key ambiguities are resolved.

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

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

The description states a specific mutation verb and resource: 'Change one or more fields on many database records at once, with a diff.' It clearly distinguishes bulk mutation from single-record siblings and immediately provides a concrete example.

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 explains selection semantics precisely: records are selected by `ids` and/or `where` conditions, all conditions must match, and with neither every record is selected. It also emphasizes the dry-run workflow, but does not explicitly compare itself to sibling tools such as `update_record` or `search_records`.

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: it discloses what gets captured (all six layers, shadow bits, events), the includeEvents default, write/replace semantics gated on overwrite, and the changeset staging interaction with commit_changeset. The .gitignore advice adds operational context an agent would otherwise have to guess.

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 core operation, its destination, and the sibling reference are front-loaded, and nearly every clause carries information. The trailing .gitignore sentence is useful but is the one piece that could be trimmed without harming invocation correctness.

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 unannotated, no-output-schema, eight-parameter write tool this is complete: validation limits, name syntax, overwrite policy, changeset staging behavior, and destination path are all stated. 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?

At 38% schema coverage the description must compensate, and it does for the most consequential parameters: width/height bounds of 1-64, the in-map constraint, the name character rules and 1-64 length, overwrite replacement rule, and includeEvents default true. x, y and mapId get no explanation beyond their names, leaving a small residual gap.

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

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

States a specific verb and resource ('Save a rectangle of a map as a reusable stamp') plus the exact on-disk target path, and immediately contrasts with the sibling paste operation. An agent can distinguish capture_stamp from place_stamp and list_stamps 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?

Explicitly routes to place_stamp for pasting and adds a concrete condition ('same tileset'), and the overwrite/gitignore notes clarify follow-up behavior. It does not state when capturing is a poor choice (e.g. large regions, cross-tileset reuse), so it stops just short of full when/when-not coverage.

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

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

With no annotations, the description carries the full burden and does so substantively: it defines record existence (non-null row with matching id field, not array position), defines id 0 as 'none' and never reported, and states that unreadable database files go to notes rather than being reported as missing. It also discloses a major limitation class (script commands, plugin commands, notetags, damage formulas, variable-designated transfers) with counts. Minor deduction only because it doesn't characterize cost/performance on large projects.

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 correctly — the core finding and the inclusion list come first, return shape and caveats later — but it is a single dense ~250-word paragraph with a long command-ID enumeration (301, 302/605, 126-128, 318, 313, 129, 117, 201, 202) that is hard to scan. Little is strictly redundant, but the structure is a wall of text rather than sections.

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

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

Despite having no output schema, the description fully documents the return value ({summary, missing[{kind,id,count,locations,severity}], truncated, counts, notes}), the ordering (by kind then id), the 3-location cap, and the limit/truncated semantics. For a diagnostic tool with one optional parameter, nothing an agent needs to call or interpret it 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 the schema lacks: limit counts kind+id groups rather than individual references, and the overflow is exposed via 'truncated'. That disambiguates what a caller is actually capping.

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 ('Finds references that point at records which do not exist') and enumerates the exact reference kinds checked. It also explicitly positions itself against the sibling find_usages ('uses the same index as find_usages, so it checks exactly the references find_usages lists'), so an agent can differentiate the two 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?

Gives explicit when-to-use ('Run it before a release and after deleting or renaming records') and a concrete follow-up alternative ('use find_usages on one reported id to see every place'). It also routes a related concern to another sibling ('Switches and variables are not checked ... lint_events reports unnamed ones').

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 disclosure burden and does so thoroughly: validate-then-write atomicity, pre-image journaling location, automatic crash rollback on project open, a mutual-exclusion rule ('Other edits are refused while the commit runs'), and the locked failure state requiring undo_changeset. These are exactly the non-obvious traits an agent must know before invoking a write operation.

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?

Purpose and return value are front-loaded, then validation, then recovery semantics. The closing sentence about the RPG Maker editor needing to stay closed is relevant but slightly detached from the commit narrative; otherwise every clause carries operational meaning.

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

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

Even without an output schema, the description states what is returned ('per-file summary (created/modified, event/tile/record counts)'). Combined with the atomicity, backup and failure-state details, an agent has everything needed to call this safely and interpret the result.

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

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

The tool takes zero parameters, so parameter semantics carry no burden and the baseline is 4. The description adds no parameter discussion, which is appropriate since the schema is empty.

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 and resource: 'Write every file staged by the open changeset to disk as one unit and return a per-file summary'. The verb 'commit' plus 'staged by the open changeset' cleanly separates it from begin_changeset, discard_changeset and undo_changeset in the sibling list.

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

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

States the precondition ('the open changeset'), the lifecycle position ('Until this is called, nothing of the changeset is on disk and reads reflect the staged edits') and the rollback alternative (undo_changeset). It does not explicitly contrast committing versus discarding, but the sequencing context makes the choice 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 must disclose behavioral traits. It mentions merging parameters and the string nature of values, but does not clarify if existing parameters are replaced or merged, what responses look like, or any side effects (e.g., does it affect existing plugin functionality? Is the change persistent?). Core action is clear but lacks depth.

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?

Single sentence, no redundancy, front-loaded with actions and key constraints. Every word earns its place.

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

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

Given no output schema and a moderate number of parameters including nested objects, the description covers the basic functionality but omits usage context, error conditions, and return value behavior. It is adequate but not fully complete.

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

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

Schema descriptions already cover parameters adequately. The description adds value by explaining that parameter values are always strings (reinforcing the schema) and that the parameters object uses merge semantics. This clarifies behavior beyond the schema.

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

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

Description clearly states the tool enables/disables a plugin and merges parameter values. It uses specific verbs ('configure', 'enable', 'disable', 'merge') and identifies the resource ('registered plugin'). This distinguishes it from sibling tools like create_plugin or read_plugin.

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

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

No guidance on when to use this tool versus alternatives. Siblings like create_plugin, write_plugin, list_plugins exist, but the description does not provide conditions or exclusions to help an agent choose correctly.

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 mutation semantics (door events written on each map), pre-write validation of both maps, and a specific failure mode (door refused if another event occupies the tile, allowOverlap overrides). It doesn't state what is returned or whether a partial failure can leave one map modified.

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 core linking behavior is front-loaded and every sentence carries operational information. It is dense but not padded; a slightly tighter grouping of the door/spawn guidance would read better.

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, nested-object, mutating tool with no annotations and no output schema, coverage is strong on placement, direction, and failure handling. The gaps are the undocumented cosmetic parameters and the absence of any statement about 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?

At 50% schema coverage the description must compensate, and it adds real meaning for the key parameters: why a spawn tile is needed (doors in walls) and how twoWay/allowOverlap change behavior. It says nothing about `fade`, `sound`, or `doorName`, leaving `fade` undocumented in both places.

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 ('Link two maps with Transfer Player events in both directions in one call') and makes the distinguishing behavior — bidirectional door events created atomically — explicit. An agent can tell this apart from create_event/update_event 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?

Gives concrete when-to conditions: 'add spawn ... (always do this for doors drawn into walls)', 'Use twoWay=false for a one-way link', and trigger selection via touch vs action. It also routes the agent to verification siblings ('Check the result with render_map_image ... and list_map_connections').

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 usefully discloses the non-obvious default scope behavior and parameter-id mapping, but it does not explain persistence, validation, required project state, or other side effects expected of a create/mutation 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 front-loaded with the core action, followed by the necessary parameter-id legend and a key default-scope rule. Every sentence adds useful information and there is no filler.

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

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

The description covers the most domain-specific gaps, especially parameter ids and scope defaults, which is important given 12 parameters and 67% schema coverage. However, with no annotations and no output schema, it should do more to describe the create/mutation behavior and what the tool returns or persists.

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 moderate at 67%, and the description adds substantial meaning that the schema lacks by mapping parameter ids 0-7 to Max HP, Max MP, Attack, Defense, M.Attack, M.Defense, Agility, and Luck. It also explains the scope default rule, though it does not clarify unrelated parameters such as mpCost, tpCost, or note.

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 gives a specific verb and resource: creating a skill that applies parameter buffs and/or debuffs. This clearly distinguishes it from sibling skill-creation tools such as create_damage_skill, create_healing_skill, and create_state_skill, though it does not name those alternatives 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?

Usage is implied by the purpose: use this when creating a buff/debuff skill. The description also gives one important usage rule about default scope when only debuffs are present, but it does not state when to choose this over the sibling skill-creation tools or mention any prerequisites.

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

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

With no annotations, the description carries the full burden. It discloses that the tool creates a skill and returns the new skill id, but does not mention validation, error handling, required permissions, or side effects (e.g., is the skill immediately available?). Adequate but not comprehensive.

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 packed with essential information: creation scope, formula syntax, and return value. No unnecessary words. Front-loaded with the key action.

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 17 parameters and no output schema, the description covers creation and formula but omits details on error conditions, default values beyond schema, and exact return format (just 'new skill id'). Adequate for experienced users but incomplete for novices.

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

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

The description adds meaningful explanation for the formula parameter: 'The formula uses MV damage syntax where `a` is the user and `b` the target,' with examples. For other parameters (76% schema coverage), the description does not add much beyond schema descriptions, but the formula guidance is valuable.

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 'Create a complete damaging skill in one call,' specifying the verb (create), resource (damaging skill), and scope (in one call). It distinctively focuses on damage, differentiating from sibling tools like create_healing_skill and create_state_skill.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives like create_healing_skill or create_state_skill. The only contextual hint is the tool name and mention of 'damage,' but no when-not-to-use or alternative recommendations.

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

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

Without annotations, the description discloses key behaviors: the return of the new event id and the default empty page creation. This is adequate for a creation tool, though more detail on persistence or side effects could improve it.

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 extremely concise with two sentences, immediately stating the core action and the critical default behavior. No unnecessary 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?

Given no output schema and low schema coverage, the description covers the essential aspects: function, default page behavior, and return value. It is fairly complete for a simple creation tool, though it could elaborate on other parameters.

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 (17%), but the description adds meaningful context for the 'pages' parameter by explaining default behavior. Other parameters like x, y, name, note, and mapId remain unexplained, leaving gaps.

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

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

The description clearly states the verb 'Add' and the resource 'event to a map at (x, y)', making the tool's purpose unambiguous. It also naturally distinguishes from siblings like 'update_event' and '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?

The description provides explicit guidance on the page parameter behavior, helping the agent understand default behavior. However, it does not explicitly contrast with alternatives or state when not to use this tool.

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

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

No annotations are provided, so the description carries the full burden. It discloses that this is a write, refuses out-of-bounds tiles and stacking unless allowStack is true, explains that graphics default to none making events invisible, and details template-specific side effects (chest pages, locked_door transfers, inn charges). It also states 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?

The description is long but justified by 21 parameters and 6 templates. It is front-loaded with the core action and constraints, and every sentence adds information. Still, a dense paragraph could be more scannable as a 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 the complexity (21 params, nested objects, 6 templates) and no output schema, the description covers constraints, defaults, template behaviors, and return value thoroughly. Nothing critical for correct invocation 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 86% (high), so baseline is 3. The description adds value by summarizing template-dependent parameters and defaults (e.g., openImage defaults to closedImage facing up; shop goods 1-40; reward requires at least one). However, much of the template parameter listing duplicates schema descriptions, so it doesn't fully transcend 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?

States a specific verb ('Creates'), resource ('map event'), and scope ('at (x, y) from a template, in one write'). This clearly distinguishes it from generic siblings like create_event or update_event by emphasizing the template-based approach.

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 context: use for building standard events (chest, npc, etc.) in a single write. However, it never explicitly names alternatives (e.g., create_event) or states when not to use this tool, leaving that to inference.

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

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

No annotations provided, so description carries full burden. It discloses formula syntax and functionality but lacks details on side effects, validation, or error 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?

Two sentences, front-loaded with purpose, no unnecessary 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?

No output schema and minimal description for a tool with 14 parameters. Missing explanation of return value, error cases, and parameter interactions.

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?

Adds meaning for formula, recoverType, removeStates beyond schema. However, with 57% schema coverage and 14 parameters, many parameters (scope, costs, etc.) are not explained in description beyond schema defaults.

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

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

Description clearly states it creates a complete healing skill with MV damage syntax, healing HP/MP, and removing states. Distinguishes from siblings like create_damage_skill and create_state_skill.

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

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

Implied usage for healing skills but no explicit guidance on when to use vs 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 carries the burden and does well: it discloses that files are written, that MapInfos.json is mutated, that the map is empty by default unless fill is supplied, and that the new map id is returned. It does not mention validation behavior (duplicate names, bad tilesetId) or whether the change is undoable.

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 and effects, then the fill caveat, then the workflow and return value. No sentence is 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?

No output schema exists, yet the description still states what is returned (the new map id), and it covers side effects and the empty-by-default behavior. The main remaining gap is the create_map vs generate_map distinction and any failure modes.

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

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

Schema coverage is only 33%, so some compensation is needed; the description does explain `fill` semantics (a ground tile for layer 0) beyond the schema's own example. But width, height, tilesetId and parentId get no additional meaning from the description, leaving half the surface undocumented.

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

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

States a specific verb and resource ("Create a new map") and spells out the concrete effects: writing MapXXX.json and registering in MapInfos.json. It does not, however, distinguish itself from the sibling generate_map, which an agent could reasonably confuse with this tool.

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 an explicit follow-up workflow (paint_tiles to paint, get_tileset_info to choose tiles, event tools to add events), which is real routing guidance. It omits when to prefer create_map over generate_map or update_map, and any preconditions about the project state.

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 burden. It discloses creation location, registration, scaffold generation when no code, and failure if file exists. This is largely sufficient for a file creation tool, though return behavior is not mentioned.

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

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

Two sentences, front-loaded with core action and key behaviors. Every sentence adds value with no redundancy.

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

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

Given no output schema, the description lacks information about what the function returns (e.g., success status or plugin object). It covers the main behavior but omits return value and potential side effects like state changes.

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

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

Schema coverage is 50% with parameters 'status' and 'description' lacking descriptions in schema. The description does not add any information about these parameters, failing to compensate for the gap. It reiterates the scaffold behavior for 'code' already stated in 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 verb 'Create', the resource 'plugin file' with location 'js/plugins/', and the action 'register it'. It also distinguishes from siblings by noting 'Fails if the file already exists', implying this is for new files only.

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

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

The description implies usage for creating new plugins but does not explicitly state when to use alternatives like write_plugin or configure_plugin. The failure condition on existing files gives some guidance, but no when-not or alternative references.

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

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

No annotations are provided, so the description carries the full burden. It discloses that fields are copied from 'data', id is auto-assigned, and returns the new id. It also suggests using get_record as a template, adding useful behavioral context.

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

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

Two sentences, no waste. The purpose and usage pattern are front-loaded. Every sentence adds value.

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

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

Given the tool's complexity (2 params, no output schema), the description covers purpose, parameter behavior, return value (new id), and a recommended usage pattern. It is complete and self-contained.

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%, baseline 3. The description adds meaning beyond the schema: it explains that 'data' fields are copied, id is automatic, and 'type' specifies which database. This provides actionable guidance.

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

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

The description clearly states the action ('Append a new record to a database') and the resource, distinguishing it from siblings like update_record or list_records.

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 advises using get_record as a template, providing clear context, but does not explicitly state when not to use the tool or list alternatives beyond the implicit sibling 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?

No annotations provided; description only states the basic action without disclosing side effects, permissions, or other behavioral traits.

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, front-loaded with core purpose, no redundant 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?

With 12 parameters and no output schema or annotations, the description is too brief to cover tool complexity; key parameters like scope, occasion, icon are left unexplained.

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

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

Schema coverage at 58% is moderate; description adds context about state IDs from the States database, but otherwise does not significantly enhance understanding beyond 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?

Description clearly states the tool creates a skill that adds/removes states with success chances, distinguishing it from damage/healing skill 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?

Implies use when you need state effects, but no explicit when-to-use or when-not vs alternatives like create_damage_skill.

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

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

With no annotations, the description carries the full burden, and it does add real behavioral insight: the slot is nulled so other event ids stay stable, which explains the data-model consequence of deletion. However it never states that the operation is destructive/irreversible, whether it is transactional or undoable via undo_changeset, or what happens to references to the deleted event.

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

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

Two short sentences, zero padding, with the core action stated first and the behavioral caveat second. Nothing could be removed without losing information.

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

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

For a two-parameter destructive mutation tool with no annotations and no output schema, the description should say whether the deletion is reversible or requires a changeset, and it omits both. The null-slot detail partially compensates but leaves the safety profile underspecified.

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

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

Schema coverage is 0%, so the description must compensate for mapId and eventId, and it largely does not — it only hints at id-slot semantics via the null-slot note. It never clarifies whether eventId is a map-event id versus an event page index, which is the main ambiguity risk in this domain.

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?

"Delete an event from a map" is a specific verb plus resource, and the delete verb cleanly separates it from siblings like update_event, get_event, and create_event. An agent can identify the operation from the first four words.

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 usage is implied by the name, but the description never says when to prefer this over update_event, undo_changeset, or discard_changeset, nor whether a changeset must be open first. No exclusions or prerequisites are given.

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 that on-disk files are untouched, that reads revert to disk state, and that the RPG Maker editor must stay closed during edits. It stops short of stating what happens if no changeset is open or whether the dropped edits are unrecoverable.

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

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

Three short sentences, front-loaded with the action, then consequences, then the precondition. Every sentence adds distinct information with no waste.

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

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

Given a parameterless tool with no output schema, the description covers effect, side effects, and the editor-closed precondition. Only the failure mode (no open changeset) and the irreversibility of the discard are left unaddressed.

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

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

Zero parameters, so there is nothing to disambiguate; baseline applies. The description correctly implies no input is needed beyond there being an open changeset.

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 and resource: "Drop every edit staged by the open changeset" precisely names the action and its scope. It does not, however, distinguish itself from the sibling undo_changeset or commit_changeset, which an agent would need to choose among.

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?

Referring to "the open changeset" implies begin_changeset must have run first and that the editor must be closed, which is useful context. But it never says when to discard versus undo (undo_changeset) or commit, leaving the most consequential choice to inference.

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

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

With no annotations, the description does real work: it declares the tool is purely diagnostic, that it never blocks or undoes edits, and that a nonzero result usually means the editor saved over server files. Missing only details of the report's shape or how detection is confirmed.

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 tight sentences; the primary check is first, the file-divergence case second, and the read-only caveat last. 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?

With no output schema and no annotations, the description carries the burden, and it covers purpose plus read-only safety. It stops short of describing what the report contains (e.g., list of changed paths, running/not-running flag), which is the one thing an agent must guess.

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

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

The tool takes zero parameters, so the baseline of 4 applies; nothing in the description could add parameter meaning, and it correctly implies no arguments are needed.

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

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

States a specific check: whether the MV editor is running plus which server-written files have diverged, with the likely cause (editor saving over them) named. It is clearly distinguishable from playtest_status and the changeset/backup tools, though it does not name any sibling explicitly.

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

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

The purpose implies when it is useful (detecting external/editor edits to files the server wrote), and 'Report only: it never blocks or undoes any edit' steers agents away from expecting remediation. But there is no explicit 'use this before X' or 'use restore_backup instead if you want to revert', so timing and alternatives remain inferred.

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

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

No annotations exist, so the description carries the burden. 'Reference table' implies a safe read operation, but the description never states that it is read-only, what shape the reference data takes, how complete the code coverage is, or whether it is version-scoped. Adequate but thin for a tool with zero structured behavior metadata.

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, zero waste, with the identity of the resource front-loaded and the actionable instruction second. Exactly the right size for a zero-param lookup.

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

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

With no output schema and no annotations, the description is the only source of information about what the agent gets back. It says 'reference table' but not the return shape, coverage, or whether it includes examples, which leaves a real gap for a tool whose entire value is its output.

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

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

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. No misleading parameter hints are present.

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 resource ('RPG Maker MV event command codes and their parameters') and frames it as a reference/lookup table, which is clearly distinct from mutation siblings like add_event_command or update_event. It stops short of naming a specific sibling to contrast with, keeping it at a solid 4 rather than 5.

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

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

Explicitly says when to use it: 'Consult this before writing or editing event command lists,' which directly points the agent at the pre-write phase and implicitly steers away from the mutating siblings. No explicit exclusions or named alternatives are given, so 4 is right.

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 that the file is written inside the project, the default path, and crucially that existing translations are carried over by key so re-exporting never loses work. It omits whether a re-export overwrites unrelated edits to the file's other columns or clears empty translations, which would complete the mutation story.

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

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

One dense paragraph that front-loads the verb, output format, and default path before the detail. It is long, but nearly every clause carries actionable information (carry-over behavior, column list, import follow-up); only the event-text enumeration is slightly sprawling.

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 3-param, no-output-schema export tool, the description covers effects, defaults, idempotency, and the follow-up tool. The one gap is that it never describes what the call itself returns (row count, file path confirmation, warnings), which is the kind of detail the missing output schema would otherwise supply.

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 67%; the description adds meaning by tying format to the resulting extension (default localization/texts.csv, CSV or JSON), naming the categories that correspond to the scope array, and explaining that the translation column may be left empty. It does not explain how the scope enum values map one-to-one to the listed content categories, but the coverage and defaults make calling it straightforward.

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 (export) and resource (every translatable text of the project), then enumerates exactly which content categories are covered (database names/descriptions/messages, System terms, type names, game title, map display names, event text). This is clearly distinguishable from the sibling import_texts, which is named as a separate step.

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?

Explains the workflow explicitly: export, fill in the translation column (leave empty to keep the original), then use import_texts. It also points to the rpgmaker-localization skill for control-code and message-length rules. It does not state any when-not-to-use condition, but the sequencing against import_texts 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 whole burden and does so: it discloses that it reads staged changeset data, that counts are true totals while lists truncate at limit, exactly which warning classes are produced, and which constructs (355/356, variable-designated transfers/battles, notetags, plugin params, ids above 1000) are not understood and therefore weaken "never" warnings. This is precisely the caveat an agent needs to avoid over-trusting results.

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 and a use-before-mutating rule, then scoping, then location-string format, then limitations — a sensible order. The exhaustive command-code enumerations (111, 121/122, 126-128, 313/318, 301/302/605) are dense and somewhat redundant with the opening kind list, but each block adds real coverage 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?

There is no output schema, and the description compensates fully: it gives exact location string forms ('Map003 event 5 page 1 command index 12', 'System startMapId'), defines index/pagination conventions including 0-based command index vs 1-based pages, and describes the shape of counts, truncated and warnings.

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 goes beyond it by explaining that an id with no name or record yields an 'unknown id' rather than an error, and that each per-role list is cut at limit with omitted counts reported via truncated. It does not spell out the kind enum values beyond the opening enumeration, but the schema covers those.

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 and resource: lists every place one switch/variable/record is read, written or used, plus dead-end warnings. The enumerated kinds and the read/write/use taxonomy make it unmistakably distinct from siblings like check_references, search_records or lint_events.

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?

"Use it before renaming, deleting or reusing an id" gives a concrete trigger condition for calling it. It does not explicitly name competing alternatives (check_references, search_records) or state when not to use it, so it stops short of a full routing rule.

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 dry-run-by-default safety behavior, that it shows before/after per enemy, and that dryRun=false actually writes. Missing limits (max 10 curves / 200 enemies) and error behavior, but the core mutation behavior is 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?

Front-loaded with the purpose, followed by ordering rules, targetable params, and the write behavior. Four sentences with no filler, each carrying distinct needed information.

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

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

For a mutation tool with no annotations and no output schema, the description covers the safety default, output preview, and interpolation semantics. It omits collection limits and handling of unspecified params, so it is not fully complete but is solidly sufficient for correct invocation.

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

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

Schema coverage is only 33%, and the description compensates by explaining that enemyIds must be weakest-to-strongest, that the first enemy gets each curve's start and the last its end, that middle ones are interpolated, and that curves target stats plus exp/gold. This adds meaning beyond the schema's per-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?

States a specific verb+resource: spreading enemy stats along a curve for difficulty progression. Very clear what it does. However, it does not differentiate from the sibling generate_param_curve, which appears to be the closest alternative, so sibling differentiation is missing.

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 operational guidance (order enemies weakest-to-strongest, dry run by default) but gives no explicit when-to-use versus the analogous generate_param_curve sibling, nor any exclusions. Usage is implied rather than stated with clear boundaries.

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: it discloses that overwrite resets every tile layer and deletes all events, enumerates the four conditions under which nothing is written (a transactional guarantee), explains seed determinism and that the seed is always returned, and declares limits (decor is best-effort, wall faces are a one-row simplification).

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 (what it does first, then parameters, then workflow, then limits) and nearly every sentence carries unique information. It is nonetheless a dense block of prose with the size-requirement guidance and limits appended as run-on sentences, which hurts scannability.

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, yet the description tells the agent what the result contains (seed, profileUsed, profileNotes, and markers with eventId and position), so return values need no further documentation. For a 7-parameter nested-object generator 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?

It adds meaning well beyond the 71%-covered schema: the mutual exclusivity of mapId and create is not encoded in the schema but is stated explicitly, the seed's reproducibility contract is described, the markers default object is restated with the tile-occupancy consequence, and the profile default is fully explained via the suggestTileProfile resolution rules.

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 ('Procedurally generate a dungeon … or a cave') and even defines what each kind produces (rooms joined by corridors vs. one organic connected region). It doesn't explicitly contrast itself with siblings like create_map or paint_tiles, so an agent must infer that this is the generative path rather than the manual one, keeping it short of a 5.

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 exclusive mapId-vs-create choice, the overwrite precondition, the refusal conditions, and then prescribes the follow-up workflow (render_map_image to inspect, connect_maps for doors, create_event_from_template for chests, delete_event/allowOverlap for marker placement). Alternative selection and sequencing are spelled out rather than inferred.

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

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

With no annotations provided, the description carries the safety burden well: it discloses that classId causes a write, that only minLevel..maxLevel rows change while 'other levels are untouched', and that dryRun defaults to true. It stops short of stating reversibility or whether a changeset must be open (siblings begin_changeset/commit_changeset imply that may matter), leaving one real gap.

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

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

Four tight sentences, front-loaded with purpose, then the shape vocabulary, then the preview/write fork and the dry-run default. Every clause earns its place; nothing is repeated from the schema.

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

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

For a five-parameter mutation tool with no annotations and no output schema, the description covers the essential decision points: preview vs apply, level range scope, and the follow-up tool. The remaining omission is workflow integration (changeset/commit requirements for the write path), which would matter for an agent editing a live project.

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 only 20%, so the description has to compensate, and it does: start/end endpoint meaning, the classId write target, and dryRun semantics are all clarified, plus the shape names are explained in plain terms ('ease-in (slow start)', 'exponential (constant growth factor)') beyond the bare enum. It does not convey minLevel/maxLevel defaults or the 8-item cap on curves, but the core meaning is supplied.

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+resource ('Generate stat curves over levels') and immediately distinguishes the two operating modes: pure preview without classId vs. rewriting the class params table with it. Its curve-shape vocabulary and level-scoping language make it clearly separable from siblings like generate_enemy_scaling and balance_report.

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 names the exact condition that switches behavior ('Without classId ... With classId ...'), specifies the dry-run default and how to override it (dryRun=false), and hands off the natural follow-up ('Follow up with balance_report'). An agent has no ambiguity about when to call this or what comes next.

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

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

No annotations are provided, so the description carries the behavioral burden. It does disclose the return content ('full JSON ... including all pages and command lists'), which is useful, but says nothing about read-only safety, error behavior for missing ids, or whether the JSON can be large.

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

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

A single front-loaded sentence with no filler; the scope and payload contents come first and every clause carries information.

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

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

For a two-parameter read tool with no output schema, the description adequately conveys what comes back (full event JSON with pages and command lists). Minor gaps remain around failure behavior and payload size, but nothing essential to invoking 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 0%, but the two parameters (mapId, eventId) are self-describing by name and the schema supplies types and minimums. The description only implicitly conveys that both identifiers jointly select the record; it adds little beyond the schema.

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

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

States a specific verb and resource ('Get the full JSON of one event on a map') and scopes the payload to all pages and command lists, which tells an agent this is a full single-record retrieval. It does not explicitly distinguish itself from siblings like search_map_events or simulate_event, leaving that differentiation implicit.

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 'one event' framing implies usage when a single event id is known, but there is no explicit when-to-use vs when-not guidance and no named alternative for finding events you cannot identify by id (e.g., search_map_events).

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 behavioral burden well by disclosing that tile data is omitted by default and is large when included. It also makes the read-only nature clear through 'Read'. It does not cover error behavior for invalid map IDs or permission requirements.

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

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

The description is two efficient sentences, front-loaded with the main purpose and followed by the important tile-data conditional. Every sentence adds useful information without repetition.

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

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

For a two-parameter read tool with no output schema, the description gives enough context to call it correctly: it lists returned property categories and explains the costly optional tile data. It could be more complete by mentioning behavior for missing maps or the shape of event summaries.

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

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

Schema description coverage is 0%, so the description must compensate. It explains includeTileData clearly, including its default omission and size cost, but it does not add meaning for mapId beyond the obvious name and integer constraint.

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

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

The description uses a specific verb and resource: read a map's properties and event summaries. It lists concrete returned fields (size, tileset, music, encounters, notes), making the tool clearly distinct from siblings like update_map or list_maps, though it does not explicitly name those alternatives.

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

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

Usage is implied: fetch details for a single map rather than listing or updating maps. However, the description does not explicitly say when to use get_map versus list_maps, render_map, or get_event, nor does it state any exclusions or prerequisites.

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

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

No annotations provided, so description carries full burden. It describes the output but does not explicitly state read-only behavior or lack of side effects. Adequate but could be more 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?

Single sentence that is front-loaded and efficient, no superfluous 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 no output schema, the description explains the return value adequately. For a simple parameterless tool, this is complete.

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

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

No parameters, schema coverage 100%. Description adds value by listing the specific fields in the summary, which is helpful beyond the empty 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?

Clearly states it provides a summary of the current project with specific enumerations: game title, database record counts, map count, and plugin count. Well distinguishes from sibling tools like get_system or list_*.

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?

Implies usage for obtaining a high-level project overview, but lacks explicit guidance on when to use or not use this tool versus alternatives.

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

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

No annotations are provided, so the description carries the full burden. 'Full JSON' usefully signals that the complete record is returned rather than a summary, but it says nothing about read-only semantics (only implied), error behavior on a missing id, or whether related sub-records are expanded.

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

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

A single front-loaded sentence with no filler; the key constraint ('one record by id') appears immediately.

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

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

A simple two-parameter read tool with a fully described schema and no output schema; 'full JSON' adequately sets the return expectation. A brief note on missing-id behavior or the record-type enum would make it complete.

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

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

Schema description coverage is 100%, so the 'id' and 'type' semantics are already fully documented in the schema, including the 12-value enum. The description adds only the general notion of selecting by id, which is a baseline-3 contribution.

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

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

States a specific verb and resource ('Get the full JSON of one database record by id'), naming both the object and the lookup key. It implicitly contrasts with list_records/search_records by stressing 'one' record, but never names an alternative 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?

Usage is only implied: call it when you already know the record type and id. There is no statement of when to prefer search_records or list_records instead, and no note about what happens for a nonexistent id.

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

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

The description 'Read' clearly indicates a non-destructive, read-only operation. It also discloses the optional key filtering behavior. However, no annotations are provided, so the description carries the full burden; it could mention safety or lack of side effects explicitly.

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 that front-loads the core functionality. Every word serves a purpose, with 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?

Given the simplicity (one optional param, no output schema), the description covers the main behavior and optional filter. It does not describe the return format, but the tool's purpose is clear. For a read-only tool, it is nearly complete.

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

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

The schema covers the parameter with description 'Optional top-level key to return (e.g. 'switches', 'variables', 'terms')'. The description repeats this, adding no new semantic detail. Baseline 3 is appropriate 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 reads System.json and lists its contents (game title, terms, etc.). It also mentions the optional key parameter that allows returning only one top-level key, distinguishing it from other tools like get_project_info.

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

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

The description implies usage for reading system configuration, but does not explicitly state when to use this tool versus alternatives or exclude specific scenarios. No guidance on prerequisites or 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?

No annotations are provided, so the description carries the burden; it does disclose the return type (an image) and the 48px grid layout, which is real value beyond structured fields. However, it omits image format/size, whether a tile set must exist, and any cost or rate considerations for fetching an image payload.

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, purpose and return shape front-loaded, then the sibling routing. Every clause earns its place with no repetition of schema 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 2-parameter image-returning tool with no output schema, the description covers what comes back (image plus grid layout) and how to pair it with get_tileset_info. Minor gaps remain on image format and error conditions, but an agent can 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 0%, so the description must compensate; it does clarify that 'sheet' selects one of the A1-A5/B-E sheets and that tilesetId identifies the tileset. It adds no detail on tilesetId validity, existence, or how sheet names map to layout regions beyond the enum already 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?

States a specific verb and resource ('Return one tileset sheet ... as an image') and explicitly scopes the sheet enum to A1-A5 and B-E. It also distinguishes itself from the closest sibling, get_tileset_info, by stating the visual purpose ('see which tile looks like what').

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

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

Explicitly routes the agent: use this to visually identify tiles, use get_tileset_info 'for the matching tile ids and kinds'. The selection condition is clear, but there is no statement of when not to use it (e.g. if you only need ids, don't fetch the image cost).

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

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

No annotations are provided, so the description carries the burden. It discloses rich return content (sheet/image mapping, autotile kinds, passability grid with an inline legend of o/x/*/p) and clarifies the overview-vs-detail behavior. It does not cover failure modes for an invalid tilesetId or confirm read-only semantics explicitly, so it stops short of 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?

A single dense paragraph that front-loads the purpose and then layers mode selection, legend, and alternatives. Every sentence carries information, though the run-on structure could be broken into clearer clauses for faster parsing.

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

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

With no annotations and no output schema, the description does substantial work by describing the shape of the returned information and decoding the passability grid. It is nearly complete for a read tool, with only output container/format and error behavior left unspecified.

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 67%, and `tileIds` has no schema description, so the description's note that 'tileIds decodes passability and terrain flags for specific tile ids' fills a real gap. It also explains that omitting `sheet` returns an overview while passing it selects one sheet, and defines the passability legend for A5/B-E. It omits limit and range details (max 100 ids, 0-8191), keeping it from a 5.

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

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

States a specific verb and resource ('Describe a tileset') and enumerates what it returns: sheet-to-image assignment (A1-A5, B-E), tile id ranges, and autotile kinds with type, position and passability. It also names the sibling get_tileset_image, so an agent can distinguish the two tools without opening schemas.

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

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

Explicitly frames the two modes: 'Without `sheet` you get an overview; pass `sheet` for the detail of one sheet', and routes visual inspection to get_tileset_image and per-tile flag decoding to `tileIds`. When-to-use and alternatives are both 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, the description carries the whole burden and does so thoroughly: header-based type detection with size caps (32 MiB images, 128 MiB audio) and a note that only the header is checked, not the codec or full file. It also discloses backup/snapshot semantics for the session, the case-insensitive replacement rule, warning behavior for sheet layout mismatches and missing sibling audio formats, and the changeset refusal.

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 and destination, and nearly every sentence contributes operational detail. However, it is one dense paragraph that packs type detection, naming rules, overwrite, backup history, warnings, and changeset constraints together; splitting into short scannable blocks would improve it without losing 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 4-parameter mutation tool with no annotations and no output schema, the description covers everything an agent needs to call it correctly: path constraints, header rules and size caps, naming rules, overwrite behavior, rollback path, and the changeset precondition.

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 would be 3, but the description adds substantial meaning beyond it: source must be an absolute path to a regular file with no relative paths, UNC shares, devices, or symlinks; name is 1-64 chars from a specific character set with no dots or path separators; and the '$'/'!' prefixes carry character-sheet semantics. The extension is derived from the detected header, not the provided name.

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 concrete verb+resource+destination shape: "Copy an image or sound file from this computer into the project: <project>/<folder>/<name>.<ext>." That clearly separates it from read-only siblings like list_assets, preview_asset, and audit_assets.

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 real preconditions and exclusions: overwrite must be true to replace, nothing is converted, and the tool is refused while a changeset is open (commit or discard first). It also points to list_backups/restore_backup for the recovery path. It does not explicitly name alternatives such as preview_asset or audit_assets for pre-import validation, so it falls just 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 at all, the description carries the full burden and does well: it discloses the safe-by-default write posture, the skip semantics, automatic splitting of long dialogue into multiple message boxes with choices kept in sync, and control-code mismatch warnings. It stops short of saying whether changes land inside a changeset (begin_changeset/commit_changeset exist as siblings) or whether a backup is taken, which matters for a bulk mutation.

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 riskiest fact (dry run by default) in the second clause, then layers skip rules, splitting behavior, and warnings in descending order of importance. Dense but every sentence carries a distinct behavioral fact; nothing is restated from the title.

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 3-parameter bulk-write tool with no annotations and no output schema, the description covers the safety model, row-level filtering, and structural side effects well. The remaining gap is what the dry-run report actually contains and how it interacts with the project's changeset/backup machinery, which an agent would want before committing a large import.

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 67% and the undocumented parameter is dryRun, whose meaning the description fully supplies (default true, read-only report, writes only on false). It also elaborates force beyond the schema's one-liner by explaining that it overrides the original-text mismatch guard. The file path parameter is left to the schema, which documents it adequately.

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 ('Apply the translation column ... back into the project's data') and ties itself to the paired sibling export_texts, which makes the import/export pair unambiguous. An agent can distinguish this from export_texts, bulk_update_records, or update_record 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?

Gives clear operating conditions: dry run is the default and nothing is written until dryRun=false, empty rows are skipped, and stale rows are skipped unless force=true. It implies the precondition that the file comes from export_texts but never states an explicit exclusion or prerequisite ordering (e.g. re-export instead of forcing).

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 itself and mostly does: it discloses the default non-destructive behavior (existing folders are skipped unless overwrite=true), and that the resource copies are always available. It does not describe what a read-only versus user scope does to the filesystem or what is returned, leaving some gaps for a write 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?

Three short sentences, front-loaded with what it does and where, followed by the resource fallback and the overwrite caveat. No wasted text.

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

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

For a zero-required-parameter tool with full schema coverage and no output schema, the description covers purpose, destination, idempotency, and an alternative access path. Only the return value and any permission requirements are unstated, which is 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?

Schema coverage is 100%, so the schema already documents scope, skills, and overwrite. The description adds the practical consequence of overwrite=false (skipped rather than erroring), which is genuinely useful, but says nothing beyond the schema about the skills filter or the project/user scope choice.

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 concrete verb (copy) and resource (bundled RPG Maker skill files) plus the exact destination (.claude/skills) and the reason (so Claude Code picks them up). No sibling tool does anything similar, so it is trivially distinguishable.

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

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

The description makes the use case explicit (installing skills so they auto-load in a project) and names an alternative route: the same files are always available as rpgmaker://skills/<name> resources, so an agent can decide not to install. It stops short of an explicit 'when not to use' statement.

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 enumerates every rule with its severity class, discloses what is deliberately not checked ('Variable-designated transfers are not checked'), explains the approximate nature of maxLineChars, and reports output mechanics (sort order, 300-finding cap, truncated count, skippedMaps). This is behavioral context an agent could not get from any structured field.

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?

Purpose is front-loaded in the first sentence and no sentence is filler; the rule catalogue and output mechanics all earn their place. It is a single dense paragraph, though, so the rule list would scan better as a structured block — a minor structural, not length, issue.

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, and the description compensates fully: findings carry {kind, mapId, eventId, page, index}, page/index are documented as 0-based with the troop-id convention for eventId, and truncation/counts/skippedMaps are all described. For a four-parameter read-only lint tool, nothing an agent needs to call it or interpret results 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 genuinely adds: it clarifies that minSeverity's warning default suppresses info findings unless requested, that mapId only narrows the map portion of the scope, and it details exactly how maxLineChars is computed (control codes stripped, font-dependent approximation).

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: 'Statically checks event command lists in map events, common events and troop pages.' The scope is exact and it is distinguishable from sibling validators like validate_project or check_references, which are not described as linting event command lists with rule-level severities.

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 ('minSeverity defaults to warning, so info findings appear only when requested', 'scope defaults to all; mapId limits the map part to one map'), which tells the agent how to widen or narrow a run. However, it never explicitly says when to choose this over validate_project or check_references, nor does it state any exclusions, so the agent must infer the routing.

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

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

With no annotations, the description carries the full burden and discloses many behavioral traits: only first 64 bytes read, sound type judged from header alone, sub-directories and other extensions skipped, case-sensitive name matching, usedBy/unused semantics, error handling for unreadable folders, sorting, and truncation 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 a single dense paragraph with no wasted sentences, but its length and compactness make it harder to scan than a structured list. It is front-loaded with the purpose, but could benefit from better organization.

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 or annotations, so the description must cover return format and behavior. It does: fields per file, warnings, error entries, usedBy/unused details, truncation, and sorting. Nothing essential for correct invocation is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds substantial meaning: includeUsage default true, which folders the reference scan covers (all except img/system and img/animations), what usedBy and unused mean, and how limit and truncated work per folder.

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

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

The description states a specific verb and resource: 'List the image and sound files in the project's asset folders', and scopes it to img/* and audio/*. It distinguishes from siblings by naming audit_assets and preview_asset in 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 explicitly says to run audit_assets for case mismatches and missing files, and to check for plugin/script loads before deleting. It also clarifies that files outside the import rule are listed but preview_asset cannot open them, giving clear when-to-use and when-not-to-use guidance.

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

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

No annotations provided, so description carries full burden. It explains that backups are created automatically on first file modification per session and where they are stored, providing behavioral context beyond a simple list operation.

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, no wasted words, front-loaded with the core purpose. Each sentence adds value.

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

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

Given no parameters and no output schema, the description is complete. It explains what is listed, where, and why (for rollback). No 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?

Input schema has 0 parameters, so baseline is 4. Description adds meaning by explaining the purpose and context of the backups, though no parameter details are needed.

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

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

The description clearly states it lists automatic backup sessions in a specific directory (.mcp-backups). The verb 'list' and resource 'backup sessions' are specific, distinguishing it from siblings like restore_backup.

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

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

The description implies usage context (to see backups before restoring) but does not explicitly state when to use or not use this tool, nor does it mention alternatives beyond restore_backup.

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 that the scan spans all maps, and critically warns that variable-driven transfers are 'dynamic and cannot be followed, so unreachable is a hint, not proof' — a real false-positive caveat. It does not explicitly confirm the operation is read-only or describe cost/pagination, but 'Scan' and the analysis framing make non-mutation clear.

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

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

Front-loaded with the scan verb and the output list, followed by a single valuable caveat sentence. Dense but every clause earns its place; 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?

With no output schema and no annotations, the description compensates by enumerating the return contents and the dynamic-transfer caveat, which is exactly what an agent needs. The only gaps are explicit read-only confirmation and performance expectations, which are minor for a single-param analysis tool.

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

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

Schema coverage is 100% and the mapId description already explains its scoping ('Only list doors on this map; reachability still uses all maps'). The description itself does not mention mapId, so it adds nothing over the schema — baseline 3 is appropriate.

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

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

States a concrete verb and resource ('Scan every map's events for Transfer Player commands') and enumerates the exact output: doors with destinations, one-way links, dangling transfers, and unreachable maps. This is clearly distinct from the sibling connect_maps (which edits links) and list_maps (which lists maps), so an agent can differentiate without opening the schema.

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

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

The use case (auditing map connectivity) is strongly implied by the output enumeration, but there is no explicit 'use this when' or naming of alternatives such as analyze_progression or connect_maps. Usage must be inferred from context rather than stated.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool reads from MapInfos.json and returns specific fields, but does not mention performance, pagination, or any potential side effects. Basic transparency is present.

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

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

The description is a single sentence that conveys all necessary information efficiently with no wasted 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 no parameters and no output schema, the description adequately specifies what the tool returns. However, it could mention if the list is exhaustive or any ordering, but it is largely complete for its simplicity.

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?

There are zero parameters, so schema coverage is 100% trivial. The description does not need to add parameter information. Baseline score of 4 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 action (list all maps), the data source (MapInfos.json), and the output format (id, name, parentId, order), which distinguishes it from sibling tools like create_map or update_map.

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 use when needing a list of maps, but provides no explicit guidance on when to use this tool versus alternatives or any prerequisites. It is adequate for a simple list operation but lacks explicit 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?

No annotations are provided, so the description carries the full burden. It states what the tool does but does not disclose whether it is read-only, requires authentication, or has any side effects. The description lacks context on permissions or safety.

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 sentence of 12 words, clearly front-loaded with the action 'List all plugins'. Every word serves a purpose, and there is no redundancy.

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

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

For a tool with no parameters and no output schema, the description adequately explains what it does and what it returns (status and parameters). It could mention ordering or whether the list is comprehensive, but it is largely complete for a simple list 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 input schema has zero parameters, so schema description coverage is 100%. The description does not need to add parameter information because none exist. It appropriately focuses on the tool's function.

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

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

The description clearly states the verb 'list' and the resource 'plugins', specifying the source 'js/plugins.js' and the returned information ('status and parameters'). It distinguishes the tool from siblings like 'read_plugin' and 'create_plugin' by indicating it lists all plugins rather than a single one.

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 use when a complete list of plugins is needed, but it does not explicitly state when to use this tool versus alternatives like 'read_plugin' or 'configure_plugin'. No exclusions or conditions 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 full burden. It discloses the output format as '{id, name} summaries', which is sufficient for a simple list operation. It does not mention pagination or limits, but for this tool such details may be implicit.

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. It front-loads the action ('List all records') and provides relevant guidance in the second sentence.

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 tool with one enum parameter and no output schema, the description adequately covers the purpose, output format, and alternative. It could mention that the result is a list/array, but overall it is complete.

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

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

The schema has 100% coverage for the single required parameter, so baseline is 3. The description does not add parameter-level details beyond what the schema already provides, so it meets but does not exceed 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 uses a specific verb 'List' and clearly states the resource 'database type', and explicitly distinguishes from the sibling tool 'get_record' by noting that this returns '{id, name} summaries' while that returns full data.

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 states the tool lists all records of a type as summaries and recommends 'Use get_record for full data', providing guidance on when to use an alternative. However, it does not explicitly mention when not to use this tool.

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 delivers the important non-obvious behavior: the stable sort order and the visibility rule that uncommitted captives from an open changeset are excluded. It could go further by explicitly stating it is a read-only, side-effect-free operation, which is only implied by 'List'.

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 compact sentences: the first front-loads what the tool returns and where it reads from, the second adds the one caveat an agent would otherwise trip on. Every clause earns its place, with no restating of the title or name.

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 parameterless read tool with no output schema, the description supplies the return field set, ordering, storage location, and the changeset visibility caveat. An agent has everything needed to call it and interpret the result without opening anything else.

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

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

The tool takes zero parameters, so the schema is trivially complete and the baseline of 4 applies. The description does not need to compensate for anything.

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 ('List') plus a precisely scoped resource ('stamps saved in <project>/.mcp-stamps/'), and it enumerates the returned fields (name, size, tilesetId, event count) and sort order. Nothing is ambiguous, and 'stamps' is clearly distinct from the sibling list_* tools (list_maps, list_assets, list_records).

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 only implied: it's evident this is the discovery step before place_stamp or after capture_stamp, but the description never names an alternative or states when to prefer it. It does give one concrete operational constraint — stamps in an open changeset are hidden until commit — which is useful context but not selection guidance.

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