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

With no annotations, the description carries the load and does reasonably well: it discloses the terminator-handling invariant (code-0 stays last), the post-append re-read of block structure, and the warnings-on-indent-mismatch return behavior. It still omits failure behavior for invalid codes and any permission/validation notes, so it is not fully transparent for a 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?

Three sentences, all substantive, with the core action front-loaded and the prerequisite and return behavior following in logical order. 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?

No output schema and no annotations, so the description must cover everything; it explains the warnings return but omits what happens on malformed codes, whether writes are atomic, and how mapId/eventId/pageIndex scope the operation. Adequate for the happy path, incomplete for an agent handling edge cases.

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

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

Schema coverage is only 20%, so the description must compensate: it mirrors the required command fields and adds real meaning to `indent` via the branch-matching rule. But mapId, eventId, and pageIndex are unexplained (only `at` is documented in the schema), leaving several parameters 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 (append) and resource (raw {code, indent, parameters} commands to a page), which is precise and unambiguous. It does not name the obvious sibling set_commands or explain how append differs from replacing a page's command list, so sibling differentiation is left 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?

Gives one actionable prerequisite (call command_catalog first to learn a code's parameter layout), which is genuinely useful. However, it never says when to choose this over set_commands or decode_commands, nor any conditions/exclusions for use.

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

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

Annotations only supply idempotentHint=false, so the description carries most of the burden and delivers: failure does not abort remaining assertions unless stopOnFailure is set, the game's log is returned alongside results, and it declares the 'Allow Eval' prerequisite. It omits polling cadence (pollMs default) and any throughput/rate limits.

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

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

Front-loaded with the core mechanism and then layered with behavior and prerequisites. It is a dense paragraph but every sentence adds information; it could be trimmed slightly but wastes little.

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, no-output-schema tool it covers the essentials: what goes in, what comes back (pass/fail report plus logs), failure handling, and the Allow Eval prerequisite. Only pollMs behavior and the 60-item cap remain 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?

Top-level schema coverage is 0%, so the description must compensate, and it explains timeoutMs (poll until truthy) and stopOnFailure meaningfully. But pollMs is never mentioned in the description and the nested label/expression semantics are largely left to the schema's inline 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 and resource: 'Hand over a list of {label, expression} and get a pass/fail report back, the way a test runner does it.' This clearly distinguishes it from siblings like live_eval (single evaluation), live_wait, and validate_game. An agent can identify it as the batched in-game assertion tool 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?

Gives strong context: 'instead of writing a throwaway script for every playtest' and concrete scenarios ('a dialog opening, a transfer landing or a battle ending'). However, it does not explicitly name sibling alternatives such as live_wait or live_eval and when to prefer them, so it stops short of the top score.

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

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

Annotations only supply idempotentHint/destructiveHint; the description carries the real behavioral load by disclosing the rollback guarantee ('every file the batch wrote goes back to the bytes it had before'), pre-flight schema validation of each step, the refusal list, and the critical limitation that game-side effects cannot be undone ('a file rollback cannot un-press a key') plus the live_reload remedy. That is exactly the context annotations cannot express.

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

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

Front-loaded with the core transaction behavior, and each subsequent sentence (rollback scope, validation, refusals, game-side caveat) adds distinct operational value. It is dense with em-dash clauses and could be tightened, but there is little genuine filler.

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

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

For an orchestrating tool with no output schema, the description covers failure semantics, validation timing, excluded steps, and the shape of the reply ('results come back per step', 'steps that talked to the running game are named in the reply'). Only the stopOnFailure behavior and exact reply structure are left to the schema.

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

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

Schema coverage is only 50%, but the description compensates by explaining steps semantics well: ordering ('in order'), transaction scope, per-step validation against each tool's schema, and per-step results. It does not, however, explain what stopOnFailure actually changes (stop at first failure vs continue-and-roll-back), which the schema description carries alone.

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 and mechanism: 'Run a list of {tool, args} calls in order as one transaction.' Combined with the title 'Apply several tool calls or none of them', an agent immediately knows this is the atomic multi-call executor and can distinguish it from every single-purpose sibling (create_map, set_tiles, etc.).

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

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

It gives clear context on composition: reading tools may be included, results come back per step, and it explicitly excludes undo_writes, rollback_data and nested batch as steps with a stated reason ('they move the write journal this transaction rolls back against'). What is missing is an explicit statement of when to prefer batch over issuing the same calls individually.

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 disclosure burden. It usefully reveals that the output includes `warnings` matching what writers return and that the rules are 'engine-verified', which frames the tool as an authoritative read. However it says nothing about side effects, permissions, or whether the call is purely read-only (only implied by the verb 'report').

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 the core capability and then the warning behavior. The em-dash clause in the second sentence is slightly convoluted but the text is tightly scoped with little waste.

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

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

With no output schema and no annotations, the description must do more work, and it does explain the semantic content of the return (rules plus warnings). But it omits the shape of the output and leaves all three parameters unexplained, so an agent still lacks what it needs to call the tool confidently.

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% and the three parameters (mapId, eventId, pageIndex) are entirely undocumented in the schema. The description's only nod to them is the vague 'Given a page', which loosely maps to pageIndex but leaves mapId and eventId meaning unexplained, 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?

States a specific verb (report) and resource (engine-verified rules for nested command lists), and even samples the content (which codes indent deeper, which continuation codes repeat, where a block ends). It is clear on its own, though it does not explicitly contrast itself with sibling tools like command_catalog or decode_commands that also deal with command structure.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no named alternative among the many command-structure siblings. The phrase 'Given a page it also returns warnings' hints that a page context is optional rather than a requirement, but the agent is left to infer the conditions for calling this.

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?

Beyond the readOnlyHint annotation, it discloses exactly what is scanned, that it reports two categories of finding (missing file, case-only mismatch), why the findings matter (missing image halts the game loop and paints into a DOM panel invisible to screenshots; missing audio is silent), and an explicit scope boundary for icons.

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 purpose and scan scope are front-loaded in the first sentence, followed by the rationale and the icon exclusion. Every sentence carries information; 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?

For a read-only tool with no output schema, the description does state what is reported (unresolved references plus case-mismatch findings), which covers the substantive return content. It omits the result shape and the limit parameter, leaving minor gaps.

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

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

Schema description coverage is 0% and the sole parameter (limit, 1-500) is never mentioned in the description, so it fails to compensate for the coverage gap. The agent must guess that limit caps the number of reported results.

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 (scan/report) and resource (image and audio asset references), and enumerates the exact sources checked: database fields, map parallax/bgm/bgs, and event commands. An agent can immediately distinguish it from write-side siblings like import_asset.

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

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

It gives clear when-to-use context ('the cheap way to find both before a playtest does') and an explicit when-not exclusion ('Icons are not covered'). It stops short of naming a sibling tool as the alternative, so it is slightly below full routing guidance.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds non-annotated behavior: the whole removal happens 'in one transaction' (atomicity), dryRun returns a preview rather than mutating, and the map is rendered in the reply. It does not discuss undo/rollback paths despite undo_writes and rollback_data existing as siblings.

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 action is front-loaded in the first sentence, and each following sentence adds distinct information (rationale, dryRun, return rendering). The rebuild-script narrative is slightly padded, but nothing is repeated and 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?

With no output schema, the description usefully states that the map is rendered in the reply and that dryRun returns a preview, and it covers atomicity and filtering. Remaining gaps are edge cases: invalid mapId behavior, filter combination rules, and whether the clear is recoverable via the rollback/undo siblings.

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%; mapId and dryRun have no schema descriptions at all. The description compensates by explaining dryRun ('answers with what would go') and by describing the filter semantics (by name, by character sheet, or all), which is more than the schema conveys. It still doesn't clarify how multiple filters combine (AND vs OR) or what eventId does when combined with name/characterName.

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 with scope: 'Remove every event on a map in one transaction, or only the ones whose name or character sheet you name.' It is immediately distinguishable from the sibling remove_event (single-event) and find_events (query-only), 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?

Explicitly frames the use case against the alternative: without this call a rebuild means 'one remove_event per event and a half-finished map if the script dies halfway.' It also routes the inspection case to dryRun ('the quickest way to see a map's cast'), so both the do-this and do-that-instead paths are 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 full burden and does notably well: it discloses that results are parameter names in order, that exact `codes` additionally returns the engine body, and why that body matters (disambiguating which params index is consumed). It does not state read-only nature explicitly, but read behavior is implied by 'Search/Returns'.

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

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

Three sentences, front-loaded with the core purpose and then the reason the richer mode matters. The parenthetical example earns its place by clarifying the value of the engine body. No filler, though the final clause is slightly dense.

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 convey return shape, and it does: parameter names in order, plus engine body when `codes` is supplied. For a 2-param, all-optional lookup tool this is sufficient to call correctly, with only minor gaps around error/empty-result behavior.

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 genuine meaning beyond the schema: it explains that passing exact `codes` changes the return shape to include the engine body, and warns that a name like `operateValueArg1` alone does not disambiguate params[1] vs params[2]. That is semantics the schema does not convey.

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: 'Search the command dictionary derived from the engine's Game_Interpreter.' An agent understands this is a lookup of event command codes. However, it never names its closest sibling (decode_commands) or otherwise differentiates itself, so the agent must infer the boundary.

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

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

The description does distinguish the two modes ('Ask for exact `codes` to also get the engine body'), which is useful usage signal. But it gives no explicit when-to-use guidance relative to alternatives like decode_commands, leaving the selection to inference.

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

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

With no annotations, the description carries the full burden and does substantial work: deep-cloning semantics, fresh id, self switches keyed by event id so a copied chest starts closed, both copies remaining live, and the source being unmodified. It stops short of covering permissions, failure modes, or what the call returns, so it is strong but not exhaustive.

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

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

Front-loaded with the core action, then layered with behavioral detail in efficiently packed sentences. Dense but each sentence adds real information; no filler.

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

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

For a six-parameter mutation tool with no annotations and no output schema, the description covers the behavioral contract well (clone depth, id/switch reset, liveness, source immutability). The gap is parameter-level detail for the four undocumented required fields.

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

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

Schema description coverage is only 33% (name and toMapId documented; mapId, eventId, x, y bare). The description implies destination semantics via 'another cell or another map' but never maps its language onto x, y, or toMapId explicitly, so the four required parameters remain semantically thin.

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 ('Duplicate an event onto another cell or another map') and immediately enumerates what is copied (pages, conditions, graphic, trigger, command list, note). This clearly distinguishes it from siblings like place_event or add_commands, which create or extend rather than deep-clone.

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 context is implied rather than stated: the note that 'both copies are live afterwards, which matters for an autorun or parallel-process event' signals a relevant scenario, but there is no explicit when-to-use versus place_event, and no prerequisites or exclusions are 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 destructiveHint=true and idempotentHint=false already declared, the description goes well beyond them: it explains the 1-based array model, that rows are never removed, that blank-slot names prevent id reuse, that it only grows the table when no blank slot exists, and that `fields` merges shallowly. This is rich behavioral context an agent cannot get from the annotations.

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

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

Front-loaded with the core concept and no filler sentences, but the middle is a long run-on covering fallback logic and merge semantics that could be tightened. Informative and structured, yet slightly dense for a single-tool description.

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

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

For a complex, mutation-heavy tool with no output schema, it covers the schema model, the default/growth path, the copy/merge behavior, what the reply reports (basedOn), and the refusal cases with alternatives. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning: it clarifies the default-id path (first blank slot, else append), the `copyFrom`-vs-last-row fallback, and that the merge is shallow 'exactly as patch_database_entry does'. It adds value beyond the schema, though most parameter facts are already documented there.

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 ('Claim a row in a database table') and immediately frames it against the editor's add button. It explicitly distinguishes itself from siblings patch_database_entry and create_map, including the exact tables each handles. An agent can tell it apart without opening a schema.

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

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

Gives explicit when/when-not: omit `id` to mimic the editor's add button, System.json and MapInfos tables refuse and must use patch_database_entry / create_map, and removal is a patch, not a delete. Alternatives are named with the conditions that select them.

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

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

With no annotations, the description carries the full burden. It does disclose one meaningful side effect: the tool also creates a MapInfos entry, which is useful. However, it omits whether an existing file is overwritten, what defaults are applied, permission requirements, or what happens on name collision.

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, and the key artifact (empty map file) is stated immediately. It is efficient, though arguably terse to the point of under-specification given the parameter gaps.

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 file-creating tool with no annotations, no output schema, and five undocumented parameters, the description is not complete enough. It states the outcome but leaves callers without the usage and parameter detail they need to invoke it correctly.

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

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

Five parameters with 0% schema description coverage and the description adds nothing about any of them. It never explains width/height bounds, the role of tilesetId (required), parentId semantics, or whether name is optional/auto-generated, so an agent gets no help from the description.

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

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

The description states a specific verb (Create) and resource (an empty map file plus its MapInfos entry), which is more informative than the title alone. It clearly distinguishes from deletion/list siblings, but it never explains how it differs from the closely related 'make_map' sibling, leaving that ambiguity unresolved.

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

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

There is no guidance on when to use create_map versus alternatives such as make_map, or whether it should precede set_map_properties/set_tiles. No prerequisites, ordering, or 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, the description carries the full behavioral burden. 'Render ... as readable lines' implies a non-mutating read, but nothing states that explicitly, nor does it mention permissions, whether the operation fails for missing maps/events, or what the returned lines actually contain.

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, which is the right size for a simple tool. It is efficient rather than padded, though the terseness is part of what leaves the gaps above.

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, no annotations, and zero parameter documentation, the description should be doing much more work. It never explains the shape of the decoded output, how mapId/eventId are sourced, or how this differs from the adjacent command tools.

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

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

Schema description coverage is 0% for three parameters, so the description must compensate and largely does not: mapId and eventId are never mentioned, and pageIndex is only obliquely gestured at by 'a page's command list'. The agent gets no indication of what these identifiers reference or what happens when pageIndex is omitted.

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 concrete verb ('Render ... as readable lines') and a specific resource ('a page's command list'), so the agent knows this is a read/transform operation rather than a mutation. It does not, however, differentiate itself from look-alike siblings such as command_catalog or show_text, so the boundary between them must be inferred.

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

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

There is no when-to-use statement, no prerequisite, and no named alternative. The agent must guess that this is the tool for inspecting an already-written command list rather than for authoring (add_commands/set_commands) or enumerating available commands (command_catalog).

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?

Goes well beyond the destructiveHint annotation: it specifies that both files are backed up first, that undo_writes restores them together, that the operation refuses while inbound transfer events exist, and that those events are listed so the caller can decide. This is exactly the kind of pre-conditions and reversibility detail annotations cannot convey.

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

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

Three dense sentences front-loaded with the destructive action and its scope, then refusal semantics, then backup/undo. Information-rich with minimal waste, though the final sentence packs backup and undo into one clause that could be split.

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

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

For a destructive, non-idempotent mutation with no output schema and no annotations covering pre-conditions, the description supplies the missing pieces: reversibility via backups/undo_writes, the inbound-transfer refusal, the force override, and the dry-run probe. An agent has everything needed 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 67%: `force` and `dryRun` are documented in the schema, but `mapId` is not. The description's discussion of force/refusal semantics adds behavioral meaning beyond the terse schema text, partially compensating for the undocumented mapId, though it doesn't state mapId's integer/tree-slot meaning explicitly.

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 (remove/delete) and two concrete resources (`data/MapNNN.json` and its `MapInfos` tree slot), and explicitly positions itself as the inverse of `create_map`, a named sibling. An agent can distinguish it from `clear_events`, `make_map`, or `remove_event` without inspecting schemas.

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

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

Describes a real usage context (build scripts tidying prototypes) and the refusal condition with transfer events, plus the `force` escape hatch and the `dryRun` report-without-writing path. It doesn't enumerate when to prefer a sibling like rollback_data, but the operational 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 readOnlyHint already declaring safety, the description adds substantial context beyond annotations: it explains the flags array semantics (directional passability, the 0x10 quirk in stock tilesets, ladder/bush/counter/vehicle/terrain bits) and discloses that contactSheet creates and deletes a scratch map, touching no tileset row or real map. That side-effect disclosure is exactly what annotations cannot convey.

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 what the tool reads, then the query modes, then the contact sheet caveat. Every sentence carries information, but the dense em-dash prose runs long and could be split for 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?

There is no output schema, so the description carries the full burden of describing return values — and it does, enumerating every field of an entry and what the contact sheet draws. For a 6-parameter tool with a nested object, nothing an agent needs to call it correctly appears to be missing.

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

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

Schema coverage is already 83%, so the baseline is 3, but the description adds real meaning: it explains the slot grouping (A1–A4 autotile shape groups of 48, A5/B–E fixed), what mapId vs tiles vs slot each retrieve, and that tilesetId defaults to the map's own tileset. Minor gaps remain, such as the interaction between limit and the various modes.

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 — reading the tile dictionary as the engine reads it — and enumerates exactly what each entry carries (slot, bound image, layer, flags semantics, usage counts). It is clearly distinguishable from siblings like tileset_slots, inspect_cell and render_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?

Explicitly lays out four query modes and when each applies: mapId 'for every tile a map really paints, which is the fastest way to learn an unfamiliar tileset', tiles for ids in hand, slot to walk a slot pattern-by-pattern, or neither for the slot table alone. contactSheet is also positioned as the answer for visual questions.

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

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

Annotations already declare idempotentHint=true and destructiveHint=true, so the bar is lower; the description adds real context — parameter defaults come from the file's own header, re-running merges rather than duplicating, and a running game needs a restart while an open editor manager will overwrite the file on save. It stops short of stating exactly what this tool overwrites in plugins.js, which keeps it from a 5.

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

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

Dense but front-loaded with the core action, and each clause (patch_plugin contrast, header sourcing, idempotent merge, restart, editor race) carries distinct information. Slightly packed, but no sentence is wasted.

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 file-mutating tool with no output schema and partial annotations, the description covers the important operational caveats (restart, editor overwrite, merge semantics). It doesn't describe the return value, which matters somewhat given no output schema exists, but the essential call-correctly information is present.

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 the schema doesn't: parameters are seeded from the file's `@param`/`@default` header and only override single keys on top of that, and it explains why nothing runs on undeclared values. That goes beyond the schema's field-level text.

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

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

The description states a precise verb and target (put a plugin file into `js/plugins.js`) and immediately differentiates itself from the sibling `patch_plugin`, which 'only reaches entries that are already listed.' An agent can tell exactly what this does and how it differs from neighbors 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?

It names the alternative (`patch_plugin`) and the condition that selects this tool over it, plus clarifies re-run behavior on an already-listed plugin. That covers when-to-use and the alternative in one pass.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses little. It never states that this is a read-only sweep, whether it searches all maps by default, how the limit is applied or what the results look like. 'Without reading every map by hand' is the only hint at breadth, and it is 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?

Two sentences, zero filler, and the search axes are front-loaded before the illustrative use case. The example sentence earns its place by clarifying commandCode semantics rather than padding.

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

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

With 5 optional parameters, no annotations and no output schema, an agent still lacks the default limit, the behavior when no filter is supplied, and the result shape. The description covers the core search concept adequately but leaves these operational gaps for a tool whose structured fields do not fill them.

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

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

Schema coverage is only 40% (name and mapId documented; commandCode, characterName and limit bare), so the description must compensate. It does partially: the common-event example gives real meaning to the undocumented commandCode parameter, and 'by name' aligns with the name filter, but characterName and limit remain unexplained 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 (find) and resource (events) plus the search axes (name, command code, graphic), which cleanly separates it from the mutating siblings place_event, remove_event, copy_event and clear_events. The claimed 'by graphic' axis has no corresponding parameter in the schema, which slightly muddies the precision of the stated scope.

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

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

The example question ('which events call common event 12') implies when the tool is useful, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. get_map / inspect_cell for a single-map read). Usage must be inferred from the illustrative case.

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

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

Annotations already declare idempotentHint=true and destructiveHint=true, so the safety profile is framed. The description adds real value on top: only genuinely absent keys are written, values come from the installation template rather than the package, and dryRun returns a plan. It explains provenance and the write-avoidance behavior the annotations do not.

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 an undivided run-on narrative of several hundred words for a two-parameter tool. Key facts (dryRun behavior, sibling alternatives) are buried mid-paragraph rather than front-loaded, forcing the agent to extract signal from dense prose.

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

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

For a repair tool with no output schema, the description covers what gets written, what does not (maps, events, start position), the no-op case, and what dryRun returns. It is functionally complete, though the density makes it harder to consume than its content warrants.

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 both parameters are documented, setting the baseline at 3. The description still adds meaning: dryRun 'answers with the plan alone' and template values come from your installation, clarifying where the default and the written values originate.

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+resource: it writes the System.json engine keys a project is missing without a fallback. It also implicitly separates itself from siblings by noting it does not invent maps/events/start position. The core purpose is recoverable but buried in a long narrative, so it takes effort to parse.

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 alternatives and the selecting condition: validate_game reports missing maps/events/start position and set_startup writes them, while this tool handles only engine keys. It also clarifies that running on an editor-made project changes nothing, which helps an agent decide when it is a no-op.

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

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

With no annotations provided, the description carries the full burden. It discloses what is returned and notes that layer dumps and command decoding are optional, which is useful, but it does not mention side effects, permission needs, or output size concerns for a read-only inspection tool. Adequate but not rich.

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, front-loading the core read behavior and then the optional slice dump. No wasted words, though separating the optional behavior more clearly would slightly improve structure.

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 appropriately enumerates returned contents. It covers the main read path and the optional dump mode, but omits any guidance on when the optional modes are preferable or how large outputs behave, leaving a small completeness 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 description coverage is 100%, so the schema already documents mapId, layerDump, and includeCommands fully. The description adds only a brief restatement of the optional layer-dump behavior and does not extend parameter meaning beyond the schema, so 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?

States a specific verb (read) and resource (a map's structure) and enumerates the exact contents returned: dimensions, tileset, events with position, graphic, trigger, and page conditions. This clearly distinguishes it from siblings like inspect_cell or render_map, which focus on narrower or visual targets.

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 a read/inspection context but does not state when to use this tool versus alternatives such as inspect_cell, find_events, or render_map. There are no stated prerequisites, exclusions, or named alternatives, so usage is only weakly guided.

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

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

Annotations only declare destructiveHint=true and idempotentHint=false; the description adds substantial behavior beyond that — extension validation, case-folding name refusal, writing through the backup journal, undo_writes recovering it including deleting a previously-nonexistent file, and recoverability of overwritten bytes. This is exactly the context annotations can't carry.

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's a dense single paragraph, but front-loaded with the core fact (no importer, folder+name is registration) before the mechanics. The long folder enumeration is bulky yet necessary for correctness; otherwise there's little waste.

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

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

With no output schema, the description still explains the reply (the value for the data field and which fields already name the asset), covers validation and rollback behavior, and needs nothing more for an agent to invoke it correctly.

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

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

Schema coverage is 100%, so the schema already documents all four parameters (baseline 3). The description adds meaning on top: `name` defaults to the source base name and overwriting requires `overwrite: true`, clarifying the mutation semantics of two params.

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 (copies a file into folders the engine's loaders read) and enumerates the exact target folders, so the agent knows precisely what happens. It also distinguishes itself from siblings by referencing check_assets and undo_writes and framing itself as the missing half of asset checking.

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

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

It gives clear conditions: the folder and base name are the whole registration, overwriting needs `overwrite: true`, and the write is reversible via undo_writes. It doesn't explicitly state when NOT to use it or name a competing import path, but the context is strong enough to route the agent 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 full behavioral burden, and it does establish this as a pure read and discloses the complete returned payload, which is the key behavioral fact. It omits edge-case behavior (out-of-bounds coordinates, nonexistent mapId) and any error or permission notes.

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 front-loaded sentence with the verb first and zero filler. Every clause earns its place by naming a returned data category.

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 usefully enumerates the return contents, which is appropriate. However, for a 3-parameter tool with zero schema descriptions it leaves parameter meaning and usage context unaddressed, so it is only minimally complete.

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

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

Schema coverage is 0% and none of the three required parameters have descriptions. 'Single cell' weakly implies x/y identify the cell, but the coordinate space, bounds, and the meaning of mapId are never explained, so the description does not compensate for the schema 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?

Specific verb ('Read') plus a precise resource ('a single cell') and an enumeration of exactly what is retrieved: tile layers, shadow bits, region id, terrain tag, and the event on the cell. This distinguishes it clearly from bulk siblings like get_map, render_map, and describe_tiles.

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 statement of when to use this versus alternatives such as get_map (whole map) or describe_tiles (tileset metadata), and no preconditions. The agent must infer from the name alone that this is the single-cell inspection 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?

Annotations only say idempotent/destructive; the description adds the real behavioral payload: the landing algorithm (above, right, left, below, facing away), the `landed` reply field, the warning when a door is walled in on all four sides, the `requires` two-page locked structure, and that both maps are re-rendered. This is well beyond what the annotations convey.

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

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

Front-loaded with the core write, then descends into landing rules and rationale. Dense but every sentence carries information; the rationale paragraph is slightly long but earns its place by explaining the blocked-destination failure mode.

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 10 parameters, nested objects, and no output schema, the description carries the return-value burden and does so by explaining the reply's `landed` field and warning behavior. Remaining gap is the undocumented `replace` parameter and the absence of any overwrite/destructive warning despite destructiveHint=true.

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 90%, so baseline is 3, but the description meaningfully extends it: `a`/`b` as doorway cells, `land` override including the doorway cell itself, `direction` arrival-facing, `sound`, `graphic`, and `twoWay` semantics. Only `replace` goes unexplained, which keeps 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?

Opens with a precise verb+resource+scope: 'Write both ends of a connection in one call: a door event on each map that transfers the player to the other.' An agent can distinguish this from place_event, set_event_page, or map_connectivity 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?

Explains the rationale for existing (the blocked-destination check that a live playtest surfaces late) and when to reach for `requires` (locked pairs) or `twoWay: false` (leave the far end alone). It gives clear context but never explicitly names an alternative sibling tool for the non-linked cases.

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 disclose a genuinely useful behavioral fact: every write produces a backup copy in .rpgmaker-mcp/backups, including a few files outside data/. It does not say what a listed entry looks like, ordering, or whether backups can be restored, which is a notable gap for a no-annotation 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?

Two sentences, no filler, and the mechanism/location is front-loaded before the scoping instructions. 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 simple optional-parameter list tool with no output schema and no annotations, the description covers origin, location, and scoping. It still leaves the return shape and the relationship to sibling restore/undo tools unstated, which is a meaningful gap given the absence of structured metadata.

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: the lone parameter is named 'table' but the description reveals it also accepts a project-relative path such as js/plugins.js, and that it is optional (omitting it lists all). This adds meaning the bare schema string type does not convey.

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 (list) and resource (write backups), and explains the mechanism that creates them (every write copies the previous file into .rpgmaker-mcp/backups). This is enough to separate it from siblings like write_history, rollback_data, and undo_writes, though it never names them explicitly.

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

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

Explains how to scope the listing (a data file, or a project-relative path like js/plugins.js), which implies when to use it. However, it gives no explicit guidance on when to prefer this over rollback_data, undo_writes, or write_history, so the agent must infer the boundary.

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. 'List' strongly implies a read-only, whole-collection operation and it discloses the returned fields, but it says nothing about pagination, ordering, or size/rate limits for a potentially large collection.

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 verb and scope lead, and the returned fields follow compactly. 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?

With no output schema, no annotations, and no parameters, the description is the sole carrier of contract information, and listing the exact returned fields covers the key need. It could still clarify ordering or scale for large projects, but nothing essential is missing.

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

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

The tool takes zero parameters, so there is no parameter semantics to convey; the baseline for a parameterless tool is 4. The description appropriately focuses on the output fields instead.

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 ('List') and resource ('every map'), and enumerates the returned fields (size, tileset, event count, encounter settings). This clearly distinguishes it as an enumeration tool versus the singular get_map sibling, though it does not name that 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 phrase 'List every map' implies the usage context (enumerating all maps), but there is no explicit when-to-use guidance, no mention of alternatives like get_map for a single map, and no prerequisites. Usage is only implied.

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

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

readOnlyHint=true already covers safety, and the description adds substantial context beyond it: it defines the cross-check behavior against @param blocks, the meaning of 'undeclared', 'unset' (running on @default), and 'fileExists: false' (plugin enabled but script missing, which halts the game at boot). That is real behavioral disclosure an agent could not infer from annotations.

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

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

Two dense sentences, front-loaded with the primary action and then the diagnostic semantics. Every clause earns its place, though the second sentence is long enough that it could be split for 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?

There is no output schema, so the description must carry the return contract, and it does: it enumerates the reported fields and explains the edge-case values (undeclared, unset, fileExists:false) including the boot-failure consequence. Nothing an agent needs to interpret the result is missing.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies a no-argument, whole-file scan and doesn't invent parameters that don't exist.

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: 'Read js/plugins.js and report every entry in load order' with the exact fields surfaced (enabled, description, stored params). This distinguishes it cleanly from read_plugin_source (single file) and enable_plugin/patch_plugin (mutations) without the reader 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?

Usage is implied by the scope (report every entry in the plugins file), but the description never names an alternative or a when-not condition, e.g. 'to inspect one plugin's source use read_plugin_source' or 'to change a setting use patch_plugin'. Adequate but leaves routing to inference.

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

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

Annotations only declare readOnlyHint; the description adds the rolling 200-entry buffer with repeat-merge semantics, call-stack retrieval behavior, and the critical fact that it keeps answering after SceneManager.stop() freezes the render loop, with `stopped` reporting that state. This is rich behavior beyond the annotation.

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 what gets returned, then parameter recipes, then the crash-resilience fact. Dense but every clause earns its place. The parenthetical about SceneManager.stop() is slightly compressed, but overall well-structured.

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

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

For a read tool with no output schema and rich annotations-light context, the description covers return content, dedup behavior, cursor semantics, and post-crash resilience. An agent has everything it needs to invoke and interpret results 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 75% (full, clear, since documented; limit is not). The description explains the intent of `since` and `clear` with concrete workflows and reinforces `full`, adding operational meaning beyond the schema. `limit` remains unexplained in both places, keeping this 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 (return logged output) and resource (live game logs), and enumerates exactly what's captured: uncaught exceptions, error screen entries, failed loads, console.warn/error. This distinguishes it from live_status, validate_game, and check_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 explicit operational recipes: pass cursor as `since` for incremental reads, use `clear` before an action to attribute new errors, use `full` for stacks. Closes with a 'when to reach for this' statement — after a crash, when the file layer can't help — which is a strong usage cue.

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 only idempotentHint=false and destructiveHint=false in annotations, the description carries the burden and delivers: it discloses that answer waits for the window to be takeable, presses one edge at a time, re-reads the cursor after each press, reports the press count, and refuses disabled options. It omits what a failure/timeout reply looks like and the return format, so it falls just short of fully exhaustive.

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

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

Front-loaded with the purpose and the action list, then a rationale paragraph justifying the design. Everything is relevant, but the second paragraph is dense and longer than strictly needed to route an agent, so it is efficient rather than maximal.

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 by detailing what read returns (message text, options with enabled state and cursor position, number-pad digits, window takeability) and what every action's reply contains. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by tying parameters to action branches (index/number for answer, presses for dismiss/cancel) and confirming 0-based engine ordering. It does not mention limit or waitMs, leaving those entirely to the schema.

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

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

States a specific verb set (read/answer/dismiss/cancel) over a specific resource (the live game's dialog layer) and enumerates exactly what each action does. It also explicitly distinguishes itself from the sibling live_key, so an agent can tell them apart 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?

Names the alternative ('three live_key calls') and explains precisely when to prefer this tool: the choice-queued/cursor-unmovable race where raw cursor keys are dropped. It also routes between its own four actions (read to observe, answer/dismiss/cancel to act).

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

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

With no annotations, the description carries the full behavioral burden and does so: it documents the promise-settling model, the 20000ms plugin ceiling versus the timeoutMs wait, and two concrete engine pitfalls (encounter counter lag on scripted walk; performTransfer using the stale $dataMap). This is far beyond what the schema provides.

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 one-line purpose, then prerequisites, then the timeout semantics, then the pitfalls. It is long, but for an eval tool the two engine-behavior paragraphs earn their place by preventing misread results; only minor phrasing ('the way') is loose.

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 no annotations, yet the description explains what comes back (the settled value of a promise), the timeout behavior, prerequisites, and the main failure modes. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains the 20000ms default and the 60000 ceiling for timeoutMs, and notes that the plugin still abandons the promise at 20s regardless. It also implies expression is a single expression, reinforcing the schema's IIFE 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?

States a specific verb and resource: 'Run a JavaScript expression inside the live game and return its value.' This unambiguously distinguishes it from siblings like live_move, live_key, and assert_in_game, which act on the game rather than evaluating arbitrary expressions.

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

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

Explicitly states prerequisites (Allow Eval parameter, RMMZ_LIVE_TOKEN, running playtest) and routes the agent to alternatives with conditions: use live_move instead of a scripted moveStraight, and reserveTransfer+wait instead of performTransfer. This is when-to-use and when-not guidance grounded in named alternatives.

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

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

With no annotations, the description carries the full burden and does most of it well: it explains the frame-hold and re-assert mechanism, that the call blocks until the game has consumed all frames, that slow/headless frame rates or browser focus loss cannot swallow the input, and that the reply carries the measured frame rate and whether the player's cell changed. It does not warn that a key press can trigger irreversible in-game actions (menu confirmations, selections), which is the main behavioral risk for a live-input tool.

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

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

Front-loaded with the core action and key table, and every sentence carries information. The third sentence is dense and slightly overloaded (frame rate, focus loss, reply contents in one breath), but nothing is padding.

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

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

For a tool with no annotations and no output schema, the description covers purpose, alternative routing, dependency, blocking semantics and reply contents, which is nearly everything an agent needs. It is silent on failure modes such as the plugin being absent or no live session running.

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%; keyCode has no schema description, and the description compensates with a concrete mapping (Ok=13/32, Cancel=27, Shift=16, arrows 37-40). It also gives meaning to the frame-count behavior behind holdFrames and pulses, though it never names those parameters directly or reconciles them against the documented 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?

States a specific verb and resource ('Press a game key in the live game') and immediately differentiates from the sibling that could be confused with it by naming live_move and the condition that selects it. The parenthetical key-code table makes the exact resource concrete rather than generic.

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 (advance dialogs or drive input) and when to use the alternative instead ('To walk somewhere, prefer live_move: one press is one step only if the player happens to be standing still when it lands'). It also states the prerequisite ('Needs the RMMZLiveBridge plugin, not Allow Eval'), which is exactly the kind of routing guidance an agent needs.

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 burden and does so: it discloses that it drives the engine's own input path, the side effects that follow (step count, encounter roll, player-touch events), the four conditions that end the walk early, and the plugin prerequisite (RMMZLiveBridge, not Allow Eval). This is exactly the behavioral context annotations would otherwise provide.

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

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

Front-loaded with the core behavior and return shape before the rationale, and most sentences earn their place. The live_key comparison and side-effect sentences are valuable but dense; a slightly tighter phrasing would lose nothing.

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, the description still tells the agent what comes back ('where they really got to and what stopped them'), what interrupts the walk, and what environment is required. Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100% and every parameter is documented in-schema (cells, numpad direction, timeoutMs), so the baseline is 3. The description reinforces cells semantics but adds no format detail beyond the schema, which is appropriate when the schema does the heavy lifting.

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 behavior ('Hold an arrow key until the player has arrived `cells` cells away') and states what it answers with. It explicitly contrasts itself with live_key, so an agent can distinguish it from its closest sibling 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 an explicit routing rule: 'Use this instead of live_key whenever the intent is go-there rather than press-this,' and justifies it with the frame-timing constraint on key presses. This is a when-to-use plus a named alternative and the condition that selects 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?

Annotations only declare idempotentHint, so the description carries the burden and does so richly: it discloses exactly what halts (SceneManager.updateMain, event interpreter, input sampling), what persists (last frame, screenshot/eval/diagnostics), and the non-obvious side effect that live_key input is dropped while paused.

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 behavioral consequence is front-loaded in the first sentence and every subsequent clause adds distinct, load-bearing information. No filler or redundancy despite its length.

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 output schema and minimal annotations, the description fully covers the state change, its scope, its side effects, and the resume path. An agent has everything needed to call it correctly.

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

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

Schema coverage is 0% with a single boolean, so the description must compensate, and it does: 'Resume with paused: false' pins down the polarity of the parameter. It could add a touch more (e.g. default state), but the core semantics are covered.

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: stop/resume the engine's update loop. It explicitly contrasts with the surrounding live_* family by naming what still works (live_screenshot, live_eval, live_diagnostics) and what is dropped (live_key), so an agent can place it precisely among siblings.

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

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

Gives clear context for when the effect applies (update loop skipped, input unsampled) and how to reverse it (paused: false). It stops short of explicitly routing to alternatives like live_step for frame advancement, so it is clear context without full when-not/alternative guidance.

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

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

No annotations are provided, so the description carries full burden. It discloses critical behavioral traits: the player stays in place, event interpreters restart from the top, database tables are not re-read, the call blocks until the reloaded map is live, and it does not require Allow Eval. This is unusually rich 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?

Three sentences, front-loaded with the core action and effect. Every sentence adds distinct value: the action and scope, the workflow context and alternative, and the caveats (what changes propagate, what doesn't, and the Eval requirement). 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?

For a zero-parameter mutation tool with no annotations or output schema, the description covers what changes, what doesn't, the blocking behavior, and the prerequisites. An agent has everything needed to invoke it correctly in the right sequence.

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 baseline is 4. No parameter semantics needed. The description doesn't waste space on parameters because there are none.

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 ('re-read the current map file and rebuild itself') and enumerates exactly what is affected: tiles, autotiles, events and map size. Distinguishes itself from siblings by naming set_tiles, place_event, and set_event_page as the tools that precede it.

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 workflow context ('author-then-look loop') and when to call it versus alternatives ('call it instead of booting a new game and transferring'). Also specifies when NOT to use it: database table changes (System, Actors, Items, Tilesets) require a new game.

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 readOnlyHint=true already covering the safety profile, the description adds substantial implementation context: it re-runs Graphics._app.render() and reads the canvas in the same task, which is why it works without preserveDrawingBuffer. It also discloses a known blind spot (DOM-based video is excluded) and the playtest dependency — all non-obvious traits not derivable from annotations or schema.

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

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

Five tight sentences, front-loaded with the core action, then differentiation, then mechanism, then caveats. Every sentence adds information; nothing is restated from the title or 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?

No output schema exists, but the description states the return artifact (a PNG of the composited frame), the mechanism, and the operational precondition, which is everything needed to call and interpret this tool correctly.

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

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

Only one parameter (saveTo) at 100% schema description coverage, so the schema already defines its meaning and the description does not elaborate on it. Baseline 3 is appropriate when the schema carries the parameter explanation.

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 — 'Grab the running game's own composited frame as a PNG' — and enumerates exactly what is composited into it. It explicitly contrasts itself with the sibling render_map ('shows what the data says; this shows what the player sees'), so an agent can separate 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?

Names the alternative (render_map) and the condition that selects it, plus a hard precondition: 'Needs a running playtest.' It also carves out a scope exclusion (video playback is not part of the frame). It stops short of a full when/when-not matrix, but the routing signal is clear.

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

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

Annotations only say openWorldHint=false and destructiveHint=true; the description adds far more: the browser is the sole process started, it is recorded in .rpgmaker-mcp/session.json, and `stop` kills only that pid's tree after confirming the recorded profile directory is still on its command line. It also discloses the Allow Eval / keepAwake prerequisites and their failure modes.

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 primary `start` behavior and action list before the edge cases. It is long and dense for a single paragraph, but nearly every clause carries operational value, so the size is largely earned.

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 this is a stateful, destructive-capable session tool, yet the description covers start/stop lifecycle, prerequisites, session-file tracking, refusal behavior, and action semantics. An agent has enough to call it correctly without opening other docs.

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%, so the schema already documents most parameters; the description still adds real meaning by explaining the newGame default walk, the 60-second call-budget interaction with boot, and why force exists. This goes beyond the schema text rather than merely restating it.

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

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

States a specific verb set and resource: it 'owns the whole loop' and enumerates each action (start/boot/status/reload/stop) with what each does. It explicitly distinguishes itself from siblings by saying live_status / live_screenshot / assert_in_game need a game that this tool provides.

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 and alternatives: pass newGame:false and call `boot` afterwards under a 60s-per-call client, use `reload` for a freshly written plugin file, `boot` alone to drive to a map. It also states the refusal condition (won't start a second browser while a game is reporting).

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 disclose meaningful behavior: the call waits for the bind to report, and a conflicting port surfaces as a listenError instead of a health signal. It also points at how to enable the bridge. It does not state what is returned when no game is running or the bridge is disabled, which is the main remaining 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?

Purpose is front-loaded in the first sentence, with the socket caveat following. The second sentence is dense and slightly convoluted ("a port another copy of this server already holds reads as a listenError here rather than as health"), and the closing "Also explains how to enable the bridge" is meta-commentary rather than tool 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, so the description must describe the return payload, and it does enumerate the reported fields (scene, map, position, switches, variables, party). Combined with the disclosed wait/listenError behavior and bridge-enabling pointer, an agent has enough to call it correctly, though the no-game/disabled-bridge case is 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?

The tool takes zero parameters, so the baseline is 4. The description's mention of `listening` refers to an output/status field, not an input, and it correctly does not invent parameter semantics that the empty schema does not support.

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 ("Report") and resource ("what the running game last sent through the RMMZLiveBridge plugin") and enumerates the payload: scene, map, player position, switches, variables and party. This clearly separates it from action siblings like live_move or live_reload. It stops short of naming the closest alternatives (live_diagnostics, live_wait), so it does not fully differentiate by name.

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 clarifies what `listening` means and how a port already held by another server copy manifests (a listenError rather than health), which is real usage-relevant context. However, it never states when to reach for this tool versus live_diagnostics or live_wait, so routing between siblings is left to inference.

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

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

The only annotation is idempotentHint=false, so the description carries nearly the full burden and does so well: it discloses the pause-first behavior, the exact engine call invoked, the 1..600 bound, and that exceptions are routed to the engine's catchException so they surface in live_diagnostics rather than crashing the session. That is rich operational detail beyond anything in the structured fields.

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

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

Three dense sentences with zero filler: purpose and use cases first, then mechanism, then error behavior. Each sentence adds information an agent needs, and the most decision-relevant content is front-loaded.

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

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

For a single-parameter live-control tool with no output schema, the description is nearly self-sufficient: it explains the mutation, the frame semantics, the `advanced` return delta, and failure handling. Remaining gaps are the default when frames is omitted and whether the session is left paused afterwards.

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% and the single parameter has no description, so the description must compensate – and it does, explaining that frames is the N count passed to updateMain and bounding it at 1..600. It does not state what happens if frames is omitted, even though the parameter is optional (0 required), which is 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 precise verb and mechanism: run N engine frames, pause, then call SceneManager.updateMain exactly N times, and stop again. The use cases (animation cycle, message window paging, battle sequence) make the intent concrete. It does not explicitly distinguish itself from the sibling live_wait, which is the nearest alternative, so it stops 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?

Gives clear usage contexts – frame-by-frame watching of an animation, a message window page, or a battle sequence – which is more than implied guidance. However, it never states when NOT to use it or names an alternative such as live_wait or live_pause, leaving the agent to infer the frame-exact vs time/condition-wait split.

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 the core behavior (repeated polling until truthy) and that the tool blocks a sequence, but says nothing about what happens on timeout, whether errors are thrown or falsy returned, or default polling/timeout values.

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 sentence with the core mechanism front-loaded and the rationale trailing. No filler, though the parenthetical examples could be tightened.

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, no annotations, and two of three parameters undocumented. For a blocking poll tool an agent needs to know the return value on success vs. timeout and the default/max wait, none of which the description supplies.

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%: only 'expression' is documented (and its 250ms polling note is in the schema, not the description). pollMs and timeoutMs are completely undocumented in both the schema and the description, and the description does not compensate with defaults, units, or bounds.

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: polling an expression in the running game until truthy. It is clearly distinct from live_eval (evaluate once) and assert_in_game by the polling-until-true semantics, though it never names those siblings 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 phrase 'so a sequence (menu open, battle over, message finished) can be followed instead of guessed at' gives concrete usage scenarios, which is better than nothing. However, it names no alternatives (e.g., live_eval or assert_in_game) and states no when-not conditions, so routing is left to inference.

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

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

Annotations declare idempotentHint and destructiveHint; the description reinforces idempotency by name ('leaves one foe, not one foe per run') and adds real behavioral detail beyond the annotations — names resolved against project tables, missing rows refused, and the specific failure mode where an action naming a skill with no Skills row 'throws on the turn the foe decides to act.' It does not explicitly warn about the destructive overwrite of existing rows, so not 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?

The purpose is front-loaded, but the prose is dense and parenthetical, with long run-on sentences carrying embedded code enumerations. Each clause is informative, but the trait-code list and the item-effect aside make it heavier than needed for a description whose job is selection and invocation.

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

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

For a complex nested tool with no output schema, the description covers the two-row output scope, the tricky encodings, resolution/refusal behavior, and idempotency, and briefly notes output comes back 'in words.' Combined with a fairly rich schema, this is nearly complete, with the main gap being the destructive-overwrite implications of rewriting an existing row.

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

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

With schema coverage at only 25%, the description compensates by documenting the failure-prone encodings the schema doesn't: the drop shape `{kind, dataId, denominator}` and its denominator semantics, the trait `{code, dataId, value}` codes (11/12/14/21/22/31/32/63), and the value-vs-value1/value2 distinction. This is meaningful semantics beyond the schema, though it references a 'trait' shape not obviously present as a top-level property.

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+resource ('Author a fight') and precisely what gets created: 'Both rows a battle needs — the Enemies row and the Troops row that holds it — from one ask.' It explicitly distinguishes itself from the sibling create_database_entry, which 'has to be handed the whole thing.' An agent can tell what this tool produces versus alternatives 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?

It names the alternative (create_database_entry) and the condition selecting this tool over it, and hints at the zone/region use case ('the region that rolls it if you want it met by walking'). It also frames the idempotency benefit for 'a build script that runs twice.' It stops short of explicit when-not-to-use exclusions, so a 4 rather than 5.

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

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

Annotations only carry idempotentHint and destructiveHint; the description goes well beyond them, disclosing the two-page self-switch architecture, that `requires` is implemented as a Conditional Branch so a locked chest stays openable, and that validation runs before any write (blank slot id or gold-as-tax fails the call). This is rich, non-obvious 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?

Front-loaded with the core action, then details; four dense sentences where each carries real information. Slightly heavy on mechanism (self switch, copy_event) that could be trimmed, but nothing is redundant.

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

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

For an 11-param tool with nested objects and no output schema, it covers what gets written, the payout-once behavior, validation failures, and the requires-gating semantics. It omits any statement of what the call returns and does not address the `replace` flag, leaving minor gaps.

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

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

Schema coverage is 55% and several properties (x, y, mapId, name, replace) lack descriptions, but the prose compensates by explaining the semantics of `requires`/`lockedMessage` interaction and the `contents` validation, adding meaning beyond the schema for the most complex nested params.

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: 'Place a chest' and enumerates the exact parts it writes (closed graphic, message line, contents, replaced open page). An agent can distinguish it immediately from siblings like place_event, make_npc, or make_shop, which handle different event types.

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

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

Explains that MZ has no chest command so this tool is the intended path, and clarifies the copy_event interaction (a copied chest is closed again because self switches key off event id). It never states exclusions or names a sibling alternative for edge cases, so it's strong context without explicit when-not-to-use 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?

Adds substantial behavior beyond the annotations: pre-write validation (unknown steps, missing switches/variables/rows, missing audio and face files), automatic indentation and branch-marker emission, and the 'one transaction, map rendered back' atomicity guarantee. The 'rewrite that page' wording also discloses the overwrite that destructiveHint=true implies.

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 the place-vs-rewrite decision, then the step catalog, then validation/transaction behavior. The step enumeration is long but each token names a real construct; slightly dense as a single block, but no filler sentences.

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

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

For a 12-param, no-output-schema mutation tool this covers purpose, modes, validation and atomicity, and notes that `script`/`raw` escape hatches 'come back named in the reply'. It stops short of describing the overall response payload or pagination/limits, but is close to 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 leaves `script` as an opaque array of single-key objects (additionalProperties {}), and the description compensates by enumerating the whole step vocabulary and the shape of key steps (choice options with `when`/`then`, battle win/escape/lose branches, loop closed by break/goto). This is meaning the schema does not carry.

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 ('Write an event's whole script from a step list') and enumerates the exact constructs it authors (dialog, choice branches, if, loop, battle, shop, etc.). It also positions itself against siblings by declaring 'the tool for a scene rather than a person', separating it from make_npc/make_chest.

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 context for both modes ('pass a cell to place a new event, or an existing eventId and pageIndex to rewrite that page') and differentiates scene-level authoring from person-level authoring. It does not explicitly name nearby alternatives like add_commands/set_commands/place_event, so the routing is implied rather than spelled out.

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?

It goes well beyond the annotations by disclosing concrete failure modes: MZ reads regionSet unconditionally so a row without it throws inside Scene_Map and freezes the map, and a missing weight produces a NaN sum that blocks all rolls. It also explains replacement vs additive behavior and that the reply flags orphaned regions, all runtime consequences an agent cannot infer.

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

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

Front-loaded with the core action and structured as what-it-does followed by why-the-shapes-matter warnings. The prose is dense and vivid ('freezes the map mid-walk'), which mostly earns its place as load-bearing caution, though a few phrasings could be tightened.

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

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

For a 6-parameter, nested, multi-file mutation with no output schema, the description covers inputs, failure modes, clearing, and even the reply's diagnostic callout. It omits explicit return structure, but the mention of what the reply reports partially fills that 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 83%, so the baseline is 3, but the description adds real semantics: region 0 means the whole map, a troop entry either names an existing troopId or lists enemies, and rows are cloned from a real troop so member shape matches the editor. These clarify nested-parameter intent beyond the schema descriptions.

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

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

The opening sentence names a specific composite action and its parts: 'Paint a region, make the troops, and attach the encounter rows in one call.' It clearly distinguishes itself from siblings like make_battle and make_map by describing the three coordinated writes across two files.

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

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

The description implies when to use it ('in one call' composite of region + troops + encounter rows) and hints at re-run behavior via clearRegion, but never names alternatives or states when NOT to use it versus make_battle or set_map_properties. Usage is inferable rather than explicit.

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

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

Annotations already declare idempotentHint=true and destructiveHint=true; the description reinforces idempotency ('re-running a build script rewrites the same row instead of adding one') and adds substantial extra context: validation/refusal of unknown states, parameters and common events, and the NaN failure mode from mismatching trait/effect shapes. It stops short of explaining reversibility or the destructive profile explicitly, so 4 rather than 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?

Purpose is front-loaded in the opening clause, which is good, but the body is a long single block dense with engine lore (NaN arithmetic, item-type menu behavior) that is educational yet costly for a tool-selection summary. It is not padded with filler, but it is longer than the selection decision requires.

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 high-complexity 30-param, nested-object mutation tool with no output schema, the description covers the effect/trait compilation contract, validation refusals, and idempotency. It omits return/result behavior and the dryRun path, but the core failure modes an agent must avoid are addressed.

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

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

With 30 parameters, 57% schema description coverage and nested objects, the schema does much of the work. The description adds genuine conceptual value by explaining the {code,dataId,value1,value2} effect shape versus the {code,dataId,value} trait shape and the itypeId/wtypeId validity rules, but leaves many uncovered params (dryRun, copyFrom, note, repeats) to the schema, so baseline 3 is right.

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 (write/make) and resource (a row across Items/Weapons/Armors/Skills), and the framing 'Write a row the player can hold or cast' is concrete. It explains what makes it distinct (compiling effects/traits into engine shapes), but never names the generic siblings like create_database_entry or patch_database_entry it presumably supersedes, so an agent must infer the routing.

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 is rich on what the tool does and why, but gives no explicit when-to-use versus when-not guidance and no alternatives. There is no mention of dryRun or when to prefer this over the generic database tools, so the agent gets no routing signal beyond implied specialism.

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

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

Annotations already declare idempotentHint and destructiveHint; the description goes well beyond by explaining the one-tile-per-cell, last-stroke-wins resolution, the layer-zeroing on repaint, the passage-flag behavior, the layer assignment per slot, and the transaction enclosing set_tileset_flags. This is rich behavioral disclosure. It docs the dryRun and the idempotent find semantics, though it does not state the destructive nature of repaint explicitly except through the zeroing 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 long and somewhat dense, moving between a scenario story, engine internals, and per-parameter behavior. It is front-loaded with the one-call intent, which is good, but several sentences could be trimmed without losing value, and the engine-internals digression is longer than necessary for tool selection.

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 14 parameters, nested objects, no output schema, and destructive+idempotent annotations, the description covers the important behavioral and transactional details. It could be more complete on the output (it mentions the reply counts walkable cells), and on permissions, but for a high-level composite tool it is fairly 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 93%, so the schema already documents most parameters. The description adds meaning beyond the schema by explaining the resolution semantics (last stroke wins), paint ordering (ground first, then what sits on it), layer-zeroing on repaint, and how flags/regions/properties map to sibling tools. This is well above the baseline 3.

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 concrete verb+resource ('makes or reuses the map, sets its tileset, resolves the paint plan, writes it in one pass, applies passage flags') and distinguishes itself from the low-level alternative ('create_map + set_tiles per map'). It is clear it is a high-level composite tool. It does not explicitly name siblings like create_map as alternatives by name, but it does reference the low-level pattern, which is close enough for a 4.

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 context is clear: it is the high-level one-call form that replaces dropping to create_map + set_tiles per map, and it names the idempotent form via 'find'. It explains when to prefer this over the lower-level layer. It does not enumerate when-not-to-use, but the alternative framing is strong.

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

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

Annotations only carry idempotent/destructive hints; the description adds the transaction/atomicity guarantee ('if any part fails, nothing is written'), the reply shape (map rendered around the new NPC), the two consequential defaults (priorityType 1, replace true), and the note that script/raw escape hatches are echoed back in the reply. This is substantial disclosure beyond the annotations and is consistent with idempotentHint=true and destructiveHint=true.

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

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

Front-loaded with the core behavior, then defaults, then the escape-hatch caveat. Sentences are dense but each carries distinct information (atomicity, defaults, alternatives). It is on the long side for a tool description, but little 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?

For a complex, deeply nested tool with no output schema, it covers the write semantics, the reply's rendered map, defaults, and the escape-hatch limitation. It omits error/validation detail beyond the characterName failure (which the schema already states) but is otherwise complete enough to invoke confidently.

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

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

With 22 params at 64% coverage, the description adds real meaning the schema does not: the rationale and default for priorityType 1 and replace true, and that `patrol` writes the page's movement route run by moveType 1. It leaves other params (e.g. moveSpeed, moveFrequency, walkAnime) to the schema, so it does not fully 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?

Opens with a specific verb+resource ('Place a non-player character in one call') and enumerates exactly what it creates: graphic, movement, dialogue, and an optional follow page. It is clearly separable from sibling place_event (raw event) and make_choice_scene (branching scenes).

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 routing rule for adjacent needs — 'For more than talk — choices, gates, battles — use `script` here or make_choice_scene' — and explains the replace default as the build-script idiom. It does not exhaustively state when NOT to use it (e.g. vs place_event), so it stops short of a 5.

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

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

Annotations declare idempotentHint=true and destructiveHint=true, and the description adds substantial behavioral context beyond them. It explains the underlying MZ command encoding (302/605), that commands after the goods run when the shop window closes regardless of purchase, the validation of each good, free-item reporting, and that `when` replaces the locked page. No annotation contradiction 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 purpose is front-loaded, but the description is a dense, single paragraph mixing purpose, MZ implementation internals, and validation rules. Some details about command 302/605 are tangential to invocation, and the text could be more structured for a 13-parameter tool.

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 13 parameters, nested objects, and no output schema, the description covers the creation behavior, side effects, and key parameter semantics fairly well. However, it omits explanations for several optional parameters and does not describe what the tool returns, leaving some gaps for an agent to infer.

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 46%, so the description must compensate. It explains the goods structure, validation rules, and `when` semantics, but leaves many parameters (name, replace, speaker, faceName, denied, image) largely unexplained. It also describes internal numeric kind/priceType values that do not match the schema's string enum, which may confuse rather than clarify.

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 composite creation action: it builds a working shop with keeper graphic, greeting, goods, and farewell line. It distinguishes itself from siblings like make_chest and make_npc by focusing on the shop event and its goods array. An agent can identify the tool's purpose 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 phrase 'One call for a working shop' implies the use case, and the explanation of `when` shows how to build conditional shops. However, there is no explicit when-to-use guidance versus alternatives such as make_npc or make_chest, and no exclusions or prerequisites are stated.

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

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

With only readOnlyHint available, the description carries the behavioral load and does so richly: blocking requires a same-as-tiles page (isNormalPriority), conditions are not evaluated, standable/touchable/automatic are defined, transfers are followed, and a portal landing on an impassable tile is flagged as a trap. This is exactly the extra context annotations cannot supply.

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

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

Front-loads the core action and definition, then layers semantics efficiently; nearly every sentence earns its place. It is a dense single paragraph, and the run-on style around the portal/trap clause slightly 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?

For a complex traversal tool with no output schema, the description covers reachability categories, transfer following, and the reports ordering well. It omits the entry shape and the maxMaps bound, which are the remaining gaps an agent would want before calling it.

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

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

Schema coverage is only 33%, so the description must compensate. It effectively explains the blocking behavior behind includeEventBlocking and the transfer-following behind followTransfers, but maxMaps (the walk bound) and the coordinate/mapId semantics are never addressed, leaving one non-obvious parameter 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: 'flood-fill walkable cells from a start position and report which events the player can actually reach.' It also frames the intent ('can the player get there') versus the naive alternative of trusting tile placement, which cleanly separates it from inspect_cell/get_map siblings.

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

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

Gives clear context for when to reach for it — verifying actual reachability rather than tile placement, and following portals into destination maps. However, it never names an explicit alternative or exclusion (e.g. when to use inspect_cell instead), so the routing guidance is implied 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?

With no annotations, the description carries the full burden and does so well: it discloses that nested objects/arrays have no partial-update semantics, that missing keys are lost, and that the reply names lost keys. It also documents the switches/variables exception. It omits auth/permission requirements and idempotency, hence not a 5.

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

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

Front-loaded with the core action and scope; the remaining sentences each carry distinct behavioral information (loss semantics, reply behavior, exception). Slightly dense and long-winded in the nested-object sentence, but no filler.

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

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

For a mutation tool with no annotations and no output schema, the description covers the key risks (data loss on nested patches) and hints at the response (names lost keys). It could say more about failure modes or permissions, but the essentials for correct invocation are present.

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% (only 'id' documented), so the description must compensate, and it does: it explains patch semantics for nested structures, the complete-pass requirement, the switches/variables alternative input shapes, and that id is ignored for System. It adds substantial meaning beyond the schema's bare types.

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 ('apply a shallow field patch') and resource ('one entry of a database table') with scope qualifier ('or System.json's top-level keys'). This clearly distinguishes it from siblings like create_database_entry and read_database.

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 implies a workflow ('read the entry first' when keys are lost) but never states when to choose this tool over read_database or create_database_entry, nor any exclusions. Usage context is only inferable from the semantics of 'patch'.

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

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

Annotations declare destructiveHint=true and idempotentHint=false, and the description substantially enriches that: only the touched entry is rewritten (no full-file reformat), scalars are coerced to strings while struct/array values stay JSON, PluginManager.parameters is read once at boot so a restart is required, and an open editor plugin manager will clobber the file on save. These are exactly the behavioral facts an agent needs before mutating the file.

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 action is front-loaded in the first clause, followed by the file-behavior nuance and then the operational caveats. Every sentence earns its place, with no redundant restatement of the title or 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 mutation tool with no output schema, the description covers the write scope, the coercion behavior, and the two critical side effects (boot-time parameter caching and editor-overwrite hazard). An agent has enough to invoke it correctly and anticipate the consequences.

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 25% (only `parameters` is documented), so the description carries extra weight: it maps the three settable fields (enabled status, description, parameter values) to the parameters and explains the MZ storage coercion (scalars to strings, struct/array stays JSON). It does not clarify `name` semantics or the `status`/`description` params individually, so it compensates well but not fully.

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: set one plugin's enabled status, description, or parameter values in `js/plugins.js`. It further distinguishes itself from write_plugin_source by noting it only rewrites the touched entry's object literal rather than reformatting the file. An agent can tell it apart from sibling plugin tools 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?

Frames the tool as 'the same edit as the editor's plugin manager' and gives clear situational context (running playtest needs a restart; editor open will overwrite on save). It does not, however, explicitly name when to prefer this over siblings like enable_plugin or write_plugin_source, leaving the alternative routing 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 are provided, so the description carries the full behavioral burden. It says nothing about whether moving an event onto an occupied cell overwrites, what happens to unspecified fields on update, permission requirements, or reversibility. For a mutating tool with zero annotation coverage this is a significant 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?

A single front-loaded sentence that covers both modes with zero filler. Nothing to trim.

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 6-parameter mutation tool with no annotations, no output schema, and near-zero schema description coverage gets only one sentence. Return value, error behavior, note semantics, and the overwrite question are all 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?

Schema coverage is only 17% (just id), so the description must compensate. It does map x/y to 'cell', id to 'move', and name to 'rename', but leaves note and mapId unexplained and gives no format or constraint detail for any of them.

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 with dual-mode scope: 'Create an event at a cell, or move and rename an existing one by id.' That distinguishes it from remove_event, copy_event, and find_events. It stops short of naming those siblings explicitly, so it's clear but not fully differentiated.

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 when each mode applies via the 'omit id to create' semantics and the schema's id description, but never names alternatives (e.g., copy_event, set_event_page) or states prerequisites like whether the map must be loaded. Usage is inferred 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?

With no annotations, the description carries the full behavioral burden. 'Summarize' implies a non-mutating read and the enumerated scope tells the agent what it covers, but it says nothing about whether this is expensive, whether it requires the project to be configured/loaded, or how it behaves on an empty or invalid project.

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

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

A single front-loaded sentence with the verb first and the enumerated contents following. Every clause carries information; 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?

For a zero-parameter, low-complexity read tool with no output schema, the description's enumeration of returned categories (maps, tilesets, database tables, switch/variable names, engine version) effectively serves as the return-value contract. Only the absence of any usage context keeps it from being 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. The baseline for a parameterless tool applies.

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

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

States a specific verb ('Summarize') and resource ('the configured RPG Maker MZ project') and enumerates the exact contents of the summary: maps, tilesets, database tables, switch/variable names, and engine version. This distinguishes it from narrower siblings like list_maps or read_database, though it never names those siblings 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?

There is no explicit when-to-use guidance, no statement of prerequisites, and no routing to alternatives such as list_maps or read_database for targeted queries. The orientation use case is only implied by the word 'Summarize'.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose meaningful behavior: the compact-vs-full return mode, and the System special case where 'entries' holds a single object. It does not mention failure behavior for an invalid table name or whether reads are cached, which keeps it 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?

Front-loaded with the core action and the return-shape summary before the table enumeration. The final sentence about System is somewhat convoluted and slightly overlong, 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?

With no output schema, describing the return shapes (`count`, `entries`, `value`) is essential and is done. Valid table values, the single-entry mode, and the field-restriction mode are all covered; only error/edge-case behavior for an unknown table 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 67%, and the description compensates for the biggest gap: the `table` parameter has no description or enum in the schema, yet the description enumerates all valid table names. The `id` semantics ('one entry in full') are also restated and reinforced, though `fields` is not elaborated beyond the schema text.

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

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

States a specific verb and resource ('Read data/<table>.json') and immediately names the exact file convention. It is clearly distinguishable from the write-oriented siblings patch_database_entry and create_database_entry, and the enumeration of covered tables pins down the scope precisely.

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 read-only framing and the table list, so an agent can infer this is the lookup tool. However, it never states when to prefer this over siblings such as find_events or project_info, nor does it name any alternative or exclusion.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds real value beyond that: the default 200-line window, the paging mechanism, and the fact that the result carries parsed @param blocks in a `declared` 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?

Three tight sentences with zero banter; the resource and its defining property are front-loaded, and each remaining sentence adds a distinct fact (default size, paging, declared output).

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 three sparsely documented params, the description covers the essentials an agent needs: where the source lives, how to page it, and what the parsed output field contains. The only real gap is the size/limit of the `lineCount` parameter.

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 carry the load and mostly does: it explains `name` through the path template, and `fromLine` as the paging control plus the 200-line default that implies `lineCount`. Only the `lineCount` parameter itself is left unnamed and unexplained.

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

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

States a specific verb and resource ('Return a window of lines from js/plugins/<name>.js') and explicitly positions it against siblings by calling it 'the only way to see what a plugin actually hooks before editing around it', which distinguishes it from patch_plugin and write_plugin_source.

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

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

Gives clear context for use (reading plugin hooks before editing, paging long files via fromLine) and implicitly routes against the plugin-writing siblings, but never states an explicit 'when not to use' or names an alternative tool by name.

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, but it does disclose one genuinely important trait: deletion leaves a null hole rather than compacting the array, so other event indices remain stable. It says nothing about error behavior for a missing eventId, whether the map must be loaded or a live session active, or permissions.

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 padding: verb, resource, and resulting state in order of importance. The trailing "as the editor does" is mildly vague but still conveys that behavior matches the editor's own delete.

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-required-parameter mutation tool with no annotations and no output schema, the description covers the post-condition (null hole, no reindexing) but omits prerequisites, failure modes, and return behavior. It is adequate for the core action but not 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 0% for both parameters, so the description must compensate. The "null hole in the events array" phrasing implicitly suggests eventId is an array index, which is useful, but mapId is left entirely unexplained and the index semantics are only implied, not stated.

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

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

The description names a specific verb and resource ("Delete an event from a map"), which is unambiguous. It does not, however, distinguish itself from near siblings such as clear_events, place_event, or copy_event, so an agent must infer the routing itself.

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

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

There is no statement of when to use this tool versus alternatives like clear_events (bulk removal) or place_event/copy_event (creation). The only contextual hint is "as the editor does," which describes the resulting state, not the conditions for calling the 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, the description carries the full burden, and it does disclose meaningful behavior: rendering is engine-accurate and the return is an image. It omits other behavioral facts, notably that saveTo writes a file to disk and whether the tool has any side effects, so it is only partially 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?

Two sentences, no filler, with the core action and its engine-accurate compositing detail front-loaded before the overlay aside. Slightly terse given eight parameters, but every sentence earns its place.

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