Unreal_mcp: Driving Unreal Engine 5 from an AI Assistant Through a Native C++ Bridge

The gap Unreal_mcp fills between an assistant and the editor

Unreal Engine has no built-in way for an external AI assistant to act on an open editor session. You can script the editor with Python, and you can drive builds with UnrealBuildTool, but neither gives an assistant a stable, typed set of operations it can call. Unreal_mcp exists to be that layer. It is a Model Context Protocol server, written in TypeScript, that talks to a native C++ plugin called McpAutomationBridge running inside the editor. The README frames the goal as enabling AI assistants to control Unreal Engine through that bridge, and the feature table shows how wide the intended surface is: assets, actors, PIE sessions, levels, animation, Niagara, Sequencer, Blueprint and Material graphs, audio, console commands and project settings. The intended user is a developer who already works in Unreal and wants assistant-driven edits without leaving the editor, not someone looking for a headless build tool.

How the bridge routes a tool call into the editor

The architecture is two processes and two languages. The TypeScript side is the MCP server that an assistant connects to; the C++ side is the McpAutomationBridge plugin inside Unreal. The README states that all operations route through that plugin. Two transports are offered. The native path is HTTP with SSE and needs no bridge process. The alternative is WebSocket through a TypeScript bridge. That distinction matters because the Node.js prerequisite is scoped to the stdio bridge only: the README says Node.js 20.19 or later is required for the TypeScript stdio bridge and is not needed for the native MCP transport. Several runtime behaviours are described as deliberate. The server starts even without an active Unreal connection, retries the automation handshake with exponential backoff, and discovers some types at runtime rather than from a fixed schema, which the README lists for lights, debug shapes and sequencer tracks. Asset lookups are cached with a 10-second TTL. The Prometheus metrics endpoint is rate limited per IP at 60 requests per minute.

Installing the server and the plugin, and where it breaks

The server installs from npm. The README gives `npx unreal-engine-mcp-server` as the recommended route, or a clone-and-build path: `git clone https://github.com/ChiR24/Unreal_mcp.git`, then `npm install`, `npm run build`, then `node dist/cli.js`. The plugin lives in the repository at `Unreal_mcp/plugins/McpAutomationBridge`. You can copy that folder into `YourUnrealProject/Plugins/McpAutomationBridge/`, or point the editor at the external directory through Edit, Plugins, Plugin Directories, Additional Plugin Directories, which the README says records the path in your `.uproject` so the plugin stays linked without copying. The hard constraint is stated plainly: your project must have a code target (`.sln` or `.xcworkspace`), and Blueprint-only projects cannot compile native plugins. The documented workaround is to add any class through Tools, New C++ Class in the editor. There is a second route for machines without a compiler. Build once with `./scripts/package-plugin.sh /path/to/UE_5.6` on macOS or Linux, or `scripts\package-plugin.bat C:\Path\To\UE_5.6` on Windows, then unzip the result into `YourProject/Plugins/`. The README warns that pre-built binaries are tied to a specific engine version: a build for 5.6 will not work with 5.5, 5.7 or 5.8. Expect the first project open to prompt for a module rebuild. If instead you see a missing-modules message about engine modules not being compilable at runtime, the README directs you to build from Visual Studio or Xcode.

Required plugins and the token file you have to find

Enabling McpAutomationBridge is not sufficient. The README lists Python Editor Script Plugin, Editor Scripting Utilities, Niagara, Gameplay Abilities and Smart Objects as core requirements, each tied to a category of operations, and Sequencer work pulls in Level Sequence Editor, Movie Render Pipeline and related passes as optional plugins that are auto-enabled. Authentication is on by default. A 32-byte secret is generated automatically at `<Project>/Saved/MCP/capability-token`, and it applies to both the WebSocket and HTTP transports. If you want to control it yourself, a manual `CapabilityToken` in Project Settings overrides the file. That is the first thing to check when calls are rejected: confirm the token file exists and that nothing in Project Settings is overriding it with a stale value. The README also mentions pattern-based validation that blocks dangerous console commands, though it does not enumerate the blocked patterns, so treat that guard as a filter rather than a sandbox.

What the tool list implies about scope and maintenance

The feature table is the most useful part of the README and also the most worrying. Graph editing is listed for Blueprint, Niagara, Material and Behavior Tree graphs. Sequencer coverage includes Movie Render Queue, Take Recorder and replay. System operations include UBT, tests, logs, project settings and CVars. That breadth is the project's selling point and its cost. Every one of those categories is tied to Unreal APIs that shift between engine versions, and the README claims support for 5.0 through 5.8 in the badge. A single codebase spanning nine minor engine versions has to carry conditional paths, and the pre-built binary warning confirms that compiled artifacts are version-locked. The release cadence visible in the metadata is steady rather than sparse: v0.5.20 in March 2026, v0.5.21 in April, v0.5.30 in June, with the default branch on `dev` and a last push in September 2026. Frequent point releases on a 0.5 line suggest active churn rather than a frozen interface. If you build tooling on top of specific tool names, pin a version and read the release notes before moving.

Where it is the wrong tool, and what to use instead

The clearest failure mode is the Blueprint-only project. There is no path around the code-target requirement except converting the project or shipping a pre-built plugin for the exact engine version, and that binary will not survive an engine upgrade. If your team upgrades Unreal on a schedule, you inherit a rebuild step each time. The second limitation is environmental: this is an editor-session tool. Nothing in the material suggests it drives a headless commandlet or a build server, so it does not replace UnrealBuildTool or a CI pipeline. For that job, the honest alternative is the editor's own Python scripting, which the README already lists as a dependency through the Python Editor Script Plugin. Python automation runs inside the editor without a second process, without an MCP transport, and without a capability token, and it is the right choice when your operations are fixed and repeatable rather than assistant-driven. The difference in approach is that Python scripts are authored ahead of time and executed, while Unreal_mcp exposes operations as MCP tools that a model selects at runtime. If your workflow does not involve a model choosing what to do next, the bridge adds a process, an auth layer and a transport without returning anything.

Licence, upgrade cost and the verdict

The project is MIT licensed, which permits commercial use and modification, and the repository carries no separate plugin licence in the supplied material, though you should confirm that yourself before shipping binaries, since the plugin ships compiled artifacts. This is not legal advice. Upgrade cost is the real recurring expense. The pre-built path means rebuilding the plugin per engine version, and the source path means every developer needs a working C++ toolchain for the target platform. Neither is free. Adopt Unreal_mcp if you have a C++-capable project, a pinned engine version, and a workflow where an assistant genuinely needs to reach into actor transforms, asset operations or Sequencer. Skip it if your project is Blueprint-only and you are unwilling to add a C++ class, or if your automation needs are a fixed set of steps that a Python script already performs. Verify the engine version against the 5.0 to 5.8 claim, confirm the token file appears under Saved/MCP/, and run one round trip on your chosen transport before wiring it into anything you depend on.

Editorial conclusion

Adopt it if you already have a C++-capable Unreal project and want an assistant to touch actors, assets, Sequencer and Niagara through one MCP endpoint. Do not adopt it for a Blueprint-only project unless you first add a C++ class or use the pre-built plugin zip built for your exact engine version. Before committing, verify three things: that your engine version is inside the stated 5.0 to 5.8 range, that the capability token file is being written under Saved/MCP/, and that your chosen transport (native HTTP/SSE or the TypeScript WebSocket bridge) actually completes the automation handshake in your editor session.

Official sources

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