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

With no annotations provided, the description carries the full burden of behavioral disclosure. It says 'Adds', which implies a mutation, but does not mention side effects like whether the scene file is saved to disk, what happens if the parent path doesn't exist, or any failure behavior. This is minimal for a mutation tool.

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

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

The description is a single, front-loaded sentence with no filler. It communicates the primary action and the key special case efficiently, making it easy for an agent to parse quickly.

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 mutation tool with no annotations and no output schema, this description is incomplete. It does not explain how properties or script_path are applied, what happens to the scene after the node is added, or how it fits with sibling tools. An agent has to infer too much to call it correctly.

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

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

The description mentions 'use "." for the scene root', but this is already covered in the schema's parent_path description. It adds no meaning for name, scene_path, project_path, or the interplay between properties and script_path. With schema coverage at 57%, the description should compensate for undocumented parameters but fails to do so.

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

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

The description clearly states a specific verb ('Adds'), resource ('a child node to an existing scene'), and location ('parent path'), making the core operation unambiguous. However, it does not explicitly differentiate from sibling tools like editor_add_node, so it does not fully satisfy the 'distinguishes from siblings' bar.

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 'existing scene' implies this tool is for modifying existing scenes rather than creating new ones, but there is no explicit when-to-use/when-not-to-use guidance or reference to alternatives such as editor_add_node. Usage is only implied, not 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?

No annotations are provided, so the description carries full burden. It only states the basic action without disclosing side effects like overwrite behavior, file creation failure handling, or permissions. For a mutation tool that creates a file, this is insufficient.

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

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

Two sentences, with the core action front-loaded. No fluff, efficient.

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

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

The tool has 5 parameters and 4 required, and no output schema. The description is minimal and doesn't explain the meaning of required parameters, overwrite behavior, or error conditions. It also doesn't clarify the distinction from editor_add_node, which could confuse an agent.

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

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

Schema coverage is only 40%, with root_type and scene_path described. The description does not add any parameter semantics beyond what the schema provides, leaving project_path, root_name, and overwrite unexplained. Given the low coverage, the description should compensate but doesn't.

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

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

The description clearly states it creates a new .tscn file with a single root node, which is a specific verb and resource. It also hints at the workflow with add_node, though it doesn't explicitly differentiate from other scene-related tools.

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

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

It provides a clear usage context: create the scene first, then use add_node to build the tree. However, it doesn't mention any alternatives or when not to use it, nor does it clarify prerequisites like project path existence.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It covers live appearance, selection, undo via Ctrl+Z, and non-persistence until save. It does not mention failure modes or editor availability, so it is not exhaustive, but it is unusually informative.

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 containing essential information: the core purpose, immediate behavioral effects, and save/alternative guidance. 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?

For a mutation tool with no annotations or output schema, the description covers the most important operational facts: live update, selection, undo, non-save, and sibling distinction. It omits return values and edge cases like 'editor not open', but the essentials for correct invocation are present.

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

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

Schema description coverage is 83%, so the schema already documents most parameters in detail. The description adds no parameter-specific meaning beyond what the schema provides, which is acceptable but not additive.

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: 'Adds a node to the scene open in the Godot editor.' It also explicitly differentiates itself from the sibling add_node by saying 'Prefer this over add_node while the editor is open.'

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 usage context: use this when the editor is open, prefer it over add_node under those conditions, and understand that the scene isn't saved until editor_save_scene. This effectively routes the agent between competing 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?

No annotations are provided, so the description carries the full burden. It states that it 'returns' data, which implies a read-only operation, but does not disclose any side effects, performance implications, or limitations. For a simple getter, this is minimal but acceptable; it does not contradict anything and provides basic behavioral context.

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

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

A single sentence that is front-loaded with the core action and result. No wasted words, and the return value is clearly specified. It is appropriately sized for a tool with no 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?

