Give an agent the whole Godot development loop.

Discover the live engine, build in the open editor, run and play the game, observe state, debug failures, fix them in place, and verify the result. The same workflow runs from a terminal or an MCP client against Godot 4.7.

Get started Source

discover, drive, prove

# discover against the live build
$ godot-mcp engine search --query velocity
CharacterBody2D.velocity : Vector2
RigidBody3D.linear_velocity : Vector3
# build in the real SceneTree
$ godot-mcp node add --type CharacterBody2D --name Player --parent-path .
{ "added": "Player", "path": "Player" }
# play, observe, and verify
$ godot-mcp scene play --mode main
$ godot-mcp input action --action jump --pressed true
$ godot-mcp runtime get --node-path Player --properties '["position"]'
{ "position": "Vector2(320, 180)" }

How it compares.

godot-ai andGodot-MCP-Native are both good, both actively maintained, and all three projects are MIT. godot-ai has the largest community; Godot-MCP-Native has the leanest install; both settle on a 4.5 floor, where this one is developed on 4.7 and its 4.3 floor is still beta. Editor-native is table stakes now, so the axes worth measuring are how you drive it, how much context the tool surface costs, and what happens across the full build, play, diagnose, and verify workflow. Figures checked 2026-08-12.

godot-aiGodot-MCP-Nativegodot-mcp

Runtime dependenciesPython + uvnoneone Go binary, or none

Drives it froman MCP clientan MCP clientany agent with a shell, or any MCP client

Primary workflowedit + game toolsedit + in-game probebuild → play → debug → verify

MCP schemas carried~43 fixed155 fixedlive-built, or 1

Running-game controllive tree + synthetic inputin-game probestate + input + capture + signals

Runtime debuggingnot documentednot documentedbreak, inspect, step, hot reload

C# projectsnot documentedsymbol indexingscaffold, build, diagnostics

New project from nothingnonogodot-mcp create

Godot versions4.5+4.5+4.7 target, 4.3 to 4.8 in beta

Craft layertool referencetool reference30 guides + skill

What it does differently

One loop from build to proof.

The same interface discovers the live API, authors the project, runs and plays the game, observes state, diagnoses failures, applies a fix, and verifies the result. The agent keeps the context of the work as the task crosses from editor to game to debugger.

discover → build → run → play → observe → debug → fix → verify

Tested by finishing real work.

Every command is exercised against a live editor and read back. Before a release, an agent that did not build the tool must also create and playtest a complete game slice through the public interface. That catches broken sequences, states, timing, and missing steps that isolated command checks cannot produce.

A CLI first, an MCP server second.

Every command runs from a shell, so a terminal-driven agent carries zero tool schemas and a human can drive the same surface by hand. The stdio and editor-direct HTTP MCP modes are a second front door onto that surface, not the only way in.

godot-mcp node add --type Sprite2D --name Player --parent-path .

It drives the running game.

The runtime and input groups inspect and control the live game over a two-hop IPC: read the running scene tree, set and read node state, eval, capture frames, await signals, and inject input for deterministic playtesting. A debug build can host the channel itself, so the game is drivable with no editor open at all.

godot-mcp runtime await-signal --node-path Boss --signal died --timeout 10

It debugs without abandoning the playtest.

Breakpoints, paused stacks, frame variables, stepping, and script hot reload keep diagnosis and repair inside the same session. A fix can enter the live process while its runtime state stays in place.

godot-mcp debug state

Introspection instead of wrappers.

The live ClassDB is the feature list. engine.search finds the name; node.set and node.get reach any property, node.call and runtime.call any method, and runtime.eval anything needing several statements. Verified against 4.8-dev, whose new classes needed no code change here.

godot-mcp engine class-info --class CharacterBody3D --filter velocity

Typed tools, or one generic tool.

serve exposes every command as a first-class MCP tool with a real schema, built live from the addon so the tool surface never drifts from what is registered. godot_run stays as the generic escape hatch for any method. Tool-limited clients run serve --typed=false for the single-tool mode, keeping the model's context lean. Read-only godot:// resources pull context without spending a tool turn.

Crash-aware discovery.

Per-project port discovery returns a verdict on every connection failure, so an agent recovers deliberately instead of relaunching blindly and breaking the editor.

running · starting · crashed · closed

One connection model.

The addon runs a WebSocket server inside the editor, the long-lived process. The CLI and the MCP serve mode are both short-lived clients that dial in. Runtime commands reach the separate running game over file IPC.

  godot-mcp (CLI / MCP client)
        |
        |  WebSocket · JSON-RPC 2.0 · 127.0.0.1:9080
        v
  Godot editor addon  (the server)
        |
        |  file IPC (user://)
        v
  running game  (MCPGameInspector / MCPGameInput)

Install in one command.

Drop the addon and the agent skill into any Godot 4.7 project, or bootstrap a fresh one. No runtime dependencies beyond a single Go binary.

Installation guide

terminal

# add the addon and skill to any Godot project
$ godot-mcp install --project ./mygame --enable
# or start a new project from nothing
$ godot-mcp create --path ./mygame --install --enable

Build the game, and prove it works by playing it.

Read the docs See samples