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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the core mutation/safety profile is covered. The description adds no further behavioral detail: it does not say whether the scene is saved automatically, what happens if the node name already exists, how parentNodePath defaults, or how properties are applied.

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

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

The description is a single front-loaded sentence with zero wasted words. Its brevity is the main issue, but that is better captured as a completeness gap than as a conciseness failure.

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

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

For a six-parameter mutation tool with nested properties, no output schema, and no sibling differentiation, the description is far too thin. It omits parent-node behavior, save semantics, failure modes, and the distinction from tools like instance_scene and duplicate_node.

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 six parameters are documented in the input schema. The description adds no parameter-level meaning beyond the schema, such as the default parent or the property value format, so the baseline 3 applies.

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

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

States a specific verb and resource ("Add a node") and scope ("to an existing scene"). It is clear what the tool does, but it does not differentiate itself from nearby siblings such as instance_scene, duplicate_node, create_scene, or modify_scene.

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

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

There is no guidance on when to use this tool versus alternatives, nor any prerequisites, exclusions, or follow-up requirements. The phrase "existing scene" weakly implies that the scene must already be loaded or present, but no explicit usage conditions are given.

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

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

Adds real behavior beyond the annotations: it executes project constructors (an unadvertised side effect), validates and refuses unavailable scripts *before saving* (so failure is non-destructive/atomic), and states the .NET build prerequisite. Annotations only cover the generic read/destructive/open-world profile, so this extra context is genuinely valuable. It still omits whether an existing attachment is replaced or an error is raised.

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 short sentences, front-loaded with the action, then side effects, then the C# caveat. Nothing is padded or repeated.

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 four-required-parameter mutation with no output schema and only generic annotations, the description covers side effects and failure mode well but leaves parameter meaning and the result of a successful attach (does it return the node, the resource, nothing?) entirely unaddressed.

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

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

All four parameters (projectPath, scenePath, nodePath, scriptPath) have zero schema description coverage, and the description explains none of them — not even the distinction between the target node path and the script path, or whether paths are absolute or project-relative. The self-describing names carry all the weight here.

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 ('Attach') plus resource ('compatible GDScript or C# script') and target ('scene node'), which clearly separates it from siblings like set_node_properties or modify_scene. It stops short of naming which sibling to use for related script work, but the operation is unambiguous.

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

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

The description gives preconditions ('C# requires Godot .NET and a built assembly', 'refuses unavailable scripts') that imply when this call will fail, but never states when to choose this over alternatives such as modify_scene or set_node_reference. Usage is implied rather than directed.

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

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

