Engine agent surface

How a game engine exposes itself to an AI agent: the set of operations an assistant can call, how it discovers them, and what stops it doing damage. All three major 3D engines now have one, and they arrived at strikingly similar designs from different directions.

The three instances

Unreal ships an experimental first-party MCP Server Plugin exposing engine data to LLMs (unreal-engine-5-8), with UE6 going further and bundling models.
Unity ships the Unity CLI + Pipeline package: a CLI that manages the editor, [CliCommand]-attributed methods that drive a running one, and eval for live C# inside it — which Unity itself maps onto function-calling and MCP tools.
Godot has godot-mcp-toolkit, a community MIT plugin with 112 MCP tools over scenes, nodes, scripts, ClassDB and playtests.

A fourth arrives claiming the opposite construction (2026-08-18). immens is an unreleased engine from ex-Epic and ex-Guerrilla founders whose pitch is that the agent surface is not a plugin but the architecture: text-based open-standard formats, "full API and MCP interoperability," and "structured, machine-readable context with full provenance" on every asset. Nothing ships yet, so it belongs on this page as a stated position rather than as an instance — see the section at the bottom.

A fifth, from a third party, and it ships (2026-09-10). kovati-automation-forge is a 34-plugin Unreal suite, not an engine, and it states the surface as its architecture: every operation on a typed subsystem, with the editor UI and the agent toolset as thin clients over the same surface, neither holding logic so "neither can drift." Its test — "if a function needs a widget to work, the design is wrong" — is the cleanest statement of the machine-user constraint in this corpus, and it comes from outside the engine vendors and outside the community-MCP pattern. It also claims a consequence: building for the machine user produced a better human API — idempotent, non-blocking, typed, costed before it commits. Vendor-stated, T3, undemonstrated beyond two videos.

Four properties they converge on

Self-description. An agent can't use an API it has to be told about, so the surface enumerates itself at runtime: unity command with no arguments lists what the editor exposes; Godot's discover_tools does the same job. Neither requires a registration step.

Extensibility in the project's own language. Unity turns any static method into a command with an attribute; Godot lets you write MCP tools in GDScript that hot-reload and appear to the agent as built-ins. The engine ships a floor, the project decides the rest.

The context budget is a design constraint. Godot deliberately keeps the startup tool surface small and expands on demand, because 112 tool definitions in every prompt is a cost. An engine API has thousands of operations and an agent's attention doesn't scale with it — a constraint no human-facing editor API ever had.

Cost as a first-class property (added 2026-09-10). kovati-automation-forge prices an operation before committing to it and suspends the run where a human should decide. None of the three engine surfaces has an analogue, because none of their operations spend money — an agent calling a paid generation API turns "what will this do" into "what will this cost," and that is a fifth property the engine-vendor instances have not needed yet.

Token-gated, localhost-only, off by default. Unity's eval runs arbitrary C# inside a live editor and is gated behind a security token, localhost-bound, dev/QA only. Godot's server binds 127.0.0.1, requires a session token as the client's first message, boundary-checks filesystem paths, and offers a read-only mode. Two unrelated projects, the same conclusion: write access to a running editor is the dangerous part.

Why it matters beyond convenience

The surface is what turns an assistant that suggests into an agent that observes, acts, and verifies. Unity's demo case is the shape of it: given "the player sometimes falls through the floor," the agent inspects the live scene, re-enables a collider, and re-enters play mode to confirm — a loop that needs the engine to be drivable and inspectable, not just scriptable. Godot's playtest control tools serve the same closing step.

It also relocates the competition. Editor AI started as "which model is in the editor" (Unity AI, UE6's bundled Claude/Gemini); the surface layer makes the answer any model, since the engine only has to speak a protocol. That is why two of the three bet on MCP rather than a proprietary plugin, and it is a live seam with ../agentic-tooling-wiki's MCP thread.

The strategies mirror the governance

Unreal and Unity ship theirs first-party; Godot's is a community add-on on the Asset Library, explicitly unaffiliated with the Foundation. That is exactly the split Godot's vision describes — a smaller solid engine, with everything else left to plugins — and it means the AI surface for Godot is maintained by whoever shows up rather than by the engine team.

Retrofit versus foundation

The four properties above are worth re-reading as consequences of retrofitting. Self-description exists because the API predates the caller. The context budget bites because an engine API accumulated thousands of operations for humans who could ignore most of them. The token-gated localhost write path is a lock fitted to a door that was built open, on an editor whose formats a non-editor tool cannot reliably parse.

immens proposes removing the cause rather than managing the symptoms: if the content is text in an open format, an agent reads the project directly instead of asking the editor about it, and provenance is a property of the asset rather than something the tool remembers. That is a coherent argument and it is currently only an argument — no engine, no specification, no demonstration. The honest position for this page is that the three shipping surfaces converged under a shared constraint, and the first project to claim it was not designing under that constraint has not shipped, so nobody knows whether the constraint was the retrofit or the problem.

The foundation-first position now has something shipping (2026-08-28)

The section above left immens's claim untestable: a surface designed in from the start rather than retrofitted, argued by a project with no release. vgpu is not that engine, but it is that construction, and it ships — so the argument can be inspected on a real artifact for the first time.

It is a WebGPU library rather than an engine, and its agent surface is the documentation system itself: npx vgpu docs and vgpu examples serve the guides and the gallery from the installed package, vgpu check validates shaders, npx vgpu mcp runs local stdio against package-versioned docs, and a public read-only MCP endpoint sits at vgpu.sh/api/mcp beside published agents.md, llms.txt and an OpenAPI-described examples API. The workspace also runs agent evals as npm scripts, which is the part no engine here does: the project tests whether agents can actually use it.

Three of the four converging properties hold; one is missing, and the reason is instructive. Self-description holds (the CLI and the manifests enumerate everything). Safety-by-default holds in translated form — the manifest tells agents to verify SHA-256 before using a downloaded artifact, and the public endpoint is read-only and tokenless, which is the same instinct as Unity's token-gated eval pointed at a supply chain instead of a live editor. Extensibility in the project's own language holds trivially, since the project's language is TypeScript and WGSL and the agent writes both.

The context budget does not bite, and that is the finding. A library has an API surface an agent can hold; an engine has thousands of operations it cannot. Godot expands its tool surface on demand because 112 tool definitions are a real cost, and vgpu has no equivalent problem to solve.

So this does not settle immens's claim. vgpu shows that designing the surface first is coherent and shippable at library scale, where the retrofit pressure the three engines are under barely exists — no editor, no scene database, no asset pipeline, no decade of accumulated API. The engine version of the argument is still unproven.

godot-mcp-toolkit · unity-cli · unreal-engine-5-8 · unreal-engine-6 · unity-engine · godot-engine · immens · vgpu · godot-contribution-policy-2026 · synthesis