In July I recommended wiring Unity’s own MCP integration into a repo-aware agent, and I still think that was the right call at the time. Unity’s documentation has since deprecated the MCP server in favour of the Unity CLI. Two months is a short shelf life for a recommendation, and the honest reaction to being wrong that fast is to ask what the change says about the direction, rather than to swap one vendor’s name for another.
The field has moved from one clever editor connection to two plainer things: tools that run outside the editor, and instructions the model reads before it starts.
Everything below was checked against the Unity assistant package documentation, the Unity CLI documentation, and the repositories named, on 7 September 2026.
Why an editor bridge became a command line
Unity’s assistant package used to ship an MCP server. You installed a relay, pointed Claude Code or Cursor at it, and the agent could ask the editor what was in the scene, read the console, and make changes. The assistant package’s documentation now marks that server deprecated and points external agents at the Unity CLI instead: a standalone binary that installs editors, manages modules, opens projects, and talks structured output. Editor control happens through a package called Unity Pipeline, and the agent reaches it by running commands rather than by holding a conversation with the editor process.
An MCP server that runs inside the editor inherits the editor’s life: it is there while the editor is open, it dies with a domain reload, and every request is a round trip through a process that was not built to be a server. A command line runs outside all of that. It survives reloads because it is not inside the thing reloading, it works in CI where no editor is open at all, and its interface is a contract a script can hold onto. The deprecation is Unity agreeing with the question this site has been asking about every bridge since July: does it survive the reload, and who keeps it alive?
That is the structural lesson of the change, and it is the same lesson the rest of the stack has been converging on. Context is not a wire you plug in: it is capabilities and instructions that have to survive outside the model’s session.
The editor access layer
Three routes to editor access are current as of this month, and they are worth naming as examples of the capability rather than as a ranking.
The most-starred open bridge is still CoplayDev’s unity-mcp, MIT-licensed and around 13,000 stars, and its README is now the clearest picture of the acquisition question from my July piece: the company behind it was folded into Ramen’s Aura assistant in March, and the repository now introduces Aura as its premium sibling. The code is still there, still MIT, still useful. The maintenance question is the point, and it does not need a crisis to be live: the person who answers your issue may now be building the commercial product the free bridge feeds.
The questions to hold onto while reading the rest of this layer are the three from July: does it see the scene, does it survive the reload, and who keeps it alive. This week’s teardown on this site is what those questions look like when the answer to all three is no for six months at a stretch.
Ivan Murzak’s Unity-MCP takes a different route: free, and it bundles skills, MCP tools and a CLI for Unity, with the interesting property that any C# method can become a tool with a single line. It works with Claude Code, Cursor, Gemini and Copilot. The C#-method-as-tool idea is the different move in this layer: instead of a fixed menu of editor commands, the project itself declares what the agent may call.
Unity’s own route is the CLI already described, and it comes with something the bridges do not: an official skills collection. Unity-Technologies’ skills repository ships reusable agent skills for Unity workflows, the unity-cli skill among them, and it is compatible with the agents that follow the skills standard, which is where the second layer starts.
The knowledge layer: skills and conventions files
The piece I wrote in July spent one sentence on a written rules file the agent has to follow. That sentence has become the fastest-moving part of the field, and it now has a standard behind it.
The Agent Skills standard is a SKILL.md file in a folder: YAML frontmatter that says when the skill applies, markdown that says what to do. It started with Claude Code and has spread across tools, with a cross-client convention of .agents/skills folders and directories like skills.sh tracking which agents support it. Unity’s own skills collection is built on it. Collections range from methodology frameworks such as Jesse Vincent’s superpowers, which is a development process built on composable skills and installs on most of the major agents, down to focused packs such as Julian Kerignard’s Unity-Skills, an 18-skill set for AI coding agents.
The project-level conventions file is the sibling of skills, and it is the one with the direct line to the failure modes this site keeps finding. AGENTS.md, CLAUDE.md and .cursorrules are all the same idea with different client names: instructions at the repository root that the agent reads at the start of every session, versioned in the repo and reviewed like code. The Unity input article made the case with one settings line: activeInputHandler decides which input API lives, nothing in the C# mentions it, and the fix is one sentence in the conventions file. Skills are general knowledge about how Unity works. The conventions file is knowledge about how your project works, and of the two, yours is the one the model cannot get anywhere else.
The general process layer
Around both sits the general stack of MCP servers that are not Unity-specific: the reference servers the MCP project itself maintains, covering filesystem, git, memory and web fetching; registries for the thousands of community servers, the official MCP Registry and Smithery among them; search and extraction servers such as Tavily’s, which has a hosted server you can point a client at; and memory layers such as mem0, which keeps the agent’s session-to-session memory somewhere other than the model.
Apply the July questions to this layer and the picture is consistent. Does it see the scene? No, and none of them pretends to: they are general process tools, and their value is that they do not need to know what Unity is to be useful. Does it survive the reload? Yes, because they all run outside the editor, which is precisely why the general layer has become the stable part of the stack while the editor-specific part churns. Who maintains it? The reference servers have a steering group behind them; the community ones vary, which is what registries are for.
What this layer actually attacks is the review problem, the one I said in July that no purchase removes. A git server gives the agent the history of a change. A memory server gives it the context of last week’s session. A browser or fetch server lets it read the documentation page for the version that is actually installed. Each of those removes one way for a model to answer confidently from nothing. None of them removes the need for a person to read what changed and decide whether it is true of the project, because the things that are true of the project are still mostly not written down anywhere the tools can reach.
What the tools still cannot see
There is a teardown on this site from this week that makes the boundary concrete. A developer built a survival game by buying a plugin for each system and letting an assistant write the glue between them. Five plugins, five data models, and the failures lived in the space between them: an update changed a lookup’s contract from null to an empty item and the glue copied the empty item; two event systems fired each other until the call stack ran out; the save add-on had been abandoned eighteen months before the project needed to move engine versions.
Now give that developer everything described above. An MCP bridge so the agent can read the scene, where it will find the plugins’ components and the glue. The skills so it knows how Unity serialises and reloads. The conventions file so it knows which plugin owns the inventory. None of it shows the agent what the plugins do to each other at runtime. That conversation happens inside compiled packages while the game runs, and no bridge or skill has a window into it. The question that broke that project was about behaviour between plugins. The stack answers questions about the project’s files, and that question was not about a file.
Each layer removes a class of confident wrongness: editor access removes guessed scene content, skills remove guessed engine behaviour, conventions remove guessed project rules, process tools remove guessed history. What is left is the part that has to be done by a person reading the code with the running game in mind, which is the part every project in this pattern has in common.
What I would install this month
The concrete stack, as of September 2026, and it is close to the one I gave in July, with the names updated.
A repo-aware agent for the C# work, with the model pinned. Unity CLI for anything that touches the editor, which is the route Unity now supports and the one that survives CI and reloads. Engine knowledge through the skills standard: Unity’s official collection, plus one smaller pack if it covers your engine version, kept in the repo where the agent can find them. A conventions file at the repository root that names the project’s actual decisions: the input backend, the render pipeline, the plugins and who owns what between them. The general process servers only where they answer a real question, which for most Unity teams means git and a documentation fetcher.
And one thing none of it replaces: a person reading every scene-adjacent change in the editor, on a schedule that is not the day before a milestone. The review is the one part of this stack with no tool in it, and it is the part that decides what ships.