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

Annotations already declare this is a non-read-only, non-destructive, closed-world write. The description adds real behavioral context beyond them: it validates FBX version/texture size/naming, expands folders only at top level, and reports whether the running editor has the module loaded plus the required ordering (materials before FBX, editor restart). It does not restate the safety hints, which is appropriate.

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

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

Purpose is front-loaded in the first clause and each following sentence carries distinct information (validation, conversion path, reporting, folder expansion). The prose is dense and slightly run-on, but no sentence is filler.

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

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

With no output schema, the description pre-empts the return-value question by saying the result tells the agent what to do next, in what order, and whether the editor has the module loaded. Combined with annotations and full schema coverage, an agent has enough to call it correctly, though the response format is left qualitative rather than structured.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining that folders are expanded only at the top level (claryfing the files parameter) and by explaining the reimport-vs-new-asset distinction tied to the Resource Browser flow, adding value the property descriptions only partly cover.

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 (copies/imports) and resource (FBX meshes and textures into <module>/AssetSources), and the naming clearly separates it from siblings such as asset_search, asset_status, and editor_command. An agent can distinguish it 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?

The description makes clear the context of use (staging sources for the Modding Kit editor to convert) and warns that copying is not converting, pointing to the Resource Browser workflow. It stops short of naming sibling alternatives or explicit when-not conditions, so it lands at 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 already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description usefully adds the search scope (vanilla AssetPackages plus mod Assets, across every module), but says nothing about result volume, pagination behavior, or what a match looks like beyond "resource names."

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 with the primary action front-loaded and no filler. The parenthetical qualifiers and enum list make the second clause dense, but every element carries information about scope or downstream use.

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 search tool with no output schema and fully documented parameters, the description is adequately complete: it establishes domain, scope, and how results are consumed. It could note the return shape (rows/names with which identifiers), but that gap is minor given the annotation and schema coverage.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the schema, making 3 the baseline. The description's kind enumeration broadly mirrors the enum values but is actually shorter than the enum (omitting animation_clip, face_animation, source), so it adds no syntax or matching semantics beyond what the schema states.

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 ("searches") and resource ("resource names inside every module's asset packages") and enumerates the asset kinds covered, so the agent knows exactly what domain this touches. It stops short of naming how it differs from close siblings like prefab_search or search_objects, leaving some overlap to inference.

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

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

The second sentence says where the returned names are consumed (scenes, items, materials), which implies usage but is guidance about the results, not about when to choose this tool over prefab_search or search_objects. No explicit when-not or alternative routing is 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?

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered; the description goes further by disclosing the four comparison categories, the resource types inspected, and the specific validation rules emulated (material-less sub-meshes, unknown materials, control-character corruption, mesh-less physics shapes). It does not mention result size limits or pagination, which is the 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?

Two sentences, front-loaded with the comparison and its four result categories before moving to validation behaviour. The second sentence is dense but each clause adds a distinct check; nothing is redundant with 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?

With no output schema, the description must convey what comes back, and it does: the four package states plus the resource inventory per package and the validation findings. For a read-only two-parameter diagnostic tool this is largely sufficient, though truncation/limits on large modules are unstated.

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

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

Schema description coverage is 100% for both parameters, so the schema already carries the semantics (module id, details listing resources). The description's clause about 'the meshes/materials/textures/physics shapes each package contains' loosely corresponds to the details flag but adds no syntax or default behaviour beyond the schema. Baseline 3 is appropriate.

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

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

