UE-Bridge

UE-Bridge is an MCP server that puts Claude inside the Unreal Editor: reading and writing Blueprints, automating the editor, and reaching Epic's own documentation and gameplay patterns on demand. I built it for my own projects. After enough time working with Claude I was confident enough to try making the tool I wanted rather than waiting for one, and this is how that went.

I'm a designer who delegates code to Claude, so the goal was simple: point Claude at a Blueprint, a level, or a material, talk through the problem, and have it scaffold the work, without leaving the editor or copy-pasting context back and forth. The off-the-shelf way to do that meant paying for a separate subscription; I wanted the capability running on the tools I already use.

I didn't start from a blank file. The genuinely hard part of driving Unreal from the outside is its Python Remote Execution socket protocol, and an existing MIT-licensed project, runreal/unreal-mcp, had already solved it cleanly in TypeScript and shipped a solid base tool set.

Forking it was the pragmatic call: inherit the part that's hard and well-tested, then spend my effort on the parts that make the tool mine: Blueprint introspection, a second connection into the editor, and a knowledge layer. The existing implementation was solid, and rebuilding it would not have made the tool any better.

Unreal exposes two very different ways in, and rather than force everything through one, UE-Bridge speaks both.

The Remote Control API is an HTTP service on port 30010. It's fast and stateless, and it handles the queries that suit it: reporting on the running editor and reading object properties. Python Remote Execution is a separate TCP socket on port 6689. It's stateful, and the only path for arbitrary Python inside the editor; that's where the heavy lifting lives: serializing a Blueprint to JSON, automating the editor, writing changes back.

There's a trap the project documents so I don't fall into it twice: the Remote Control API can't run Python, and calling its execute route just returns a 404. The two channels are genuinely separate systems, so the architecture treats them that way rather than pretending one can do the other's job.

Where neither official path reaches far enough, a small C++ editor plugin, UEBridgeEditor, fills the gap. Unreal can list a Blueprint's variable names natively, but not the shape around them: flags, tooltips, categories, the default value held on the class object. That metadata has no native equivalent, and it's what makes introspection useful rather than merely complete. The plugin only exists where it has to, which later hardened into a rule. It carries a real cost worth stating: it has to be compiled, so the deepest introspection isn't a one-line install.

The work is organized into three independent pillars, so I can push on whichever one matters that week without blocking the others.

Pillar 1 is introspection: reading the project as structured data. The marquee tools are read_blueprint, which serializes any Blueprint to JSON (its variables, functions, event graphs, and component hierarchy, each tagged blueprint / inherited / native), and read_widget_blueprint, which does the same for UMG widgets, down to the nested widget tree, slot info, bindings, and animations.

Pillar 2 is authoring: creating and editing. Scaffolding Blueprints, adding typed variables and functions, spawning and updating actors, and checking the result is structurally sound before anyone runs it. Reading is safe and writing isn't, so authoring moves more carefully than the other two.

Pillar 3 is knowledge: giving Claude retrieval over Unreal's own documentation, so answers cite Epic rather than leaning on training data that may be stale.

One rule sits above all three: Official-Epic-First. UE-Bridge always reaches for an official Epic API (Python, Blueprint libraries, engine functions) before any custom code, and the C++ plugin only exists where an official option genuinely doesn't. It keeps the tool durable as Epic evolves the engine instead of accumulating brittle workarounds.

The one moment the plan broke was the knowledge layer. My original design had UE-Bridge doing its own semantic ranking internally, via an embedded library making programmatic API calls to a model to score and pick the most relevant search results.

Mid-build, a question surfaced: would that incur cost outside my existing Claude plan? It would. At the time, a subscription-versus-API-key billing distinction meant programmatic calls from a third-party tool would have needed a separate paid key instead of drawing on what I already paid for. That was a second billing surface, and a violation of a principle I'd set early: single vendor, one cost.

So I pivoted. Instead of an internal ranking library, UE-Bridge ships two plain tools: ue_search_corpus runs a local BM25 search and returns candidates, and ue_fetch_pages retrieves and caches the pages. The semantic ranking the library would have done is now done by Claude itself, inline, using the conversation it already has. Lighter code, no second bill, and Claude brings more context than my library ever could have. The lesson I wrote down: verify a vendor's billing terms before you build an architecture around them.

A smaller wrinkle from the same layer: Epic's docs sit behind Cloudflare, so the fetcher presents a Chrome-like TLS fingerprint (built on undici) to be let through like any ordinary browser, with caching and polite rate-limiting so it stays a good citizen.

UE 5.8 shipped Epic's own AI tool framework: around 830 official tools covering Blueprints, Sequencer, materials, actors, and static meshes. Claude couldn't reach any of it.

Registering all of them was the obvious move and the wrong one. Every MCP tool's schema loads into the model's context and stays there, so 830 schemas would eat an enormous slice of the context window before any actual work began. The gateway exposes three tools instead: a lightweight catalog of names and one-line descriptions gets filtered inside the editor, so only small slices cross the wire, and Claude searches, pulls the one schema it needs, then calls the tool. The trade is an extra round-trip compared to keeping every schema resident. I took it deliberately.

Blueprint event-graph authoring was a wall I hit during real project work. Epic's own Blueprint toolset already had the answer sitting there, out of reach until the gateway.

I built an FPS character out of official Epic atoms. It compiled clean. It validated at zero errors. The pawn possessed correctly. No input ever fired.

Epic's own version puts AddMappingContext on the player controller. Their character has no BeginPlay at all. Every piece I'd used was correct and the assembly was invented, which is the failure mode you get when a model has the right vocabulary and no worked examples.

So the tool now includes them. A pattern library returns Epic-derived gameplay recipes with working node identifiers and the traps that fail silently, each one stamped with the exact engine build it was read from. Six so far. Knowing the parts is not the same as knowing how they go together, and that gap doesn't show up in a compile.

A Blueprint that returns ok from a compile can still be structurally dead. I lost most of two working days to exactly that signature, so validate_blueprint now lints for it: logic that will never be reached, wired in a way the compiler has no opinion about. Five rules, three of them errors and two deliberately advisory.

Building it taught me something about the tooling underneath. Half of the first findings were false positives, because Epic's node-finding call reports only events as entry points, so any graph entered another way read as entirely unreachable.

The catalog solves a quieter version of the same problem. Eight hundred tools are only useful if the right one surfaces, and a designer asking to "run the game" is not going to type the function's real name. Before the annotation layer, that phrase ranked the correct tool at number 384. After it, number 11. Discoverability behaves exactly like absence: I spent a month believing UMG authoring wasn't possible while twenty-three tools for it sat unused in the registry.

Forty-three tools in total, 23 of them ue-bridge's own and the rest inherited with the fork. The gateway adds reach into Epic's eight hundred and thirty on demand.

UE-Bridge is stable, and it's mid-journey. The introspection pillar still has component-hierarchy, animation, material, and behavior/state-tree readers queued. Authoring has the validation and pattern work behind it now, and the next stretch is widening what it can build without supervision.

And one honest limitation: Unreal's online docs are a single-page app, so ue_fetch_pages currently retrieves the page shell (title, description, canonical URL) rather than the rendered body text. The next step is headless rendering to pull the actual prose, slotting into the caching and rate-limiting machinery that's already in place. The tool surface won't change; the thing behind it just gets smarter.

Anything that isn't engine-specific gets verified against both Unreal 5.7 and 5.8 before it counts as done. Some of the newer work is 5.8-only by design, because that's where the features it depends on live. On a single Claude subscription, it does what I set out to build: makes Claude a genuine collaborator inside the engine.