Annotations cover safety (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds a meaningful prerequisite (a display is required) plus the key semantic that it launches a fresh run rather than snapshotting an existing one. It doesn't explain time cost or how frames/timeout affect the capture, leaving some gap.

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

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

Two short sentences, front-loaded with the core action and output, followed by prerequisites and exclusions. 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?

The output medium (PNG viewport) is conveyed even without an output schema, and the display prerequisite is noted. However, for a tool with frames and timeoutMs knobs, nothing explains their effect on the capture, leaving the agent to guess at how to tune the run.

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

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

Schema coverage is only 50%: projectPath and scenePath are described in the schema, but frames and timeoutMs have no schema description. The description says nothing about any of the four parameters, so it fails to compensate for the documented gap on frames and timeoutMs.

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 ('run a fresh scene') and concrete output ('rendered viewport as a PNG image'), and explicitly distinguishes itself from capturing existing runs, which separates it from siblings like capture_screenshot and run_scene.

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

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

Gives a clear condition ('requires a display') and an explicit exclusion ('does not capture an existing run'), implicitly routing agents to a different tool for that case. It stops short of naming the alternative sibling outright, so not a 5.

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

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

Annotations already declare the safety profile (not read-only, open-world, non-destructive), so the description's marginal contribution is the return format (inline PNG) and the renderer prerequisite, both genuinely useful. It stops short of clarifying what happens with no active session or whether the captured image is returned inline vs. written to disk.

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 short sentences, no filler, with the core action and output format front-loaded. The pause caveat and renderer prerequisite are appended compactly.

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 no-output-schema, single-optional-param read-like tool, the description covers action, output format, and one hard prerequisite. Only minor gaps remain (behavior without a live session, inline vs. saved artifact) against an otherwise thin surface.

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

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

Schema coverage is 100% and the single optional sessionId is fully documented in the schema, so the baseline of 3 applies. The description adds nothing about sessionId, such as what happens when it is omitted or why follow-up tools need it.

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

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

States a specific verb and resource ('Capture the current live debug session as an inline PNG'), which is more precise than the name alone. The 'live debug session' framing implicitly differentiates it from the sibling capture_scene_screenshot, but it never names that sibling to make the distinction 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?

Adds two useful usage cues: it works even when the session is paused, and it requires a display renderer. However, it gives no guidance on when to choose this over capture_scene_screenshot, and no exclusions or fallback behavior when no renderer is available.

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

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

Annotations already declare the operation is a non-destructive, non-read-only, closed-world mutation. The description adds that the session is stopped and its handle released, which is meaningful context, but it does not say what happens to follow-up tool calls, whether the call is idempotent, or what occurs if the session is already gone.

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

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

A single front-loaded sentence with no filler. Slightly terse for the scope, but every word contributes.

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 one-parameter cleanup tool with annotations covering safety and a fully documented schema, the definition is functionally sufficient. It omits the relationship to start_debug_session and the post-close behavior of pending handles, which would matter to an agent sequencing debug workflows.

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

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

Schema description coverage is 100% and the single sessionId parameter is fully documented in the schema, including its role in follow-up tools. The description adds no syntax, format, or validity details beyond that, so baseline 3 applies.

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

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

States a specific verb pair and resource ('Stop and release an explicit process/debug session'), which an agent can distinguish from stop_project or quit_godot at a high level. However, it does not explicitly name those alternatives, so the differentiation is only partial.

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 word 'explicit' implies this applies to sessions opened via the sibling start_debug_session rather than the whole project, but usage is only implied. There is no explicit when/when-not guidance relative to stop_project, set_debug_pause, or quit_godot.

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 the generic profile (readOnly=false, destructive=false, openWorld=true); the description adds genuinely new behavior: existing files are never clobbered, the parent directory must pre-exist, and a dryRun path exists. It stops short of saying what dryRun returns or how errors surface on an existing file.

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

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

Three short sentences, each carrying a distinct constraint, with the file-overwrite guarantee front-loaded. Nothing is redundant.

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

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

Output schema and annotations cover the return and safety profile, and the description supplies the overwrite and directory prerequisites. The remaining gap is the nested 'properties' payload shape and the projectPath/resourcePath relationship, which an agent needs to build a valid call.

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

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

Schema description coverage is 0% for 5 parameters including a nested 'properties' object, so the description carries the full burden. It explains dryRun and hints at typed 'properties', but projectPath, resourcePath, and className are only obliquely implied and no format for the nested object is given.

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 ('Create a built-in Resource') and pins down the output format (.tres/.res), which implicitly separates it from create_scene. It never names a sibling or explicitly contrasts resource creation with scene creation, so an agent must infer the boundary.

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

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

Gives a real prerequisite ('Parent directory must exist') and a safety condition ('without overwriting existing files'), which is more than most siblings offer. It does not say when to prefer this over create_scene or set_resource_properties, nor when to choose dryRun.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true, but the description adds no context explaining that destructive flag — notably whether creating at an existing scenePath overwrites an existing file. For a write tool with a destructive hint, the description should clarify overwrite/error behavior, which it does not.

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

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

A single front-loaded sentence with no filler. It is efficient, though the brevity leaves it thin rather than genuinely tight.

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

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

For a file-creating mutation with a destructive annotation and no output schema, the agent needs to know what is returned (path, UID, root node) and what happens on path collisions. Neither is covered, leaving meaningful gaps for correct invocation.

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

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

Schema description coverage is 100%, so all three parameters (scenePath, projectPath, rootNodeType) are already documented in the schema. The description adds no extra meaning such as a default root node type or path format expectations, so baseline 3 applies.

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

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

States a specific verb and resource ('Create a new Godot scene file'), so the agent knows exactly what operation occurs. It does not, however, distinguish itself from nearby siblings such as save_scene, modify_scene, or instance_scene, which all touch scenes.

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

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

There is no guidance on when to use this versus save_scene or modify_scene, and no stated prerequisites (e.g., project must exist, scene path must not already exist). The agent must infer everything from the name.

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

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

With destructiveHint=false already declared, the description goes further by stating that other plugins and comments are preserved, that a dryRun preview exists, that expectedHash guards the write, and that live activation does not occur. It still omits failure behavior (plugin not found, hash mismatch) and whether a backup or rollback exists.

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

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

Three short sentences, front-loaded with the core action and its side-effect guarantee. The closing clause about not claiming live activation slightly restates the reopen instruction, but it is a deliberate scope caveat rather than filler.

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

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

An output schema exists, so return values need no explanation; the description covers the mutation target, preservation guarantee, preview and hash options, and the activation caveat. For a 4-parameter config-mutation tool this is sufficient 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 only 25% — pluginPath is documented, but projectPath and expectedHash are bare. The description names dryRun and expectedHash but never explains what expectedHash is compared against or what projectPath's format is, so it only partially compensates for the coverage gap.

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

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

States a specific verb and resource (disable an editor plugin) and the exact file it mutates (project.godot), which cleanly separates it from enable_editor_plugin and get_editor_plugins in the sibling list. An agent can identify the operation 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 post-call guidance (save and reopen an already-open editor to apply) but never explicitly states when to prefer this over siblings or when dryRun should be used versus a real mutation. Usage is implied by the verb rather than spelled out.

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

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

Adds real behavior beyond the annotations: atomic save, two explicit refusal conditions (instance contents, uncertain references), and the optimistic-concurrency guard expectedHash. It does not say what happens if a sibling with newName already exists — collision handling is unstated — which keeps it from a 5.

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

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

Three short sentences, front-loaded with the core action and destination, then failure modes, then optional controls. No filler; every clause carries information.

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

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

An output schema exists, so return values need not be described, and the description covers atomicity, refusal preconditions, and dry-run/hash safety. The remaining gap is collision/overwrite behavior on the new sibling name, which an agent performing a mutation would want to know.

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

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

Schema coverage is only 17%, with just nodePath documented, so the description has to compensate. It names dryRun, newName, and expectedHash, but gives no semantics for expectedHash (what hash, sourced where) or for projectPath/scenePath, so the compensation is partial.

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 ('Duplicate a local subtree') plus the destination ('as a sibling') and the naming input ('newName'). It is clearly distinct from add_node or instance_scene thanks to the 'local subtree' scope and the refusal of instance contents, though no sibling is named explicitly.

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

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

'Refuses instance contents and uncertain references' gives implicit when-not conditions, which helps the agent avoid misusing it. But it never names an alternative (e.g. instance_scene) or states when duplication is preferred over add_node, so routing is left to inference.

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

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

Annotations cover the safety profile (readOnly=false, destructive=false, openWorld=true), and the description adds genuinely new context beyond them: the write is surgical (other plugins and comments preserved) and it explicitly disclaims live activation. It stops short of saying what happens on an expectedHash mismatch or whether a backup is made, so it is strong but not exhaustive.

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

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

Three compact sentences: action and file target first, then options, then the activation caveat. No filler and nothing buried.

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 need not be explained, and the annotations cover the safety profile. Combined with an accurate description of file impact and the non-live-activation caveat, an agent has nearly everything; only expectedHash semantics and idempotency (plugin already enabled) are 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 only 25%, with just pluginPath documented, so the description must carry more weight. It names dryRun and expectedHash but supplies no meaning for either — in particular expectedHash's role as a concurrency/consistency guard is left for the agent to guess — and projectPath is never addressed.

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 ('Enable an editor plugin') plus the exact file it mutates ('project.godot'), which cleanly separates it from siblings such as disable_editor_plugin and get_editor_plugins. An agent knows precisely what this call does without opening the schema.

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

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

The description gives a useful prerequisite/caveat ('Save and reopen an already-open editor to apply; this does not claim live activation'), which implies the agent needs a separate action to see the effect. However, it never names an alternative tool or states conditions for choosing dryRun versus a real write, so selection guidance is only implied.

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

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

Annotations already say it is a non-readOnly, openWorld, non-destructive mutation. The description adds genuine behavioral context beyond that: it will not restart an open editor and refuses modified/unowned files, and it supports dryRun/expectedHash for safe verification. It could still say more about permissions or output, but output schema exists.

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

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

Four short, front-loaded sentences with no filler. The primary purpose comes first, followed by key constraints and supported options.

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 discloses the key safeguards (no editor restart, refuses modified files) and mentions optional safety parameters. It is only incomplete because expectedExportHash is never addressed and parameter semantics are thin.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It merely names dryRun and expectedHash without explaining what they do, and it omits expectedExportHash entirely, leaving two of four parameters effectively undocumented.

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

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

States a specific verb+resource: 'Install and enable the bundled annotation addon' in a selected project. Clearly distinguishable from siblings like enable_editor_plugin (generic plugin) and remove_annotation_addon/get_annotation_status.

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

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

Implies usage when you need the annotation addon installed, and gives failure conditions (refuses modified/unowned files, does not restart an open editor). However, it never explicitly names alternatives such as get_annotation_status or remove_annotation_addon or states when not to use it.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it doesn't say whether outputPath is overwritten if it exists, whether the project must be open, or what happens if the scene contains non-mesh nodes.

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

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

A single front-loaded sentence with zero padding. It is efficient, though its brevity comes at the cost of the missing usage and behavioral detail noted elsewhere.

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?

This is a file-writing operation with four parameters, no output schema, and no annotations explaining side effects; the description should at least address overwrite behavior and the MeshLibrary concept. As written, an agent knows what it produces but not the operational consequences of calling it.

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

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

Schema coverage is 100%, so all four parameters (including meshItemNames and its default of 'all') are already documented in the schema. The description adds no syntax, path-format, or behavioral detail beyond what the schema states, so the baseline 3 applies.

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

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

States a specific verb+resource pair: exporting a scene into a MeshLibrary resource. An agent can distinguish it from export_project and create_resource by the MeshLibrary output, but the description never explicitly contrasts with those siblings.

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

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

There is no guidance on when to use this versus alternatives like export_project or create_resource, no preconditions (e.g. scene must be valid/imported), and no note about when the optional meshItemNames filter should be supplied.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, openWorldHint=true, so the write/destructive profile is known. 'Writes the requested output file' adds useful context about the mutation's product, but the description omits whether an existing outputPath is overwritten, error/partial-write behavior, and timeout implications—leaving the destructive profile under-explained.

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 short sentences with zero filler and the core action front-loaded. It is efficient, though the brevity edges toward under-specification rather than refined conciseness.

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 5-parameter, 3-required destructive write tool with 20% schema coverage and no output schema, the description does far too little—it leaves four of five parameters and the return/error behavior undocumented, so an agent lacks enough to call it correctly in edge cases.

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

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

Schema coverage is only 20% (only projectPath is documented), so the description must carry the load. It loosely maps 'existing preset' and 'output file' to the preset and outputPath params, but adds no format, requiredness, or meaning for debug and timeoutMs, nor syntax for preset or outputPath.

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 (export) and clarifies it works via an existing preset and installed templates, producing an output file. This distinguishes it from manipulation siblings and from export_mesh_library, though it never names that sibling explicitly.

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

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

'Using an existing preset and installed export templates' hints at prerequisites (a preset must exist, templates must be installed) but frames no explicit when-to-use/when-not conditions and offers no alternatives vs export_mesh_library or run_project. Usage is implied rather than guided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: it returns both original and marked images, and flags the comment field as untrusted user content, which is an important injection warning 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?

Two short sentences with no filler; the payload is front-loaded and the security caveat is placed after the main description.

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

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

An output schema exists, so return-shape explanation is not required, and annotations cover the read-only profile. However, with 0% parameter documentation and no error/precondition note for an unresolvable annotationId, the definition is only 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 0% for two required parameters, so the description must compensate. It does not explain what projectPath should point to or what form an annotationId takes (prefix, UUID, integer), leaving both opaque.

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 ('Return') plus concrete resources: annotation context, comment, and original/marked PNG images. An agent can tell it retrieves one annotation's payload, though it never contrasts itself with list_annotations or get_annotation_status.

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

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

No statement of when to call this versus list_annotations, get_annotation_status, or resolve_annotation, and no preconditions (e.g. whether the annotation addon must be enabled). The only guidance is a content-trust warning, which does not help select the tool.

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

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

Annotations already declare readOnly, non-destructive, closed-world, so the safety profile is covered. The description still adds meaningful non-obvious behavioral context: presence is derived from files rather than a live command connection, which prevents the agent from over-reading a positive presence result as an active connection.

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 short sentences, no filler, with the semantic caveat placed immediately after the capability statement where it is most useful. Every clause carries information.

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

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

An output schema exists, so return shape need not be explained, and the key interpretive risk (file-based vs. live presence) is addressed. Minor gap: it never names which addon is being inspected, leaving that to inference from siblings.

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

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

Schema description coverage is 0%, so the single required projectPath parameter is documented nowhere. The description says nothing about its format or expected value; the name is largely self-explanatory, which keeps this at a baseline-adequate 3 rather than lower.

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

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

States a concrete verb (read) and enumerates what is reported: addon version, enablement, and editor/runtime presence. The resource is only inferable as the annotation addon from the sibling set (ensure_annotation_addon, list_annotations), not from the description itself, so it is clear but not fully self-distinguishing.

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

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

There is no statement of when to call this rather than get_project_info, list_annotations, or ensure_annotation_addon, and no prerequisites or exclusions. The only guidance-like content is an interpretive caveat about presence, not about tool selection.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that results are reflection metadata tied to the installed engine version, which is useful context, but says nothing about pagination behavior (despite a limit cap of 500), result shape, or cost of enumerating inherited members.

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 short sentences, front-loaded with the action and scope, with the second sentence adding a genuinely useful clarifying distinction. 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?

It conveys the nature of the return value, which matters since there is no output schema, but with 5 parameters at 0% schema coverage it leaves filtering, limiting, and inherited-member behavior undocumented. Adequate but with clear gaps for a tool whose main complexity is in those options.

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

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

Schema description coverage is 0% across 5 parameters. The description's enumeration of 'properties, methods, signals or enums' loosely maps to the `section` parameter, but `filter`, `limit`, and especially `includeInherited` get no explanation at all in either schema or description.

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

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

States a specific verb (read) and resource (properties/methods/signals/enums of a built-in class) and adds the key qualifier that this is reflection metadata from the installed Godot version rather than prose docs. It is clearly distinct from runtime siblings like get_node_properties, though it never names an alternative.

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?

'Reflection metadata, not prose documentation' implicitly tells the agent when this is the right source, and 'installed Godot version' implies version-accurate reflection. However, no sibling tool is named and there is no explicit when-not guidance versus get_node_properties or get_project_info.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description only adds that the output is 'current' and includes errors; it does not say what happens when no session is active or whether output is a snapshot versus cumulative.

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

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

One front-loaded sentence with no filler; nothing needs trimming. The terseness is a completeness problem rather than a verbosity one.

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

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

The tool has an optional session handle, so it can be called with or without context, yet the description never explains what session is used by default or how the returned errors relate to a running debug session. For a session-aware retrieval tool among many similar readers, this leaves real gaps.

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

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

Schema description coverage is 100% and the single sessionId parameter is fully documented in the schema, including its follow-up-tool requirement. The description adds no parameter meaning beyond that, which is the expected baseline.

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

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

The verb+resource is identifiable (retrieves current debug output and errors), but 'debug output' is not distinguished from the sibling view_log or get_runtime_tree, so an agent cannot tell which retrieval tool to pick without reading 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?

There is no statement of when to call this tool, when not to, or which sibling (view_log, start_debug_session, get_runtime_tree, step_frames) is the alternative for adjacent needs.

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

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

Annotations already declare readOnlyHint/destructiveHint/openWorldHint, so safety is covered; the description adds genuinely new behavioral context by saying the data comes from saved enablement rather than a running editor and that live checkbox state is unavailable. This prevents a common misuse (expecting real-time editor state). It could still note whether a missing project config yields an error or an empty list.

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 short sentences, zero filler, with the capability stated first and the key limitation immediately after. Nothing could be removed without losing 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 an output schema present and annotations covering the safety profile, the description only needs to establish scope and read semantics, which it does. The remaining gap is the undocumented projectPath argument, which neither schema nor description clarifies.

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

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

Schema description coverage is 0% and the single required parameter projectPath has no description anywhere. The description says nothing about what path form is expected (project root vs. project.godot file) or whether it must be an existing project, leaving the only input undocumented.

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

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

States a specific verb and resource (list installed editor plugins) plus the exact data returned (saved enablement), and explicitly scopes it away from live editor state. An agent can distinguish it from enable_editor_plugin / disable_editor_plugin without opening either schema.

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

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

The phrase 'without executing Godot' and 'does not report the live editor checkbox state' clearly establish the offline/inspection context in which this tool is correct. It stops short of explicitly naming the mutation siblings (enable_editor_plugin/disable_editor_plugin) as the alternative for changing state, so a routing inference is still 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?

The read-only, non-destructive annotations already establish the safety profile, and the description is consistent with them. However, the description adds no further behavioral context such as whether the version comes from the local installation only or what happens if Godot is not installed.

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

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

A single short sentence with no filler and the key information front-loaded. It is efficient, though slightly terse given the lack of return-value context.

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 getter this is mostly adequate, but with no output schema the description should ideally state what the returned version looks like (e.g., a version string). Error behavior when Godot is not installed is also unstated.

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

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

The tool has zero parameters, so there is no parameter semantics burden; baseline 4 is appropriate. The empty schema is fully consistent with the description.

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

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

States a specific verb ('Get') and resource ('installed Godot version'), making the purpose immediately clear. It does not explicitly differentiate itself from sibling tools such as get_project_info, but the version query is distinct enough.

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

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

Usage is implied by the purpose: call it when the installed Godot version is needed. There is no explicit when-to-use guidance or mention of alternatives, but for a simple zero-argument getter that is minimally adequate.

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

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

Adds real behavioral context beyond annotations: an isolated ConfigFile parser, exclusion of engine defaults, no live InputMap state, and no project autoloads started. The description does not address why annotations mark this inspection tool as readOnlyHint=false, leaving that mismatch unexplained.

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

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

Two sentences with no filler, front-loading what is inspected and then the important scoping caveats. Slightly terse given the parameter burden it leaves unaddressed.

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 need no explanation, and the caveats about defaults/live state/autoloads are valuable. Still, for a 3-parameter tool with undocumented parameters, an agent lacks guidance on filtering by action, pagination via limit, or what projectPath must contain.

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

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

Schema description coverage is 0% and the description mentions none of the three parameters. The meaning of 'action' (single-action filter) and 'limit' (1-200 cap) is left entirely to bare schema fields, so the description fails to compensate for the coverage gap.

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

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

States a specific verb and resource: 'Inspect configured input actions and key/mouse/joypad bindings' read via a ConfigFile parser. This clearly separates it from the write-side sibling set_input_action, though no sibling is named explicitly.

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

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

Implies usage by stating what the tool is not (no engine defaults, no live InputMap changes), which nudges an agent toward runtime inspection tools when live state is needed. However it never explicitly says when to use this instead of set_input_action/remove_input_action, nor that projectPath must point at a project.godot.

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?

Given readOnlyHint=false and openWorldHint=true, the description adds real value by disclosing that it 'Executes property getters' — explaining why the call is not purely read-only — and that it 'Does not change pause state'. It stops short of warning that getter execution may have arbitrary side effects, which would fully justify the non-read-only 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?

Two compact clauses, front-loaded with the core action and scope, followed by the behavioral caveats. No filler whatsoever.

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 only partially covers return semantics via 'bounded typed values'. It omits nodePath addressing conventions and the sessionId follow-up requirement documented in the schema, leaving notable gaps for a live-session inspection tool.

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

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

Schema description coverage is only 33% (only sessionId is documented), so the description carries extra burden. It usefully explains the 'properties' parameter ('up to 50 named properties', echoing the maxItems cap) and hints at 'bounded typed values', but says nothing about the nodePath format or that sessionId is required for follow-up tools.

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 ('Read') and resource ('named properties from a node in the live debug session') with a clear cap of 50. It is easily distinguished from set_node_properties and get_runtime_tree, though it does not explicitly contrast with the closest sibling, sample_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 phrase 'in the live debug session' implies the precondition that a session must be running, and 'Does not change pause state' hints at safe use during inspection. However, there is no explicit when-to-use / when-not-to-use guidance and no named alternative such as sample_node_properties for repeated sampling.

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

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

Annotations already declare the read-only, non-destructive profile, so the description is free to add real context: values are timestamped and carry units, output is a point-in-time snapshot rather than a profiler trace, and render metrics are absent under headless. Those are behavioral facts the annotations do not encode.

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

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

Two sentences, no filler, with the core action stated first and the caveats after. Every clause carries information an agent would otherwise have to discover by trial.

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 need not be explained, and the description covers the headless limitation and the snapshot granularity. What remains missing is the relationship to the other sampling tools, which is the one real gap.

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

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

Only one optional parameter (sessionId) and schema coverage is 100%, so the schema already explains its purpose and the MCP-version requirement. The description adds nothing about it, which is the expected baseline 3 when the schema does the work.

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?

"Read timestamped runtime Performance monitor values with units" gives a specific verb and resource, and the snapshot-vs-profiler clause rules out one misreading. It stops short of differentiating from the similar sibling sample_performance, so an agent still has to guess which sampling tool applies.

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 headless caveat ("Render metrics are unavailable under headless") is a useful exclusion, but there is no explicit statement of when to pick this over sample_performance or sample_node_properties. Usage is only implied by the snapshot framing.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds nothing further — not what fields the metadata contains, not what happens on an invalid projectPath. It essentially restates the tool name.

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

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

A single short sentence that is front-loaded and wastes no words. It is efficient, though brevity here shades into under-specification.

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

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

No output schema exists, so the description carries the burden of explaining what "metadata" is returned — project name, version, settings, scene list? It does not, leaving the agent unable to predict the result. For a sole-parameter info tool this is a real gap.

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

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

Only one parameter with 100% schema description coverage ("Path to the Godot project directory"), so the schema fully documents it. Per the baseline rule for high coverage, a 3 is appropriate; the description adds no extra meaning such as path format or relative-vs-absolute handling.

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?

"Retrieve metadata about a Godot project" names a verb and resource, but "metadata" is undefined and overlaps heavily with sibling tools such as get_project_overview, get_project_setting, and get_godot_version. An agent cannot tell from this text which of those returns what.

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

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

There is no statement of when to use this tool rather than the many similar read-only siblings (get_project_overview, get_project_setting, list_project_files, validate_project). Usage must be inferred entirely from the name.

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

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

Annotations already establish read-only, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the result is "bounded" and computed without launching Godot, and it explicitly discloses incompleteness for binary resources and UID resolution — a real caveat an agent would otherwise not know.

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

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

Two sentences, zero filler, and the leading clause establishes what the tool does before the caveat. The scope enumeration is compact and front-loaded.

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

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

With no output schema, the description does reasonably well by listing exactly what the overview contains. But it omits the meaning of the bound (does limit truncate lists silently?), the projectPath format, and what "explicitly incomplete" means practically for results — leaving gaps an agent would hit on first call.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it does not. projectPath is never explained (format, absolute vs project-relative, is it a directory containing project.godot?), and "bounded" only vaguely gestures at limit without stating its purpose, default, or that it caps result count up to 500.

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

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

States a specific verb and resource ("Read a bounded project overview") and enumerates the exact data returned: main scene, autoloads, input actions, addons, GDScript classes, dependencies. That makes it clearly a static inspection tool, but it never names or contrasts the closest siblings (get_project_info, validate_project, list_projects), so an agent must infer the boundary itself.

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

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

"without executing Godot" implies this is the non-invasive static alternative to launch/run tools, which is useful directional signal. However there is no explicit when-to-use or when-not-to-use guidance, no alternatives named, and no mention of what to call instead for UID or binary-resource questions.

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

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

Annotations already establish that this is read-only, non-destructive, and closed-world, so safety behavior is covered. The description adds useful behavioral detail beyond annotations: absent entries return stored:false, and the tool does not resolve defaults, feature tags, or override.cfg.

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

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

The description is compact and front-loaded, stating the core read operation first and then the important behavioral caveats. Every clause carries useful information without unnecessary 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?

With rich annotations and an output schema already present, the description is reasonably complete on safety and return/absence behavior. However, because the input schema has no parameter descriptions at all, the lack of parameter-format guidance leaves a meaningful gap for an agent trying to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description needs to clarify both parameters. It implies that setting is a project.godot expression and projectPath is the project location, but it does not explain the expected format for either, such as how setting keys should be written or whether projectPath must be absolute.

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

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

The description uses a specific read verb and names the resource precisely: a stored project.godot expression/setting. It also distinguishes the tool's scope from write-oriented siblings like set_project_setting and remove_project_setting by making clear this is a read 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?

It gives clear usage context by saying the setting can be read without starting Godot, and it states important exclusions: defaults, feature tags, and override.cfg are not resolved. It does not name an alternative tool for those resolved-value cases, so it falls short of full when-to-use/when-not guidance.

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

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

Annotations declare readOnlyHint=false and openWorldHint=true, and the description adds meaningful context beyond that: loading resources and invoking getters may execute project code, explaining the non-read-only hint. It does not say what happens on failure or what 'bounded' means operationally, keeping it below 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?

Two short sentences, front-loaded with the core action and followed by the safety caveat. No wasted words, though it is terse to the point of leaving gaps rather than being optimally informative.

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 need not be explained, and the side-effect warning is a plus. However, with three undocumented parameters at 0% coverage, the definition is not complete enough for an agent to call it correctly without inspecting the schema manually.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It only hints at bounding via 'bounded' (likely maxProperties); projectPath, resourcePath, and the max cap of 200 are never explained.

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 ('Inspect') and resource ('bounded stored properties of a .tres/.res resource'), which distinguishes it from mutation siblings like create_resource and set_resource_properties. It does not explicitly contrast with inspection siblings such as get_scene_info or get_node_properties, so it stops short of 5.

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

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

The word 'Inspect' implies a read-style usage, but there is no explicit statement of when to pick this over get_scene_info, get_node_properties, or get_project_info. The agent must infer usage from the resource-file framing alone.

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

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

Adds real context beyond the annotations: it explicitly promises not to change pause state (relevant next to set_debug_pause) and states the result is bounded, which tells the agent output is truncated rather than exhaustive. Since there is no output schema, describing the returned fields here is genuinely additive. It still omits details like what happens on truncation or the session-handle requirement, so it falls short of 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?

Two sentences, front-loaded with the action and the key non-mutation guarantee, then the return shape. Nothing is wasted and there is no preamble.

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

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

For a read-only inspection tool with no output schema and weak parameter documentation, this is the minimum viable amount: it tells the agent what the tool returns and that results are bounded. Missing are the session prerequisite, default limits, and how truncation is signaled, which an agent needs to 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 description coverage is only 33%: maxDepth and maxNodes carry no descriptions, and only sessionId is documented. "Bounded" hints that those two parameters constrain the result, but the description never explains depth counting, defaults, or truncation behavior, so it does not fully compensate for the low coverage.

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

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

States a specific verb and resource: inspect the scene tree of a live debug session, and describes what comes back (node paths, classes, script paths). It stops short of naming the boundary versus editor-side siblings such as get_scene_info or get_node_properties, so an agent must infer the distinction.

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?

"Live debug session" implies this only works while a debug session is running, which is useful implied context. But there is no explicit when-to-use or exclusion against get_scene_info, get_node_properties, or sample_node_properties, and no statement of what happens if no session exists.

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

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

Adds real behavioral context beyond the annotations: it warns that loading resources/autoloads may execute project code, which explains why readOnlyHint=false and openWorldHint=true despite 'Inspect' sounding passive. It also flags that results are bounded, matching maxNodes/maxProperties. It stops short of stating the actual caps, defaults, or failure modes.

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

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

Three dense sentences, zero preamble, with the core capability front-loaded and the safety caveat immediately after. The trailing 'bounded results include inheritance and instances' is slightly cryptic, but nothing is padding.

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

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

With no output schema, the description does a good job enumerating what comes back (hierarchy, properties, scripts, groups, connections, dependencies, inheritance, instances). But for a 4-parameter tool with 0% schema coverage it leaves the path arguments and the numeric bounds/defaults unexplained.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden. Only the two bounding integers are alluded to via 'bounded results'; projectPath, scenePath, their expected formats (res:// paths, project root), and the default/limit values of maxNodes and maxProperties are entirely undocumented.

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

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

States a specific verb ('Inspect') and a specific resource ('a saved PackedScene'), then enumerates exactly what is exposed: hierarchy, properties, scripts, groups, connections, dependencies. The clause 'without instantiating it' implicitly separates it from instance_scene and get_runtime_tree, though no sibling is named outright.

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

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

'Without instantiating it' implies static file inspection vs. runtime/instance approaches, which is useful context. However, there is no explicit when-to-use / when-not-to-use statement or named alternative (e.g., use get_node_properties for a live node, instance_scene to actually load it), so the routing is left to inference.

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

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

Annotations already declare this is a non-destructive, read-only, closed-world operation. The description adds the Godot 4.4+ applicability constraint, which is genuine value, but says nothing about what happens when the file has no assigned UID or the path is invalid.

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

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

A single front-loaded sentence with no filler; the version caveat is compact and placed inline. Nothing wasted, though it could have spent that space on return-value behavior instead.

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

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

There is no output schema, so the description arguably should indicate that the result is a UID string and how failure appears; it does not. For a simple two-parameter lookup this is adequate but leaves a gap.

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

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

Schema coverage is 100% with both parameters fully documented (projectPath, filePath relative to project), so the schema carries the burden. The description adds no parameter meaning beyond what the schema states.

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

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

States a specific verb and resource ('Get the UID for a specific file') plus a version constraint, so the agent knows exactly what operation is performed. It does not differentiate itself from near-siblings like update_project_uids or list_project_files, so it falls short of 5.

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

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

The '(for Godot 4.4+)' qualifier implies a usage precondition, which is useful, but there is no explicit when-to-use/when-not guidance or mention of the related update_project_uids / list_project_files tools. Usage is only implied.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, and the description adds genuinely new context: the save is atomic, dryRun is supported for previewing, expectedHash guards against stale state, and recursive dependencies are rejected. It stops short of 5 because permission requirements and any limits on the target parent are unstated.

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

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

Two tight sentences, with the core action and the atomic-save behavior front-loaded. Every clause carries information 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?

An output schema exists so return values need no explanation, and annotations cover the safety profile. However, for a 7-parameter mutation tool with 14% schema coverage, the description should disambiguate instanceScenePath from scenePath and clarify the newName/parent relationship; that gap keeps it at adequate rather than complete.

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

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

Schema description coverage is only 14% (just nodePath), so the description carries weight here. It usefully clarifies dryRun and expectedHash, but leaves instanceScenePath versus scenePath, newName, and projectPath unexplained, which are exactly the ambiguities an agent would hit.

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 ('Instance a saved scene under a local parent') plus the atomic-save outcome, which clearly separates it from create_scene, save_scene, and duplicate_node. It does not explicitly name or contrast a sibling, so it stops short of a 5.

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

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

The mention of dryRun and expectedHash hints at preview/drift-check workflows, and 'refuses recursive dependencies' implies a constraint. But there is no explicit when-to-use guidance and no named alternative for related tasks like create_scene or duplicate_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 already declare readOnlyHint=false, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: it does not say that a long-running external GUI process is spawned, that a session must later be terminated via close_session/quit_godot, or how the sessionId is surfaced for follow-up tools.

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

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

A single front-loaded sentence with zero filler. It is efficient, but the terseness contributes to the missing usage and behavioral context rather than being an appropriately complete definition.

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 that spawns a persistent external editor process with openWorldHint=true and no output schema, the description should say what the agent gets back and how the session lifecycle works. Neither the process lifecycle nor the sibling routing is addressed, leaving the agent under-informed despite full schema coverage.

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

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

Schema description coverage is 100%, and the schema itself explains that projectPath is the project directory and sessionId is the handle required for follow-up tools. The description adds no further meaning, so the baseline 3 applies.

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

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

States a specific verb ('Launch') and resource ('Godot editor') scoped to a project, so the agent knows exactly what operation occurs. However, it offers no differentiation from siblings such as run_project, start_debug_session, or run_playtest, which all sound like they 'start' something Godot-related.

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

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

There is no guidance on when to launch the editor versus run_project, run_scene, or start_debug_session, nor on when this is inappropriate. The agent must infer the distinction purely from the sibling names, which overlap heavily.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description goes beyond that by disclosing two non-obvious behaviors: pagination is bounded, and errors are reported per-record rather than failing the whole call. It also confirms reading has no resolve side effect, which matters given a sibling named resolve_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?

Two tight sentences with zero filler; the resource and the scope constraint are front-loaded before the side-effect clarification. Every clause carries information.

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

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

An output schema exists, so return values need not be explained, and the pagination/partial-failure model is stated. The gap is on the input side: with 0% schema coverage and a status filter, the definition leaves an agent guessing about the semantics of open vs resolved vs all.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, but "bounded pagination" only loosely gestures at limit and cursor and never states the upper bound. The status enum (open/resolved/all) — the most semantically important filter — and projectPath are left entirely unexplained by both schema and description.

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

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

States a specific verb+resource ("Read submitted immutable annotations") and adds the distinguishing property that these are immutable submissions read with bounded pagination. It implicitly separates itself from resolve_annotation via "Reading never resolves records," though it never names the sibling that fetches a single annotation.

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?

"Reading never resolves records" implies that mutation of annotation state belongs to a different tool, which is useful routing. However, there is no explicit guidance on when to use this bulk listing versus get_annotation or get_annotation_status, and no exclusion criteria are stated.

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

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

Annotations already declare this as a safe, read-only, non-destructive operation, so the description does not need to repeat that. It adds useful behavioral details beyond annotations: hidden directories and symlinks are excluded, and results are bounded, though the bound itself is not specified.

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

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

The description is a single compact sentence with no filler, and the primary scope is front-loaded. Every clause contributes either asset scope or filtering/bounding 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?

For a four-parameter tool with no output schema, the description gives core scope and two important filters, but it leaves out return shape, whether traversal is recursive, ordering, and clearer limit semantics. It is adequate but not fully complete for an agent relying on the description alongside a partially documented schema.

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

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

Schema description coverage is 50%, with projectPath and pattern documented in the schema. The description adds some meaning by naming scene, script, and resource categories, which maps to the type enum, and by implying bounded results, which relates to limit; however, it does not clarify pattern syntax, limit behavior, or default values.

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 clear discovery operation over specific project asset types: scenes, scripts, and resources. It does not explicitly differentiate from sibling tools such as list_projects or get_project_overview, but the resource scope is specific enough to identify what the tool does.

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

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

Usage is implied by 'Discover scenes, scripts and resources,' but there is no explicit when-to-use guidance and no named alternatives or conditions for choosing this over related listing/introspection tools. The exclusion of hidden directories and symlinks describes result scope rather than usage routing.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it doesn't say what counts as a Godot project (presence of project.godot?), what the result looks like, or how recursion affects output size — all useful context for a discovery tool with no output schema.

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

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

A single front-loaded sentence with zero filler, but its brevity edges toward under-specification for a tool that returns an undocumented result shape.

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

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

With no output schema, the description carries the burden of explaining what is returned — project paths, names, counts, or metadata — and it says nothing. It also omits the definition of 'project' detection, leaving a real gap for an agent deciding whether this tool will answer its question.

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

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

Schema description coverage is 100%, with both 'directory' and 'recursive' (including its default) documented in the schema, so the baseline is 3. The description contributes no additional semantics such as expected path format or recursion depth behavior.

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

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

States a specific verb ('List') and a specific resource ('Godot projects in a directory'), which an agent can distinguish from file-level siblings like list_project_files or single-project siblings like get_project_info. It never explicitly names those siblings, so differentiation is inferred from the noun rather than stated.

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

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

There is no guidance on when to choose this over list_project_files or get_project_overview, and no prerequisites or exclusions are given. The agent must infer usage entirely from the name.

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

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

Annotations already indicate readOnlyHint=false, openWorldHint=true, and destructiveHint=false, so the safety profile is partially covered. However, the description adds no behavioral context beyond 'load', such as whether the scene must be saved afterward, what happens if the node is missing, or how texture paths are resolved.

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

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

The description is a single front-loaded sentence with no wasted words. It is appropriately concise, though its brevity contributes to gaps in usage and behavioral guidance.

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 four required parameters, no output schema, and openWorldHint=true, the description is too sparse. It omits key context such as save behavior, error conditions, and relationship to sibling tools, leaving the agent under-informed despite the complete parameter schema.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the input schema. The description adds no additional parameter meaning, making the baseline score of 3 appropriate.

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

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

The description states a specific verb ('Load') and resource ('sprite') and names the exact target node type ('Sprite2D node'). It is clear what the tool does, though it does not explicitly distinguish itself from siblings like set_node_properties or create_resource.

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

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

There is no guidance on when to use this tool versus alternatives such as set_node_properties, create_resource, or instance_scene. The description gives only the action, leaving the agent to infer the appropriate context.

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 annotations already declaring destructive and open-world behavior, the description adds meaningful context beyond them: it saves once after ordered operations, executes constructors, refuses inherited or instanced edits, and rejects uncertain references. It still omits failure/rollback semantics and permission requirements, but it substantially characterizes behavior.

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

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

The description is dense and front-loaded: the core batch/save behavior comes first, followed by preview guidance and safety constraints. Every sentence contributes operational 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?

For a complex batch mutation tool with no output schema, the description covers supported operations, previewing, and key refusal behaviors well. It remains incomplete on parameter structure, per-operation results, and what dryRun returns, which an agent would need for correct composition.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It mentions dryRun, expectedHash, and the 100-operation limit, but says nothing about projectPath, scenePath, required nodePath fields, or how the operation object fields map to each op 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: applying scene operations in order and saving once. It clearly identifies this as a batch mutation tool by specifying up to 100 operations and listing supported operation categories, though it does not explicitly name sibling alternatives like add_node or set_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?

It explains preview usage with dryRun and notes that expectedHash guards stale previews, which gives clear context for safe invocation. However, it never states when to use this batch tool versus single-operation siblings such as instance_scene, duplicate_node, or set_node_properties.

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 earns credit by naming the concrete consequence ('Unsaved editor changes may be lost') and the blocking behavior ('wait for exit'). Not a full 5 only because it doesn't say what happens if no editor is running or what is returned after exit.

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 short sentences, zero filler, with the destructive caveat placed immediately after the action so it is read before invocation.

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

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

For a no-output-schema, zero-required-param termination tool, the description covers action, scope, consequence, and blocking semantics. Minor gap: no statement of what happens if no editor is running or how the exit is reported.

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

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

Schema coverage is 100% and the single optional sessionId is fully documented in the schema, so the baseline of 3 applies. The description adds nothing about when sessionId matters or what the default behavior is without it.

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

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

Specific verb+resource: 'Terminate the editor launched by this server'. The scoping phrase 'launched by this server' helps distinguish it from a general editor shutdown, though it never names the nearest siblings (stop_project, close_session) that an agent might confuse it with.

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

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

Usage is only implied: you call it when you're done with the editor. There is no explicit statement about when to prefer this over stop_project or close_session, and no note about whether it should be called before other teardown tools.

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

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

Annotations declare a non-read-only, non-destructive, open-world mutation; the description adds real context beyond that — the validation performed (path and built-in name conflicts), the explicit scope limit (no script/runtime compatibility checking), and the refusal-unless-replace guardrail. It stops short of saying which project file is written or what happens to dependent scenes at runtime.

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

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

Three dense sentences with zero filler: capability first, then validation scope, then the override/dry-run controls. Every clause adds information an agent needs before calling.

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 an output schema present the description needn't explain returns, and annotations already cover the safety profile, so the remaining burden is behavior and parameters — both addressed. For a 7-parameter mutation tool this is complete enough 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 description coverage is 0%, so the description must carry parameter meaning, and it does for most: name (conflict against built-in names), resourcePath (must be an existing .gd/.cs/.tscn/.scn), singleton (named singleton vs plain autoload), replace, dryRun, expectedHash. Only projectPath and the exact hash semantics of expectedHash are left to inference.

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 named singleton or plain autoload") plus the exact accepted resource types (.gd/.cs/.tscn/.scn). This cleanly distinguishes it from the sibling unregister_autoload and from create_resource, which handles resources but not autoload registration.

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 preconditions and override paths: conflicts are checked, a different existing entry is refused unless replace:true, and dryRun/expectedHash are offered for safe application. It does not explicitly say when to prefer unregister_autoload + re-register over replace:true, so the alternative-selection guidance is implicit rather than spelled out.

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

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

Annotations already declare destructiveHint=false and readOnlyHint=false; the description adds real context the annotations lack — what is deleted (unchanged addon-owned files only), what is spared (annotation data), and a post-condition (an open editor must be reopened to unload). It does not explain what happens to modified files, which is the remaining behavioral unknown, so not a 5.

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

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

Two sentences, no filler, with the scope/preservation constraint front-loaded and the editor-reload caveat as a trailing operational note. Nothing to cut.

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 need not be described, and the annotations set the safety baseline. But for a filesystem-mutating tool with two entirely undocumented parameters (dryRun, expectedHash) and no statement of what failure looks like when files have changed, the description leaves a material gap.

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

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

Schema description coverage is 0% across three parameters, so the description must carry the load and does not: dryRun and expectedHash are never mentioned, and 'unchanged' only loosely gestures at expectedHash without defining what hash or what mismatch does. Only projectPath's role is inferable from context.

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

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

States a specific verb pair and resource: 'Disable and remove ... addon-owned files', and scopes it with 'only unchanged'. That clearly distinguishes it from ensure_annotation_addon and the read-only annotation tools (list_annotations, get_annotation_status), though it never names the sibling it complements.

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

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

Usage is implied by the 'only unchanged' qualifier and the note that an open editor must be reopened, but there is no explicit 'use this when' or reference to the ensure_annotation_addon counterpart. An agent must infer that this is the teardown counterpart of the addon setup 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 destructiveHint=true, readOnlyHint=false, and openWorldHint=true. The description adds useful behavioral context beyond those annotations by explaining that removing a built-in override restores the default on next launch, that this does not disable a built-in action, and that dryRun and expectedHash are supported.

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 compact sentences with no redundant wording. The core action is front-loaded, followed by the important built-in override caveat and the optional parameters.

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

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

The description adequately covers the tool's core behavior and built-in override nuance, and the output schema means return values need not be explained. However, with 4 parameters at 0% schema description coverage, the description leaves required parameters like action and projectPath unexplained, which is a meaningful gap for a destructive tool.

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

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

Schema description coverage is 0%, so the description must compensate. It only says 'Supports dryRun and expectedHash' without explaining what dryRun does or what format expectedHash takes, and it says nothing about the required action or projectPath parameters.

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

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

The description states a specific verb and resource: 'Remove a configured input action.' It also distinguishes the operation from disabling a built-in action by explaining that removing a built-in override restores its default on next launch. This clearly separates it from sibling tools like set_input_action and get_input_actions.

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

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

The description gives clear context for when removal has a specific effect: removing a built-in override restores its default, and this does not disable a built-in action. It does not explicitly name alternatives or state when not to use the tool, but the built-in distinction provides meaningful usage context.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description still adds real value beyond them: it discloses that unrelated config is preserved, that engine defaults may take effect, and that dryRun and expectedHash guards exist — all consequence information not encoded in 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?

Three compact sentences with the core action and consequence front-loaded. Slightly clipped, but nothing is redundant.

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

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

An output schema exists, so return values need no explanation, and annotations cover the destructive profile. However, for a mutation tool with four completely undocumented parameters, the description leaves the agent unable to construct a safe call — particularly how expectedHash should be sourced.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it does not. It merely name-drops 'dryRun' and 'expectedHash' without explaining semantics (e.g., that expectedHash is an optimistic-concurrency token), and the two required parameters projectPath and setting receive no explanation anywhere.

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 ('Remove a stored project setting override') and clarifies scope with 'preserving unrelated configuration.' It is clearly distinguishable from get_project_setting and set_project_setting, though it never names those siblings explicitly.

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

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

The description implies when to use it (removing an override so engine defaults apply), but gives no explicit when-not guidance or comparison to set_project_setting, which could also revert a value. The agent must infer the choice from the sibling names.

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

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

Beyond the annotations (readOnlyHint false, destructiveHint false), the description discloses that stale writes are refused and that a revision from retrieval is mandatory. This adds meaningful concurrency and safety context. It could go further on what happens to the annotation's other fields, but the core behavioral trait is covered.

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

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

Two tightly written sentences with no filler; the prerequisite and the stale-write warning are front-loaded and directly useful.

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 an output schema present and annotations covering the safety profile, the description supplies the key operational facts: required revision and stale-write rejection. The gap is minor, mostly around the unmentioned projectPath and annotationId, which are self-descriptive names.

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

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

Schema description coverage is 0%, so the description must carry the load. It clarifies the meaning of expectedRevision ('revision returned by retrieval') and implies status via 'resolve or reopen', but it says nothing about projectPath or annotationId. The added meaning is partial rather than complete.

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 pair ('resolve or reopen') and the resource ('annotation'), and the word 'explicitly' distinguishes it from passive retrieval siblings like get_annotation or list_annotations. It doesn't explicitly name a sibling alternative, but the action is unambiguous.

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

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

It clearly states the prerequisite ('Requires the revision returned by retrieval'), which effectively tells the agent to call a retrieval tool first. It doesn't spell out when to reopen versus resolve, but the context of a stale-write refusal gives 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=false and openWorldHint=true, so the agent knows this is not a pure read operation. The description adds meaningful behavior beyond that: bounded output, timeout handling, and cancellation, though it does not detail side effects on the project or how cancellation is enforced.

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

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

Two sentences, front-loaded with the core action and followed by the most important parameter constraint. There is no redundant or filler language.

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

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

For a 7-parameter tool with very low schema description coverage, the description is too sparse. It mentions timeout and output bounds but does not explain most parameters or their effects, and it says nothing about default behavior or execution side effects.

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

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

Schema coverage is only 14% across 7 parameters. The description adds a critical constraint for testFile and directory exclusivity, but leaves projectPath, headless, logLevel, timeoutMs, and includeSubdirs undocumented beyond the sparse 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 gives a specific verb and resource: 'Run installed GUT tests'. 'GUT' distinguishes it from generic scene or project runners such as run_scene_test and run_playtest, though it does not explicitly route against those siblings.

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

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

It provides a useful selection rule: 'Choose exactly one testFile or directory.' However, it does not explain when to use this tool instead of run_scene_test, run_playtest, or run_project, so the agent must infer the broader usage context.

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

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

Adds substantial behavior beyond the annotations: inputs are delivered on the following frame step (ordering semantics), reference PNGs are never updated (no baseline mutation despite a comparison step), the game is always stopped, the session's game is replaced, and simulation is explicitly non-deterministic. These are exactly the traits an agent cannot infer from readOnlyHint/destructiveHint/openWorldHint.

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

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

Four dense, front-loaded sentences with almost no filler; the isolation and teardown guarantees come first. The 'Returns evidence and pass/fail' sentence is the least necessary, since an output schema already exists, but it is brief.

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?