With no output schema, the description is the sole source of return information. It clearly states both the scene tree and the list of open scenes, which is sufficient for an agent to know what to expect. Given the simplicity of the tool, this is complete enough, though it could optionally mention whether the result is read-only or cached.

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 the baseline is 4. The description does not need to add parameter details because there are none. It correctly focuses on the output instead.

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 ('Returns') and resource ('scene currently open in the Godot editor as a node tree, plus the list of open scenes'). It clearly distinguishes itself from siblings like editor_get_selection (which returns selection) and editor_open_scene (which opens a scene). The purpose 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 no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. However, the purpose is self-evident for a getter, and the context of siblings implies it is the tool for retrieving the scene tree. Still, no explicit routing guidance is provided, so a 3 is appropriate.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It accurately indicates this is a read-only retrieval operation, but it does not explain what the returned node selection looks like, whether it can be null/empty, or whether it reflects only the active editor viewport. The core behavior is stated, but the output format is left undefined.

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 one sentence with no filler, front-loading the action and resource. Every word contributes to the agent's understanding.

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 parameterless getter with no output schema, the description gives the essential purpose and no side-effect concerns. It would be more complete if it stated the returned value format in one clause, but the absence of inputs and the simple read-only nature make this largely sufficient.

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?

This tool has zero parameters, so there is nothing for the description to clarify beyond noting that no arguments are needed. The baseline of 4 applies because schema coverage is vacuously complete and no parameter semantics are required.

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 ('Returns'), a specific resource ('currently selected node(s)'), and a context ('Godot editor'). It is clearly distinct from siblings like editor_get_scene_tree, which returns a scene tree, and editor_ping, which highlights something in the editor.

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 editor_get_scene_tree or read_scene. It does not mention prerequisites like an open scene, nor the kind of selection state needed for a useful call. The intended usage is only implied by the tool's 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 no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the side effect of switching to the editor tab, which is useful, but does not disclose potential failure cases (e.g., if the scene does not exist) or that it changes the editor's UI state without modifying the scene. This is a moderate gap for a non-destructive operation.

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, concise sentence that front-loads the primary action and purpose. Every word contributes to understanding the tool's function, and it does not waste space on redundant details.

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

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

For a simple tool with one parameter and no output schema, the description is sufficient to guide an agent. It explains the action, the resource, and its role in the editing workflow. The only missing piece is explicit error behavior for non-existent scenes, which is a minor omission for an opening command.

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

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

The input schema has 100% coverage for the single parameter, including an example format. The description does not add additional parameter semantics beyond the schema, so the baseline of 3 is appropriate since the schema already documents the parameter thoroughly.

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

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

The description clearly states the specific action (opens a scene), the resource (a scene in the Godot editor), and the purpose (to enable live editing via editor_add_node, editor_set_properties, and editor_remove_node). It distinguishes itself from sibling tools by focusing on opening an existing scene for editing, rather than creating, reading, or manipulating nodes directly.

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 the tool is a prerequisite for live editing tools by stating it enables them. However, it does not explicitly mention when to avoid using it or alternative tools such as read_scene for inspection. The context is clear for its intended use, but lacks explicit exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only check but does not specify the return value (e.g., boolean indicating success/failure), error behavior if the editor is not running, or whether the check has any side effects. This is a significant gap for a zero-parameter tool where the agent must know what to expect.

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, concise sentence that is front-loaded with its core purpose. It contains no fluff or redundancy. Every word contributes to the agent's understanding of what the tool does.

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 is simple (0 params, no output schema), but the description still lacks critical context. It does not explain what the agent will receive (e.g., a boolean, a message, or an error if the editor is missing). It also does not position the tool among its siblings, such as whether it should be called before other editor tools. This makes it incomplete for an agent that needs to decide when and how to use 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?

The tool has no parameters, and the schema reflects that. Per the rule for 0 params, the baseline is 4. The description does not need to explain parameters since there are none, and the schema coverage is effectively 100%. The description adds no parameter-related value because there is nothing to add.

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 ('Checks') and resource ('whether the Godot editor is running with the godot_mcp_bridge plugin enabled'). This clearly distinguishes it from sibling tools like editor_run_scene or editor_get_selection, which perform different operations. The purpose is immediately 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 provides no guidance on when to use this tool versus the many sibling editor tools. It does not mention that it could be used as a prerequisite check or as a way to verify the environment before invoking other tools. There is no explicit when-to-use or when-not-to-use 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 no annotations, the description carries the full burden. It discloses the destructive scope ('and its descendants'), the immediate live effect, and reversibility ('undoable with Ctrl+Z'). It does not mention potential auth or failure conditions, but the core behavioral traits are clearly exposed.

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 sentence packs the action, scope, target context, and undo behavior with no filler. It is front-loaded and every part earns its place.

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

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

For a direct mutation tool with no annotations or output schema, this description covers the core behavior, scope, and reversibility, and the schema covers the safety parameter. The main missing piece is node_path syntax detail, which slightly limits completeness but does not undermine correct usage for an agent familiar with Godot paths.

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%: node_path is undocumented while scene_path has a safety description. The tool description clarifies that node_path is the node to remove and implies an editor tree path, but it does not specify format, root-relative vs absolute, or example values, so it only partially compensates.

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 action ('Removes'), a precise resource ('a node (and its descendants)'), and the context ('from the scene open in the Godot editor'). It also adds distinctive traits—live and undoable—that separate it from siblings like remove_node or editor_add_node.

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

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

The context is clear: this operates on the live Godot editor scene and is undoable, implying it is for interactive editor edits. However, it does not explicitly contrast itself with remove_node or state when to prefer one over the other, so it misses full exclusion 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?

No annotations are provided, so the description carries the burden. It discloses the core behavior (sending a play command to the running editor), but it does not mention side effects, like whether current playback is stopped, whether unsaved changes are affected, or whether the call blocks until the scene loads. The analogy provides some context but not full transparency.

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

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

A single concise sentence that immediately states the action and includes a useful analogy. No wasted words; all content earns its place.

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

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

For a simple, one-parameter command tool with no output schema, the description plus schema coverage are sufficient for an agent to call it correctly. It lacks details on failure modes or return behavior, but these are less critical given the low complexity and the editor-control nature.

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

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

Schema description coverage is 100%, so the parameter scene_path is already documented with an example. The description adds no extra meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

States a specific action and resource: tells the running Godot editor to play a specific scene, with a helpful analogy to pressing the Play Scene button. This clearly distinguishes it from siblings like editor_stop and run_headless, which are about stopping or running without the editor.

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 analogy implies usage context (when you want to start a scene in the editor), but there is no explicit guidance on when to use this versus sibling tools like run_headless or editor_stop. No alternatives or exclusions are mentioned, so usage is left to inference.

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

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

With no annotations, the description carries the full burden. It discloses that the tool writes the current scene to disk, which is the key side effect, but it does not explicitly mention that an existing file will be overwritten, whether changes are reversible, or what happens if no scene is open. The Ctrl+S analogy partially covers standard overwrite 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?

One sentence, front-loaded with the action, and every word earns its place. The Ctrl+S comparison adds clarity without bloat.

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

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

For a zero-parameter tool, the description is largely complete: it names the action, target, and result. It would benefit from an explicit note about overwriting or failure behavior, but given the low complexity and the Ctrl+S analogy, the remaining gaps are minor.

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

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

The tool accepts zero parameters and the input schema is empty, so the description cannot add parameter meanings. The baseline for a 0-parameter tool is 4, and no parameter documentation is needed 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?

States a specific verb (Saves), resource (the scene currently open in the Godot editor), and destination (to disk). The Ctrl+S analogy makes behavior instantly recognizable and clearly distinguishes it from sibling tools like editor_open_scene or editor_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?

The description implies when to use it: to persist the currently open scene, analogous to Ctrl+S. It does not explicitly discuss alternatives or when not to use it, but with no save-like siblings in the tool list the intended usage is reasonably clear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly discloses that the operation is live, undoable, and not saved until editor_save_scene, which are important behavioral traits. It also mentions the optional scene_path safety check in the schema, but the description itself does not elaborate on failure modes or side effects beyond the undo/save 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 a single sentence that is concise and front-loaded with the core action ('Sets properties on a node'), followed by key behavioral caveats. Every word earns its place, and it avoids redundancy with the schema.

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

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

