Unity MCP: an AI agent wired into the editor and the compiled game

The plugin answers in play mode, not only in the editor

Most editor automation lives on one side of the play button. Unity-MCP is built so the same plugin keeps serving an agent after the game is running, which is why the README splits its feature list between Editor work and a Runtime bullet about running LLMs inside a compiled build for dynamic NPC behaviour or for debugging. An agent can therefore hold a conversation about the running scene, not just about a scene file on disk.

Only part of that badge row describes a real user. Those badges link to Claude, Codex, Cursor, GitHub Copilot, Gemini, Antigravity, VS Code, Rider, Visual Studio, opencode, Cline and Kilo Code, but the audience that actually benefits is a studio or an individual who already ships a Unity project and wants an agent to write mechanics, place prefabs and then inspect the result while it is live.

The repository layout explains where the code sits: Unity-MCP-Plugin/ holds the package, cli/ holds the Node command line tool, Unity-Tests/ and tests/ hold coverage, docs/ holds the tool registry. Everything the agent touches therefore has to go through C# inside the editor process, which is the reason the tool names read like editor API calls rather than like prompts.

Work on it is not dormant. The Timeline, Tilemap and Terrain 2.1.0 packages were all released on 31 October 2026, so expect the tool surface to move under you between editor upgrades.

Two transports, and the CLI decides which one you get

The connection is standard MCP, so the editor end is a server and the agent is the client. The README calls the deployment flexible in one line and then names the two shapes: local over stdio, remote over http, chosen by configuration. That choice matters more than it sounds. An stdio server is started by the agent process itself, which means the agent binary has to be on the same machine as the licensed Unity editor and able to spawn it. An http server is reachable from elsewhere, which is the only version of this plugin you can point at a build machine or a colleague's editor.

The Docker image aigamedeveloper/mcp-server is published on Docker Hub, which is the remote shape packaged for you. The plugin is also distributed as com.ivanmurzak.unity.mcp through OpenUPM and as a downloadable .unitypackage from the releases page, so the editor half can arrive without any package manager involvement at all.

The consequence for an evaluator: choosing http moves the security boundary. Check how the http transport is secured before exposing it beyond localhost.

Seventy tools are four API surfaces with a naming convention

The tool registry is not a list of invented actions. Read the Project and Assets family and it is the Unity AssetDatabase and the package manager: assets-copy, assets-move, assets-find, assets-prefab-instantiate, assets-refresh, package-add, package-list, package-remove. The next family, Scene and Hierarchy, does the same for GameObjects and components. The names are the mechanism, and once you see that the mapping is mechanical.

The README states the plugin ships 70+ built-in tools across four categories and that every one is usable straight after installation, with the full reference kept in docs/default-mcp-tools.md and mirrored on a site under ai-game.dev. That count is the number to check against the docs rather than a quality claim.

Extension is the part with a real design opinion in it. The README advertises that any C# method can be turned into a tool by a single line, and points at a custom tool example in the project code. So the tool surface is not fixed at 70. Your own editor code becomes agent-callable, which is the reason to use this rather than a generic editor bridge.

Installing with unity-mcp-cli, and the login it adds on top

The CLI is the shortest documented path. It installs globally through npm, then installs the Unity package into a project path you name, then opens the project so the plugin connects and generates skills.

npm install -g unity-mcp-cli
unity-mcp-cli install-plugin ./MyUnityProject
unity-mcp-cli login
unity-mcp-cli open ./MyUnityProject

Read that third line carefully. unity-mcp-cli login opens a browser for an OAuth device flow against ai-game.dev, which is the same host the README lists as the project homepage and the home of the browsable tool registry. The repository description says the project works with any agent absolutely for free, and nothing in the install path above is paid, but a CLI-driven setup does put an account and a network round trip between you and a working editor. If that is unacceptable on your machine, use the editor route instead: install the .unitypackage or run openupm add com.ivanmurzak.unity.mcp and configure from inside the editor.

The claim of zero configuration contradicts step three of the quick start

Here is the detail a skim misses. The tool section says all tools are available immediately after installation with no extra configuration required. The Quick Start, three steps earlier, ends with: open Window/AI Game Developer in Unity and click Auto-generate skills, or Configure MCP. Both cannot be true in the same sense. The tools are compiled into the package and callable, but the agent side still needs a generated skills file or a written MCP configuration to know the tool names and the arguments.

That step is what the Auto-generate skills button exists for, and the README recommends it over Configure MCP because it reads the project: it generates skills based on the operating system, the Unity version and the plugins present. The CLI has a command for the same job when you would rather not click.

npx unity-mcp-cli setup-skills claude-code ./MyUnityProject

So the honest summary is that the plugin needs no configuration, and the agent needs one step of it. On a project with an unusual plugin set, that generated file is the part worth reading before you trust it.

Runtime agents inherit every editor tool, including the destructive ones

The default registry contains assets-delete, assets-move, package-remove and gameobject-component-destroy. In the editor a mistaken call is recoverable through version control. Inside a running build there is no undo stack and no project window, and the agent is reasoning from a description of the scene rather than from a screenshot of it.

That is the failure mode to design around, and it is not a bug so much as the cost of one unified tool surface. If you enable the runtime path, decide yourself which tool names you are willing to expose, and where you draw that line.

The other limit worth naming is the documentation silence around version compatibility. The README's badges link the Unity editor archive; check which Unity versions the current 2.1.0 packages support, and the tool calls sit close to editor internals that do move between versions.

How this differs from driving Unity through a plain MCP file bridge

A file-oriented alternative lets the agent read and write scripts, scene YAML and .meta files through filesystem tools, and run batch mode with Unity's command line for anything that must execute. Unity-MCP takes the opposite route: it runs C# inside the live editor, so the agent works against the resolved object model, the asset database and the play state rather than against text.

The practical difference is the feedback loop. Text-level edits need a domain reload and a compile check before anything observable happens, and errors arrive as compiler output the agent has to parse. Editor-side tools return the actual component state. Runtime capability is where the gap widens, since a file bridge cannot answer a question about a live build at all.

The cost is that you give a language model write access to a licensed desktop application. That is a real difference in trust model, not a matter of taste, and it is the first thing to settle before deciding between them.

Editorial conclusion

Adopt it if your agent work happens inside Unity, on a licensed editor you control, and you want the same tool surface during play mode. Do not use the CLI route if your pipeline forbids an ai-game.dev OAuth login, and do not adopt it at all if you only want asset scripting that a lighter in-editor tool already covers. Verify first that the agent can reach your Unity version through the transport you intend to run, because the plugin ships as an editor package and a runtime component at once, and the tool calls sit close to editor internals.

Frequently asked questions

Official sources

1. IvanMurzak/Unity-MCP on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases