Install
"command": "npx",
"args": ["-y", "ue-mcp@latest", "C:/path/to/MyGame.uproject"]Who it's for
Developers and technical artists building Unreal Engine projects on Windows (UE 5.4-5.8) or Linux/macOS (UE 5.6+) who want to drive the editor in natural language from an MCP client. The official description claims 29 tool categories and 2040+ actions covering blueprints, materials, levels, actors, animation, VFX, landscape, PCG, foliage, audio, UI, physics, navigation, AI, networking, Sequencer, and the build pipeline, plus a YAML flow engine for multi-step workflows. It fits best if you spend your days on repetitive scene assembly and asset tweaking inside the editor, or want AI to take over part of the editor work; an offline pipeline that never opens the editor has no use for it. The test is simple: is most of your daily work done inside the editor, and are you willing to let the model modify project assets directly? Read on only if both answers are yes.
The prerequisite is a complete local toolchain: Node.js 18 or newer; the engine's PythonScriptPlugin (it ships with the engine, and init enables the remaining required plugins for you); and a mandatory C++ toolchain — Visual Studio with the C++ workload on Windows, Xcode command line tools on macOS — because the bridge plugin compiles when the editor first launches. Machines without a C++ toolchain, or where deploying a C++ plugin into a project is unwelcome, do not fit; anything that needs the epic category requires UE 5.8+. Also note that plugin deployment happens per project: switching to another project means re-running the interactive init to deploy the bridge plugin there, then waiting for it to compile the first time that project's editor launches; the evidence does not spell out the full steps for switching projects, so they remain unconfirmed. Licensing, costs, and any extra requirements on project size are also absent from the evidence — check them yourself.
First try in 3 minutes
Recommended main path: start the server with npx in your MCP client config and point it at your .uproject. Prerequisite: UE, Node.js 18+, and the C++ toolchain from above, already installed.
Add the official snippet to your client's config:
"command": "npx",
"args": ["-y", "ue-mcp@latest", "C:/path/to/MyGame.uproject"]
Replace C:/path/to/MyGame.uproject with the path to your project file. The first run enters an interactive setup: it auto-detects the .uproject in the current directory, lets you choose which tool categories to enable, deploys the C++ bridge plugin into the project, enables the required UE plugins (Niagara, PCG, GAS, etc.), then detects and configures your MCP client.
Success signals: once the editor's first launch has finished compiling the plugin, the server's tool categories appear in the client; send one natural-language command to the open editor and watch for an actual response inside the editor. If the categories are slow to appear, first check that the project path in your config is written correctly, then wait for the first compilation to finish.
Note: the project is officially positioned as deep read/write access to the editor for AI assistants, and write operations change project content directly; the evidence names no individual tools or their read/write annotation, so no specific read-only tool can be designated as the first call. Try it on a project under version control or with a backup first, and have the AI state what it is about to do before it acts.
Use cases
Case one: adjusting levels and actors in natural language. With the editor open, describe the scene change you want in one sentence in the client, and the server calls the level and actor categories to execute it in the editor. What to expect: both domains sit inside the natural-language-programmable surface claimed officially. The evidence gives no specific tool names or parameters, so treat the tools the client actually shows as authoritative. When unsure, get it working in a test project first, then return to your real one.
Case two: multi-step workflows with the YAML flow engine. When a single sentence is not enough and you need a fixed series of editor operations, describe the multi-step flow with the built-in YAML flow engine and hand it to the server. What is confirmed: the engine exists and targets multi-step workflows; the evidence provides no YAML format or examples, so consult the official documentation before you start. If you cannot get a flow written down, validate it step by step with single commands first, then chain them into a flow.
Boundaries
Read/write nature: what is officially granted is read/write access, not a read-only service, and no undo path is provided — do not treat write operations as reversible; before the AI acts, confirm exactly what it will change in the project. Local footprint: installation deploys a C++ bridge plugin inside the project and enables UE plugins; at runtime the client reaches the server over stdio, and the server reaches the in-editor plugin over WebSocket JSON-RPC. Which categories are enabled is your decision during setup, so leave any category you do not need yet disabled and the exposed surface stays smaller. The evidence says nothing about external network access, telemetry or data collection, credential requirements, or how several clients connected to the same project behave — all of this is unconfirmed; the absence of a statement is not a guarantee of safety, so brief everyone who will use it on these boundaries beforehand.