Names a specific verb (compares) and two concrete resources (module AssetSources vs editor's imported Assets/*.tpac packages), then enumerates the exact states it classifies: imported, pending, stale, orphaned. This clearly separates it from siblings like asset_import (performs the import), asset_search (finds assets) and validate_module (validates module 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?

The mention that it 'checks the packages like the editor will when loading them' implies a pre-flight/diagnostic use case, so an agent can infer it should run this before import or when investigating load failures. However, no explicit when-to-use, when-not, or named alternative (e.g. asset_import or validate_module) is given, 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 already declare destructiveHint=true and readOnlyHint=false, and the description adds meaningful non-obvious behavior: omitting new_id fully overrides the original with the same id, and a plain 'name' gets a fresh {=id}. That override semantics is exactly the detail an agent needs to avoid clobbering vanilla content. It doesn't mention writability prerequisites or return behavior, keeping it out of 5 territory.

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

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

Two sentences, purpose first, then the critical edge-case behavior. Zero filler and front-loaded.

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

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

For a destructive mutation tool with seven parameters (including a nested set object) and no output schema, the description covers the surprising override behavior and the id-generation nuance. Only minor gaps remain, such as the writable-module requirement and the effect of the validate flag.

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 semantics beyond the schema for two parameters: the new_id omission override rule and the name-to-{=id} behavior. Those are interpretations the raw schema strings don't 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 (copies) and resource (an existing object into a writable module under a new id), and grounds it with concrete examples (weapon/troop/hero/culture). An agent can distinguish it from write_object, create_module, or set_attributes 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 clear context for why you'd pick this tool ('the fastest way to make a new weapon/troop/hero/culture based on an existing one'), which implies when it beats authoring from scratch. It never names an explicit alternative or an exclusion, 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 this is a write (readOnlyHint=false) but non-destructive. The description adds real value beyond that: the concrete file layout it generates, that dependencies default to the installed official modules, and the default target folder. It does not state behavior when a folder already exists (overwrite vs. error), which is a notable 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?

Three dense but well-front-loaded sentences; the primary action and default location lead, and each clause carries concrete technical detail without filler.

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

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

With no output schema and a mutation tool, the description is nearly sufficient: it explains what is created and where. Missing only the return value and the collision/overwrite behavior, which an agent would want before invoking 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 100%, so all seven parameters are already documented, setting the baseline at 3. The description adds some meaning for with_csharp by describing the generated csproj/SubModule.cs and bin output, but does not clarify the dependencies syntax or other parameters beyond the schema.

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

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

States a specific verb ('Scaffolds') and resource ('a new module folder') and enumerates exactly what is produced: SubModule.xml with dependencies, ModuleData/, and an optional C# project. This clearly separates it from read-only siblings like module_info or list_modules.

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 name and the scaffolding detail, but there is no explicit when-to-use, no prerequisites (e.g. game install path requirement), and no routing to alternatives such as clone_object for duplicating an existing module. Adequate but gaps remain.

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 readOnlyHint=false, so the safety profile is covered. The description adds genuinely useful behavioral detail beyond that: deletion applies to ALL definitions of the given id, not just one, and is confined to module XML. It stops short of stating reversibility or not-found 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?

A single front-loaded sentence with no filler. The verb, resource, and the critical 'all definitions of that id' qualifier all land immediately.

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

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

For a two-parameter destructive tool with no output schema, the description plus annotations cover what an agent needs: what is removed, from where, and how broadly. Minor gaps (failure mode when the id is absent, whether an undo path exists) remain but are not blocking.

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 both params are documented inline (ref accepts 'Item.x' or bare id; module is a writable module id), so the schema carries the load. The description's phrase 'writable module' reinforces the module param but adds no new syntax or format detail.

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 — 'Removes an object definition' — and scopes it to 'a writable module's XML', which is more precise than the title. It does not, however, name or distinguish itself from nearest siblings like write_object, edit_submodule, or undo_edit.

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

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

Usage is implied rather than stated: 'writable module's XML' hints the module must be editable, but there is no explicit when-to-use guidance, no mention of the undo_edit alternative, and no note on what to do if the id is not found.

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 cover the safety profile (readOnlyHint=true, openWorldHint=false). The description adds valuable provenance context beyond that: data comes from XSD files plus real values observed in official data, which tells the agent how authoritative the results are.

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, then efficiently maps each argument mode in terse fragments. It is compact and each sentence carries weight, though the signature-style fragments are slightly harder to parse than 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?

With no output schema, the description carries the burden of explaining returns, and it does so for each invocation mode. For a read-only introspection tool this is complete enough for an agent 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 already 100%, yet the description still adds behavior mapping the schema alone cannot convey: no args lists XmlName ids, xml_id only returns root/object elements, element (+path) returns attributes with types/enums and children. This binds parameter combinations to concrete output behavior.

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: it explains which elements/attributes are valid, sourced from the game's XSD files plus observed official data. This distinguishes it from sibling validators and writers (e.g., validate_module, write_object) by framing it as a pre-write inspection tool.

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

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

Explicitly says 'Use before writing XML', which gives a clear when-to-use context. It further documents three usage modes keyed to which params are supplied, though it never names alternative siblings to prefer over this one.

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 and openWorldHint=false, so safety is covered. The description adds two genuine behavioral facts beyond the annotations: every write is journaled with a backup, and results are returned newest first. It still omits pagination behavior and the default cap's effect on truncation.

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 sentence, no filler, with the core operation front-loaded and the ordering guarantee appended where it belongs. Every clause earns its place.

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

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

For a zero-required-parameter read tool with full schema coverage and no output schema, the description covers what the tool returns at a conceptual level and adds a provenance detail. It could say more about result volume and pagination, which is the only remaining 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% with both parameters documented (limit default 20, module filter). The description adds no syntax, format, or filtering semantics beyond what the schema already carries, so the baseline of 3 applies.

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

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

States a specific verb+resource: lists recent changes made through this MCP server, with entries ordered newest first. It is clearly distinguishable from read_logs or undo_edit in intent, though it never explicitly contrasts itself with those 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 gives no when-to-use guidance and no exclusions. An agent wanting to review or reverse a change cannot tell from this text whether to call edit_history, read_logs, undo_edit, or forget_history.

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 readOnlyHint=false, so the safety profile is covered structurally. The description adds real prerequisites (installed game, Windows .NET compiler, recompile after updates) but never says what the destructive action overwrites or whether an existing bridge is replaced without confirmation. Useful additions, but the mutation semantics remain thin.

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 action and install location, with no filler. The parenthetical about scene_* live tools is dense but earns its place by linking the bridge to sibling tools.

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 installer with one optional boolean parameter, no output schema, and annotations covering safety, the description supplies the important missing context: the required toolchain, the install target, and the update re-run rule. Failure modes and whether a restart is needed are not covered, keeping it below 5.

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

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

Schema description coverage is 100% and the single 'force' parameter is fully documented in the schema. The description adds no meaning beyond it, so the baseline 3 for a fully-covered schema applies.

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

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

The description states a specific verb (compiles ... and installs) plus the exact artifact and install path (Modules/MB2MCP.EditorBridge), and names what the module enables. This is clearly distinguishable from every sibling, none of which install a bridge.

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 a clear trigger ('Re-run after game updates') and explains the enabling condition for the live tools, which is context an agent needs. It stops short of stating when not to run it (e.g. if the editor is running or the bridge is already current), so not 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?

Annotations already declare readOnlyHint=false and destructiveHint=true; the description is consistent with these and adds real context: 'set' preserves direction, 'get' works in play mode and returns pitch/heading, and the engine has no live-camera turn call. It does not explain the destructive framing, but the behavioral picture is otherwise well covered.

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 resource and prerequisite, then expands each action tersely. The final sentence about the missing turn capability is dense but earns its place by preventing a wrong tool choice; overall efficient though a single dense block.

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 multi-action tool with no output schema, the description covers return values for 'get', the bridge prerequisite, direction-preservation semantics, and alternatives for the unsupported turn operation. An agent has everything needed to select and call it correctly.

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

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

Schema coverage is 100%, so the per-parameter descriptions carry the baseline (3). The description adds value beyond the schema by clarifying 'set' keeps direction and by describing the 'get' return content (position, view direction, pitch, heading) that the schema itself 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 the specific resource (live viewport camera) and the three verbs (get/set/move) it supports. It explicitly differentiates itself from scene_edit action=focus and scene_settings editor_camera, so an agent can distinguish it from siblings without opening a schema.

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

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

Names the prerequisite ('needs the bridge'), explains what each action does, and routes the agent to alternatives with the condition that selects them (turning the camera is impossible, so use scene_edit action=focus or scene_settings editor_camera). Nothing 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?

Adds substantial behavior beyond the annotations: quit loses unsaved changes, cleanup deletes the server's screenshots/traces/logs, dialogs without a matching button are left open, fill_dialog 'never presses a button', and engine-source screenshots go black while the scene editor is in front. One caveat: destructiveHint=false is arguably loose given quit and cleanup, though both are explicitly gated (confirm=true) and warned about, so I do not treat it as a hard 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?

Nearly every clause maps to a distinct action, so the word count is largely earned for a 16-action dispatcher. The structure is poor, though: one dense run-on paragraph with nested parentheses instead of a scannable list, and the cleanup sentence is tacked on at the very end after the 'with the bridge' group.

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 structured param help beyond the schema, and 17 parameters, the description carries a lot and does it reasonably well, including light return-value notes ('returns the image', 'read everything back'). It stops short of describing failure modes, bridge-install prerequisites, or how errors/partial results are surfaced.

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

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

Schema description coverage is 100% and every parameter's description already names the action it belongs to ('raycast: end point', 'prefix: list_commands', 'confirm: quit'). The description adds the cross-action rule that editor/file dialogs only answer to a named `button`, but otherwise restates what the schema carries, 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?

The opening clause names the resource (the running Modding Kit editor) and the description enumerates every one of the 16 actions with a concrete gloss (console runs a command, raycast returns a hit point, perf samples frame times). An agent can tell what each action does. It does not, however, position itself against siblings such as editor_status, editor_play or read_logs, so sibling routing is left to inference.

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

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

Prerequisites and conditions are stated explicitly: 'needs the bridge' for live actions, and a clean split of which actions work without the bridge (screenshot, dialogs, dismiss_dialogs, fill_dialog) versus only with it (perf). It even routes one case away to another tool: 'new files need the Resource Browser's Import new asset'. Missing is explicit when-to-use guidance versus the sibling editor_* 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?

Annotations only mark it as non-read-only and non-destructive; the description goes far beyond that, disclosing the 1-5 minute load time, every message box that gets auto-dismissed, and the reassuring fact that no files are collected/uploaded and no settings are changed. This is exactly the side-effect detail an agent needs before triggering a long, window-driving launch.

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 and the long sentence is dense with non-redundant operational detail. It loses a point because the enumerations of which prompt gets which answer largely restate the dismiss_module_warnings schema text, making the description longer than strictly necessary.

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 six optional parameters, the description supplies the timing, the polling target, and the automation side effects an agent needs. Minor gaps remain around failure/timeout handling, but nothing essential for a 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 schema already documents all six parameters including the prompt-handling behavior of dismiss_module_warnings. The description adds only marginal value (e.g., the editor opens with an empty scene), 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 concrete verb and resource ('Starts the Modding Kit build .../Bannerlord.exe') with the exact module set it loads, which cleanly separates it from siblings like editor_play, editor_bridge_install, and editor_status. An agent can identify the action 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 the operational workflow explicitly: launch, then 'poll editor_status until it reports edit mode ON', and notes when open_editor takes effect. It does not state when NOT to use this versus editor_play or a bridge install, so it stops short of full alternative 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?

Annotations only declare readOnlyHint=false and destructiveHint=true; the description adds substantial context beyond that: the bridge requirement, that it loads the SAVED file rather than live edits, the save-refusal condition, spawn point fallbacks, blocking wait behavior, and the exact semantics of stop mirroring the leave key. Nothing here contradicts the destructive/read-write 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?

Purpose is front-loaded in the first clause and every subsequent sentence carries operational information (save requirement, restrictions, alternatives). It is dense and somewhat run-on, but there is little that could be cut without losing behavioral detail.

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

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

With no output schema and six optional parameters, the description covers what an agent needs: prerequisite (bridge), save-state gate, per-action semantics, waiting behavior, and which sibling tools to use during play mode. Nothing required 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 baseline is 3, but the description adds real meaning: it clarifies the saved-file constraint that motivates allow_unsaved, explains that start/stop block until the player is spawned or the editor returns (wait_seconds), and notes the scene override keeps the editor's own scene. It does not, however, restate the levels/mission enum details.

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 (play mode of the Modding Kit editor) and then spells out each action's effect: start plays the open scene, stop returns to the editor, status/missions report. An agent can distinguish this from editor_status, editor_launch, and scene_edit 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 explicit when-to-use ('start plays the open scene... the same managed entry the editor's Play button reaches'), a prerequisite ('save first; start refuses when changes through this server are newer than the file'), and explicit when-not/alternatives ('while playing, live scene_* commands are refused... use mission, navmesh_query and editor_command screenshot').

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 readOnlyHint=true and openWorldHint=false, so the safety profile is already covered. The description adds meaningful context the annotations do not: that it reports on blocking message boxes like 'RGL WARNING' and 'Safe Mode', and that some results (editor state, scene, counts) are conditional on the bridge being connected. That conditional behavior is exactly the kind of trait structured fields 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?

