AnkleBreaker Unity MCP Server: 268 to 330 Tools, One HTTP Bridge, and a Plugin You Must Install Separately

The gap this fills: an AI client that can touch the Unity Editor, not just write C#

An assistant that can write a MonoBehaviour still cannot place that script on a GameObject, wire its serialized references, bake a NavMesh, or read the console after compilation. AnkleBreaker Unity MCP Server exists to close that loop. It is a Model Context Protocol server, written in JavaScript, that exposes Unity operations as MCP tools so a client such as Claude Desktop, Cursor, or Windsurf can call them from a chat session. The README describes the intent directly: it turns the assistant into a Unity co-pilot that can create scenes, manipulate GameObjects, manage components, run builds, profile performance, edit Shader Graphs, and control Amplify Shader Editor. The target user is a Unity developer who already has an AI client configured for MCP and wants editor actions, not just code suggestions. The Hub side matters too. Unity Hub is driven through its CLI, and the README notes support for both the modern --headless syntax and the legacy -- --headless form, which is the kind of detail you only write down after hitting both.

Architecture: MCP client to server to an HTTP plugin inside the Editor

The data flow is a four-hop chain. The AI assistant talks MCP to this server. The server talks to Unity Hub through the Hub CLI. For everything inside a project, the server talks to a separate repository, unity-mcp-plugin, which runs an HTTP API inside the Unity Editor. The README's diagram names the hops: Claude or another assistant, then the MCP server, then the Unity Editor plugin as an HTTP bridge, with Unity Hub CLI hanging off the server. That split is the single most important design fact about the project. The server is not a Unity package. It is an external process, and the Editor side is code you install into your project. Two consequences follow. First, the Editor must be running with the plugin loaded for project tools to work, which is a different operational model from a headless CLI tool. Second, the plugin is versioned separately from the server, so a server release can outpace or lag the plugin it talks to. The repository also lists a Multi-Instance category for discovering and switching between running Unity Editor instances, and a Multi-Agent category for listing active agents and reading agent action logs. Those two categories only make sense in the HTTP-bridge model, where several editor processes can be alive at once.

What the tool categories actually cover, and where they stop

The README's table is long and concrete. Hub tools list and install editors and manage modules. Scene tools open, save, and create scenes and return a paginated hierarchy tree. Component tools add, remove, and get or set any serialized property, with single and batch reference wiring. Console and compilation are deliberately separated: console logs come from the Unity console, while C# compilation errors are read through CompilationPipeline independently of the console buffer. That distinction is a real one, because a full console buffer can hide compile errors, and the v2.35.5 release note mentions restored Unity error messages plus fail-closed routing. Testing runs EditMode and PlayMode tests through the Unity Test Runner API and polls results. Graphics capture scene and game views as inline images, which is what lets a model inspect what it built rather than assume. Profiler, Frame Debugger and Memory Profiler are separate categories, and the README marks the memory profiler as depending on com.unity.memoryprofiler. The Amplify Shader Editor category is explicitly conditional, described as available if installed. So the headline count is not a flat guarantee. Several categories are gated on a package or a third-party asset being present in your project.

The count problem: 268 in the description, 330+ in the README

The repository description says 268 tools. The README says 330+ tools across 30+ categories, and repeats that figure in the features section and the architecture section. Both numbers sit in material published by the same project, and nothing in the supplied text reconciles them. The likely explanation is growth over time: the README was updated as categories were added while the one-line description was not. That is a normal kind of drift, but it has a practical effect for anyone evaluating the project. You cannot cite a tool count as a stable interface size, because the count changes between releases. Recent release notes back this up. v2.35.4 added ProBuilder tools. v2.35.6 added object-reference animation curves for 2D sprite animation. Each release moves the number. If you are writing integration tests against specific tool names, pin a version and read the tool list from that version rather than from the README.

Getting it running: two installs, not one

