Unreal MCP talk: repository and backlog review

Reviewed 2026-09-19. Requested source: Getting Started with MCP in Unreal Engine 5.8, Epic Games Education Office Hours, Unreal Engine channel.

Evidence boundary#

The initial review used documentation because YouTube blocked transcript access. The user subsequently supplied the transcript through 1:00:50, and this revision reviews that supplied text. Timestamped observations below come from that text; the video imagery, off-screen prompts, QR code, linked PDF, and actual demo artifacts were not inspected. Apparent transcription errors such as MPC/MCP and model names are not API or model identifiers. The review does not require another agy run.

The earlier access limitations remain historical: yt-dlp received HTTP 429 and a sign-in challenge; youtube-transcript-api returned IpBlocked. Those failures no longer prevent reviewing the supplied narration.

Primary technical references inspected on the review date, kept distinct from the supplied transcript:

• Epic's Unreal MCP documentation. The integration is experimental. Setup requires MCP and toolset plugins. Its default discovery path is list_toolsets, describe_toolset, then call_tool. Calls execute serially on the game thread. The local HTTP server has no authentication. Registry tool discovery belongs to the editor adapter; explicit registration also permits runtime hosts. Thus, editor capabilities must not be inferred for a packaged game. Shipping toolsets advertise no MCP resources or prompts. Tool changes may require refresh, reconnection, or restart.
• Epic's PCG and LLM workflow guide. It recommends selecting relevant assets, inspecting reference graphs before planning, reusing project conventions, and making small changes with feedback.
• Epic's UE 5.8 release announcement and patch notes. The 5.8.1 notes include MCP response-framing fixes and disabling transactions during tool script execution. A generic claim of automatic undo is therefore insufficient evidence for a pinned operation/version.

The implementation requirements below are our engineering recommendations from those facts and the repository inspection. Native MCP is an optional candidate backend; this review does not authorize replacing existing project engine pins.

What the repository already has#

The paths required by AGENTS.md, /root/workspace/UnrealEngine-5.5/Engine/Build/Build.version and /root/workspace/UnrealEngine-5.5/Engine/Binaries/Linux/UnrealEditor-Cmd, were absent on this host when checked. Historical 5.5 evidence in the repository is not current host evidence. No editor was launched or engine installation changed. Existing task 5.21 owns provisioning; this review does not create another generic "install Unreal" task.

Findings added by the supplied transcript#

1. Oversized descriptions can defeat lazy discovery (44:53–50:40). The speakers describe material and Niagara tool descriptions exceeding some harness/model limits. Truncated descriptions then lead to repeated guessing, extra calls, and cost. Their workaround divides the registry into smaller discoverable pieces. This is more specific than keeping the initial tool list short: a single describe_toolset result can still be too large. Reported payload sizes have ambiguous units in the transcript, and the one-minute material example is anecdotal, not an acceptance SLA. Task 5.33 measures bytes and tokens at each real boundary, validates completeness, and tests loss and recovery with the actual harness/model tuple.
2. Correct object names do not settle editing scope (24:37–28:16). The character exists at runtime, and the first approach changes a placed instance instead of the Blueprint used to spawn the player. The instructor explicitly redirects the edit to the Blueprint. Task 5.34 distinguishes an asset, an editor-world instance, and a play-world instance, binds that choice to the plan, and verifies it after save/reopen and spawning. It also covers the preview-list-then-edit batch workflow described at 52:06–53:03.
3. A working artifact can violate project conventions (39:00–40:54, 53:40–54:38, 56:32–57:51). The material example initially uses HLSL when the intended output is a native node graph. Later examples discuss delay chains and a project build check against Event Tick. Task 5.35 makes the project's authoring rules executable and verifies the produced assets and code. These are project-specific preferences, not universal bans on HLSL, Tick, Blueprint logic, or legitimate latent actions. The speaker's preference for C++ with thin Blueprint containers does not determine our architecture.

The inspected repository has useful foundations that these additions must reuse:

