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?

No annotations, so the description carries the full burden. It discloses auto-save, type checking (errors instead of silently storing zero value), automatic conversion of dicts to Vector2/Vector3/Color, object-typed property handling, and error conditions. However, it does not mention whether the operation can be undone or how concurrency is handled.

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 and mostly efficient, but the description is fairly dense and includes some repetition (e.g., both schema and description explain dict conversion). Sentences are purposeful with no obvious waste, but could be slightly tighter.

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 is reasonably complete: it covers auto-save, type checking, conversion rules, error conditions, and session interference. However, it lacks details on return format beyond 'plain-text confirmation' and does not mention permissions or side effects like undo capabilities.

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 parameters. The description reiterates top-level params, dict conversion rules, and the default behavior of parentNodePath, adding some clarity but largely duplicating schema info. Baseline 3 is appropriate when schema is fully covered.

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

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

States a specific verb+resource (add a node to a Godot scene) and clearly describes the operation. Siblings like create_scene, add_autoload, duplicate_node, attach_script are distinguishable because the resource and action are explicit.

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

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

Provides implicit context through prerequisites (errors if a Godot runtime session is active) and fallback behavior (parentNodePath defaults to root), but does not explicitly say when to use this tool versus alternatives like duplicate_node, batch_scene_operations, or create_scene.

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 in annotations, the description adds substantial context: a 15s wait budget, the exact failure mode ('bridge did not respond'), the ordering constraint tied to autoload reading at process start, and the plain-text return with resolved port. It does not explicitly disclose that injection modifies the project's mcp_bridge.gd file (which is what justifies destructiveHint), leaving that to the schema's bridgePort note.

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 critical ordering constraint and parallel-launch guidance are front-loaded, and every sentence carries actionable content. It is dense and appropriately sized for a tool with a non-obvious timing contract, though slightly long.

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, the description covers return format (plain-text status with resolved bridge port), timing, failure behavior, and cleanup. The main residual gap is explaining why it is destructive (project file modification), but otherwise it 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 description coverage is 100%, so both parameters are already fully documented, including the auto-select behavior and port-baking detail. The description adds no additional meaning beyond what the schema provides, so the baseline 3 applies.

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

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

The description states a specific verb and resource: 'Inject the MCP bridge into a Godot process you launch yourself.' It clearly distinguishes this tool from siblings run_project and launch_editor, so an agent can route correctly without opening the schema.

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

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

It gives explicit when-to-use ('Call BEFORE Godot launches'), when-not/alternative ('Prefer run_project unless MCP must not spawn Godot'), a recommended calling pattern (launch in parallel with this call), and follow-up cleanup tools (detach_project or stop_project). 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?

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?

Annotations only give destructiveHint=true, so the description carries most of the weight. It discloses the single-process execution (~3s startup avoided per call), shared in-memory scene cache, save-once-at-end behavior, error semantics (abortOnError false continues by default), and the session precondition. It still leaves open whether partial mutations persist in the cache or whether the end-save can fail after errors, which is why it is not a 5.

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

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

One dense paragraph, front-loaded with the primary use case before diving into per-operation mechanics and return shape. Sentences are long but each carries distinct information (caching, error defaults, session lifecycle); minor redundancy with the schema descriptions of abortOnError.

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 the return-value explanation is a bonus rather than a necessity, yet it still documents results[] ordering and tagging. Combined with the session-lifecycle caveat and caching behavior, the agent has enough to invoke correctly; only the fate of partial mutations on error remains unspecified.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning by explaining that each array item selects its own sub-operation and params, that add_node accepts the same promoted spatial params as the standalone tool, and that set_node_properties mirrors the standalone per-update and per-operation fields. This clarifies the nested dispatch structure beyond the flat 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 (batch) and resource (scene operations) with a clear scope: "multiple mutations on the same or related scenes" in one Godot process. It names the exact siblings it replaces (add_node / load_sprite / save_scene), so an agent can immediately distinguish it from the standalone 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?

Explicit when-to-use: "Use this instead of chaining add_node / load_sprite / save_scene calls when you have multiple mutations on the same or related scenes." It names the alternatives and the selecting condition, and adds a second condition (active Godot runtime session) with the clearing tools stop_project / detach_project.

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 declare readOnlyHint=true, so safety is covered. The description adds meaningful behavior beyond that: it specifies the return shape in both modes and discloses the error condition when projectPath is set without a project.godot. This is useful behavioral context not available in structured fields.

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

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

Three dense sentences, front-loaded with purpose, then parameter behavior, then return shape. No filler; every sentence adds signal.

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

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

With no output schema, the description compensates by specifying the exact return objects for both modes, and covers the error case. Fully adequate for a single-optional-parameter read tool, with only minor gaps (e.g. no mention of projectPath format expectations).

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 description re-states the parameter's meaning, but it also adds value beyond the schema by explaining the omit-to-get-version-only behavior and its purpose. Slightly redundant with the schema description but the mode semantics are genuinely clarified.

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 (Get) and resource (metadata about a Godot project), then enumerates exactly which fields are returned. Clearly distinguishes itself from siblings like get_project_files, get_project_settings, and get_scene_dependencies by focusing on project-level metadata.

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

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

