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

The description discloses network side effects (image sent to external API), required env vars, and failure modes. Annotations already state readOnly, safe, idempotent, open-world; description adds critical behavioral context without contradiction.

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 fairly long but well-structured with clear mode breakdowns. Every sentence provides necessary info; minor verbosity in the 'ai' mode explanation but overall earns its space.

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

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

For a complex tool with three modes, network side effects, and offline analysis, the description covers all important aspects: return values, failure modes, environment dependencies, and alternatives. No output schema but return format is described per mode.

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

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

Schema descriptions cover all 5 parameters, but the description adds significant value by explaining mode-specific usage, defaults (resizeMax=1024), and constraints (base64PNG must be raw). This goes beyond the schema's basic descriptions.

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

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

The description clearly states the tool analyzes images with three distinct modes (ai, grid, colors), each with specific functionality. It distinguishes itself from sibling tool query_map by noting that query_map's 'ascii' view is better for precise map layout.

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

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

The description provides explicit when-to-use guidance for each mode, including failure conditions (path escapes, missing file, API timeout) and a clear alternative (query_map for map layout). This helps the agent decide 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context beyond that: it operates over an in-memory model cached until data files change, formulas are parsed but never executed, and unreadable formulas are listed. This is meaningful extra detail.

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

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

The description is front-loaded with the core purpose, but it then becomes a dense, semicolon-chained wall of text enumerating thirteen views in a single run-on sentence. While each view entry carries information, the lack of formatting or paragraph breaks makes it difficult to scan and violates conciseness and structure expectations.

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

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

For a complex tool with 15 parameters, 13 views, no output schema, and annotations already covering safety, the description is remarkably complete. It explains what each view does and even sketches output shapes (e.g., validate as {issueCount, bySeverity, issues[]}, ast as a logical tree with outline), leaving little that an agent would need 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 100%, so the per-parameter descriptions already carry the baseline. The description goes further by explaining how parameters combine with views—for example, `severity` filters the validate view, `expected` sets the dead-space band for metrics, and `thresholdSd` controls balance flagging. It adds contextual meaning beyond the schema's field-level notes.

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 states a specific read-only analysis capability over the whole project model, and 'Nothing is written' distinguishes it from write-oriented siblings. However, it does not explicitly differentiate itself from other read-only query tools such as query_database, query_map, or get_project_context.

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

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

The description provides extensive guidance for the `view` parameter, effectively telling the agent which lens to use for each analysis task. It does not, however, say when to use analyze_project instead of sibling tools or when not to use it, leaving tool-level selection implied 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 the safe pure-function profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, yet the description still adds substantial context beyond them: no file writes, no project selection needed, the return shape {commands, warnings?}, the end-marker convention for fragments vs branches, and that game-reference validation is deferred to insert time.

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?

Appropriately sized for an 83-parameter tool and front-loaded with the core purpose and routing before the finer MV/MZ semantics. It is a dense single paragraph with no wasted sentence, though the lack of any structural breaks makes the later constraints harder to scan.

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 does explain the return value ({commands, warnings?}), which is the key gap it needed to close. Combined with the fragment/branch nesting rules and MV-vs-MZ caveats, it is largely complete for this complexity, though the 46% of undocumented parameters leave some functional territory uncovered.

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 54% across 83 parameters, so the description must compensate, and it does add real cross-parameter semantics: 'kind selects the command; only fields belonging to that kind are accepted,' the troop-only kind list, the MV Show Text four-parameter rule, plugin_command emitting code 356, and the integer-or-decimal-string ID rule. It still leaves many individual parameters undocumented, so not 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+resource (build an RPG Maker MV event-command fragment) and immediately scopes it against the sibling that actually writes ('without writing files or requiring a selected project'). An agent can distinguish this from insert_event_commands 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 routes the agent: 'feed commands to insert_event_commands, or nest them in a choice/conditional builder,' which names the downstream alternative and the compose-vs-insert choice. It does not state any when-not condition or prerequisites for this tool itself, so it stops short of a full 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?

