← All posts
August 7, 2026·4 min read

MCP in Unreal Engine 5.8: Connecting an AI Agent to Your Project

UE 5.8 shipped a built-in MCP server: how to enable the Unreal MCP plugin, generate a client config, what an agent can do in the editor, and why the server shouldn't be exposed externally.

On June 17, 2026, Unreal Engine 5.8 shipped with the industry's first built-in MCP server right inside the editor. That means an external AI agent can connect to an open project and work with it: spawning actors, setting up lighting, building materials, running tests.

The feature is marked experimental, and that's not a formality. Here's how to enable it and where the trust boundaries sit.

What actually shipped

Epic added a plugin called Unreal MCP. It starts an MCP server inside the editor process and exposes part of the engine as a set of protocol tools.

What an agent gets access to: spawning actors in a level, configuring lighting, creating material instances, inspecting Slate widgets, running automated tests. In other words, not "generate a game," but specific operations on an already-open project.

The protocol itself is explained in what MCP is — the important part here is that Unreal acts as the server, and the agent connects to it as a client.

How to enable it

The steps:

  1. Open Edit → Plugins, find Unreal MCP, and enable it. You'll also need the All Toolsets plugin alongside it.
  2. Restart the editor.
  3. In the editor console, run the config generator for your client:
ModelContextProtocol.GenerateClientConfig ClaudeCode

Instead of ClaudeCode you can use Cursor, VSCode, Gemini, Codex, or All if you want configuration for all of them at once.

By default the server starts on http://127.0.0.1:8000/mcp. The port and path are configurable.

◆

Not every transport is supported: only HTTP and Server-Sent Events. Neither stdio nor WebSocket works. If your client only knows how to connect over stdio — and a good chunk of examples online are built that way — it won't connect to Unreal, and the config isn't the problem.

On security: read the docs literally

Epic states the limitations plainly, and they're worth quoting rather than paraphrasing. The plugin runs inside the editor process, has no authentication layer, and isn't meant for remote use. The documentation says exposing it beyond the local machine is unsafe.

The practical takeaways follow from that.

Don't change the 127.0.0.1 address. The temptation to set 0.0.0.0 so you can connect from a laptop to a machine with the project open costs more than usual here: the server has no password, and the tools change the project's contents.

Second: an agent connected to the editor acts with editor-level permissions. It can change a level, assets, settings. The experimental status means the tools' behavior can change between versions, and undo in the editor isn't always complete.

How to work with this without losing your project

A few rules worth setting before your first session.

Keep the project under version control and commit before letting an agent in. That's the only reliable way to roll back: Ctrl+Z in the editor won't undo a series of operations performed through the API.

Start with operations you can verify by eye: arranging actors on a grid, creating a set of material instances, running tests. Let the first task be one where a mistake is obvious right away.

Don't hand the agent a task like "clean up the project." An unbounded request on a live project is a bad idea regardless of how good the agent is.

Where the value is, and where it's hype

Honestly: spawning actors through an agent isn't why you'd change your process. The mouse is faster.

The value starts at volume and routine. Arranging a hundred objects by a rule. Creating fifty material instances with different parameters from a table. Running tests and compiling a report. Checking that every level has the right lighting settings. That's work where a human makes mistakes out of boredom and a script takes longer to write than doing it once by hand — and that's exactly where an agent fits.

What to do if the project is local but the agent isn't

Worth pausing on, because it's a non-obvious point.

The MCP server inside Unreal is local. But the agent connecting to it can be a cloud one. In that case, whatever the agent sees goes to the cloud: the project structure, asset names, whatever content it queries through the tools. For a personal side project, that's probably fine. For a project under NDA, it's critical.

Doka closes that gap: it's a desktop agent that connects to MCP servers and can run on a local model, downloaded right inside the app. The project stays on the machine end to end — the engine and the model working with it. Plus the agent sees not just Unreal through MCP, but the project's files and terminal too: builds, logs, scripts.

Where to start

Enable the plugin, generate the config, connect the agent, and give it one small task on a test level — not your production one. Watch what it calls and how that looks in the editor.

This is a new topic: the query "unreal engine mcp" didn't exist before spring 2025, and after the 5.8 release it tripled in a month. Practice is still thin, including at Epic, so caution pays off better than enthusiasm right now. Try Doka on this setup for free.