Unreal Engine MCP Server: driving the editor from an AI assistant through a C++ Automation Bridge

What the Unreal MCP server actually solves, and for whom

Unreal Engine has no built-in way for an external program to ask the editor to do something. The Python Editor Script Plugin exists, and the Editor Scripting Utilities exist, but neither is a protocol an AI assistant can speak. ChiR24/Unreal_mcp fills that gap with a Model Context Protocol server that sits between the assistant and the editor. The assistant sees a list of tools; the server translates each call into an automation request; a native C++ plugin running inside the editor executes it against the asset registry, the actor subsystem or the Blueprint graph.

The intended user is a game developer who already works in C++ UE5 projects and wants an assistant to do bulk or repetitive editor work: spawn and transform actors, browse and rename assets, load and save levels, run a PIE session, take a screenshot, or manipulate a Blueprint, Niagara or Material graph. The README's feature table is broad, covering animation state machines, Sequencer and Movie Render Queue, audio, physics and console commands. That breadth is the pitch and also the thing to be skeptical about, since a tool that claims to touch every subsystem rarely gets equal depth everywhere.

It is not a runtime framework. Nothing here ships in your packaged game. It is an editor-side automation layer, and the plugin is compiled into the editor build.

Two transports, one C++ Automation Bridge

The architecture has three moving parts. The assistant speaks MCP to the TypeScript server. The TypeScript server speaks to the editor. The editor runs the McpAutomationBridge plugin, which is where the actual Unreal API calls happen.

The second hop is where the design choice lives. The README describes dual transport: native HTTP/SSE, which it says needs no bridge at all, or WebSocket through the TypeScript bridge. The native path removes a process from the chain, which matters if you are already running the editor and do not want another Node process in the middle. The WebSocket path routes through the TypeScript layer, which is the route that requires Node.js 20.19 or later. Node.js 18 is explicitly not supported.

Several details in the architecture section are worth reading closely. Connection is on demand, and the server retries the automation handshake with exponential backoff, so it starts even when no editor is open. Asset lookups are cached with a 10-second TTL, which tells you the server is optimizing for chatty assistant behaviour rather than single calls. Console commands pass through pattern-based validation that blocks dangerous ones. Metrics are exposed on a Prometheus endpoint with per-IP rate limiting at 60 requests per minute.

Authentication is on by default. A 32-byte capability token is generated into `<Project>/Saved/MCP/capability-token`, and both transports use it. If you set `CapabilityToken` manually in Project Settings, that value overrides the file. This is the right default for a tool that can delete assets, but it also means the first run writes a secret to disk and you need to know where it lives.

Installing the server and getting a first tool call through

Start with the TypeScript side. The README recommends npx, which avoids a local checkout:

npx unreal-engine-mcp-server

If you would rather build from source, the clone and build sequence is spelled out in the README:

git clone https://github.com/ChiR24/Unreal_mcp.git
cd Unreal_mcp
npm install
npm run build
node dist/cli.js

Now the plugin. It lives at `Unreal_mcp/plugins/McpAutomationBridge`. The README gives two ways in. The simple one is to copy the folder into your project:

Copy:  Unreal_mcp/plugins/McpAutomationBridge/
To:    YourUnrealProject/Plugins/McpAutomationBridge/

The alternative avoids the copy. In the editor, open Edit then Plugins, click Plugin Directories in the bottom-left, and add the path to `Unreal_mcp/plugins/` under Additional Plugin Directories. Restart, and the plugin is picked up from the external location. The README notes this writes the path into your `.uproject` so the link survives without duplication.

Either way, UnrealBuildTool compiles the plugin when the project opens. Expect a rebuild prompt on first open; the README says to click Yes. If you instead get a Missing Modules message about McpAutomationBridge, the README's instruction is to open the project in Visual Studio on Windows or Xcode on macOS and build from there. This is the step where most people will lose an afternoon.

Configuration is environment-based. The example file ships with the automation endpoint and timeouts:

MCP_AUTOMATION_HOST=127.0.0.1
MCP_AUTOMATION_PORT=8091
MCP_AUTOMATION_CLIENT_MODE=true
MCP_CONNECTION_TIMEOUT_MS=5000
MCP_REQUEST_TIMEOUT_MS=30000

Set `UE_PROJECT_PATH` to your `.uproject` file. Then, in the editor, enable the core plugins the README lists as required: MCP Automation Bridge, Python Editor Script Plugin, Editor Scripting Utilities, Niagara, Gameplay Abilities and Smart Objects. Restart the editor. A first real call would be something in the asset or actor category, since those are the subsystems the Editor Scripting Utilities plugin backs.

The tool surface is tiered, and the default tier is small

This is the part that surprises people. The server does not hand every tool to every client. Tool categories are comma-separated and selected through `MCP_DEFAULT_CATEGORIES`, with valid values core, world, authoring, gameplay, utility and all. The default is core, described in `.env.example` as being for reduced context.

There is an escape hatch. Clients that cannot load tools dynamically, and the README names Claude Desktop as an example, automatically receive all tools for backward compatibility. So the same server presents a small surface to one client and a large one to another. If your assistant seems to be missing a capability that the feature table promises, this setting is the first thing to check, not the plugin.