A single long sentence, but it is front-loaded with the primary purpose ('whether the Modding Kit is installed') and then expands through a readable checklist. No filler sentences. The em-dash parenthetical for the bridge-connected case is efficient. Slightly dense list-form, but every clause earns its place.

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

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

For a zero-param, no-output-schema read tool, the description covers the full surface an agent needs: what is checked, the conditional nature of the editor-state fields, and the blocking message-box concept. What is missing is a hint about return shape (structured vs. free text) and whether it is safe to call repeatedly, but annotations already signal it is a read operation.

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 zero parameters, the baseline is 4 per the rubric. There is nothing to document, and the description correctly omits any parameter narrative rather than inventing one.

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 read operation with a clearly enumerated set of outputs: installation status, bridge module currency, running processes, blocking message boxes, and editor state. This is distinguishable from siblings like editor_bridge_install or editor_command, which are mutations. The verb 'Shows' plus the exhaustive field list leaves no ambiguity about what the tool returns.

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

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

The description implies this is a diagnostic/status-read tool but never explicitly says when to call it versus alternatives, nor does it name a sibling. There is no 'use this before X' or 'if you need Y, use Z instead' guidance. For a zero-param status tool this is tolerable, but stronger routing would mention editor_bridge_install as the follow-up when the bridge is absent or stale.

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 flag destructiveHint=true/readOnlyHint=false, so the safety profile is covered. The description adds real behavior beyond that: edits happen in place, XML formatting is preserved, and only writable modules are eligible. It still omits reversibility/undo and failure behavior, but it earns credit for the formatting-preservation 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?

A single front-loaded sentence that leads with verb and resource, then lists capabilities without filler. Slightly dense with the trailing enumeration but nothing 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 an 11-parameter destructive mutation with no output schema, the description covers the operation surface and the key precondition (writable module) while annotations carry the safety signal. It stops short of explaining side effects of removal operations or validation behavior, so it is good but not fully complete.

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

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

Schema description coverage is 100% and every parameter, including nested add_dll and register_xmls fields, has its own schema description. The description names the same fields (name/version/url/category) the schema already documents, so it adds little syntax or format meaning beyond the baseline.

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

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

States a specific verb (Edits) and resource (SubModule.xml in place) and enumerates the concrete operations: name/version/url/category, dependencies, XML registration, DLL entries. An agent can tell it operates on module manifests, though it never explicitly distinguishes itself from siblings like write_object, set_attributes, or create_module.

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

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

Usage is only implied: use this to modify an existing writable module's SubModule.xml. The 'writable module' constraint hints at a precondition, but there is no statement of when to prefer this over write_object/set_attributes, nor any when-not guidance or prerequisite detail.

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 and openWorldHint=false, so the safety profile is covered by structured data. The description adds useful semantic context about what kind of results come back (referencing objects of various types), but it says nothing about result grouping, truncation, or how the module filter narrows output. Given the annotations carry the safety burden, this is 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 tight sentences with zero filler; the core definition is front-loaded and the input-format note is appended where it is needed. Every clause 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, the description must convey what comes back, and the examples do that well for a read-only query tool. The gap is the module parameter's filtering semantics ('official, mods…'), which is left entirely to the schema, but 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 description coverage is 100%, so all three parameters (ref, limit, module) are already documented in the schema, including the 'Prefix.id or bare id' format restated in the description. The description adds no 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 and resource ('Lists objects that reference a given object') and immediately disambiguates the direction of the lookup with three concrete examples (troops carrying Item.x, troops upgrading into NPCCharacter.y, settlements in Faction.z). These examples let an agent distinguish this reverse-lookup tool from forward-lookup siblings like get_object or search_objects 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?