The description discloses key behaviors: immediate file write, return of complete object, preset validation with error on missing fields, automatic curve expansion for class params, and non-validation of referenced IDs. This adds substantial value beyond the annotations, which only mark read/write safety.

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

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

The description is comprehensive but well-structured: core function and return in first sentence, then forms, presets, special cases, and limitations. While lengthy, each sentence adds necessary detail, and the front-loading of key info aids quick comprehension.

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

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

Given the tool's complexity (two modes, presets, special handling) and no output schema, the description fully covers return values, validation behavior, unsupported types, and ID validation warnings, providing complete guidance for correct invocation.

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

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

With 100% schema coverage, the description still enriches understanding by clarifying raw vs preset usage, listing exact preset required fields, explaining class param expansion, and detailing expected data structures (e.g., effects for items, members for troops). This goes well beyond the schema's basic property descriptions.

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

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

The description clearly states the tool creates a new entry with the next free ID in an RPG Maker MV database. It distinguishes itself from sibling tools like query_database and delete_database_entry by detailing two creation forms (raw and preset) and specifying the returned object.

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

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

The description explains when to use each form: raw entity+data for custom entries, presets for common types. It explicitly excludes tilesets/animations (use the editor) and advises confirming referenced IDs with query_database, providing clear usage context and 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?

Beyond the annotations (destructiveHint=true, readOnlyHint=false), it discloses that the change is written immediately, not undoable, that IDs are never reused, that references are never cleaned up automatically, and that the delete is refused while references exist. It also enumerates every reference category checked and lists the result shape on forced deletes. 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?

The description is front-loaded with the DESTRUCTIVE warning and every sentence carries substantive information with no filler. However, it is a single dense paragraph for a complex topic, and itemizing the reference list or options would have improved scanability.

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

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

With no output schema, the description supplies the return shape ('Returns the deleted object') and the error behavior ('fails with an error if the ID does not exist'), and it covers the auth/safety profile through both annotations and explicit warnings. An agent has everything needed to call this correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description mostly restates schema semantics for id, force, and entity, and it introduces a 'dryRun:true' parameter that does not appear anywhere in the input schema, which is a potential inconsistency rather than added clarity.

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 resource ('delete a database entry'), names the mechanism ('nulling it out in its data file'), and lists the exact supported entity types. This clearly distinguishes it from siblings like update_database_entry and create_database_entry without the agent needing to open 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 gives explicit conditions for use and non-use: refusal while references exist, fixing references first, using dryRun to preview, or force to override. It also names hard exclusions (never skill 1/2 or state 1). It does not, however, direct the agent to any sibling tool as an alternative, which keeps it 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?

Goes well beyond the annotations: files are written immediately, fill_layer is destructive and not undoable, missing-map entries are reported in `skipped` rather than erroring for set_display_names, and connect creates bidirectional transfer events. The idempotentHint=true is slightly at odds with event-appending actions like connect, but the description's disclosure quality is high.

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 key mutation warning (immediate write) and then organizes each action as a labeled clause. Dense but every clause carries an action-specific fact; the enumeration could be tighter but little 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 7-action, 14-parameter mutation tool with no output schema, the description covers each action's semantics, error behavior, and return shape (per-action summary). Nothing critical for correct invocation is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: layer numbering (0-1 ground, 2-3 upper, 4 shadow, 5 region 0-255), tileId 0 clears, weight default 5, regionSet [] = whole map, and posA trigger semantics.

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

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

States a specific verb (Modify) and resource (existing maps) and then enumerates each action with its exact effect. It explicitly differentiates from siblings by routing event-level work to manage_map_event.

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

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