Context budget is the reason for the tiering. A feature table spanning assets, actors, levels, animation, Niagara, Sequencer, graph editing, audio and system commands is a lot of tool descriptions to put in front of a model, and every one of them costs tokens on every turn. Splitting by category is a reasonable answer. The cost is that users now have to know which category contains the operation they want before they can ask for it, and the README does not map individual tools to categories.

There is a related knob for content paths. `MCP_ADDITIONAL_PATH_PREFIXES` takes a comma-separated list of mount points beyond `/Game/`, for plugins whose `.uplugin` declares `CanContainContent`. Without it, assets that live under a plugin mount point may not be reachable by the asset tools.

Where this breaks: Blueprint-only projects and version-locked binaries

The clearest limitation is stated plainly in the README. The plugin is native C++, so your project needs a code target, meaning a `.sln` or `.xcworkspace`. Blueprint-only projects cannot compile native plugins. The suggested fix is to add any class through Tools then New C++ Class in the editor, which converts the project. If you are not willing to make that change, this tool is not for you, and no configuration will work around it.

The pre-built route looks like the answer to that, and partly is. You build the plugin once with `scripts/package-plugin.sh` on macOS or Linux, or `scripts/package-plugin.bat` on Windows, and distribute the zip. The README is explicit that this works with any project including Blueprint-only ones. But it also warns that pre-built binaries are tied to a specific UE version: a build for 5.6 will not work with 5.5, 5.7 or 5.8. So the pre-built path trades a compile step for a version matrix. If your team runs mixed editor versions, you are maintaining one artifact per version.

Two more constraints are worth naming. Node.js 20.19 or later is required for the stdio bridge, and 18 is not supported, which rules out older CI images and locked-down workstations. And network media URLs are disabled by design: `.env.example` says to use `filePath` or `mediaPath` under Project Content or Project Saved instead. If your workflow pulls reference images from a URL, that path is closed.

Finally, the README does not document a rollback procedure for destructive operations. There is console command validation and there is token auth, but if an assistant deletes an asset or overwrites a level, the documentation is silent on undo. Treat version control as the recovery mechanism.

How it compares with Unity MCP and with plain editor scripting

The closest comparison people search for is Unity MCP. The structural difference is the bridge. Unity's editor is scripted through C#, and MCP servers for it typically run inside the editor process as a C# package, which means no separate native compile step and no version-locked pre-built binaries. Unreal's C++ module system forces the split this project uses: a TypeScript server outside the editor and a compiled plugin inside it. That split buys a language most MCP tooling already targets, and it costs you the plugin build.

The other alternative is not a competitor at all: the Python Editor Script Plugin and Editor Scripting Utilities that this project already depends on. If your need is a one-off batch rename or a scripted asset import, a Python script run from the editor's own console does the job with no token file, no bridge and no MCP client. Where the MCP server earns its place is when the operator is a language model rather than a script you wrote, because the tool schema is what lets the model discover operations it was not told about in advance.

Docker is supported for the server side. The Dockerfile is a multi-stage build that runs `npm ci --ignore-scripts`, builds TypeScript on `node:22-alpine`, then copies only `dist` and production dependencies into a Chainguard node image running as a non-root user. That containerizes the TypeScript half only. The plugin still has to be compiled and loaded inside a real Unreal Editor on the host, so Docker does not remove the hard part.

Maintenance, licensing and what an upgrade costs

The repository is not archived, and the last push was on 2026-09-10, which is recent enough that the project is being worked on. Releases are more spread out: v0.5.20 in March 2026, v0.5.21 in April, v0.5.30 in June. The gap between the June release and the September push suggests active development between tagged releases, so if you track versions, expect the tag to lag the branch. The default branch is `dev`, not `main`, which is worth knowing before you pin a git dependency.

Upgrade cost has two axes. The npm package is the easy half: `npx unreal-engine-mcp-server` always resolves the published version, and `package.json` shows a `prepare` script that builds automatically if `dist/cli.js` and `dist/index.js` are missing. The plugin is the hard half. A server upgrade can require a matching plugin rebuild, and any pre-built binary you distributed is pinned to one UE version. If you maintain pre-built zips for a team, budget for a rebuild per Unreal version per server release.

The licence is MIT. That is permissive: you can use it commercially, modify it and redistribute it, provided the copyright notice and permission notice are retained. The C++ plugin under `plugins/` falls under the same repository licence. Nothing in the README describes a separate commercial tier or a licence key. This is a description of what MIT says, not legal advice; if you are redistributing the plugin inside a shipped product, read the LICENSE file and talk to someone qualified.

Editorial conclusion

Adopt it if you are already building C++ UE5 projects and want an assistant to move actors, drive PIE or edit Blueprint graphs without leaving the chat window. Skip it if your project is Blueprint-only and you cannot add a C++ class, because the bridge plugin will not compile. Before trusting it with a real level, verify three things: that your editor build is inside the 5.0 to 5.8 range the README lists, that the capability token file exists under Saved/MCP after the first handshake, and that your MCP client exposes the tool categories you actually need rather than the core default.

Frequently asked questions

Official sources

1. ChiR24/Unreal_mcp on GitHub
2. Issues
3. License: MIT
4. README
5. Releases