The material gives the shape of setup but not a full command sequence, so treat this as the outline you will finish against the repository's own instructions. Step one is the MCP server itself, a JavaScript project, which you register with your MCP client. The README names Claude Desktop, Claude Cowork, Cursor, Windsurf, and any MCP-compatible tool as clients, so the registration step is client-specific and lives in that client's MCP configuration. Step two is the companion plugin from AnkleBreaker-Studio/unity-mcp-plugin, which you add to the Unity project you want to control. The server reaches Unity Hub through the Hub CLI, and the README notes it handles both --headless and the legacy -- --headless argument styles. The server reaches the Editor over the plugin's HTTP API. What the supplied README does not contain is the literal install command, the config file path, or a JSON snippet for any client. That is a documentation gap, not a hidden feature. Budget time to read the repository's install docs and the plugin repository side by side, because the two halves have to agree on a port and a running Editor before anything works.

Where it will frustrate you: state, package gates and licence ambiguity

The first limitation is inherent to the architecture. Because project tools go through an HTTP API inside a running Editor, the server cannot do project work against a closed Editor or a bare CI runner the way a pure CLI build script can. You get a live editor, with its domain reloads, its play mode, and its compile cycles, and the server has to route around all of that. The v2.35.5 note about fail-closed routing suggests the project has already met cases where a command could not be safely dispatched. The second limitation is the conditional categories. Amplify Shader Editor tools require that asset. Memory Profiler tools require com.unity.memoryprofiler. UMA tools assume Unity Multipurpose Avatar. If your project does not use those, a chunk of the advertised surface is inert, and the effective tool count for you is lower than the headline. The third is the licence. Repository metadata reports NOASSERTION, which means no recognised SPDX identifier was detected, even though the description calls the project free and open source. That is a gap you resolve by reading the licence file, not by trusting the description. None of this is a reason to avoid the project. It is a reason to scope what you are actually getting before you wire it into a team workflow.

Alternatives and the real difference in approach

The obvious comparison is a plain Unity Editor script or a custom EditorWindow that runs your own menu items. The Editor category here includes executing menu items and running C# code, so a team that already has internal editor tooling can expose it through this server instead of writing a new integration layer. The difference is that a custom EditorWindow is deterministic and typed, while an MCP tool call is a natural-language-driven request that a model composes. That trade is the whole point of the project and also its main risk. A second comparison is Unity's own command line build and test invocation, which you would script directly in CI. That path has no model in the loop, no running Editor requirement beyond the batch process, and no dependency on a plugin repository tracking your Editor version. It is the right tool for repeatable pipelines. This server is the right tool for exploratory and interactive work: building a scene, inspecting it through captured game view images, adjusting lighting, running a play-mode check. The two are not substitutes. A team could reasonably use direct CLI invocation for nightly builds and this server for interactive authoring, and the README's own showcase clips, a brick breaker, a medieval village, a castle with an FPS walkthrough, are all interactive authoring stories.

Maintenance cost and the licence question you have to answer yourself

The release cadence is fast. v2.35.4, v2.35.5 and v2.35.6 all landed within four days in late July 2026, and the notes cover reliability fixes, restored error messages, fail-closed routing, and per-action undo. A cadence like that means the server and the plugin are both moving, and you should expect to track them together. The practical cost is not the upgrade itself but the compatibility check: server version against plugin version against Unity Editor version, repeated each time you pull. Pinning a known-good triple is cheaper than chasing main. On licensing, the description says free and open source, and the metadata says NOASSERTION. Those are not the same statement. Read the licence file in the repository and confirm what it permits for your use, especially if you redistribute the server inside a product or run it in a commercial pipeline. That is a question for your own review, not something the repository metadata answers. The one thing the material does establish is that the project is actively maintained and not archived, which removes the abandonment risk from the decision.

Editorial conclusion

Adopt this if you already run a Unity project with a stable Editor version and want an MCP client to drive scene setup, component wiring, builds and profiling without leaving the chat. Do not adopt it if you need a single self-contained package, if your project depends on packages the tool categories list as conditional (Amplify Shader Editor, com.unity.memoryprofiler), or if a non-standard licence blocks your legal review. Before installing, verify three things: which Unity Editor versions the companion unity-mcp-plugin supports, whether the tool count is 268 or 330 for the release you pin, and what the actual licence text says, because the repository metadata reports NOASSERTION rather than a recognised identifier.

Official sources

1. AnkleBreaker-Studio/unity-mcp-server on GitHub
2. Issues
3. Project website
4. README
5. Releases