The examples imply when the tool is appropriate (you already know the target object and want its referrers), but there is no explicit when-to-use/when-not guidance and no sibling is named as the alternative for forward lookups. Usage must be inferred from the examples 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?

Annotations already declare destructiveHint=true, so the bar is lower, yet the description adds substantial context: exactly what is destroyed (the edit journal plus the backup files undo_edit relies on), where they live (MB2_DATA_DIR), that the loss is irreversible, and that confirmation is mandatory. It also clarifies that screenshots/traces in the bridge folder are not covered here.

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 and its scope, then consequences, then the confirm gate, with the cleanup cross-reference placed last where it doesn't interfere. Dense but every clause carries weight; the stacked parenthetical paths make it slightly harder to scan than it needs to be.

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

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

For a destructive tool with full annotation coverage, a fully documented 2-parameter schema, and no output schema, nothing an agent needs is missing: target, scope, irreversibility, confirmation requirement, and where the related-but-unhandled artifacts are cleaned up.

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 already documented, and the description largely restates them ('Needs confirm=true', 'default: all'). It adds the consequence framing for confirm, but no syntax or edge-case detail 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 and resource ('Deletes this server's edit journal and the file backups it keeps for undo_edit'), scopes it ('all of it, or only edits older than older_than_days'), and ties it to the sibling undo_edit it feeds. An agent can distinguish it from edit_history and undo_edit 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?

Gives clear context: this is the irreversible cleanup path ('Forgotten edits can no longer be undone') and requires confirm=true, while routing the adjacent-but-different cleanup (screenshots/traces) to editor_command action=cleanup. It never states the explicit alternative 'use undo_edit instead if you want to revert', so it stops short of full when-not guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral value by enumerating what gets surfaced (install detection, writable module folders, launcher-enabled mods, index/validation status, recommended workflow), which tells the agent what to expect from the response.

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 with the imperative 'Start here.' front-loaded. The second sentence is a dense enumeration, but each listed item conveys distinct diagnostic value rather than 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 carries the burden of describing returns and does so comprehensively, listing every category of environment data the agent will receive. For a zero-parameter overview tool this is complete.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. The baseline of 4 applies for a no-argument tool.

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 (shows) and a well-defined resource (the detected install, version, module folders, writability, enabled mods, validation status, recommended workflow). The 'Start here' framing plus this enumerated scope lets an agent distinguish it from narrower siblings like module_info, list_modules, or editor_status.

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 'Start here' opener gives clear entry-point guidance, implying this should be called before other tools. It does not name explicit alternatives or when-not-to-use conditions, but for an orientation tool the context is unambiguous.

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

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

Annotations declare readOnlyHint=true, so the safety profile is covered; the description then adds real behavioral value by disclosing what the result contains: load-order winner, other definitions, XSLT patches, and the absolute file path. This goes beyond 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?

A single front-loaded sentence that states the return value first, then illustrates with examples and enumerates result contents. Dense but 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?

With no output schema, the description compensates by explaining what the response shows (effective definition, other definitions, patches, file path). Combined with readOnly annotations, this is nearly complete for an inspection tool.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema. The description reinforces the ref format with examples but adds little beyond what the schema already states.

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 ('Returns the XML') and resource ('a game object') with concrete ref examples, clearly distinguishing it as a read tool. It doesn't explicitly name a sibling like write_object, but the read-only nature is unambiguous.

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

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

Usage is implied by the purpose (inspect an object's definition), but the description gives no explicit when-to-use guidance, prerequisites, or alternatives such as search_objects when the ref is unknown.

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 readOnlyHint=false and destructiveHint=true, and the description corroborates by disclosing that the fix flags rewrite the module's XML with fresh unique ids — concrete detail beyond the annotation about what is mutated. It stops short of stating reversibility or whether a scan alone (no fix flags) is purely read-only.

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

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

Three sentences, all informative and front-loaded with the scan scope before the reporting categories and the mutation behavior. The second sentence is a dense list but every item 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, the description usefully summarizes the report contents (missing/empty/reused/colliding ids plus per-language coverage) and the mutation side effects, which is enough for an agent to call it correctly. Permission or rate-limit prerequisites are absent but are marginal here.

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 structured fields already document all five parameters; the description still adds value by tying code_dir to the Source/ fallback and by characterizing the fix flags as XML rewrites with fresh unique ids rather than just boolean toggles.

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 (scans a module's XML, GUI prefabs and C# code for {=id}Text strings) and enumerates exactly what problems it reports, so an agent knows the scope well. It does not explicitly distinguish itself from the nearby l10n_status / l10n_set siblings, which 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?

The closing sentence explains what fix_missing_ids / fix_conflicts do, implying when those flags apply, but there is no explicit when-to-use guidance or comparison to l10n_status / l10n_set, so the agent must infer the routing.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the bar is lower, yet the description still adds real context: files are created when missing (language_data.xml, <module>_strings.xml), existing ids are updated in place, and a warning fires on placeholder mismatch. It does not mention that the `remove` parameter deletes ids, which is the most destructive behavior here.

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 and front-loaded: the primary action and target location come first, with file-creation and update semantics packed into one parenthetical. No filler sentences, though the parenthetical is heavy enough to slow a quick read.

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

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

With annotations covering the safety profile and no output schema to explain, the description is nearly sufficient: it covers target files, creation, in-place updates, and placeholder validation. The gap is the deletion semantics of `remove` and any indication of return/confirmation 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 description coverage is 100%, so the schema already documents all seven parameters, making 3 the baseline. The description adds only indirect parameter context (placeholder validation tied to `translations`), with no elaboration on `remove`, `file` defaults, or id handling beyond the schema.

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

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

States a specific verb (writes), a specific resource (translations for one language), and a precise scope (the module's ModuleData/Languages/<folder>/ files). The write semantics clearly distinguish it from read-oriented siblings like l10n_scan and l10n_status.

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 conveys the operation but gives no explicit when-to-use, when-not, or named alternative (e.g. l10n_scan for reading, l10n_status for checking coverage). Usage is inferable from the verb and resource, but nothing routes the agent decisively.

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 declaring safety, the description still adds real behavioral context: stale means translations whose id no longer exists, and strings already translated by the game or other modules (matching id and text) are silently skipped. That skip rule is essential to interpreting results and is not in the 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?

Two dense sentences, front-loaded with the action and output format, then the filtering/skip semantics and the next-step handoff. The inline {id, text[, tr]} notation is compact and earns its space, though it reads slightly telegraphically.

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 return-value burden, and it does describe the JSON-lines record shape and skip behavior. Combined with 100% parameter coverage and readOnly annotations, an agent has nearly everything needed; only pagination behavior (limit/offset) is 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 100%, so baseline is 3, but the description adds meaning beyond the schema: it defines the default filter (untranslated) and clarifies the non-obvious 'stale' enum value as translations with vanished ids. This enriches the most ambiguous parameter rather than 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 (Lists) and resource (a module's strings for one language) and pins down the exact output shape as JSON lines of {id, text[, tr]}. It also names the counterpart tool (l10n_set) that consumes the results, so an agent can place it in the workflow 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 description explains the filter modes (untranslated default, translated, all, stale) and gives a clear workflow: list, translate, send to l10n_set. It does not explicitly state when to prefer this over l10n_scan, so it stops short of full alternative 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful context by disclosing the sources scanned (official, Steam Workshop, user's own) and exactly which fields come back (id, version, flags, folder), which the annotations do not 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?

Two dense sentences, front-loaded with the verb and scope, then the return fields, then filter values. No filler; 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?

With no output schema, the description usefully enumerates the returned fields and sources, and the two optional params are fully covered by the schema. It is nearly complete, though it could clarify the difference between the 'mods' and 'writable' filter buckets and note whether results are ever paginated.

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 both parameters are already documented, including the enum values and default. The description merely restates the filter options and adds no syntax or format meaning beyond the schema; baseline 3 is correct.

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 ('Lists') and resource ('installed modules'), enumerates the module sources and the fields returned (id, version, flags, folder). It is unambiguous on its own, though it never names or differentiates itself from the sibling module_info.

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

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

Usage is only implied: the 'filter: all | official | mods | writable | workshop | enabled' list suggests how to narrow results, but there is no explicit when-to-use, no when-not-to-use, and no pointer to alternatives such as module_info for single-module details.

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 and openWorldHint=false, so the safety profile is covered. The description adds what the output contains (object tags and counts per module), but it does not disclose permissions, rate limits, or any other behavioral constraint beyond the summary shape.

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

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

Two sentences with zero filler: the first front-loads the purpose and examples, the second states the usage condition. Every phrase earns its place.

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

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

For a simple, read-only listing tool with full schema coverage and no output schema, the description explains the return shape (tags and counts per module) and the intended use. It omits any direct mention of the module parameter, but the schema covers that completely, so the gap is minor.

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

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

Schema description coverage is 100%, and the schema already explains the optional module filter in detail (id, comma list, or official | mods | writable | workshop). The description only indirectly references modules via 'counts per module' and adds no syntax or format details beyond the schema, so the baseline of 3 applies.

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

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

The description gives a specific verb (Summarizes) and resource (game data by XmlName id), plus concrete examples (Items, NPCCharacters, etc.) and the output shape (object tags and counts per module). It does not name a sibling tool explicitly, so it falls short of the top score, but an agent can still tell it apart from list_modules and search_objects from context.

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

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

It states a clear use case: 'Use it to learn what exists before searching.' That implies search_objects is the alternative, but no sibling is named and there are no explicit when-not conditions or prerequisites, so it is clear context without exclusions.

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

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

Annotations declare destructiveHint=true and readOnlyHint=false, so the agent already knows this mutates state. The description adds valuable behavior for walk (per-leg reached/stuck/timed out, closest approach, JSON trace location) and that teleport is cosmetic. However it never explains what the destructive actions change or need (dismount/use/stop_using side effects, bridge/auth requirements), leaving the destructive profile under-described.

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 run-on sentence with stacked parentheses covering nine actions is hard to parse and not front-loaded by action. The content is dense rather than padded, but the structure works against quick scanning.

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 16 parameters, the description compensates by describing what status returns (position, direction, mission state), what objects returns (usable objects and whether usable), and what walk produces. Coverage of the secondary actions is thinner, but the core workflows are adequately explained.

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% across 16 parameters, so the schema already defines every field including defaults. The description adds only high-level semantics (walk vs teleport, walk reports) rather than per-parameter meaning. Baseline 3 is appropriate when the schema carries the parameter burden.

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 tool role (acting inside the running mission) and enumerates each action with its effect: status, objects, walk, teleport, use, dismount, etc. It distinguishes itself from siblings by requiring play mode (editor_play) or another running mission via the bridge. The laundry-list form makes it verbose but the verbs and resources are concrete.

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

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

It states the operating precondition ('In play mode (editor_play) or another running mission (needs the bridge)') and draws a meaningful discrimination between walk and teleport: walk is 'evidence that a route can be walked', teleport is 'positioning before a test ... not evidence of a walkable route'. No explicit exclusions or when-not guidance beyond that.

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 and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavioral detail beyond that: it discloses that dependency versions are resolved/installed, that Xmls entries come with resolved files and object counts, and that unregistered files and language files are included — which tells the agent this is an aggregating inspection call, not a raw file dump.

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 that front-loads the core purpose ('Details of one module') and then lists contents. Nothing is wasted, though the long comma-separated enumeration is slightly harder to scan than a short lead sentence plus a bulleted scope list would be.

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

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

With no output schema, the description carries the burden of describing return values, and it does so thoroughly across every section the agent will receive. It is nearly complete; the only gap is error behavior for an unknown module id and any note on output size for large mods.

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

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

Schema coverage is 100% and the single 'module' parameter is already documented with examples (MyMod, Native, SandBoxCore). The description adds nothing about the parameter itself, 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 resource (one module) and enumerates exactly what the tool surfaces — SubModule.xml fields, dependencies, DLL entries, Xmls registrations, XSLT patches, unregistered/language files. It is clearly distinct from list_modules (singular vs plural) and from edit_submodule, but it never names those siblings to sharpen 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?

There is no explicit when-to-use guidance, no statement of prerequisites (e.g. a valid installed module id), and no routing to alternatives such as list_modules for enumeration or game_info for broader game context. Usage is only implied by the singular 'one module'.

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 and openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond that: the bridge prerequisite for mission queries and a detailed enumeration of what each action returns. No output schema exists, so this return-value disclosure carries real weight.

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 a single dense, run-on sentence but front-loads the core idea (read-only queries using the engine's own pathfinding) before the action list. Nearly every clause earns its place; only the length makes it slightly heavy.

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, read-only tool with no output schema, the description covers the modes, their outputs, and the bridge prerequisite. It leaves minor gaps such as return format or coordinate conventions, but nothing essential to 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 schema already documents all six parameters. The description still adds value by mapping parameters to actions (at uses position, path/line use from/to/radius, group uses id), which the raw schema does not group this way.

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 (query) and resource (navigation mesh) and enumerates the five query modes with their exact return fields. It clearly distinguishes itself from the mission tool by pointing to 'mission action=walk' for real-agent route proof.

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 context: queries run on the editor scene or the running mission (needs the bridge), and routes the agent to 'mission action=walk' to prove a route with a real agent. It lacks explicit when-not conditions, but the alternative and its selection criterion 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?

Annotations already declare destructiveHint=true and readOnlyHint=false. The description goes beyond them by disclosing that the entity position is reset to the origin, the destination file, and that the editor only picks up new prefabs at startup (a restart is required) — genuinely useful operational context.

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

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

Two tight sentences with the primary action and destination front-loaded, followed by the source-mode detail and the startup caveat. Dense with useful detail rather than padded.

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

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

For a destructive create tool with full annotation coverage and no output schema, the description supplies the destination path, dual input modes, and the restart requirement. Minor gaps remain around error handling and how overwrite interacts with an existing prefab.

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 relational meaning the flat schema lacks: that from_scene and entity are used together as a pair and that position resets unless keep_position is set, clarifying how the source-mode parameters combine.

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?

Uses a specific verb (Saves) and resource (prefab) and names the exact output file path and the two source modes (scene entity or game_entity XML). The purpose is unambiguous, though it never explicitly contrasts itself with the sibling prefab_search.

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 two source modes (from_scene + entity vs. xml) imply when each input applies, and the startup-load note hints at the workflow context, but there is no explicit when-to-use/when-not guidance or reference to any alternative 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 already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: name=<exact> changes the result shape by returning the prefab's full XML, and it clarifies the underlying file scope. It does not mention pagination behavior, though limit/offset are schema-documented.

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

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

Two tight sentences with no filler: the search scope and fields come first, then the special exact-name behavior, then the integration hint. Every clause 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, the description still conveys the key return-value nuance (full XML on exact name match) and the intended consumer (scene_edit). It omits what non-exact result rows contain, but with all 8 parameters fully described in schema and read-only annotations present, an agent has enough 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 description coverage is 100%, so every parameter is already documented, which sets the baseline at 3. The description adds only the exact-vs-substring distinction between name and query, which the schema already conveys via 'Exact prefab name to show in full', so net added meaning is marginal.

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 (Searches) and resource (prefab definitions) plus the exact searchable fields (name, mesh, script, tag) and where the data lives (Modules/*/Prefabs/*.xml). This cleanly separates it from prefab_create, asset_search and search_objects, so an agent can pick it 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 a concrete downstream workflow: 'Use the names with scene_edit action=add prefab=…', which tells the agent why and when to call this. It does not explicitly exclude the overlapping siblings (asset_search, search_objects), so it stops short of full when/when-not guidance.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds real context by naming the log locations (ProgramData/Documents), the file families, and default behaviors (tail of latest log, grep filtering). It does not cover output format or size limits, but the behavioral additions are solid.

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

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

A dense but well-ordered single passage: purpose first, then actions, with no padding sentences. Slightly long, but every clause carries information about files or actions.

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 six optional parameters, the description adequately conveys what the tool reads and how actions map to behavior. It lacks any note on result format, but for a read-only log tool it 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?

Schema coverage is 100%, so the schema carries the per-parameter detail and baseline would be 3. The description raises this by describing how parameters combine - read returning the tail or grep/errors_only matches - which is interaction 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 (Reads) and resource (Bannerlord's logs) and immediately names the goal (debug a mod), then enumerates the concrete file families involved. This is clearly distinguishable from data-oriented siblings like module_info or game_info.

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

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

Explicitly differentiates action=list (recent files) from action=read (default, tail of latest log or grep/errors matches), giving the agent a clear selection rule. It stops short of stating when to prefer this over other diagnostic tools, so it misses the top tier.

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 say it is a non-destructive, non-openWorld write), the description discloses concrete side effects: terrain/navmesh files are copied, and the name and unique token are renewed. It also specifies the contents of the empty-scene variant (envmap probe + ground plane, terrain off). This is useful behavioral context the annotations do not 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?

A single dense sentence with the output path and primary behavior front-loaded, followed by the two modes in parentheses. Every clause carries information, though the parenthetical structure is dense enough to require careful parsing.

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

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

For a 3-parameter write tool with no output schema but full annotation coverage, the description covers what gets created, where, and how the template parameter changes the result. It stops short of stating what is returned or whether the writable-module requirement is validated, but there is no major gap for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: 'template=…, any module' clarifies the template may come from a different module than the target, and 'Omit for an empty scene' reinforces the optional parameter's branching behavior.

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

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

States a specific verb ('Creates') and the exact artifact produced ('SceneObj/<name>/ in a writable module'), plus the two distinct creation modes. The level of detail (directory layout, file copying, token renewal) makes it clearly distinguishable from scene_edit or clone_object 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?

The description tells the agent how to choose between the two modes: supply template=… to copy an existing scene, or omit it for a minimal empty scene. It gives clear context for when each path applies but names no explicit exclusions or alternative tools (e.g. clone_object).

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 cover safety (destructive=true, not read-only), but the description adds real behavior the annotations cannot: file edits preserve formatting and are undoable, live edits are not persisted until Ctrl+S, live handle targets are only valid until the scene is reopened, and Siege spawner names are protected/refused. This is exactly the value-add the higher bar looks for.

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?

For 30 parameters and two modes this is tightly compressed, front-loaded with the action list and the file/live split before the per-action detail. The semicolon-chained sentences are dense but every clause carries operational meaning.

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

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

Given dual-mode complexity, 30 params and no output schema, the description covers mode semantics, target identity (handles/names/#ids), naming protection and the live save workflow. It omits what the tool returns (e.g. handles of newly added entities) and whether undo applies to live as well as file mode, which for a destructive multi-action tool would have closed the loop.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes beyond it by mapping parameters to actions (add: prefab/mesh/xml/count+offset; update: position/move_by, rotation/rotate_by, scale, name, tags, attributes, script+variables, levels; live-only: select, focus, snap_to_ground) and clarifying relative vs absolute and units. It largely restates schema text (degrees unless rotation_unit=rad), so it lands just above baseline.

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

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

The description opens with a specific set of verbs (adds, updates, deletes, duplicates) applied to a concrete resource (scene entities), then immediately splits the tool into its two operating modes (file vs live editor bridge). An agent can distinguish this from read-only siblings like scene_entities or scene_info 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?

It gives an explicit routing rule for the biggest decision — file mode edits scene.xscene of a writable module while live=true edits the scene open in the editor (then save with Ctrl+S) — and cross-references helpers (scene_entities for live #handles, prefab_search, asset_search kind=mesh, scene_settings add_levels). It stops short of stating when *not* to use it (e.g. vs editor_command or delete_object).

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 declaring safety, the description still adds real value: handle syntax ([12], [12/0] for children), rotation expressed in degrees, the XML return for entity=, and the live-mode session-id semantics. It doesn't cover paging/limit behavior in prose (deferred to schema), but the output-shape disclosure is strong for a tool with no output 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?

Three dense sentences, front-loaded with the core purpose and return columns, then the single-entity path, then live mode. No filler; every clause carries information an agent needs.

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

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

For a 15-param read tool with no output schema and no enums, the description supplies the return-column list, mode semantics (file vs live), and the entity= drill-down path, fully compensating for the missing output schema.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: rotation is in degrees, handle vs name formats, and the composite filtering surface (name/prefab/tag/script/mesh or distance). These clarify parameter intent rather than merely restating field names.

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

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

States a specific verb ('Lists') and resource ('entities of a scene file') and enumerates the returned columns (handles, name, prefab, mesh, position, etc.). An agent can distinguish this from scene_info (scene metadata) and scene_edit (mutation) without opening a schema.

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

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

Gives clear conditional guidance: entity=<handle|name> to get one entity's XML, live=true to query the editor's open scene, and notes the #handle linkage to scene_edit live=true. It stops short of explicitly stating when to prefer this over scene_info or when not to use it, so it's clear context rather than full 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?

Annotations declare readOnlyHint=true and openWorldHint=false, so safety is covered, and the description still adds real context: live=true depends on the Modding Kit editor bridge being available, and checks flag unknown prefabs/meshes/physics shapes plus XML errors. It doesn't disclose output format, but as a read-only tool that gap is modest.

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 resource and its contents; the live/editor caveat comes last where it belongs. The first sentence is a long comma-delimited enumeration, but every listed item is informative given there is no output 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?

With no output schema, the description usefully compensates by enumerating what is reported, and all four parameters are documented. It is nearly complete for a read-only overview tool; only the live-vs-file behavioral difference in returned data could be spelled out further.

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 3 is the baseline, but the description adds meaning the schema doesn't: live=true reports the currently open editor scene rather than a named file, and 'checks' is expanded into the concrete problems it detects. The dependency note ('needs the editor bridge') is genuinely additive parameter context.

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

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

States a specific resource (scene file) and enumerates exactly what the overview contains: header, environment/atmosphere, terrain, statistics, spawn points, bounding box, references, and checks. This distinguishes it cleanly from siblings like scene_list, scene_entities, and scene_settings, which target narrower slices of scene data.

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

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

Frames the tool as an overview/first-look and gives a clear conditional for the live variant (use live=true for the scene open in the editor, needs bridge). It does not explicitly name alternatives such as scene_settings or scene_entities or state when-not to use it, so it stops short of 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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that terrain/navmesh presence is reported and the file layout it inspects, which is useful context, but it says nothing about ordering, truncation behavior at the default 100-row limit, or cost on large module sets.

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 that front-loads the operation, then the path convention, then the returned fields. Nothing is padded and nothing needs re-reading.

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

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

With no output schema, the description compensates by naming the fields returned (size, date, terrain/navmesh presence), which is exactly the information an agent would otherwise lack. Combined with annotations covering read-only semantics, it is close to sufficient; only ordering/pagination behavior is unstated.

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 limit, query and module (including the official|mods|writable filter). The description only echoes module selection at a high level and adds no syntax, default, or semantics beyond what the schema provides; 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 and resource ('Lists scenes') and even names the storage layout (SceneObj/<name>/scene.xscene) plus the columns returned (size, date, terrain/navmesh presence). That scope ('all or selected modules') implicitly separates it from the single-scene sibling scene_info, though no sibling is named 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 'of all or selected modules' implies when to reach for it (broad enumeration across modules) versus a single-scene lookup, but there is no explicit when-to-use, when-not-to-use, or named alternative such as scene_info. Usage 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 already declare readOnlyHint=false and destructiveHint=true, so the agent knows this is a mutating, potentially destructive tool. The description adds useful context in disclosing the dual read/write behavior and the full scope of what it touches, but it does not explain reversibility or what removal actually destroys beyond what the schema already states ('refused while entities still use them').

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

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

The description is a single sprawling sentence dense with parentheticals and ellipses. It is front-loaded with the read/change verb, but the packed example lists make it harder to parse than a structured multi-sentence form would be.

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

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

For an 8-parameter destructive tool with nested objects and no output schema, the description covers the scope of every resource it manages and notes the read-vs-write behavior. The remaining gap is the lack of any routing versus the overlapping editor_camera and scene_edit siblings, but nothing essential to invoking it 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?

With 100% schema description coverage the baseline is 3, but the description earns extra credit by giving concrete value-name examples for the atmosphere (time_of_day, color_grade_name, fog_density, sun_altitude) and environment (atmosphere_name, is_indoors, water_level) objects, clarifying what the otherwise opaque name→value maps should contain.

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 clear verb pair (reads or changes) and enumerates the specific resources involved: environment_properties, atmosphere.xml values, level definitions, and the editor camera in editor_data. It partially distinguishes itself from siblings by noting that entities join levels via scene_edit, but it is a bundled tool covering several resources at once, which blurs a single crisp purpose.

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

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

'Without changes it lists the current values' implies the read mode, and the scene_edit reference hints at the level workflow. However, there is no explicit when-to-use guidance against the sibling tools editor_camera or scene_edit, which overlap directly with portions of this tool. Usage 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: it searches across every module, supports Chinese (简体中文) name matching, and specifies the exact return line format, which is valuable given no output schema exists.

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 no filler; the scope and matching behavior are front-loaded and the return-format sentence earns its place by compensating for the absent output 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 broad read-only search with no output schema, the description supplies the missing return shape and notes cross-module and multilingual matching. It is nearly complete, though it omits default result caps and paging interplay that the schema handles separately.

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

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

Schema description coverage is 100%, so all seven parameters are already documented in the schema. The description only restates the id/name/attribute-filter dimension, adding no syntax detail beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb (Searches) and resource (every module's XML objects), then enumerates the object families covered. This clearly distinguishes it from single-object retrieval tools like get_object and reference tools like find_references.

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 notes query is optional when type/where is given, implying filter-based search, and the schema notes default module scope. However, it never states when to choose this over siblings such as list_types, get_object, or find_references, leaving the 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 already declare readOnlyHint=false and destructiveHint=true, so safety is covered; the description adds the important detail that the edit happens in place on the file and is limited to writable modules. It stops short of explaining reversibility, failure/rollback behavior on validation failure, or interaction with edit_history/undo_edit.

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 scope, then path syntax, then the alternative tool. The dense XPath examples earn their space by being directly actionable.

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 in-place mutation with 7 fully documented parameters and no output schema, the description covers purpose, scoping, routing, and path semantics. The remaining gap is failure behavior (e.g., whether a failed XSD validation leaves the file modified).

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 goes beyond the schema's vague 'Optional path to nested element(s)' by supplying real mini-XPath syntax and three worked examples. It does not add anything for set/remove/all/validate beyond what the schema already documents.

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 (changes attributes of an object) and immediately bounds the scope to objects in a writable module, edited in place. This clearly separates it from xslt_patch, which the description names as the tool for objects owned by other modules.

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 tool for objects in a writable module, and use xslt_patch for objects owned by other modules. It also demonstrates when the path parameter is needed (nested elements) with three concrete XPath examples.

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 flag destructiveHint=true and readOnlyHint=false, and the description adds real substance beyond that: it restores backed-up files, deletes files the edit created, and refuses when files changed afterwards unless force=true. The guard and the loss-on-force condition are exactly the behavioral detail an agent needs.

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

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

A single dense sentence with zero filler, front-loading the core action and default behavior before the refusal/force caveat.

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 three-parameter mutation tool with no output schema, the description covers action, default selection, side effects, and the failure/override path completely; 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 cross-parameter meaning: that seq defaults to the latest not-yet-undone edit and that module narrows selection to one module. The force condition is also explained in behavioral terms.

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 (reverts) and resource (one change made through this server), with the exact scope of a single edit. It is clearly distinguishable from siblings like edit_submodule or forget_history.

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 default selection behavior (most recent not yet undone) and the condition under which the tool refuses and requires force=true. This gives clear operating context, though it does not explicitly name sibling alternatives such as edit_history.

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 and openWorldHint=false, so safety is covered. The description adds the meaningful behavioral detail that it checks "like the game would" and enumerates breadth, implying a heavyweight comprehensive pass, but it says nothing about cost, latency, or what the result contains beyond the annotation profile.

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 that front-loads the verb and the "like the game would" framing before the enumerated checks. It is long and list-heavy, but every clause names a distinct check, so 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?

With no output schema, the description carries the burden of explaining what comes back, and it never states the result shape (findings list, error severity, pass/fail). The input side is fully covered, but an agent knows what is checked yet not what to expect in return.

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

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

Schema description coverage is 100%, so all four parameters (module, xsd, l10n, refs) are already documented with defaults. The description's check list loosely maps to the three boolean switches (XSD/XSLT, localization, references), adding marginal clarity, but supplies no syntax or semantics beyond the schema.

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

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

States a specific verb ("Checks") and resource ("a module") and then enumerates the exact scope: SubModule.xml ids/versions/DLLs, XML well-formedness and XSD, XSLT compilation, duplicate ids, unresolved references, unregistered files, and localization. This clearly separates it from narrower siblings such as l10n_scan or find_references, which cover only subsets.

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 (run a full pre-flight validation of a module) but never stated explicitly, and there is no guidance on when to prefer this over the narrower sibling tools (l10n_scan, find_references, describe_schema) or when not to run it. An agent can infer the context but is given no routing rules.

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 flag destructiveHint=true, but the description goes well beyond them: it discloses that a matching tag+id is replaced while non-matches are appended, that a new ModuleData/<mod>_<type>.xml file may be created and registered in SubModule.xml, and that an XSD check runs afterward. These are exactly the side effects and hidden registrations an agent needs before invoking a mutation.

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

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

Three sentences, front-loaded with the core action and examples before the replacement/append mechanics and validation note. Dense but every clause carries information; the long parenthetical example list borders on verbose, keeping it just under a 5.

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 mutation with no output schema, the description covers write semantics, file creation/registration, and post-write validation. It omits permission or auth requirements for 'writable' modules and does not describe failure behavior beyond mode semantics, which are the only 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 100%, so the schema already documents every parameter including the mode enum and validate default. The description adds the object-identity semantics (replace on matching tag+id) and the accepted container/wrapping form, but does not elaborate on mode or validate beyond what the schema says, so the baseline 3 is appropriate.

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

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

States a specific verb (writes/creates or replaces) and resource (XML objects in a writable module), naming concrete element types like <Item>, <NPCCharacter>, and <Culture>. This clearly distinguishes it from siblings such as set_attributes, clone_object, and delete_object, which the description implicitly contrasts with by covering the full create/replace path.

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

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

The description explains the internal upsert-vs-append behavior and the implied prerequisite of a 'writable module', which gives useful context for when this tool applies. However, it never explicitly routes the agent against alternatives (e.g. use set_attributes for partial field edits, clone_object to duplicate, edit_submodule to change file registration), so usage 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?

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description corroborates this by describing removal/clear operations. Beyond annotations it adds real context: the exact file written, automatic registration, that it uses the same mechanism as official DLC, and that repeated calls merge rather than overwrite. It stops short of stating permission/auth requirements or conflict-resolution rules.

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, front-loaded with the core action and its mechanism before enumerating operations and the diff behavior. Nearly every clause earns its place, though the parenthetical about the official DLC is slightly ornamental.

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-parameter destructive mutation with no output schema, the description covers mechanism, target file, merge semantics, operation set, and the before/after diff. It omits prerequisites (writable module, permission to patch another mod's object) and conflict behavior, 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 100%, so the schema documents all 12 parameters and the baseline is 3. The description still adds value by grouping the operations (set attributes, remove attributes, remove node, replace, append child XML, clear the rule), which conceptually maps to set/remove_attributes/remove/replace_xml/append_xml/clear, helping an agent understand the tool's 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+resource: it 'changes an object owned by vanilla or another mod without copying it' by adding a rule to the module's XSLT. This clearly distinguishes it from copy-based siblings like clone_object/write_object, which operate on your own objects. The mechanism (ModuleData/XSLT/<mod>_<XmlId>.xslt) is named 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?

The phrase 'without copying it' implies the copy-then-edit alternative it replaces, giving clear usage context. It also clarifies the merge model ('one call per target node; repeated calls merge'). It does not, however, explicitly name siblings like write_object, set_attributes, or xslt_preview or state when to prefer them, so no hard 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine value beyond that: it runs the real game engine path (System.Xml XslCompiledTransform), claims fidelity to actual game loading, and discloses that XSLT load-breaking errors are surfaced — useful behavioral context not derivable from 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?

Two tight sentences, front-loaded with the core action, followed by the secondary benefit (error surfacing). No filler and nothing 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?

With no output schema, the description does the work of explaining the return shape (before/after diffs per object, plus XSLT errors). Combined with full schema coverage, an agent has enough to call it correctly; only the exact diff/error format is unspecified.

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

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

Schema description coverage is 100% and each of the 4 parameters is documented in-schema (including the `targets` default). The description's '(or only `targets`)' merely restates the schema default rather than adding format or semantics, so the baseline 3 is appropriate.

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

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

The description states a concrete verb+resource: it runs the game's merge + XSLT pipeline for a module and shows before/after diffs per targeted object. The dry-run/preview framing clearly separates it from the sibling xslt_patch, though it never names 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?

Usage is only implied — the preview/diff framing suggests 'check before patching', and it notes `targets` is optional, but there is no explicit when-to-use vs xslt_patch or validate_module, and no stated exclusions. The schema ('any module, read-only is fine') carries the little guidance that exists.

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