Godot MCP Runtime

Overview Schema Source Related Servers Discussions Admin

set_node_properties

Idempotent

Update one or more node properties in a Godot scene with type validation, inline resource creation, and per-update error results. Use for programmatic scene tweaks during runtime.

Instructions

Set one or more node properties on a scene in one Godot process. Always-array: pass a single-element updates array for one-off edits. Values are checked against the property's declared type and error instead of silently storing that type's zero value. Object-typed properties (e.g. CollisionShape2D.shape) take a res:// path, a {type: ClassName, ...props} dict that builds a Resource inline, or null to clear; slash-suffixed keys like shader_parameter/ go inside that dict, not on the node. Value coercion, Packed*Array/Array[T] element rules and error details: Property Values in docs/tools.md. Saves once at the end. Returns: results[] with one entry per update in input order (success or error). Errors while a Godot runtime session is active; stop_project or detach_project clears it.

Input Schema

TableJSON Schema

Name	Required	Description
`updates`	Yes	Property updates to apply
`scenePath`	Yes	Scene file path relative to the project
`projectPath`	Yes	Path to the Godot project directory
`abortOnError`	No	Stop processing on first error (default: false)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`results`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv3.8.0Sep 22, 2026

changedInput schema / properties / updates / items / properties / value / description

Previous value: -"New property value"New value: +"New property value. Vector2/Vector3/Color auto-convert from {\"x\",\"y\"} / {\"x\",\"y\",\"z\"} / {\"r\",\"g\",\"b\",\"a\"} objects; primitives pass through. Packed*Array and script-declared Array[T] properties take a plain array and the element conversions apply per element (e.g. [{\"x\":10,\"y\":20}, ...] for Polygon2D.polygon); an element that cannot represent the element type errors with its index instead of silently storing zeros."

Addedv3.1.1May 17, 2026

TDQS

A4.8/5.0

Behavior5/5

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

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

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

Conciseness5/5

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

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

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

Completeness5/5

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

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

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

Parameters5/5

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

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

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

Purpose5/5

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

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

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

Usage Guidelines4/5

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

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

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