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

With no annotations, the description carries the full burden and does so well: it discloses that no Godot process is needed, that autoloads initialize in headless mode, that a broken script crashes every subsequent headless op, what the return format is (plain-text name/path/singleton), and the duplicate-name error path.

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 action, then layers path syntax, singleton default, environment behavior, the headless crash warning, return format, and error path — every sentence earns its place with no filler.

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

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

For a mutation tool with no annotations and no output schema, the description covers the mutation's side effects, the environment requirement, the return value, and the failure mode, leaving nothing an agent needs to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds real value by explaining that autoloadPath accepts both 'res://...' and project-relative paths (auto-prefixed) and by restating the singleton default and its global-access meaning.

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

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

States a specific verb and resource ('Register a new autoload in a project') and explicitly routes the modify case to a named sibling (update_autoload), letting an agent distinguish it from list_autoloads, update_autoload, and remove_autoload.

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 (no Godot process required) and names the alternative for modification, plus a pre-flight warning to validate before adding. It does not spell out the inverse case (when not to add an autoload) beyond the duplicate-name error, so it falls just short of a full 5.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses automatic saving, type-checking with error instead of silent zero values, object-typed property input formats, runtime-session conflict behavior, and a specific docs reference. It also lists precise failure conditions. This is exemplary transparency.

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

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

The description is dense but every sentence carries information, and the primary purpose is front-loaded. It is a single long paragraph rather than structured bullets, but the flow is logical and no sentence is filler. Slight length is justified by the tool's complexity.

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

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

