Unity MCP by IvanMurzak: AI Agents Inside the Unity Editor and Inside the Built Game

The gap Unity MCP is aiming at: agents that cannot touch the editor

A coding assistant that can only read and write files has a narrow view of a Unity project. Scenes, prefabs, components, asset imports and play-mode state live in the editor, not in the text files the assistant can open. Unity MCP exists to close that gap. It is an MCP server plus a Unity plugin that exposes editor operations as tools an MCP client can call, so an agent can act on the project rather than only suggest edits to it.

The audience is Unity developers who already use an MCP-capable client. The README lists Claude, Codex, Cursor, GitHub Copilot, Gemini, Antigravity, VS Code, Rider, Visual Studio, Open Code, Cline and Kilo Code as supported clients, and states there is no vendor lock-in across Anthropic, OpenAI and Microsoft providers. The project is written in C# and licensed Apache-2.0.

The second half of the pitch is unusual. The README says the plugin works inside your compiled game, which it frames as the difference from other tools, and lists runtime use for dynamic NPC behavior and debugging. That is a different product category from an editor automation bridge, and it is the claim worth scrutinising before you commit.

How the pieces fit: plugin, MCP server, CLI and runtime

The repository layout tells you the shape of the system. Unity-MCP-Plugin/ holds the Unity-side package, published on OpenUPM as com.ivanmurzak.unity.mcp. cli/ holds the command line installer. Installer/ holds the .unitypackage build. Unity-Tests/ holds the test project, and commands/ and docs/ carry the tool documentation.

On the client side, the README describes two transports: local stdio and remote http, selected through configuration. In the stdio case the MCP client launches the server process directly. In the http case the server listens and the client connects over the network. A Docker image is published at aigamedeveloper/mcp-server, which fits the remote mode where the server does not have to live on the same machine as the editor.

Tools are the unit of work. The README points to a default tool list and says any C# method can be turned into a tool with a single line, which is the extension path for project-specific operations. Skills are generated from the operating system, the Unity version and the plugins present in the project, so the agent's context is shaped by the actual project rather than a generic Unity description. The README frames this as efficient token usage.

Installing Unity MCP with the CLI and making a first tool call

The README gives two install routes: a downloadable .unitypackage called AI-Game-Dev-Installer.unitypackage, and the CLI. The CLI route is the one the README calls quick setup. It is an npm package named unity-mcp-cli, installed globally.

npm install -g unity-mcp-cli

With the CLI on the path, the plugin is installed into a specific Unity project directory. The README passes the project path as an argument.

unity-mcp-cli install-plugin ./MyUnityProject

The next step authenticates against ai-game.dev. The README notes this opens your browser and uses an OAuth device flow, so the terminal waits while you approve in the browser.

unity-mcp-cli login

After that the README's fourth step is to open Unity, and the excerpt stops there. What you should expect at this point is the plugin present in the project and a server the MCP client can connect to, configured for either stdio or http. The README does not document a verification command, so the practical check is whether your client lists the Unity tools after you point it at the server. If the tool list is empty, the client is not reaching the server, and the transport setting is the first thing to inspect.

Turning a C# method into a tool, and what that costs you

The extension model is the most concrete claim in the README: any C# method may be turned into a tool by a single line. That is a low-friction way to expose game-specific operations, for example spawning a prefab variant or running a project-specific validation pass, without writing a separate MCP server.

The trade-off is surface area. Every method you expose becomes something an agent can call, and the README does not describe an approval step, a dry-run mode or a permission layer for custom tools. Default tools operate in the Unity Editor, which means an agent with access to them is editing your project. Version control is your safety net here, not the tool. The repository does include a .gitignore at the top level and the README's related searches include git usage, but the README itself does not document rollback behaviour for an agent action, so treat commit-before-you-let-it-run as an operational habit rather than something the project enforces.

Skills are the counterweight. By generating context from the OS, Unity version and installed plugins, the project tries to keep the agent from wasting tokens on capabilities the project does not have. Whether that materially reduces cost depends on your project, and the README gives no numbers.