Given the tool's moderate complexity (3 params, no output schema, no annotations), the description covers the essential behavioral context: live, undoable, not saved. It could be more complete by explicitly mentioning the optional scene_path safety check or the Godot-syntax requirement, but the schema already covers those. The description is sufficient for an agent to understand the tool's role and 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 description coverage is 100%, so the schema already documents all three parameters. The description adds a bit of context by noting the operation is live and undoable, but it does not add meaning beyond the schema for the parameters themselves. The example in the schema ('position': 'Vector2(100, 50)') already clarifies the Godot-syntax requirement, so the description's contribution is minimal.

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 ('Sets') and resource ('properties on a node in the scene open in the Godot editor'), which clearly identifies the tool's function. It does not explicitly differentiate from the sibling 'set_node_properties', but the mention of 'live, undoable with Ctrl+Z' and 'not saved until editor_save_scene' provides some distinguishing context.

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

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

The description implies usage context: it operates on the live editor scene and is undoable, and it notes that changes are not persisted until editor_save_scene. However, it does not explicitly state when to use this tool versus alternatives like set_node_properties or editor_add_node, nor does it mention any exclusions or prerequisites.

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

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

With no annotations, the description carries the behavioral disclosure burden. It clarifies that this is a command to the running Godot editor rather than a file operation, which is useful. However, it does not disclose side effects such as whether the call is asynchronous, what happens when no scene is playing, or whether any error/status is returned.

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 filler. It communicates the target environment, the action, and the affected resource without wasting words.

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

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

For a parameterless control command, the description is largely complete: it names the target (running Godot editor) and the operation (stop currently playing scene). It would be marginally better with explicit note of no-op behavior or return semantics, but those are not essential given the tool's simplicity.

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 the input schema imposes no documentation burden. The description does not need to explain parameter meaning, and the baseline score of 4 applies because there is nothing for the description to compensate for.

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 ('stop') and resource ('currently playing scene'), making the tool's purpose unambiguous. It does not explicitly differentiate itself from sibling tools like editor_run_scene, but the reverse relationship is clear enough for an agent to infer the 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?

The phrase 'currently playing scene' implies the tool should be used when a scene is running and needs to be stopped. However, there is no explicit guidance about when not to use it, what happens if no scene is playing, or how it compares to alternatives like editor_run_scene or run_headless.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully specifies that only one exact occurrence is replaced and frames the operation as patch-like, which adds real meaning. However, it does not disclose what happens if old_text is not found, whether the file is modified in place, or any side effects of this mutation.

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

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

The description is a single, front-loaded sentence that conveys the core operation and scope without technical filler. The analogy is compact and reinforces meaning without adding bulk. Every word serve the core message.

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 mutating tool with no annotations, no output schema, and zero schema descriptions, so the description must do heavy lifting. It leaves important context missing: error behavior when the exact text is absent, path semantics, interaction with existing script state, and why edit_script is preferable to write_script.

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 for all four parameters. It clarifies the roles of old_text and new_text, but leaves project_path and script_path unexplained, including how they relate to each other. This is only partial compensation for completely undocumented 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 ('Replaces'), a precise resource ('one exact occurrence of old_text with new_text in a GDScript file'), and uses an analogy ('like a find-and-replace patch'). This clearly distinguishes it from sibling tools like write_script or read_script, which would operate on entire file contents rather than a single targeted occurrence.

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

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

The description explains the mechanism but gives no guidance on when to choose edit_script over alternatives such as write_script or read_script. There is no mention of prerequisites, exclusions, or scenarios where a full-file replacement would be more appropriate.

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

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

No annotations are present, so the description carries the full burden. It adds file-type scope and that output is relative to project_path, but does not disclose whether traversal is recursive, whether directories are included, or what the return format looks like.

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 clean, grammatically straightforward sentence with no filler. The action and object are front-loaded, and every clause adds relevant detail.

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

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

Adequate for a simple read-only tool, but incomplete on return details: there is no output schema, and the description does not state whether subfolders are scanned or how results are presented. An agent needs this to trust the listing's completeness.

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

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