Per-action guidance is concrete: it names which action to use for which goal, points to get_project_context detail "tileset" for valid tile IDs, and directs event work to manage_map_event. It also states an exclusion (maps have no random battles without set_encounters).

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 non-read-only, non-destructive, non-idempotent behavior, but the description adds substantial context: files are written immediately, registration in MapInfos.json, seed reproducibility, template cloning behavior, transfer-event caveat in duplicate mode, and specific failure conditions. It does not contradict 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-loads the core action and then efficiently details modes and parameters. It is dense and long, but the length is justified by the seven modes and 24 parameters; a few thematic examples could be trimmed without loss.

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 return shapes for each mode (mapId, seed, batch mapIds, markers, interiorMapIds) and specifies error behavior. Combined with annotations and the complete input schema, an agent has enough to invoke it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds some cross-parameter meaning and defaults beyond the schema, especially around mode semantics and reproducibility, but much of the per-parameter detail is already covered by the rich schema descriptions.

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

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

States a specific verb and resource: 'Create a new map file,' with seven generator modes clearly differentiated. It explicitly names sibling tools for related tasks (edit_map fill_layer, get_project_context templates, manage_system mine_templates), so an agent can select it over alternatives without opening schemas.

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

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

Gives explicit mode-selection conditions and alternatives: blank maps are painted later with edit_map, template listing uses get_project_context, and mine_templates should run first for semantic generation. It also explains when to override defaults (templateId, useTemplate:false) and when procedural fallback applies.

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

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds valuable behavioral context: warns against inventing tile IDs ('guessing tile IDs produces glitched maps'), explains return types, and details what each mode outputs. No contradictions.

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?

Well-structured with clear ordering: main purpose, detail modes, golden rules. Every sentence adds value, though the description is lengthy due to the tool's complexity. Could be slightly tighter, but still efficient.

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?

Completely covers all aspects: explains every detail mode, parameters, return types, and golden rules for correct usage. Even without an output schema, the description makes it clear what to expect. No gaps for an agent to misuse the tool.

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

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

Input schema has 100% coverage, but description adds meaning beyond schema: explains what each enum value of 'detail' returns, and for tilesetId, category, theme, it specifies their role in filtering. Schema defers to description for full semantics.

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

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

Explicitly states it is 'read-only: pre-digested project knowledge' and advises 'CALL THIS FIRST'. Clearly distinguishes each detail mode (full, summary, assets, tileset, templates) with specific use cases, differentiating it from sibling tools like query_map and generate_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?

Provides explicit when-to-use instructions: 'CALL THIS FIRST'. Golden rules guide proper usage: use generate_map for maps, never invent IDs, set encounters correctly. Details when to use each detail mode (e.g., 'tileset' for edit_map 'fill_layer').

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 annotations: it discloses pre-write validation, that invalid data refuses the write, safety rules for explicit positions, fragment rebasing to target indentation, atomic backup-protected writing, unknown vs MZ-only extension command handling, and exactly what the result contains. This is unusually rich behavioral disclosure 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?

Content is front-loaded with purpose and validation, then flows into position semantics, dryRun, writer behavior, and return values. It is dense and slightly long, but nearly every sentence carries distinct information 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?

Despite having no output schema, the description enumerates the return payload (target identity, insertion count, resulting list length, listCodes, warnings, and verbose before/after lists), so an agent knows what to expect. Combined with the validation and safety rules, 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%, so the baseline is 3, but the description adds meaning the schema lacks: the safe-boundary constraint on position, the append-before-root-end behavior when position is omitted, dryRun's write-and-backup suppression, and verbose's effect on the result shape.

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 (Insert) and resource (event-command fragment) with explicit scope across three target types (map event page, common event, troop battle page). It also implicitly distinguishes itself from build_event_commands by noting fragments are 'typically returned by build_event_commands', so an agent can tell the two apart without opening the 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?