Runtime AI in a shipped build: the claim that needs the most scrutiny

Most Unity AI tooling stops at the editor. Unity MCP does not, per the README, which states the plugin works inside your compiled game and enables AI within your games for real-time debugging and player interaction. The badges mark both Unity Editor and Unity Runtime as supported.

This is where the documentation is thinnest. The README does not describe how the runtime component authenticates end users, what happens when the LLM provider is unreachable mid-session, what the latency budget looks like for player-facing dialogue, or how cost is contained when the caller is a player rather than a developer. For an editor tool those questions are minor. For a shipped game they are the design.

There is also a licensing dimension the README does not address. The project is Apache-2.0, which covers the code, but it says nothing about the terms of the ai-game.dev account the CLI signs you into, or about the provider terms that apply once your players' sessions reach an LLM. If runtime AI is your reason for looking at this project, that gap is the first thing to resolve, not the last.

Where Unity MCP is the wrong tool

If you do not use an MCP-capable client, nothing here helps you. The whole design assumes a client that speaks Model Context Protocol and can hold a tool list. A team that wants scripted, deterministic editor automation should look at Unity's own batch-mode and editor scripting instead, because an agent deciding which tool to call is a different reliability model from a script that runs the same steps every time.

If your project cannot tolerate an agent modifying scenes, prefabs or assets, the editor tools are a liability rather than a feature. The README describes a wide range of default tools for operating in the Unity Editor and does not describe a read-only mode.

If you need runtime AI with published latency, cost and fallback behaviour, this project's README does not give you enough to plan against. And if your Unity version falls outside what the badges cover, or your client is not on the supported list, you are outside the tested path even though the underlying MCP protocol should in principle allow it.

How it differs from editor-only Unity MCP servers

The obvious comparison is an editor-only Unity MCP server: a bridge that exposes scene and asset operations to a client and stops when the editor closes. The difference is not the protocol, which is the same, but the deployment target. Unity MCP ships a plugin that the README says also runs in the compiled game, plus a Docker image for the server, which means the same tool layer can be reached from a build rather than only from the editor process.

That difference changes what you can build. An editor-only bridge automates authoring. A bridge that also runs at runtime can be wired into gameplay, which is what the NPC behavior and in-game debugging claims rest on. It also changes the risk profile: an editor-only tool fails during development, while a runtime tool can fail in front of a player.

If your need is purely authoring, an editor-only server is the smaller dependency and the easier thing to reason about. Choose Unity MCP when the runtime path is actually part of your plan, because that is the capability you are paying for in complexity.

Maintenance, releases and what to check before adopting

The repository is not archived, and the last push was on 2026-09-04, which is recent relative to today. Releases have been frequent: 0.88.0 on 2026-08-16, 0.89.0 on 2026-08-19 and 0.90.0 on 2026-08-24. A 0.90 version number means the API surface is still pre-1.0, so tool names, configuration keys and the CLI's flags can change between minor releases. Pin the CLI version in CI rather than installing latest, and read the release notes before upgrading a project you depend on.

The upgrade path has two halves that can drift: the OpenUPM package com.ivanmurzak.unity.mcp inside the Unity project, and the unity-mcp-cli npm package outside it. Nothing in the README states that they are versioned together, so check both after an upgrade.

On licensing, Apache-2.0 covers the repository and permits commercial use with the usual notice and patent terms. It does not cover the ai-game.dev service the CLI authenticates against, and it does not cover the LLM provider you connect. Those are separate agreements, and the README does not describe them. This is not legal advice; read the LICENSE file and the service terms yourself.

Editorial conclusion

Adopt it if you already drive an MCP-capable client and want the same tool surface in the editor and in a compiled build; the runtime story is what separates it from editor-only bridges. Skip it if you need a stable, documented protocol for shipping player-facing AI, because the README describes runtime capability without publishing latency, cost or failure-handling guidance. Verify first that your Unity version is covered by the badges, that your client is among the listed ones, and that the OAuth device flow in unity-mcp-cli login fits your team's account policy.

Frequently asked questions

Official sources

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