The description covers return format (plain-text confirmation), failure conditions, runtime-session constraint, and parameter semantics. It even points to a docs file for advanced coercion rules. For a tool with no output schema and no annotations, this is complete enough for an agent to call it correctly in most cases.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds critical semantics beyond the schema: it distinguishes top-level params from the properties dict, explains type-checking behavior, and spells out the allowed formats for object-typed properties (res:// path, inline dict, or null) plus the slash-suffixed key convention. This materially improves the agent's ability to construct valid parameters.

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

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

The description opens with a specific verb and resource ('Add a node to a Godot scene'), immediately distinguishing it from siblings like set_node_properties or delete_nodes. The scope is unambiguous, and additional detail about saving and parameter handling reinforces the purpose.

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

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

There is no explicit when-to-use guidance or named alternatives. Usage is implied by the tool name and first sentence, but no exclusions compare it to related tools like create_scene or duplicate_node. Error conditions are presented as failure modes, not as selection criteria.

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 destructiveHint annotation, the description discloses wait-time budgets, early failure on unresponsive ports, the error message for late calls, and the plain-text return format. No contradiction with 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?

The description is dense but every sentence earns its place: the core action is front-loaded and the timing, failure mode, recommended pattern, alternative, and cleanup are all packed efficiently without redundancy.

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

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

For a tool with no output schema and only a destructive hint annotation, the description is remarkably complete. It covers invocation timing, process lifecycle, timeout behavior, failure modes, return value, and related tools needed to finish the workflow.

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

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

The schema already covers both parameters fully at 100% coverage. The description adds useful behavioral nuance for bridgePort (e.g., a port that listens but answers no ping gives up sooner), but most parameter meaning already lives in the schema.

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

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

The description clearly states the action ('Inject the MCP bridge into a Godot process you launch yourself') and the target resource. It also distinguishes this tool from run_project by the launch-ownership condition.

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 explicit timing requirements ('Call BEFORE Godot launches'), a recommended parallel launch pattern, an explicit alternative ('Prefer run_project unless MCP must not spawn Godot'), and cleanup guidance ('Call detach_project or stop_project when done').

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 lone idempotentHint annotation, it discloses that the operation replaces any previously attached script, that it saves automatically, the resolution behavior of the returned nodePath/scriptPath, and two distinct error conditions (missing scriptPath, unknown nodePath). The runtime-session constraint and its remedy are exactly the kind of context annotations cannot 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?

Four short sentences, front-loaded with the action, then prerequisites, side effects, and errors, with zero filler. Every sentence contributes operational information.

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

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

For a mutation tool with an output schema, the description covers prerequisites, destructive behavior (script replacement), auto-save, return shape, and both failure modes plus the runtime blocker and its clear command. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so all four parameters are already documented with examples (nodePath, scenePath, scriptPath, projectPath). The description adds little parameter-level syntax beyond reiterating that nodePath and scriptPath are resolved on return, 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 names a specific verb (attach) and resource (an existing GDScript file) plus its target (a node in a scene), and the scope is unambiguous against siblings like validate or run_script. An agent can distinguish this tool's job 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 states the prerequisite workflow explicitly ('after writing the script with the standard file tools and validating it via the validate tool') and the blocking condition (runtime session active, cleared by stop_project/detach_project). It does not, however, point to an alternative for cases where attaching is the wrong choice versus run_script.

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

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

The description discloses important behavioral traits: it runs in a single Godot process, saves once at the end, shares an in-memory cache, and has specific error handling (abortOnError). It also warns that errors occur while a Godot runtime session is active and provides remediation (stop_project or detach_project). This adds substantial value beyond the destructiveHint annotation, which only warns of destructiveness. The description clearly explains the batch semantics and lifecycle, though it doesn't delve into every edge case.

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

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

The description is dense but structured, front-loading the primary purpose and key benefit (avoiding startup overhead, shared cache). It then lists sub-operations and their parameter equivalences, concluding with error handling and a note about Godot runtime conflicts. While it is somewhat long, every sentence provides useful information; no filler. The structure is logical, moving from purpose to mechanics to side effects.

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

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

Given the complexity (multiple sub-operations with differing parameters, nested objects) and the presence of a rich output schema, the description is fairly complete. It covers the core usage, the sub-operation variants, error handling, and an important caveat about Godot runtime sessions. However, it doesn't explicitly explain the ordering semantics beyond 'in input order', which is implied in the schema, and the output schema likely covers return details. Minor gaps but overall adequate.

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

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

The schema already provides detailed descriptions for each parameter (e.g., operation enum, per-operation fields like nodePath, properties). The description adds context by explaining how sub-operations map to standalone tools and mentions that add_node items accept the same promoted spatial params, and set_node_properties accept the same per-update params. However, since schema coverage is 100%, the description doesn't add significant semantic beyond what's already in the schema, so a baseline of 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 clearly states the tool's purpose: to batch multiple mutations on scenes in one call, instead of chaining individual calls. It explicitly names the operations it replaces (add_node, load_sprite, save_scene) and lists the supported sub-operations, making its scope unmistakable. It also distinguishes itself from the standalone tools by emphasizing the shared cache and single save.

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

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

The description explicitly states when to use this tool: when you have multiple mutations on the same or related scenes, to avoid per-call startup overhead and benefit from a shared cache. It names the alternative (chaining individual tools) and even mentions the error-handling behavior (abortOnError). This gives clear guidance on usage and comparison.

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 the description adds meaningful behavioral context: the runtime probe is always present, never errors on the runtime probe itself, and errors only if projectPath is set but lacks project.godot. This goes beyond the annotation by disclosing error conditions and the always-present runtime block.

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

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

The description is compact and front-loaded: the main purpose is in the first sentence, the optional-parameter behavior is stated next, and the error condition is last. Every sentence earns its place with no filler.

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

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

Given the output schema exists, the description doesn't need to explain return values in detail, but it still summarizes the return shape. It covers the optional parameter behavior, error conditions, and usage context. Nothing an agent needs to call this tool correctly is missing.

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

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

Schema coverage is 100% and the schema already describes projectPath. The description adds value by explaining the consequence of omitting it (returns only Godot version and runtime status) and the error condition when set to a non-project directory. This is more than the schema provides, though the schema already covers the basic meaning.

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 ('Get') and resource ('project metadata'), enumerates the exact fields returned (name, path, Godot version, structure summary), and adds a distinguishing runtime block. It clearly differentiates from siblings like get_project_settings and get_project_files by describing the metadata + runtime status scope.

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

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

Explicitly instructs to use as the first call before driving a running project, and explains the optional projectPath behavior ('Omit projectPath for just the Godot version and runtime status'). This gives clear when-to-use guidance and implies when not to use it (when you need files/settings, use siblings).

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

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

No annotations exist, so the description carries the full burden and does so well: it discloses auto-save behavior, the idempotency hazard (duplicate connections), the exact error conditions (missing signal/method, active runtime session), and the return format. These are non-obvious traits an agent must know before invoking.

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

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

Front-loaded with the core action, then prerequisites, side effects, return value, and failure modes in five tight sentences. No filler; each sentence contributes distinct operational information.

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

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

No output schema, yet the description describes the return value ('plain-text confirmation naming source, signal, target, and method'), and it covers persistence, errors, and the runtime-session conflict. For a 6-required-param mutation tool this is complete enough to call 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 all six parameters are already documented in structured form, which sets the baseline at 3. The description adds only indirect value by advising get_node_signals to validate signal/method names; it does not add format or path-syntax detail 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 (connect), resource (signal on source node to method on target node), and destination of the change (.tscn file). The pairing of source-signal / target-method is precise enough to distinguish it from disconnect_signal and get_node_signals without opening any schema.

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

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

Explicitly tells the agent to call get_node_signals first to confirm names, states the duplicate-connection consequence, and names stop_project/detach_project as the ways to clear the runtime-session blocker. That is genuine when-to-use and when-not-to-use guidance with named alternatives.

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

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

Annotations only provide idempotentHint=true, but the description goes much further: 'Overwrites silently if the file already exists,' 'Saves automatically,' and — critically — 'Errors while a Godot runtime session is active... stop_project (or detach_project) clears it.' This is a runtime precondition no annotation would convey, and it's exactly the kind of behavior that causes agent failures if missed.

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

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

Front-loads purpose, then the routing alternative, then parameter hints, then behavior (overwrite, save), then return shape, then the runtime precondition. Every clause is load-bearing; no filler.

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

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

Output schema exists, so return values ('success and the scenePath') need not be explained in depth — the description summarizes anyway. Combined with the runtime-session precondition, silent-overwrite warning, and default handling, an agent has everything needed to invoke correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema for rootNodeType by giving concrete values ('pass "Node3D" for 3D scenes or "Control" for UI') and reinforcing the default, which the schema states only in one short clause. No enum is declared in the schema, so this guidance is otherwise unavailable.

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

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

Specific verb+resource: 'Create a new Godot scene file with a single root node.' Distinguishes from sibling add_node explicitly, and the write target (.tscn at scenePath) is stated. An agent can identify this tool without ambiguity.

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

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

Explicit when-to-use ('starting a new scene from scratch') and the alternative for the opposite case ('for adding nodes to an existing scene, use add_node'). Covers the main routing decision cleanly.

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 destructiveHint=true annotation, it discloses that descendants are removed, that the save happens once at the end, that a root-delete fails per-entry without aborting the batch, and that an active runtime session causes errors. These are meaningful behaviors an agent cannot get from annotations alone.

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

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

Front-loads purpose, then packs array semantics, failure behavior, return shape, and prerequisites into tight sentences with zero filler. Every sentence earns its place.

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

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

For a destructive batch mutation with an output schema already defined, the description covers the safety-relevant behaviors, partial-failure semantics, prerequisites, and return structure. Nothing an agent needs to call it correctly is missing.

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

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

With 100% schema coverage the baseline is 3, but the description adds the non-obvious always-array contract (single-element array for one-off deletes), which prevents a common invocation mistake. The per-entry results ordering also clarifies how nodePaths maps to output.

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

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

States a specific verb (Remove) and resource (nodes and their descendants) plus scope (from a scene file). An agent can distinguish it cleanly from add_node, duplicate_node, and remove_autoload 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?

Adds operational guidance: always-array contract for one-off deletes, the scene-root exclusion, and the runtime-session prerequisite with concrete remedies (stop_project/detach_project). It stops short of an explicit when-to-use/when-not comparison against sibling mutation tools, but the context is otherwise clear.

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

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

Annotations only supply destructiveHint=true, but the description adds substantial context: it preserves the external Godot process, is idempotent on repeat calls, auto-cleans up when the bridge disconnects, distinguishes 'already ended' vs 'never attached' messages, and errors only when a spawned session is active. This is well beyond what the single annotation conveys and is consistent with it.

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

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

The description is dense and front-loaded, leading with the core action and its key exclusion. It is on the long side and spends a full sentence detailing return values ('message confirming detach plus externalProcessPreserved') that the output schema already covers, which is mild redundancy but not padding.

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

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

For a zero-parameter, zero-ambiguity lifecycle tool with an output schema and a destructive annotation, the description covers scope, alternatives, idempotency, error conditions, and cleanup behavior. Nothing an agent needs to invoke it correctly is missing.

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

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

The tool takes zero parameters (schema is an empty object), so there are no parameter semantics to document. Per the baseline for 0-param tools, this is adequate; the description's discussion of externalProcessPreserved belongs to the output, not the input.

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 action ('clear attached-mode runtime state and remove the injected McpBridge autoload') and immediately delimits its scope by naming what it does NOT do ('Does NOT stop the manually launched Godot process'). It explicitly distinguishes itself from siblings attach_project, run_project, and stop_project, so an agent can route correctly 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 explicit when-to-use ('Use after attach_project when you are done driving the game'), the alternative for other cases ('For spawned sessions (run_project), use stop_project instead'), and notes it is 'mostly optional now' because the session auto-ends on disconnect. When-not/alternative guidance is fully present.

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, but the description adds far beyond that: it discloses persistence behavior ('persisting the change in the .tscn'), auto-save, the exact return format ('plain-text confirmation naming the disconnected signal and target'), two error conditions, and the runtime-session blocking condition with its workaround. Rich behavioral context that annotations alone 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?

Five tight sentences, front-loaded with the core action, then prerequisites, recovery, return, errors, and blocking condition. Every sentence earns its place with no redundancy.

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

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

For a destructive 6-param mutation tool with no output schema, the description covers persistence, return format, error conditions, recovery, and the runtime-session blocker. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema description coverage is 100%, so baseline is 3. The description alludes to 'two nodes' and a 'connection' but adds no syntax or format details beyond what the schema documents for each of the 6 parameters.

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

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

States a specific verb+resource ('Remove an existing signal connection between two nodes') and distinguishes itself from siblings connect_signal and get_node_signals by naming both. An agent can identify the exact operation 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?

Explicitly names get_node_signals as a prerequisite to confirm the connection exists, connect_signal as the recovery path, and stop_project/detach_project as the way to clear the runtime-blocking condition. Covers when to use, when it errors, and the alternative for recovery.

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

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

With no annotations, the description carries full behavioral burden. It discloses automatic saving, default naming and parent behavior, return values (originalPath and newPath), error conditions, and the critical requirement that no Godot runtime session be active, naming stop_project and detach_project as remedies. This is strong, though it could mention reversibility or deeper semantics.

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

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

The description is front-loaded with the core action, followed by defaults, return values, and error conditions. It is compact but includes some redundancy with the schema (defaults). Overall efficient.

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

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

Given an output schema exists, the description needn't explain return values, yet it still summarizes them. It covers defaults, error cases, and a critical runtime prerequisite. For a mutation tool with no annotations, no output schema gaps, and complete parameter schema, this is fully adequate.

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

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

Schema description coverage is 100%, so the schema already documents all parameters including defaults for newName and targetParentPath. The description repeats those defaults but adds no extra syntax or format details 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?

The description gives a specific verb+resource ('Duplicate a node and its descendants in a Godot scene') and explicitly contrasts itself with the node-by-node approach via add_node. This clearly distinguishes it from siblings like add_node.

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

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

Provides clear context by contrasting with add_node and explaining default behavior for newName and targetParentPath. It also defines error conditions (nodePath nonexistent, targetParentPath invalid) and runtime session conflicts. However, it doesn't explicitly state when to prefer this over other siblings beyond add_node.

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

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

Annotations only declare destructiveHint=true; the description goes far beyond by disclosing silent overwrite of outputPath, both error conditions (no valid meshes, active runtime session), the return format, and how to clear the session blocker. This is rich behavioral context.

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

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

Five dense sentences, zero filler, with the core purpose and the 3D-only constraint front-loaded before parameters and error/return behavior.

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

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

With no output schema, the description supplies the return format and count, covers error paths, prerequisite session state, and overwrite risk. Nothing an agent needs to invoke this safely 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 parameters are self-documented, but the description still adds semantics the schema lacks: outputPath is overwritten silently and meshItemNames defines a subset vs. all-export behavior. It stops short of adding format detail on scenePath/projectPath.

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 ('Export a scene of MeshInstance3D nodes as a MeshLibrary .res file') and immediately scopes it ('For grid-based 3D tile palettes only, not 2D scenes'), which sharply distinguishes it from the many scene-manipulation siblings.

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

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

Gives explicit when-to-use (grid-based 3D tile palettes), when-not (2D scenes), and prerequisite alternatives ('stop_project (or detach_project) clears it'). The routing to sibling tools for the runtime-session blocker is spelled out.

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

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

Goes well past the readOnlyHint=true annotation: it discloses that captured logs survive process exit and crashes, that the session clears itself on exit, that logs are retained until stop_project, and that attached mode yields empty arrays with running=null. These are exactly the lifecycle and edge-case behaviors an agent needs and cannot get from annotations or schema.

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

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

Front-loads the purpose, then usage trigger, then lifecycle caveats, then return shape in tight successive sentences. Despite being relatively long, every clause carries distinct operational information - no filler or repetition.

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

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

Covers prerequisite tooling, retention semantics, post-crash retrieval, attached-mode behavior, and return-field semantics. Even though an output schema exists (making the return-value prose partly redundant), the description leaves no gap an agent needs filled before calling 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?

With one parameter at 100% schema coverage, the baseline is 3. The description restates the default of 200 and adds that it applies per-array ('last limit lines each'), which mildly enriches the schema's 'from end of output' wording, but it does not introduce new meaning beyond the schema.

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

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

States a specific verb and resource ('Get captured stdout/stderr from a spawned Godot project') and immediately scopes it to runtime diagnostics. It is clearly distinguishable from siblings like run_project, stop_project, and the editor/profiling tools.

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

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

Explicitly says when to reach for it ('whenever runtime tools fail unexpectedly - script errors, missing nodes, and crash backtraces all surface here') and names a hard prerequisite and its alternative ('Requires run_project (not attach_project; attached mode does not capture output)'). Both the trigger condition and the exclusion are stated, leaving nothing to inference.

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

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

Annotations declare readOnlyHint:true, consistent with 'Read'. The description adds the return format structure and error behavior, which goes beyond annotations. No contradiction.

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

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

The description is extremely concise with four sentences, each providing essential information. It front-loads the purpose and packs in behavior, input nuance, and return format without redundancy.

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

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

Given no output schema, the description adequately covers the return shape, error handling, and parameter details. It could mention potential errors or scenarios, but it is sufficient for the tool's complexity.

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

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

Schema coverage is 100%, baseline 3. The description adds value by explaining the 'always-array' behavior for the nodes parameter and the semantics of 'changedOnly:true', which clarifies the parameter usage beyond the schema.

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

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

The description explicitly states 'Read one or more nodes' current property values', providing a clear verb and resource. It distinguishes from siblings like 'set_node_properties' and 'get_node_signals' through its specific focus on property values and its 'always-array' behavior.

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

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

The description offers usage tips such as passing a single-element array for one-off reads and using 'changedOnly:true'. However, it does not compare with siblings like 'get_node_signals' or 'get_scene_tree', nor does it specify when not to use this tool.

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

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

Annotations already declare readOnlyHint=true, so safety is covered; the description goes further by disclosing that the connections[].target value is scene-root-relative, that 'root' means a self-connection, and that it errors when the node is not found. These are useful behavioral facts beyond the annotation, though return-shape detail is partly redundant with the 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?

Front-loads the purpose and the routing guideline first, then adds format detail. Dense and mostly earned, though the path-format parenthetical is long enough to slightly strain readability.

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

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

For a read tool with an output schema present, the description covers purpose, when to call it, the path-format quirk that could otherwise cause errors, and the error case. 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 real semantic value by tying the output's target field format to the targetNodePath argument that connect_signal/disconnect_signal accept, explaining that no path conversion is needed.

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

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

States a specific verb and resource: list signals defined on a node plus their current connections. It clearly distinguishes itself from connect_signal/disconnect_signal by describing a read/inspection role rather than a mutation.

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 to use it 'before connect_signal/disconnect_signal to verify signal/method names', naming both alternatives and the condition that selects this tool. No inference required.

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

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

Annotations already indicate readOnlyHint=true. The description adds transparency about skipped entries ('Skips hidden (dot-prefixed) entries and the .mcp directory') and the return type. There is no contradiction with 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?

The description is two sentences: first states the core purpose, second covers parameters and behaviors. It is front-loaded, with no unnecessary words.

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

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

Given the absence of an output schema, the description provides the return structure '{ name, type, path, extension?, children? } (nested tree)'. It also covers filtering and hidden entries. It is reasonably complete for a tool with 3 parameters, though could mention the default for maxDepth explicitly (already in 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?

With 100% schema description coverage, the baseline is 3. The description adds some value with examples (e.g., '["gd","tscn"]') and explains maxDepth behavior, but doesn't significantly exceed the schema's own descriptions.

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

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

The description 'Return a recursive file tree of a Godot project' clearly states the verb and resource. It distinguishes from sibling tools like search_project by specifying 'Use to discover project structure when paths are unknown', making it clear when this tool is appropriate.

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

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

The description explicitly says 'Use to discover project structure when paths are unknown' and explains parameters like extensions filter and maxDepth. However, it does not explicitly mention when not to use it or compare to siblings, so it is slightly below a perfect score.

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

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

Annotations only declare readOnlyHint=true, and the description goes well beyond that: it documents the return shape, the raw-string treatment of complex Godot types (multi-line arrays/dicts, the input action map), and the __global__ bucket for keys outside any section. These are non-obvious behaviors an agent could not infer from annotations or schema.

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

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

Front-loaded with the core action, then usage, then return contract. Every sentence carries information, though the return-format sentence is dense enough to require careful 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 fully carries the return-value burden by specifying the two response shapes and the raw-string/__global__ edge cases. Nothing essential for correct invocation appears to be missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds value by giving example section names and clarifying that omitting section returns all sections, and that out-of-section keys land under __global__. It slightly exceeds the schema's documentation of the same fields.

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

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

States a specific verb+resource ('Parse project.godot into structured JSON') and scopes it to reading configuration settings without launching Godot. This clearly separates it from siblings like get_project_info and get_project_files.

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

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

Gives clear context for when to use it ('inspect configured display, input, rendering, etc. settings without launching Godot') and how to narrow with section. It does not name an alternative tool or state when not to use it, so it falls short of an explicit routing instruction.

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 description adds details about return values (path, type, uid) and error condition (file missing). No 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?

Three sentences, no filler. Purpose first, then usage guidance, then return info. Efficient and well-structured.

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

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

Output schema is described in prose (path, dependencies array with type and uid). Tool is simple and description covers behavior, inputs, and outputs adequately.

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

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

Input schema covers both parameters (projectPath, scenePath) with full descriptions. The description adds no further parameter-level context beyond schema.

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

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

Explicitly states it parses .tscn files for ext_resource references (scripts, textures, subscenes). Action and resource are clear. Distinct from sibling tools like add_node or get_scene_tree.

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?

Clearly states 'Use to inspect what a scene depends on before refactoring or moving files.' Provides context but does not explicitly exclude alternatives or mention when not to use.

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

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

Annotations already declare readOnlyHint=true; description adds that it returns JSON text and errors on non-existent scene or path. This provides useful behavioral context beyond annotations without contradiction.

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

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

The description is three sentences, each adding distinct value: output definition, parameter usage, and error conditions. No wasted words.

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

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

Given no output schema, the description explains the return format as JSON text. It covers errors and parameter effects. Could optionally mention performance implications for deep trees, but this is sufficient for a read-only utility.

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%, but the description adds meaning by explaining the effect of maxDepth values and parentPath scoping, as well as the nested structure returned. This compensates adequately.

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

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

The description clearly specifies the tool retrieves a scene hierarchy as a nested tree with specific fields (name, type, path, script, children). It distinguishes itself from sibling tools like get_node_properties and get_debug_output by focusing on hierarchical 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 description provides explicit guidance on using maxDepth for shallow vs full tree and parentPath for subtree scoping. It implies when to use each parameter but does not explicitly state when not to use the tool, though the context is clear.

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

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

Annotations already mark it as read-only. The description adds details on default behavior (visibleOnly defaults true), optional parameters (filter narrows by class), and return fields (path, type, rect, visible, plus optional text/disabled/tooltip). No contradiction with 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?

The description is concise with no wasted sentences. It covers purpose, usage, prerequisites, parameter behavior, and return format efficiently. Each sentence serves a distinct purpose.

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

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

Given the tool's simplicity (2 optional parameters with output schema), the description fully covers what the tool does, when to use it, prerequisites, parameter details, and return structure. It is complete without extending beyond necessary information.

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

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

Input schema has 100% description coverage for both parameters. The description reinforces the schema by stating defaults (visibleOnly defaults true) and explaining filter narrows by class, adding value beyond the structured schema.

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

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

The description clearly states the tool walks the running scene tree to return Control nodes with positions, sizes, types, and text content. It distinguishes from siblings by specifying it should be called before simulate_input actions, setting it apart from other get tools like get_scene_tree or get_node_properties.

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

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

The description provides explicit guidance to call this before simulate_input for discovering element names and paths. It also states the prerequisite of an active runtime session, implicitly indicating when not to use. However, it lacks explicit alternatives or situations to avoid.

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

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

With no annotations, the description carries the full burden and does most of it well: it discloses that the editor cannot be controlled programmatically, that it returns plain-text confirmation after spawning the process, and that it errors when projectPath lacks project.godot. It does not say whether the call blocks until the editor closes or how the spawned process is later managed, which is the main remaining gap for a process-spawning tool.

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

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

Three tight sentences with zero filler; the primary purpose is front-loaded, followed by the routing rule and then the return/error contract. Every sentence carries distinct information.

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

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

For a single-parameter tool with no output schema, the description covers purpose, exclusions, alternatives, return type, and the failure condition. An agent has everything needed to decide whether and how to call 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 already 100% for the single projectPath parameter, so the baseline is 3. The description adds real constraint semantics beyond the schema by stating the directory must contain project.godot or the call errors, which tells the agent how to validate the path before invoking.

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 ('Open the Godot editor GUI for a project for the human user') and scopes it to the human user, which immediately separates it from the agent-driven siblings like add_node and set_node_properties. An agent can identify its role 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 an explicit when ('only when the user explicitly asks to "open the editor"') and an explicit when-not with named alternatives ('for any agent-driven work, use the headless scene/node tools (add_node, set_node_properties, etc.)'). Nothing about tool selection 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=true, so the safety profile is covered. The description adds valuable behavioral context not in annotations: it requires no Godot process and reads project.godot directly, and it explains the consequence of broken autoloads. It could go further on failure/error behavior, but this is solid.

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

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

Front-loaded with the core action, then why to use it, then operational notes, then return shape. Every sentence earns its place and there is no filler.

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

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

Despite no output schema, the description includes a return shape '[{ name, path, singleton }]' and covers usage rationale, operational requirements, and data source. It is complete enough for an agent to call and interpret results correctly.

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

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

Schema coverage is 100%, so the single projectPath parameter is fully documented in the schema. The description adds that no Godot process is needed, implying the call is lightweight and file-based, which is useful context beyond the parameter type.

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

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

The description states a specific verb and resource ('List all registered autoloads in a project') and adds scope details (paths, singleton status). It distinguishes itself from siblings like add_autoload/remove_autoload/update_autoload by being the read/list operation.

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 first when diagnosing headless failures' and explains why (broken autoloads crash all headless ops). This tells the agent exactly when this tool is the right first step, which is strong usage 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?

The readOnlyHint annotation already indicates a safe read operation, and the description adds meaningful behavioral nuance beyond it: recursive descent skips hidden directories, default behavior checks only the directory and immediate children, and an empty array is returned when no matches exist. This is solid behavioral disclosure for a read-only discovery tool.

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

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

The description is compact and front-loaded with the core purpose, then covers usage distinction, recursion behavior, and return format in just three sentences. Every sentence earns its place with no filler or repetition of schema content.

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

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

For a simple read-only discovery tool with two well-documented parameters and no output schema, the description is complete: it states input behavior, edge cases (hidden dirs, no matches), and the exact return shape. The agent has all necessary information to invoke the tool correctly without additional context.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds value by explaining the semantic effect of recursive=true versus the default, including hidden-directory skipping. The directory parameter could use a little more elaboration, but the recursive parameter is meaningfully enriched beyond the schema.

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

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

The description clearly states a specific verb and resource: finding Godot projects by locating project.godot files. It also explicitly differentiates from check_project ('for inspecting a known project, use check_project'), resolving a key sibling ambiguity. The return shape is included, which further sharpens purpose.

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

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

The description explicitly says when to use this tool: 'Use to discover available projects when the user has not specified one.' It also gives an exclusion and an alternative: for inspecting a known project, use check_project. Recursion behavior is also defined, removing any need for the agent to guess.

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 idempotentHint, the description discloses automatic saving, the plain-text confirmation return, error conditions for invalid node class and missing texture file, and a runtime-session conflict with the clearing alternatives. This is rich behavioral context that an agent cannot infer from annotations alone.

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

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

The description is front-loaded with the primary action and supported node types. Every sentence adds operational value: sibling routing, save behavior, return format, error cases, and runtime conflict handling, with no wasted wording.

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

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

Given a mutation-style tool with only idempotentHint annotations and no output schema, the description supplies the missing context an agent needs: automatic save, confirmation return, supported node classes, texture path validation, and runtime session errors. Nothing essential for correct invocation appears to be missing.

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

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

Schema coverage is 100%, so the schema already documents all four parameters. The description adds useful constraints beyond the schema: texturePath must be a real file under projectPath, and nodePath must target one of three specific node classes. It does not elaborate every parameter, but the added validation semantics are meaningful.

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: set the texture on an existing Sprite2D, Sprite3D, or TextureRect node. It names the exact node classes and distinguishes the tool from add_node by explaining that new nodes should receive textures through add_node properties instead.

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

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

It explicitly says when to use this tool (existing supported nodes) and when not to use it (new nodes, where add_node properties should be used). It also gives a runtime-session constraint and names stop_project and detach_project as ways to clear that blocker.

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

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false) by disclosing blocking behavior ("Blocks for `seconds`"), the default capture length, error preconditions, and a crucial measurement caveat: times are elapsed not CPU and inclusive rows overlap so totalMs must never be summed.

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

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

Dense but front-loaded: purpose, prerequisite, blocking duration, and the key measurement warning come first, with return details last. It is long for a single paragraph but nearly every clause carries operational 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?

Even though an output schema exists, the description summarizes the return payload (rows, frame budget, servers, worstFrame, frames/frameGaps/limitReached) and flags interpretation pitfalls, so an agent has everything needed to call and read the result correctly.

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

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

Schema coverage is 100%, so the schema already documents all four parameters; the baseline would be 3. The description adds genuine meaning on top by explaining that `seconds` is a blocking capture window and that `captureLimit` causes Godot to select rows by inclusive time, hiding cheap functions and setting limitReached.

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+resource: "Capture a window of Godot's function profiler - the editor's Profiler tab numbers." It clearly differentiates this sampling tool from the start_profiler/stop_profiler siblings by describing a bounded capture window with returned 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?

It states the prerequisite explicitly ("Requires run_project with profiling: true") and gives failure conditions ("Errors if profiling was off at launch or a capture is already open"), which is strong when-to-use guidance. It does not explicitly contrast with start_profiler/stop_profiler, 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?

The description discloses behavioral traits beyond the 'destructiveHint' annotation: it states that no Godot process is required, returns a plain-text confirmation, and errors if the autoload name does not exist. This adds valuable context for the agent.

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

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

The description is only three sentences, all front-loaded with the action. Every sentence adds value: the purpose, a use case, operational detail, and error behavior. No wasted words.

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

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

For a simple two-parameter tool with annotations and no output schema, the description is complete. It covers the action, when to use it (broken autoloads), operational constraints (no Godot process), return type, and error case. No gaps.

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

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

The input schema has 100% description coverage for both parameters (projectPath, autoloadName). The description adds no extra meaning beyond what the schema already provides; the parameter names and schema descriptions are self-explanatory.

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 starts with 'Unregister an autoload from a project by name,' which is a specific verb+resource combination. It clearly distinguishes the tool from siblings like 'add_autoload' and 'list_autoloads' by focusing on removal.

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

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

The description provides a concrete usage scenario: 'Use to recover from a broken autoload that is crashing headless ops.' This guides the agent on when to invoke the tool, though it does not explicitly mention when not to use it or list alternatives.

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

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

Annotations indicate destructiveHint=true, and the description adds rich behavioral context: stdout/stderr capture, MCP bridge readiness verification, port assignment, and explicit error conditions. It also warns that profiling must be set at launch and explains the background mode's effect on input and visibility.

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

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

The description is dense but front-loaded: it starts with the core action, then dependencies, then optional features, and ends with cleanup and error conditions. Every sentence carries essential information without redundancy.

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

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

Given the tool's complexity (5 parameters, no output schema), the description covers all critical aspects: prerequisites, side effects, profiling constraints, bridge port assignment, and error cases. It leaves no significant gaps 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 100%, so baseline is 3; the description adds meaning by stating that profiling must be set at launch and that bridgePort is baked into mcp_bridge.gd. However, it does not elaborate on the scene, background, or projectPath parameters beyond what the schema provides.

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

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

States the specific action ('Spawn a Godot project as a child process') and clarifies it as a prerequisite for multiple sibling tools, making its role unmistakable. It also distinguishes itself from attach_project by scope.

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

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

Explicitly lists when to use this tool versus attach_project, specifies required predecessor relationships (must be called before take_screenshot, simulate_input, etc.), and provides a clear 'call stop_project when done' directive. The profiling parameter is linked to enabling profiler tools, and error conditions (invalid projectPath, active session) are stated.

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

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

With only destructiveHint=true given, the description carries real weight: it discloses the runtime-session requirement, that print() output is routed to get_debug_output rather than the result, that stderr errors escalate to errors or warnings depending on the return value, and the exact response envelope. This is unusually rich behavioral context that the annotation alone cannot convey.

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

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

Information is front-loaded: purpose first, then precondition, then script contract, then output routing and envelope. It is dense but every sentence carries distinct payload; the only minor cost is a slightly long middle section on return-type serialization.

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

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

For a high-complexity tool that executes arbitrary code with full scene-tree access, the description covers the precondition, the script contract, side-channel output routing, error semantics, and the response shape. Even though an output schema exists, the added framing of success/result/warnings/tip is appropriate rather than redundant.

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

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

Schema coverage is 100% so the baseline is 3, but the description goes further by specifying the script's structural contract (extends RefCounted, func execute(scene_tree: SceneTree) -> Variant) and enumerating which return types survive JSON serialization. That adds genuine meaning for constructing a valid parameter.

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

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

The opening sentence gives a precise verb+resource+scope: 'Execute a custom GDScript in the live running project with full scene tree access.' This clearly separates it from read/query siblings like get_scene_tree or get_debug_output and from static-analysis siblings like validate.

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 hard precondition ('Requires an active runtime session') and explains mode-specific behavior (spawned mode error escalation), which tells the agent when this tool is applicable. It does not name an explicit alternative tool for when no runtime session exists, so it stops short of a 5.

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

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

Annotations only supply idempotentHint, so the description carries the rest and does so well: it discloses silent overwrite, the plain-text confirmation return, an error when the scene file is absent, and a runtime-session precondition with the remedy. That is beyond what any structured field provides.

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

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

Front-loaded with purpose, then constraints, then the runtime precondition. Dense but essentially every clause carries load; the only slight excess is stacking four separate constraint sentences where a tighter grouping would read faster.

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 tool with no output schema and minimal annotations, the description covers purpose, alternatives, overwrite semantics, return value, and both error conditions. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description goes further by framing newPath as "save-as" and contrasting it with the default overwrite, which tells the agent why the optional parameter exists rather than just what type it takes.

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

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

States a specific verb+resource ("Re-pack and save a scene") and immediately scopes it, distinguishing save-as from the auto-saving mutations named later (add_node, set_node_properties, delete_nodes). An agent can tell this apart from create_scene and the mutation siblings without opening any schema.

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

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

Explicitly says when NOT to use it ("Most mutations ... auto-save - only use this for save-as via newPath, or to re-canonicalize a hand-edited .tscn") and names the precondition-clearing tools (stop_project, detach_project). This is exactly the when/when-not/alternative guidance the dimension asks for.

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 state readOnlyHint=true, so the description's addition of default values, hidden-entry skipping, and .mcp directory exclusion adds useful behavioral context. It also mentions truncation behavior, which is beyond annotations and helps set expectations for large result 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?

Front-loads the core purpose, then packs details into a compact paragraph. Every sentence carries information, though the default-value repetition is slightly redundant. Structure is efficient and scannable.

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

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

An output schema exists, so return values needn't be detailed, but the description still summarizes matches[] format and truncation, which is helpful. Combined with annotations covering safety, the description is nearly complete, missing only explicit when-not-to-use guidance.

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 parameters. The description repeats defaults for fileTypes, caseSensitive, and maxResults, which is redundant but not harmful. It adds no syntax or format details 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?

Uses a specific verb+resource ('Plain-text (substring) search across project files') and clarifies scope by naming example targets (references, callers, signatures). This distinguishes it from siblings like get_project_files or get_scene_dependencies, which enumerate rather than 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?

Gives clear context ('to find references, callers, or signatures across the codebase'), which implies when to use it. No explicit exclusions or named alternatives, but the context is sufficient for an agent to distinguish use cases.

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

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

Beyond the idempotentHint annotation, the description richly discloses behavior: values are type-checked and error instead of silently defaulting, object-typed properties accept paths/resources/null, saves happen once at the end, and runtime-session errors are cleared by stop_project or detach_project. This gives strong insight into side effects and failure modes.

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

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

The description is dense but every sentence contributes necessary operational detail. Key purpose and array convention are front-loaded, and later sentences efficiently cover resource values, coercion, errors, and return shape without fluff.

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

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

Given the tool's complexity, the description is complete: it covers parameters, value semantics, error behavior, return format, and interaction with runtime sessions. The output schema exists, so not restating return structure is appropriate.

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?

Even with 100% schema coverage, the description adds substantial meaning: the always-array convention, object-typed property value forms, slash-suffixed shader_parameter keys, and the type-checking/error semantics. These details go well beyond the input schema's basic property descriptions.

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

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

The description opens with "Set one or more node properties on a scene in one Godot process," which names a specific verb, resource, and scope. This clearly distinguishes the tool from siblings like get_node_properties or add_node.

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 concrete usage context: "Always-array: pass a single-element updates array for one-off edits" and explains error behavior during active runtime sessions. It does not explicitly name alternative tools or exclusion conditions, but the guidance is clear enough for selecting it.

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

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

Annotations only declare destructiveHint=true. The description adds significant behavior beyond that: it explains that invalid batches inject nothing, that a runtime failure stops the batch and skips the rest, and it details the result structure (ok, timing, signals, Control hit, changes, watch samples, errors). This goes well beyond the annotation's simple hint and gives the agent a realistic picture of side effects and failure modes.

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

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

The description is dense but organized: it leads with purpose, then lists action types, gives key behavioral notes, and closes with return and failure handling. It is long but every clause earns its place. Minor structural improvement would be bullet lists for the action specifics, but it's already front-loaded and readable.

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

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

Given the tool's complexity (two parameters, nested action objects, many conditional fields), the description covers the essential operational aspects: sequential execution, action types, return contents, failure behavior, and the get_ui_elements cross-reference for node resolution. It also mentions the watch sampling mechanism. It does not explicitly state that the project must already be running, but that is implied by 'running project' in the first sentence and by the tool's purpose. An output schema exists, so the return summary is a bonus rather than a necessity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add much parameter-level meaning beyond what the schema already provides; it summarizes action types and repeats the 'omit pressed to tap' rule, but the schema itself already explains each parameter in detail. It adds no new semantic insight beyond the overview, so it stays at 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 'Simulate sequential input in a running project and report what each action did,' which states a specific verb (simulate), resource (running project), and outcome (report). It enumerates the supported action types, making it immediately distinct from sibling tools like run_script or run_project, and clarifies that it interacts with a running project rather than editing it.

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

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

The description gives strong guidance on parameter usage (e.g., 'omit `pressed` to tap', 'click_element resolves by node path/name (see get_ui_elements)'), and warns about long waits being cut off. However, it does not explicitly contrast itself with alternatives or state when it should be preferred over similar tools, leaving the when-to-use-vs-others partly implicit. It provides no exclusions or 'do not use when' 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?

The description discloses key behaviors beyond the annotations: it returns immediately, stops itself after `seconds`, requires prior profiling setup, errors under specific conditions, and returns a defined set of fields. Annotations only say readOnlyHint=false and destructiveHint=false, so the description carries the behavioral burden and does so thoroughly.

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

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

The description is compact but information-dense. Every sentence earns its place: what the tool does, why it returns immediately, prerequisites, auto-stop behavior, related tools, return values, and error conditions. It is front-loaded with the core purpose and contains no filler.

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

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

Given the full input schema and output schema, the description still adds essential context: how this tool fits into an interactive capture workflow, how to retrieve results, prerequisites, alternatives, and failure modes. An agent has everything needed to decide whether to call it and how 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?

Input schema coverage is 100%, so the schema already fully documents `seconds` and `captureLimit`. The description mentions `seconds` with its default and max, but this repeats the schema rather than adding new meaning. There is some value in listing returned fields, but that is output semantics rather than parameter semantics.

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

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

The description states a specific verb and resource: 'Start a profiler capture and return immediately.' It also differentiates itself from siblings by explicitly naming profile_project for unattended windows and stop_profiler for retrieving results, so an agent can distinguish it without opening other tool schemas.

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

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

Usage conditions are explicit: it requires run_project with profiling: true, errors if a capture is already running or profiling was not enabled, and tells the agent to use profile_project instead for an unattended window. This is strong when-to-use and when-not-to-use guidance.

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

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

With only readOnlyHint=false/destructiveHint=false in annotations, the description carries real behavioral weight: it clarifies that stopping may just read back an expired capture, that results can be re-fetched with a different sort, that times are elapsed not CPU, that inclusive rows overlap and must not be summed, and that it errors when nothing was started.

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 action leads, then the read-back caveats, then the return payload list. Every clause carries information, though the enumerated return fields are somewhat long for a tool that has an 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?

Covers the no-capture error case, the elapsed-vs-CPU timing caveat, the non-summing warning for inclusive rows, and the return shape, so an agent can invoke and interpret results correctly without additional sources.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by tying 'sort' to re-reading the same capture and by contrasting selfMs (own time) vs totalMs (inclusive) vs calls, which is directly the semantic distinction the sort enum encodes.

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

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

States a specific verb+resource ('Stop the capture started by start_profiler and rank the recorded functions') and names the sibling that creates the capture, so the agent can distinguish it from start_profiler/profile_project immediately.

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 read-back semantics: a capture that hit its time limit is read as-is and can be re-read with a different sort, plus the failure condition (errors if no capture was started). It stops short of an explicit when-not/alternative routing, but the context is clear.

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

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

Annotations only declare destructiveHint=true, but the description adds substantial context beyond that: it clears a flag blocking scene-editing tools, frees a process slot, reports alreadyExited:true with exit code and logs when the process self-exited, detaches attached sessions without killing the external process, and errors only when there is nothing to report. This is rich behavioral disclosure that goes well beyond the single annotation.

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

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

Front-loads the core action, then follows with usage conditions and return details. The sentence about already-exited behavior is long but dense with relevant information. The return-value enumeration ('message, mode, ...') is somewhat list-like but earns its place given the output schema exists and the description summarizes key fields.

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

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

Despite having an output schema, the description helpfully summarizes the key return fields (especially alreadyExited, exitCode, finalOutput) and explains the error condition. It covers lifecycle, cleanup side effects, and interaction with other tools. Complete for a zero-parameter lifecycle 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?

Zero parameters, so the baseline is 4. The description does not need to document parameters, and correctly focuses on behavior instead. No param meaning is missing.

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

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

States a specific verb+resource ('Stop the spawned Godot project') and adds scope ('clean up bridge state'), clearly distinguishing it from siblings like detach_project (which detaches without killing) and stop_profiler. An agent can pick this over its neighbors without opening any schema.

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

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

Explicit when-to-use ('Call when done with runtime testing, even after a crash, and even if you closed the Godot window yourself') and specifies the consequences of not calling. It also implicitly distinguishes from detach_project by noting attached sessions preserve the external process. 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?

Annotations only declare readOnlyHint=true, and the description adds substantial behavioral context beyond that: the file is persisted under .mcp/godot-runtime/screenshots/ and survives stop_project, warnings are emitted for non-fatal runtime errors, and it errors when there is no session or the bridge times out. This is rich disclosure for a read tool.

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

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

Front-loaded with the core action followed by mode semantics, persistence location, and error conditions. It is dense and somewhat long, but nearly every clause conveys actionable information, 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?

An output schema exists, and the description still clarifies the return payload (inline image block, saved path/size, previewPath/previewSize, warnings) and failure modes. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, and the description exceeds it by explaining what each responseMode actually produces (preview saves the full PNG but returns a bounded inline preview; path_only returns no image) and by justifying the full mode. It adds rationale and consequences beyond the schema's terse enum docs.

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: 'Capture a PNG of the running viewport.' No sibling tool captures images, so it is unambiguously distinguishable, and the subject (running viewport) scopes it 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?

Gives clear mode-selection guidance, notably 'full ... use for small text or pixel-level inspection', which tells the agent when a given mode is appropriate. It stops short of naming an alternative tool or stating when to avoid screenshots entirely, so it is strong context rather than full when/when-not 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 supply idempotentHint, so the description carries most of the burden and does so well: it discloses partial-update semantics (omitted fields retained), that no Godot process is required, the return shape (plain-text confirmation), and a concrete error condition (unregistered autoloadName). This is meaningful behavior beyond the structured fields.

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

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

Four short, front-loaded sentences with no filler: purpose first, then parameter contract, then sibling routing, then operational notes. Every sentence carries distinct information.

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

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

With no output schema, the description correctly states the return value; it also covers the error case and execution requirements for a 4-parameter mutation tool. An agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes further by explaining that autoloadPath and singleton are optional edits whose omission preserves current values, which is semantic meaning the schema alone does not convey. It does not add format or validation detail beyond that.

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 and resource ('Modify an existing autoload') and enumerates exactly the mutable fields ('path or singleton flag'). It is clearly distinguishable from the sibling pair add_autoload and remove_autoload, which it explicitly contrasts.

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

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

Gives explicit when-to-use guidance with an alternative named: 'Use instead of remove_autoload + add_autoload (single edit, no orphan window).' It also states the partial-update contract ('Pass either or both - omitted fields keep their current value'), so nothing about invocation conditions 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?

Beyond the readOnlyHint annotation, the description discloses exact return shapes for single and batch calls, the discriminated error entry format, and the non-obvious behavior that checks instantiate the scene and run each script's _init(). It also clarifies that any parse error yields valid:false. No contradiction with 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?

The description is dense but every sentence earns its place: purpose, usage timing, input constraints, return formats, and special behavior are each covered once and in a logical order. It front-loads the core action before details.

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 parameters, the description fully compensates by specifying single vs. batch result shapes, error entry variants, and check execution behavior. The only implicit point is that check findings likely also set valid:false, but this is reasonably inferable from the stated error structure.

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

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

All six parameters are already described in the schema, so baseline is 3. The description adds critical semantics the schema alone does not express: the mutually-exclusive one-of rule and the batch optimization of 'targets array validated in one Godot process.' This is meaningful but not a huge departure from the existing schema coverage.

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

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

The description opens with a specific verb and resource: 'Validate GDScript syntax or scene integrity using headless Godot.' It clearly distinguishes the tool from siblings like run_script and check_project by naming their relationship ('Use before attach_script or run_script').

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 explicit when-to-use guidance: 'Use before attach_script or run_script to catch parse errors early.' It also states the key input constraint ('Give exactly one of scriptPath, source, or scenePath, or a targets array'), preventing invalid calls.

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