Gives clear operational context: omit position to append before the root end marker, use dryRun:true to preview without writing, and pass verbose:true for full lists. It does not explicitly state when to prefer this over sibling writers like edit_map or manage_map_event, which keeps it out of 5 territory.

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 cover the safety profile (destructiveHint, non-idempotent), and the description adds substantial context beyond them: the map file is written immediately, IDs/destinations/walkability are not validated, chest and boss are one-time, boss loss causes game over, delete is destructive, and it fails when the map or event doesn't exist. That is exactly the extra layer annotations can't 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 action/preset overview, which is good, but it then becomes a single ~340-word paragraph mixing actions, presets, and inline parameter schemas that partly restate the input schema (e.g., the goods and items tuples). Dense and hard to scan for a 36-param tool; tightening would help.

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-action, 8-preset, 36-parameter tool with no output schema, the description covers every action, every preset's required inputs, cross-tool dependencies (create_database_entry, manage_system, query_map), the immediate-write side effect, and the return/error contract ("Returns the event(s) with ids; fails if the map or event does not exist"). Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real value the schema lacks: it groups which parameters belong to which preset, explains cross-parameter coupling (puzzle_switch links two events via gameSwitchId; door stays locked until lockedSwitchId is ON), and states defaults. It duplicates some field docs (goods/items) rather than adding, keeping it at 4.

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 triad plus resource ("Create, change or remove map events") and immediately distinguishes its scope from structural siblings like edit_map or insert_event_commands. An agent can tell what this tool owns 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 per-action routing: bare create vs preset create, when to fall back to add_command/insert_event_commands for empty pages, when to use convert vs update, and pre-flight checks (query_database/query_map, query_map "ascii" for walkability). No explicit top-level "don't use this for X" exclusions, so it stops short of a 5.

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

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

Annotations only supply readOnlyHint=false, idempotentHint=true and destructiveHint=false; the description goes well beyond them by disclosing that writes are immediate, that re-using a plugin `name` replaces it, that scaffold_project never overwrites, that outDir must be new/empty, and that prune can lose runtime-only assets. These are exactly the mutation and risk details an agent needs and the 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?

It is one dense run-on paragraph covering 19 actions with no bullets, headings, or grouping; every clause is informative but the lack of structure makes scanning for a single action slow. Front-loading is only partial since it opens with the settings section rather than a scope statement.

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

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

For a 19-action, 36-parameter tool with no output schema, the description covers essentially every action's effect and several return details (lastAuthError, drained frames, export file counts/bytes/screen size). Minor gaps remain, e.g. return shape of get full vs. switches and what bridge_start's handshake yields.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds real meaning: it ties parameters to actions (body/help/params/commands for create_plugin, section values for get, types/peek/limit for bridge_telemetry) and explains consequences such as load order for plugin registration and zip placement beside outDir.

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?

Despite bundling three domains (project settings, project lifecycle, live bridge) into one tool, the description enumerates each of the 19 actions with a specific verb and resource, so an agent can tell what 'export_web' or 'bridge_telemetry' does without opening the schema. It differentiates from a sibling like query_map by pointing there for validation, though the heterogeneous scope keeps it short of a 5.

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

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

Some operational conditions are given ('not validated; check with query_map "infos"', 'never overwrites', 'active only in playtest'), which is useful context. However there is no systematic when-to-use vs. when-not guidance, and notably no explanation of how this tool's take_screenshot action relates to the sibling tool of the same 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?

Annotations already indicate read-only, non-destructive, idempotent. Description adds key behaviors: returns null for missing id (not error), case-insensitive search, description matching for certain entities. No contradictions.

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?

Concise and well-structured: starts with read-only safety emphasis, then enumerates three usage forms, provides usage guidance, and ends with sibling differentiation. Every sentence adds value without redundancy.

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

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

Despite no output schema, description explains return types (array vs single object/null) and covers all three modes. Provides complete context for usage, parameter interactions, and relationship to sibling tools. Fully sufficient for an AI agent.

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?

100% schema coverage with descriptions, but description adds crucial semantics: explains that omitting id and query lists all entries, id returns null on missing, query is case-insensitive and also matches descriptions for items/weapons/armors/skills. Significantly enriches understanding.

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

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