The schema already describes project_path as 'Absolute path to the Godot project folder', reaching 100% coverage. The description adds no new parameter meaning; 'relative to project_path' clarifies the output base, not the parameter itself.

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?

Describes a specific verb ('Lists') and resource (scenes, scripts, and resources in a Godot project folder), with precise file extensions (.tscn/.gd/.tres/.res). Clearly distinguishes from sibling tools like read_scene or create_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?

No explicit when-to-use or alternative routing is provided. The purpose implies it is for enumerating project files, but it doesn't mention when to prefer this over editor_get_scene_tree or other related 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?

With no annotations, the description carries the burden of behavioral disclosure. It does indicate the return value and fields ('name, type, parent path, properties'), which is useful. However, it does not explicitly state that the tool is read-only, how invalid or missing files are handled, or whether it affects the editor state.

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 that communicates the core action, target file type, and return structure without any filler. Every element earns its place.

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

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

For a tool with no output schema, no annotations, and a partially documented input schema, the description provides the output shape but omits important operational context like project_path semantics, failure modes, and when to prefer this over editor-based siblings. It is adequate but not fully complete.

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

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

Schema coverage is only 50%: scene_path is described, but project_path has no schema description. The description does not add any parameter-level meaning beyond the schema, so it fails to compensate for the undocumented project_path parameter, leaving its role and relationship to scene_path mostly implicit.

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 ('Parses'), a specific resource ('.tscn file'), and the output format (JSON with name, type, parent path, properties). This clearly distinguishes it from siblings like editor_get_scene_tree, which operates on the editor's current scene, or read_script, which handles scripts.

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 explicit guidance is given about when to use this tool over alternatives such as editor_get_scene_tree, editor_open_scene, or list_project. The description only states what the tool does; the agent must infer usage from the phrase 'Parses a .tscn file' without any comparison or 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 no annotations provided, the description carries the full behavioral burden. 'Reads' clearly indicates a non-destructive operation, but the description does not disclose details such as path interpretation, encoding, error behavior, or whether the full file content is returned verbatim.

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, focused sentence with no filler. It states the verb, target file type, and what is returned in a compact, front-loaded way.

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

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

