Breakpoint MCP

A Model Context Protocol server that brings the Godot game engine into an AI assistant's development loop — authoring scenes, writing type-checked GDScript, running the project, and debugging the live game. Developed and tested with Claude; MCP is an open protocol, so other clients can connect too (see Compatibility).

npm 1.35.0 · addon 1.9.5 · full 291 / secure-default 278 tools · 6 MCP resources · MIT. The host builds against the stable @modelcontextprotocol/sdk 1.x API and is exercised by a 569-test suite plus real-Godot integration jobs on Node 18/20/22.

Breakpoint MCP connects an MCP-compatible AI assistant to a running Godot editor and game. Instead of only scaffolding files, the assistant can open a scene, add and wire nodes with full undo/redo, write GDScript with type-aware completion and diagnostics, set a breakpoint and step through a failure from real program state, and then drive the running game — the same inner loop a human developer uses.

It speaks Godot's own protocols — the editor plugin's loopback bridge, and Godot's built-in language server (LSP) and debug adapter (DAP) — rather than reimplementing them, so behavior tracks the engine you already have.

Why Breakpoint?

Breakpoint is an MCP server that drives Godot through the engine's own interfaces: the editor plugin's loopback bridge for scene/node/resource work, a runtime bridge inside the running game, the headless CLI, and — the part that sets it apart — Godot's built-in language server (LSP) and debug adapter (DAP), to which Breakpoint speaks as a real client. Most Godot MCP servers stop at the first group: they create and edit scenes and scripts, take screenshots, and read the output log. Several now add stepping too — but they drive Godot's internal editor debugger and present it in "DAP-style" shapes rather than speaking the Debug Adapter and language-server protocols as a client. Breakpoint is that client, for GDScript and C#, and its breakpoints are proven to stop execution by integration tests run against real Godot binaries in CI. That is the difference between observing a running game from the outside and stopping inside it at real program state.

Two differentiating capabilities are the reason to reach for Breakpoint:

• A step-debugger for GDScript and C#. Set a breakpoint, step, read the real call stack and variable values, watch expressions, and evaluate in the paused frame — over Godot's Debug Adapter (and netcoredbg for C#). This is the difference between inspecting state and reading logs: the assistant can stop at the failure and look at actual values instead of inferring them from print() output and re-runs. A runnable example lives in example/demo/: a buggy melting-snowman scene where the debugger stops on ice -= melt and reveals melt = -2 — a mild warm spell growing the ice instead of melting it. The same bug is mirrored in C# at example-csharp/demo/ (DemoSnowman.ApplyWarmth), diagnosed the same way over netcoredbg — and verified the same way on both tracks: the read-only assertion family below proves the one-line clamp over the runtime bridge (GrewEver == false, "ALL MELTED" on screen), a check that fails before the fix and passes after.
• A language-server client for GDScript and C#. Completion, hover, go-to-definition, find references, rename, and diagnostics — over Godot's LSP (and OmniSharp for C#). Edits are symbol-accurate rather than text-substituted, and type errors surface before the project runs.

Around those, the editing surface is built to be safe to hand to an agent: every edit goes through EditorUndoRedoManager (Ctrl-Z reverts anything the assistant did), destructive tools are confirmation-gated, and every tool result is validated against a frozen output schema. A read-only verific