Explains the two usage modes clearly: full metadata with projectPath, or just the Godot version when projectPath is omitted, explicitly noting the capability-check use case. Does not name sibling alternatives for related tasks (e.g. get_project_settings for configuration), but the behavioral mode guidance is strong.

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

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

Annotations only 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?

Annotations already declare readOnlyHint=true, consistent with description. Description adds details on recursive behavior (skipping hidden directories) and return format, adding value beyond annotations.

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

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

Two sentences, no wasted words. Purpose is front-loaded, and all essential information is included concisely.

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 (two params, no output schema), the description covers behavior, return type, and edge cases (empty array). No gaps remain.

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%, but description adds context for 'recursive' (default false, descends into subdirectories skipping hidden ones) and clarifies return behavior. Provides value beyond schema descriptions.

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

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

Description clearly states it finds Godot projects by locating project.godot files. It distinguishes from the sibling tool get_project_info, which inspects a known project.

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

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

Explicitly says to use when user has not specified a project, and for known projects to use get_project_info instead. Provides clear when-to-use and alternatives.

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

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

Beyond 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?

With only idempotentHint=true in annotations, the description carries real weight: it discloses type-checking behavior (errors instead of silently storing the zero value), auto-conversion of {x,y}/{r,g,b,a} literals, object-typed property handling via res:// path or typed dict, abortOnError continuing semantics, and 'Saves once at the end.' This is exactly the beyond-annotations context an agent needs for a mutation tool.

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

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

Dense but front-loaded and every sentence carries information (array convention, conversion rules, type checking, abort behavior, session precondition). The pointer to 'the Property Values section of docs/tools.md' is a reasonable offload rather than a wall of text. Slightly information-dense, but nothing is wasted.

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

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

An output schema exists, yet the description still notes the results[] shape and per-update ordering, and it covers the mutation's save semantics and the runtime-session error condition. For a batched write 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 baseline is 3, but the description adds genuine meaning: how `value` is interpreted (auto-convert, type-checked, object-clearing via null) and abortOnError's default behavior. It adds more than the schema's one-line field descriptions.

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

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

Specific verb+resource: 'Set one or more node properties on a scene in one Godot process.' The write verb 'set' clearly contrasts with the read-only sibling get_node_properties, so an agent can route without opening either schema. Scope (one process, batched updates) is stated up front.

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

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

Gives concrete invocation guidance ('Always-array: pass a single-element updates array for one-off edits') and an operational precondition (errors while a runtime session is active; stop_project/detach_project clears it). It stops short of naming alternatives like batch_scene_operations or add_node, so it lacks explicit when-not guidance.

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

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

With only destructiveHint=true in annotations, the description carries most of the burden and does so: it discloses the return shape (success, actions_processed, warnings from input handlers) and failure conditions (no session, any action failing validation). It doesn't restate the mutation risk that destructiveHint implies, but adds substantial runtime-error and sequencing behavior.

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

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

Front-loaded with purpose, then constraints, then return/error contract in a tight block. Sentences are dense but each carries a distinct operational fact, so little is wasted; slightly information-packed but justified for the action-gating 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?

An output schema exists, so return values needn't be explained in depth, yet the description still summarizes them and adds the error/failure contract. Combined with the gating rule and sibling reference, an agent has what it needs 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 the baseline is 3, but the description adds cross-cutting semantics the schema cannot: the `type` field 'gates which other fields apply', and the press/release two-action pattern. It directs the reader to per-property docs, but doesn't itself restate relative vs absolute mouse semantics beyond the schema.

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

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

States a specific verb+resource ('Simulate sequential input in a running project') and enumerates the action types (key, mouse_button, mouse_motion, click_element, action, wait) it accepts. This clearly distinguishes it from siblings like run_script or run_project.

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

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

Routes the agent explicitly ('For click_element use get_ui_elements first') and gives operational guidance ('Press/release require two actions; insert wait between for frame ticks'). It lacks explicit when-not-to-use guidance or a named alternative for other scenarios, so it is a strong 4 rather than 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 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?

Annotations declare readOnlyHint=true, and the description adds meaningful behavior beyond that: valid:false on any parse error, never throws, and line numbers only appear when Godot's stderr includes them. The one gap is that it doesn't note the temp-file write for inline source (that detail lives only in the 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, then mode rules, then return shape. Every sentence carries information; nothing is redundant with the title or schema.

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

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

No output schema exists, but the description spells out both return shapes (single: { valid, errors }, batch: { results }), the error-object shape, and failure semantics. An agent can call and interpret results correctly without more.

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 a real constraint the schema does not encode: 'provide exactly one of scriptPath, source, or scenePath.' That mutual-exclusivity rule is genuinely useful beyond the structured 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 (validate) plus two resources (GDScript syntax, scene file integrity) and the mechanism (headless Godot). This clearly separates it from siblings like run_script or attach_script, which execute or attach rather than check validity.

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 attach_script or run_script to catch parse errors early, and states the alternation rules: single-target requires exactly one of scriptPath/source/scenePath, while batch uses a targets array. When-to-use and mode selection are both given.

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