This is a cool MCP use case because it connects AI to an actual creative workflow instead of keeping it trapped in chat.
The powerful part is obvious: Claude Code can help inspect project state, make changes faster, and reduce the back-and-forth between code, editor, and testing.
The part I’d watch carefully is the action boundary. Once an AI assistant can interact with a live editor, it needs clear limits around what it can read, what it can change, what requires confirmation, and how changes are logged or reverted.
For game development, this could be genuinely useful if it speeds up iteration without making the project state unpredictable.
The best version of this is not “Claude controls everything.” It is Claude becoming a fast assistant inside a workflow where the developer still has final control.
Really appreciate this — you put your finger on the exact thing I cared about while building it: the action boundary.
A few design choices that tackle it head-on:
editor.transactAPI — changes are atomic and land in the editor's normal undo stack. A bad edit is just Ctrl+Z, nothing exotic.editor.save()— the AI stages changes in the live editor, but the developer decides when they get persisted.editor_state,*_get_*,*_findare read-only; mutations are separate calls), so inspecting state never has side effects.So it's exactly the "fast assistant, developer keeps final control" model you describe — not "Claude controls everything." The editor stays the source of truth and the human stays in the loop.
Thanks for the thoughtful read — this is exactly the kind of feedback that shapes where it goes next.
— Esteban. On a tangent, since you're clearly into AI + game tooling: I also maintain estebanrfp/gdb on github (a real-time graph DB) and a Godot integration, godot-genosdb — different engine, but the same itch of keeping live state predictable. Might be up your alley.