The description clearly states the tool queries RPG Maker MV database files, specifies three forms (list, fetch by id, search), and distinguishes from siblings (query_map, get_project_context). Verb 'query' and resource 'database' are explicit.

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 advises using before create/update/delete operations to discover IDs, and directs to query_map for maps and get_project_context for a full digest. Provides clear when-to-use and when-not-to-use guidance.

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

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

Annotations already provide readOnlyHint and idempotentHint; description adds specifics like failure on missing file, offline nature of ascii view, and validation behavior, adding value beyond annotations.

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

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

Efficient and front-loaded with 'Read-only: inspect maps.' Each sentence serves a purpose, but the description is somewhat dense; could be slightly shorter.

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 7 parameters, 1 required, and no output schema, the description thoroughly explains each view's return format, failure cases, and even provides a cheap way to 'see' layout via ASCII. Complete for the tool's complexity.

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

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

While schema has 100% coverage, the description adds meaning by explaining what each view returns (e.g., 'full' returns dimensions and tile data, 'validate' returns issueCount and issues). This compensates for the lack of output schema.

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

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

The description clearly states it is a read-only tool to inspect maps, with specific verbs like 'inspect' and lists each view. It distinguishes itself from siblings like edit_map and generate_map by emphasizing read-only nature.

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

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

Provides explicit when-to-use for each view and mentions an alternative tool (analyze_image) for player-visible images. Could be more explicit about when not to use, but context is clear.

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

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

Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), yet the description adds real value: capture scope ('only the game canvas, not the desktop or credentials'), the output path, the returned payload shape, and required runtime preconditions.

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

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

Four dense sentences with no filler; purpose and the start/stop semantics are front-loaded, and the return payload and defaults follow the core intent.

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 compensates by naming the returned fields and save location, and it lists the runtime prerequisites for a non-read-only operation. Minor gaps remain, such as behavior when a capture is already active or how timeoutMs interacts with the defaults.

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 five parameters with ranges and defaults. The description restates name/fps/bitrate defaults but says nothing extra about timeoutMs, so it sits at the baseline for full schema coverage.

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

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

States a specific verb+resource ('Start or stop recording the live RPG Maker MV playtest canvas') and scopes it precisely via the action enum. It is clearly distinguishable from siblings like take_screenshot or run_playtest.

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 two modes and lists prerequisites (bridge plugin, running bridge, connected playtest). It does not explicitly contrast with the sibling take_screenshot, so the alternative-selection guidance 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 already declare readOnlyHint=false and destructiveHint=false, and the description adds genuinely non-obvious behavior: project data is never changed, screenshots land in .mcp-cache/renders/, runs can take minutes, a progressToken is needed for progress, and optional chromium/playwright prerequisites are required. This is exactly the added context annotations cannot carry, and it is consistent with (not contradictory to) the annotation set.

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

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

Purpose and safety/execution notes are front-loaded, and the dense semicolon-delimited action catalogue is information-dense rather than padded. The single long step sentence is heavy but each clause earns its place by defining a distinct action; it is appropriately sized for the tool's complexity, if somewhat unwieldy to scan.

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

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

Despite covering a complex, multi-action tool with no output schema, the description explains the result shape (each step with ok, a finalState, page problems such as errors and missing files), the prerequisites, and the timing/progress mechanisms. An agent has everything it needs 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 baseline is 3, but the description goes further by mapping which fields belong to which action (e.g. load {mapId,x,y,direction?,party?...}, advanceText {maxMs?}, walk {direction,steps?}), a correlation the schema's flat property list does not express. It adds real meaning for a polymorphic steps array, though it does not document every field exhaustively.

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 ('Play the game headless from a script of steps') and concretely frames the outcome ('report what happened'), even giving example assertions like door transfers, NPC lines, and choice branches. This clearly distinguishes it from siblings such as take_screenshot, record_video, and analyze_project.

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

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

