Drive a running Godot 4.7+ editor from your terminal, and from AI agents.

A Go CLI and a GDScript addon talk to a live editor over WebSocket. Build scenes, write GDScript or C#, play the game, and read its state back. 312 commands, every one verified against a running editor. Not Godot's batch CLI: that starts a fresh engine process; this drives the editor you already have open, live scene, undo history, running game and all.

Get started Source

discover, drive, prove

# ask the live 4.7 build what it exposes, then act
$ godot-mcp engine search --query velocity
CharacterBody2D.velocity : Vector2
RigidBody3D.linear_velocity : Vector3
# build against the real SceneTree, undo-safe
$ godot-mcp node add --type CharacterBody2D --name Player --parent-path .
{ "added": "Player", "path": "Player" }
# play it, then read live state back
$ godot-mcp scene play --mode main
$ godot-mcp runtime get --node-path Player --properties '["position"]'
{ "position": "Vector2(320, 180)" }

A co-developer, not just a bridge.

Calling out the big dog on the block is what a young pup does, and this is exactly that. hi-godot/godot-ai is a great framework; this project just went a different direction. Editor-native is table stakes now, so the difference worth measuring is depth once an agent is building and testing.

godot-aigodot-mcp

Running-game controleditor-time only full runtime + input groups

MCP tool schemas carried~43 as few as 1 (godot_run)

Command surface~120 ops 312 across 49 groups

Runtime dependenciesPython + uv single Go binary

Craft layertool reference 26 craft docs + agent skill

What it does that editor-time servers don't

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. Most editor-time servers stop once the scene is assembled.

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

Introspection instead of wrappers.

The live ClassDB is the feature list. engine.search, generic node.set and node.get, and runtime.eval reach any 4.7 feature the day you upgrade, with no new release of this tool.

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