Godot MCP Pro: The Paid Server Behind the Free Godot Addon

What the Public Repository Actually Contains

The README is unusually direct about this: the public repo holds the free Godot addon, and the Node.js MCP server that connects AI assistants is distributed only in the paid package. If you clone the repository and find no server/ directory, the README says that is expected. The paid zip is advertised as containing the addon, a server/ directory with pre-built JavaScript, INSTALL.md, and AI-client instructions. The homepage lists $15 one-time with lifetime updates, sold through Buy Me a Coffee and itch.io. So the thing you are evaluating is not fully in front of you. The GDScript plugin is inspectable; the process that speaks MCP to your assistant is not. That matters for anyone who treats a dependency as something to read before trusting. The licence field on the repository is NOASSERTION, which means no standard licence identifier was detected. The README does not state licence terms for the paid package either, so the terms you agree to are whatever the storefront presents at purchase time. Treat that as the first thing to read, not the last.

The WebSocket Bridge Between Assistant and Editor

The architecture diagram in the README shows three hops: the AI assistant talks to a Node.js server over stdio using MCP, and that server talks to a Godot editor plugin over WebSocket on port 6505. The README states the connection is real-time, with no file polling, and that the plugin has access to Godot's editor API, the UndoRedo system and the scene tree. Protocol-wise, the server speaks JSON-RPC 2.0 with error codes and suggestions. That design choice explains most of the tool list. Because the plugin sits inside the running editor rather than parsing .tscn files on disk, tools like get_scene_tree return the live hierarchy, delete_node can route through UndoRedo, and get_editor_selection can report what a human currently has selected. It also explains the failure mode: nothing works unless the editor is open with the plugin enabled and the port is reachable. There is no headless path described in the README, and no way to drive a Godot project that is not currently loaded in an editor session. The bridge is the product and the constraint at the same time.

Tool Modes Exist Because Clients Cap Tool Counts

The README claims 175 tools and then admits most clients cannot hold that many. Four modes are offered: Full with 175 tools, 3D with 103, Lite with 84, and Minimal with 35. The mode is selected by a flag in the server args, for example --lite or --minimal, placed after the path to build/index.js in your .mcp.json. The compatibility table is the most useful part of the documentation because it names the constraint per client. Windsurf and JetBrains Junie are listed with a 100 tool limit and pointed at Lite. Gemini CLI is described as having roughly a 100 client limit and pointed at Lite, with excludeTools suggested for finer control. OpenCode and local LLMs such as LM Studio are pointed at Minimal or the CLI, with the note that models degrade past roughly 40 tools and that the context window is the bottleneck. Claude Code, VS Code Copilot, OpenAI Codex CLI, Cline, Roo Code and Cursor are all listed as Full, each with a different reason: deferred tool loading, virtual tool grouping, MCPSearch overflow, no hard limit, or dynamic context discovery. That table is more honest than most. It tells you the tool count is a marketing number and the usable count depends on your client.

Installing the Plugin and the Server

The plugin install is a file copy: put addons/godot_mcp/ into your project's addons/ directory, then enable it under Project, Project Settings, Plugins, Godot MCP Pro. The server install happens from inside the paid package, not the repository. After extracting the zip, the README gives three commands: cd server, npm install, npm run build. Client configuration goes in .mcp.json, with command set to node, args pointing at the absolute path to server/build/index.js, and an env block setting GODOT_MCP_PORT to 6505. The mode flag is appended to the args array. That is the whole setup surface. There is no config file format to learn beyond this JSON block, and no database or service to provision. The one detail worth noting is that the port appears in two places with different defaults: GODOT_MCP_PORT is 6505 in the MCP config example, while the CLI section says it needs an available port in the 6510 to 6514 range. The README does not explain why the CLI uses a different range, so if you plan to run both, verify which port each path expects before debugging a connection that never opens.

The CLI Is the Escape Hatch for Tool-Limited Clients