For a simple read tool, the description is minimally viable, but it lacks essential context for calling it correctly, such as how project_path and script_path relate and what the output looks like. There is no output schema to fill that 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%, yet the description adds no meaning to project_path or script_path. The parameter names are somewhat self-explanatory, but the description does not explain expected formats, path relationships, or whether paths are relative to the project root.

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 verb ('Reads') and resource ('GDScript (.gd) file's contents'), making the tool's purpose unmistakable. It also implicitly differentiates from sibling tools like write_script and edit_script by focusing only on reading.

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 guidance is given on when to use this tool versus alternatives. The description does not mention write_script, edit_script, or any conditions that would route an agent to one tool or the other.

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

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

With no annotations, the description must disclose behavior itself. It does disclose the key destructive detail that descendants are removed along with the node. However, it does not state that this mutates the scene file permanently, whether it requires special permissions, or what the effect is on the editor state, so transparency is incomplete.

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 sentence with no filler. The verb and the most important behavioral caveat (descendants) are 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?

Given no output schema and no annotations, this is a sparse tool definition. The description does not address how this differs from the sibling editor_remove_node, whether removal is permanent and saved, or what the tool returns/confirms on success. For a destructive operation with multiple similar siblings, more context is needed.

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 needed to explain the parameters. It only indicates that 'node' refers to the node being removed (including descendants), but does not clarify the meaning/format of project_path, scene_path, or node_path, nor how they relate. The parameter names help, but the description does not compensate for the missing schema descriptions.

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

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

States a specific verb and resource: 'Removes a node (and its descendants) from a scene.' This is clear and adds the descendant detail. However, it does not differentiate from the sibling editor_remove_node, which likely performs the same conceptual 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?

No guidance on when to use this tool versus editor_remove_node, add_node, or set_node_properties. The description only states what it does, not the conditions or context for choosing it. With a near-identical sibling name, this is a real gap.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'headlessly (no window)' and 'for a fixed duration', but fails to explain what happens after execution, how errors are reported, whether the call blocks, or the nature of the return value. This is a significant gap for a tool that runs a project.

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

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

The description is concise, consisting of two sentences. It front-loads the core purpose and includes only essential information, such as the binary requirement, with no filler or repetition.

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

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

Given the tool has no output schema and no annotations, the description should provide more details about the execution behavior, such as what constitutes success, how errors are surfaced, and whether the tool is blocking. The current description leaves critical operational aspects unspecified, making it incomplete for an agent to rely on.

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

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

The schema has low coverage (33%) with only scene_path described. The description hints at scene_path via 'runs a specific scene' and timeout_ms via 'fixed duration', adding some context beyond the schema. However, it does not explicitly define parameters, defaults, or how they map to the two modes, leaving room for ambiguity.

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 action ('Runs the Godot project headlessly') and a clear purpose ('to catch parse/runtime errors'), with an alternative mode for running a specific scene. It clearly distinguishes from editor_run_scene by emphasizing headless execution, which is a key differentiator among siblings.

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

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

The description implies usage for validating a project's error-free state via headless execution, but it does not explicitly state when to prefer this over editor_run_scene or other tools, nor does it mention any exclusions. The requirement for the godot4 binary is a prerequisite rather than 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that properties are set or overwritten, implying a write operation, but it does not explain what happens if the node does not exist, whether properties are merged or fully replaced, whether changes are persisted automatically, or any side effects. For a mutation tool, this is insufficient.

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, concise sentence that front-loads the action and object. There is no extraneous information, and it is well-structured for quick reading. It earns a perfect score for conciseness, though this brevity contributes to incompleteness 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?

Given the tool has four required parameters, a nested object, no output schema, and no annotations, the description is severely incomplete. An agent has no information about return values, error conditions, the format of property values beyond an example, or how this tool relates to the editor_* siblings. It leaves too much to inference, making it inadequate 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 only 25%, with only the 'properties' parameter having a description. The description does not compensate by explaining the roles of project_path, scene_path, or node_path. It only implicitly ties 'properties' to the action but adds no meaning beyond the schema's example. With low schema coverage, the description should clarify these parameters but does not.

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

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

The description clearly states the action: 'Sets or overwrites one or more properties on an existing node in a scene.' It identifies the verb (set/overwrite), the resource (properties on a node), and the context (scene). This distinguishes it from tools like add_node or remove_node, but it does not differentiate itself from the sibling editor_set_properties, which likely performs a similar operation in the editor context, so it lacks explicit differentiation.

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 guidance is given on when to use this tool versus alternatives. With siblings like editor_set_properties and various editor_* tools, an agent cannot infer whether this tool operates on files directly or requires an open scene, nor when to prefer it over the editor variant. The description offers no contextual cues for 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?

The description discloses the key behavioral trait: it fully overwrites, not merges or appends. With no annotations provided, the description carries the burden, and it does convey the destructive nature of the operation. However, it does not mention whether the file is created if missing, whether directories are created, or what happens on failure.

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, efficient sentence that front-loads the key behavior ('Creates or fully overwrites'). It earns its place with no wasted words, though it could add a brief usage note without becoming bloated.

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 write tool with no annotations and no output schema, the description is adequate but thin. It tells the agent the operation is destructive, which is the most critical fact, but it omits details like whether parent directories are created, whether the file must already exist for overwrite, and how it differs from edit_script. Given the sibling set includes both read_script and edit_script, a bit more context would help.

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%, with only script_path having a description. The description itself adds no parameter-level detail beyond the schema. The tool description does clarify the overall purpose of content (the full file contents), but it does not explain project_path semantics or the relationship between project_path and script_path.

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 ('Creates or fully overwrites') and a specific resource ('GDScript (.gd) file'). It clearly distinguishes the write operation from sibling tools like read_script and edit_script, though it does not explicitly name those alternatives.

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 this tool: when creating a new script or fully replacing an existing one. However, it does not explicitly contrast with edit_script, which is the natural alternative for partial modifications, nor does it state any prerequisites or conditions.

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