• Task 15.3 already closes generic context-compaction and tool-result loss handling. Its loss envelope is not evidence that an external harness preserves a complete, usable Unreal schema. Maat's tool-registry.ts already owns the MCP client/cache; 5.33 adds a bounded schema-delivery qualification there and at the existing Eve model/tool-result boundary, not another context subsystem.
• libs/bellona/unreal/src/onbox/material-authoring.ts and libs/bellona/unreal/onbox/python/author_material.py already create material expression nodes. The gap is ensuring agent-directed output obeys the chosen representation across backends and is independently inspected, not adding material-node authoring from scratch.
• libs/bellona/unreal/src/onbox/blueprint-authoring.ts already creates and compiles Blueprint assets/components, while remote-protocol/src/unreal.ts defines actor operations. Neither inspected surface proves end-to-end intent resolution between an existing asset and its editor/play instances.
• V2/ue/Tools/check-v2-asset-linter-plugin.py and the V2 asset-linter plugin already provide naming, move-data, and Blueprint-time validation machinery. Extend appropriate validators and existing build gates for 5.35; do not create a competing lint pipeline or apply V2-specific rules to every project.

Other transcript points refine existing work rather than create new tasks:

• Setup (5:16–18:58): 5.30 must reproduce the three-plugin setup named in the demo, particularly the connected-but-no-editor-tools case, and diagnose project-root, startup-order, and port conflicts. Reconcile plugin dependencies against the pinned installation rather than assuming the tutorial's list is timeless or enabling every tool in production.
• Incremental work and intent (20:19–30:55): 5.13/5.14 retain short inspect-plan-edit-readback steps and intent-linked verification. The misplaced lights and character attachment are regression fixtures. Apply existing authority/confirmation policy when required; the advice does not mandate an extra human approval for every reversible action or globally serialize independent agents/projects. Failures are not automatically the user's prompt fault.
• Debugging and extension (32:27–34:42): 5.30 includes useful logs and a direct-tool diagnostic that isolates agent reasoning from endpoint behavior. Custom Python/C++ tools must inherit 5.32's target/schema/authority controls; adding a tool is not permission to execute arbitrary code.
• Runtime and animation limits (31:05–32:19, 58:42–59:41): distinguish editor orchestration, game runtime, rig/sequence setup, and generation of new animation. Capability matrices and existing media/toolchain tasks own these distinctions. Current Epic documentation permits explicitly registered runtime MCP hosts, so the tutorial's editor-only description must not become a blanket protocol restriction. No provider or generated-animation capability is admitted by this review.
• External supplements (48:43–50:40, 53:08–55:24): the QR-linked PDF and divided registry were not supplied. Do not invent their URL, contents, license, or implementation. A modern scoped-discovery solution must be tested against the current engine and harness rather than copying an unavailable workaround.

Backlog decision#

The first pass added 5.30–5.32. The supplied-transcript pass adds 5.33–5.35 in the same eve-sota-gap-closure family, Phase 5. All six were entered through ./eve add and remain unchecked.

These tasks do not by themselves admit a new production capability. Existing Security, Evaluation, Reliability, and Privacy gates still apply. If the qualification rejects the native option, retain the measured reason and verified alternative; withdraw contingent implementation tasks through the board rather than falsely marking them delivered. This contingency applies to native-only integration, not the cross-backend schema, targeting, and authoring gaps in 5.33–5.35. Missing infrastructure is not such a rejection, and it does not close a required Unreal workflow.

Existing owners retained#

Journal notes on 5.13 and 5.14 link this review and the new work. For 5.14, add a small reference-driven authoring case: record the selected actors/assets and project revision, inspect an existing example, apply a bounded edit, independently read back the result, save, reopen, and compare. Use a PCG graph when a ratified workflow requires it. Verify its nodes, connections, parameters, generated result, and failure recovery. A PCG demo alone is not grounds to add an entire new product workstream. Measure schema/context usage and intervention alongside persisted correctness; preserve failed runs and compare against the existing backend.

Follow-up journal notes on 5.30, 5.32, and 5.14 attach the supplied transcript's setup, schema-loss, and demonstrated-error cases to their existing owners.

Verification scope#

This change adds research, unchecked tasks, dependency edges, and journal notes. It changes no runtime, API, UI, engine configuration, or capability admission. Applicable checks are tracker preservation/format, board consistency and drift, dependency integrity, and generated-board consistency. Runtime tests and live engine qualification are acceptance requirements of the implementation tasks.