For clients without MCP support, or where loading 175 tool definitions would consume too much context, the README offers a CLI that talks to the same editor plugin over WebSocket. It requires the server to be built first, a running Godot editor with the plugin enabled, and a free port in the 6510 to 6514 range. Commands are grouped and discoverable in layers: cli.js --help lists groups, cli.js node --help lists commands in a group, and cli.js node add --help shows options for one command. Execution looks like cli.js project info, cli.js scene play, or cli.js node add --type CharacterBody3D --name Player. The stated advantage is that an LLM discovers capabilities progressively through --help instead of loading every tool definition upfront, which works with any client that has terminal access regardless of tool limits. This is the most interesting design decision in the project. It trades the structured MCP handshake for plain shell output, and in exchange it removes the context ceiling entirely. Whether the assistant can use it well depends on how reliably it reads help text, which is a property of the model rather than the tool.

Where the Split Between Free and Paid Bites

The obvious limitation is the one the README states outright: cloning the repository gives you a plugin that cannot talk to anything. The server is closed, shipped as pre-built JavaScript, and gated behind a purchase. If your organisation requires source review, reproducible builds from source, or a licence file you can read before adoption, this project fails that bar on the server side regardless of how good the plugin is. A second limitation is environmental: every capability depends on a live editor session and a reachable WebSocket port. Continuous integration, headless export pipelines and batch scene processing are outside what the README describes. A third is version coupling. The plugin runs inside Godot 4, the server is Node.js, and the two must agree on a protocol over the socket. The release history shows v1.15.0 adding editor selection tools and legacy TileMap support, then v1.15.1 and v1.16.0 within weeks. Frequent releases are a good sign for maintenance, but they also mean the addon and server versions need to move together, and the README does not describe a compatibility matrix between them. Update one without the other and you are debugging a socket protocol with no version negotiation mentioned.

What It Replaces, and What That Costs You

The realistic alternative for many teams is the file-editing approach: let the assistant read and write .tscn and .gd files directly in the project directory, with no editor bridge at all. The difference is not cosmetic. A file-level assistant sees the serialised scene, so it can edit a scene that is not open, run in CI, and work against a git checkout with no Godot process running. Godot MCP Pro sees the live editor, so it can read the current selection, route deletions through UndoRedo, and report editor errors that only exist at runtime. Those are capabilities a text editor cannot fake. The cost is that you give up everything the file approach is good at: no editor, no tools. A second alternative is writing your own small MCP server against the Godot editor's own scripting, which keeps the server auditable but means owning the protocol, the error handling and the tool surface yourself. The 175 tools listed in the README are the part you would be rebuilding, and that list is long: 7 project tools, 9 scene tools, 17 node tools, 8 script tools, and more groups the truncated README does not fully enumerate. Whether that list is worth $15 depends on how much of it you would actually call.

Who Should Buy It, and What to Check First

This fits a solo developer or small team already working in Godot 4 with an MCP-capable assistant, who wants the assistant to manipulate the live editor rather than edit files blind. It fits less well if your assistant runs in a headless environment, if your procurement process requires reading the server source, or if your client's tool limit forces Minimal mode and you need the 3D or animation tools that the smaller modes drop. The README's own compatibility table is the place to start: find your client, note the recommended mode, and check whether that mode still contains the tools you care about, because Lite is described as project, scene, node, script, editor, input, runtime and input_map tools only. Before paying, confirm the licence terms on the storefront, since the repository reports NOASSERTION and the README does not state them. Then confirm the port situation on your machine: 6505 for the MCP server, 6510 to 6514 for the CLI. If either range is occupied by something else, you will be editing JSON before you write a single line of GDScript.

Editorial conclusion

Adopt Godot MCP Pro if you already drive Godot 4 from Claude Code, Cursor or a similar MCP client and you are willing to pay once for the server that the public repository does not contain. Skip it if you need an auditable server, a permissive licence you can read in the repository, or a tool that works without a running editor. Before buying, verify the licence terms, confirm your client's tool limit against the Full, 3D, Lite and Minimal modes, and check that port 6505 is free on your machine.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. youichi-uda/godot-mcp-pro on GitHub