Skip to main content
Glama

Change a scene

godot_scene_edit
Destructive

Edit .tscn scenes without the Godot editor: add or remove nodes, set properties, connect signals, and attach scripts, previewing a diff before writing changes.

Instructions

Change a .tscn safely, without the editor: add a node (a Godot class or an instanced scene), remove a node (with its children, connections and the resources only it used), set a property (name and type checked against Godot 4.7; enums by name, resources as res:// files), connect or disconnect a signal (checks the signal exists, and warns when the method is missing or takes the wrong number of arguments, with the func line to add), or attach a script (refuses one that extends another node type). Node paths are relative to the scene root, which is ".". op picks the change and which fields it needs: add_node (parent, name, and type or instance), remove_node (node), set (node, property, value), connect and disconnect (from, signal, to, method), attach_script (node, script). Only the lines of that change are touched. Without write it changes nothing and returns the diff and warnings; with write: true it writes and reports the review errors before and after (an error result when there are more after). A missing field or a change it refuses returns an error and writes nothing. Use it instead of editing .tscn files by hand. For project.godot use godot_project_edit; to rename a node everywhere, use godot_rename.

Input Schema

NameRequiredDescriptionDefault
opYeswhat to change
toNoconnect/disconnect: path of the node that receives
fromNoconnect/disconnect: path of the node that emits
nameNoadd_node: name of the new node
nodeNoremove_node/set/attach_script: path of the node ("." is the root)
typeNoadd_node: a Godot node class, e.g. Sprite2D
sceneYesthe scene: res://main.tscn, or a path
valueNoset: the value, e.g. Vector2(10, 20), 3, true, ALWAYS, res://icon.svg, null
writeNowrite the change (default false: show the diff only)
methodNoconnect/disconnect: method name
parentNoadd_node: path of the parent ("." is the root)
scriptNoattach_script: res:// path of the script
signalNoconnect/disconnect: signal name
instanceNoadd_node: a res:// scene to instance instead of a type
propertyNoset: property name, e.g. position

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the destructiveHint/readOnlyHint annotations, the description discloses that writes are opt-in via `write`, that dry-run returns diff plus warnings, that validation occurs against Godot 4.7 (signal existence, method arity, script base-type refusal), that only the lines of the change are touched, and that refused/incomplete changes write nothing. This is exactly the mutation context an agent needs and it is consistent with destructiveHint=true.

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

Conciseness4/5

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

Front-loaded with purpose and the destructive/alternative routing, and every clause carries information (validation rules, write semantics, op-field mapping). It is a dense single paragraph, though quite long for one breath; a small structural break would aid scanning without losing content.

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

Completeness4/5

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

For a 15-parameter mutating tool with no output schema, it covers the essentials: dry-run vs write, return of diff and warnings, before/after review errors, and no-write-on-error behavior. Minor gaps remain, such as whether a preview diff is stable enough to approve blindly or how concurrent edits are handled, but nothing required to call it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds cross-field semantics the schema cannot express per-property: which fields each `op` requires (add_node needs parent/name plus type or instance, etc.) and the node-path convention ('relative to the scene root, which is "."'). Value formats (enums by name, res:// resources) partially duplicate the schema's `value` description, keeping it below a 5.

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

Purpose5/5

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

Opens with a specific verb+resource ('Change a .tscn safely, without the editor') and then enumerates the six concrete mutations supported. It explicitly names the sibling tools it is not (godot_project_edit, godot_rename), so an agent can route correctly without inspecting schemas.

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

Usage Guidelines5/5

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

States explicit when-to-use ('Use it instead of editing .tscn files by hand'), when-not ('For project.godot use godot_project_edit; to rename a node everywhere, use godot_rename'), and the dry-run vs write decision rule ('Without `write` it changes nothing... with `write: true` it writes'). Nothing is left to inference.

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