It gives strong context for when to use it ('no editor or running game needed', headless Chromium boot) and enumerates the exact action vocabulary an agent must choose from. It stops short of naming alternatives or explicit when-not-to-use cases, so it is clear but not fully routing-aware.

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 provide idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds behavioral details: session-wide side effect, path validation (checks for data/System.json), error behavior (fails leaving previous active), and return value (new active path). No contradictions.

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-load the purpose, then side effect, then return/alternative. No wasted words; every sentence adds value.

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

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

Given the tool's simplicity (one parameter, no output schema), the description covers purpose, side effects, validation, return value, and the alternative (environment variable). No missing critical details.

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

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

Schema covers 100% of parameters with a clear description. The description adds validation context (must contain data/System.json) and emphasizes absolute path, which enhances understanding beyond the schema.

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

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

The description clearly states the tool's purpose: switching to a different RPG Maker MV project directory. It specifies the action (switch), the resource (project directory), and distinguishes from the startup environment variable, making it unique 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?

The description explains when to use the tool (to change the project directory) and notes the alternative (environment variable at startup). It implies persistence until changed or restart, but doesn't explicitly mention when not to use it or compare with other tools.

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

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

Beyond the annotations (which only declare readOnly/idempotent/destructive=false), the description discloses the save location, the exact return shape {path, bytes, mimeType, name}, and that each capture keeps a timestamp so repeated calls accumulate files — consistent with idempotentHint=false. It does not cover failure modes when the bridge is not running.

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

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

Three dense sentences with the core action and destination front-loaded, followed by prerequisites and then the alias. Every sentence carries information, though the alias sentence could be trimmed.

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 9 optional parameters and no output schema, the description compensates by explaining the return object and naming conventions. The notable gap is that `mapId` switches the tool into a headless map-render mode (different output dir, no running game, Playwright dependency) that the description's 'requires playtest first' framing does not acknowledge.

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 89%, so the schema already carries most parameter meaning. The description only adds that `name` is a filename prefix and that timestamps are appended — useful but marginal, and it never reconciles the `mapId` headless-render mode that writes to a different directory.

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 ('Capture the current RPG Maker MV playtest frame ... save it as a PNG') and names the destination directory. It is readily distinguishable from siblings like record_video (still frame) and manage_system, and it explicitly names the compatibility alias.

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 concrete prerequisites ('Requires manage_system actions install_bridge_plugin, bridge_start, and playtest first') and points to an alternative invocation path (bridge_screenshot alias). It does not, however, state when a still capture is preferable to record_video, so an agent still infers the choice.

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 context beyond the annotations: immediate write, no undo, replace-not-merge for arrays, error on nonexistent ID, full-entry return, and cross-cutting side effects (tilesets affect every map; malformed flags break passability project-wide). However, it conflicts mildly with idempotentHint=true, since appendCommand/addEnemyId/addPage are explicitly additive and would duplicate on repeat calls.

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 partial-update and no-undo semantics, and every sentence carries weight for a 6-param, nested-object tool. It is dense to the point of being a wall of text, mixing core behavior with edge cases in one paragraph, which 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?

Despite no output schema, it states the return ('the full entry after the update') and the failure mode (error if the ID does not exist), and covers all three special append modes plus entity-specific caveats. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is already 100%, so the 3 baseline applies, but the description genuinely adds meaning: that `fields` is unnecessary with the append parameters, that appendCommand picks up build_event_commands output, and that class params accept 8 seeds or 8 arrays of 100 per-level values. This goes beyond restating the schema.

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

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

States a precise verb+resource+scope: 'Partially update an existing database entry', with the partial/overwrite semantics spelled out (only keys in `fields` are overwritten; arrays replaced wholesale). An agent can immediately distinguish this from create_database_entry, delete_database_entry, and query_database without opening a schema.

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

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

Gives concrete when-to-use guidance ('fetch current values with query_database first if you may revert') and routes the special append workflows by entity ('common_events + appendCommand', 'troops + addEnemyId/addPage'). It never states a when-not-to-use condition (e.g. use create_database_entry for new entries), so it stops short of the top band.

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