Unity-MCP: C#-Methoden als MCP-Tools für Claude, Cursor und Copilot

Welches Problem Unity-MCP löst und für wen

Ein MCP-Client wie Claude Code oder Cursor sieht zunächst nur Dateien. Er kann eine C#-Datei schreiben, aber er weiß nicht, ob die Szene danach noch lädt, ob ein Prefab-Verweis gebrochen ist oder ob ein Test in der Unity Test Runner durchläuft. Unity-MCP setzt genau an dieser Lücke an: Das Projekt beschreibt sich selbst als MCP-Server für den Unity Editor und zusätzlich für die Laufzeit, also für das kompilierte Spiel. Die Zielgruppe sind damit nicht Werkzeugentwickler, sondern Teams, die einen Agenten bereits im Einsatz haben und ihm Zugriff auf die Editor-Interna geben wollen, ohne für jede Operation ein eigenes Plugin zu schreiben.

Der zweite Adressatenkreis ist enger: Wer LLM-Aufrufe in das fertige Spiel einbauen will, etwa für NPC-Verhalten oder für Debugging in einem Build. Das README formuliert das als Abgrenzung zu anderen Werkzeugen, die nur im Editor arbeiten. Ob dieser Laufzeitpfad in der Praxis stabil genug für ein ausgeliefertes Spiel ist, lässt sich aus dem Material nicht belegen. Der Hinweis auf Debugging im Build ist plausibel, die Aussage zur Spieler-Interaktion bleibt eine Behauptung ohne Mechanismusbeschreibung.

Wie der Server Tools registriert und Anfragen weiterleitet

Das Modell ist eine Registrierung von Methoden. Laut README kann jede C#-Methode mit einer einzigen Zeile in ein Tool umgewandelt werden. Ein Attribut markiert die Methode, der Server sammelt diese Markierungen beim Start ein und stellt sie dem MCP-Client als aufrufbare Tools bereit. Der Client sieht also nicht das Unity-Projekt als Ganzes, sondern eine Liste von Einstiegspunkten, die das Projekt selbst definiert. Das ist der eigentliche Mechanismus, und er erklärt, warum das Projekt mit vielen Clients funktioniert: Die Anbindung liegt nicht im Client, sondern im Unity-Projekt.

Für den Transport nennt das README zwei Varianten. Lokal läuft die Verbindung über stdio, für entfernte Szenarien über http, gesteuert über Konfiguration. Welche Konfigurationsschlüssel dabei genau gesetzt werden, geht aus dem bereitgestellten Ausschnitt nicht hervor. Neben den selbst geschriebenen Tools liefert das Projekt eine Sammlung von Default-Tools mit, die in einer separaten Datei docs/default-mcp-tools.md dokumentiert sind. Diese Datei lag nicht vor; wer den Umfang einschätzen will, muss sie im Repository öffnen. Ein weiterer Bestandteil sind Skills, die laut README abhängig von Betriebssystem, Unity-Version und den im Projekt vorhandenen Plugins erzeugt werden. Das ist ein interessanter Ansatz, weil er verhindert, dass der Agent API-Aufrufe vorschlägt, die in der installierten Unity-Version nicht existieren. Wie diese Generierung abläuft, bleibt im Ausschnitt offen.

Installation über die CLI in vier Schritten

Der vom README empfohlene Weg führt über npm. Zuerst wird das Kommandozeilenwerkzeug global installiert:

npm install -g unity-mcp-cli

Danach folgt die Installation des Plugins in ein konkretes Unity-Projekt, wobei der Pfad als Argument übergeben wird:

unity-mcp-cli install-plugin ./MyUnityProject

Der dritte Schritt ist eine Anmeldung, die laut README einen Browser öffnet und den OAuth Device Flow verwendet:

unity-mcp-cli login

Damit ist eine Abhängigkeit zu ai-game.dev gegeben, die im weiteren Text noch eine Rolle spielt. Alternativ zum CLI-Weg bietet das Projekt ein Unity-Paket namens AI-Game-Dev-Installer.unitypackage als direkten Download an. Für Nutzer von OpenUPM existiert zusätzlich das Paket com.ivanmurzak.unity.mcp, das über die Registry package.openupm.com bezogen wird. Wer den Docker-Weg bevorzugt, findet unter dem Namen aigamedeveloper/mcp-server ein Image auf Docker Hub. Diese vier Bezugswege sind ein Hinweis darauf, dass das Projekt unterschiedliche Betriebsmodelle unterstützt, aber auch darauf, dass die Dokumentation an mehreren Stellen parallel gepflegt werden muss.

Grenzen: Laufzeit, OAuth und die fehlende Spezifikation der Tools

Die erste Einschränkung betrifft den Laufzeitmodus. Ein MCP-Server im kompilierten Spiel bedeutet, dass ein Agent Zugriff auf Spieldaten erhält, und das in einer Umgebung, die beim Spieler läuft. Das README nennt das als Vorteil, ohne ein Sicherheitsmodell zu beschreiben. Wer diesen Pfad wählt, sollte selbst klären, welche Tools im Build überhaupt registriert werden und ob sie durch das Attribut versehentlich mit ausgeliefert werden. Das Material enthält dazu keine Aussage.

Die zweite Einschränkung ist der Login. Der CLI-Befehl login öffnet einen Browser und autorisiert gegen ai-game.dev. Für Einzelentwickler ist das unproblematisch, in Umgebungen ohne Browser oder mit restriktiven Netzwerkregeln wird es zum Hindernis. Ob es einen rein lokalen Betrieb ohne diesen Schritt gibt, lässt sich aus dem Ausschnitt nicht beantworten.

Drittens die Dokumentationslage. Das README verspricht eine breite Tool-Palette, verweist für Details aber auf eine Datei, die hier nicht vorliegt. Ebenso bleibt offen, wie die Skill-Generierung tatsächlich funktioniert und welche Unity-Versionen unterstützt werden. Die Badges im Repository nennen für Editor und Runtime nur ein X als Platzhalter, also keine konkrete Versionsangabe. Wer auf eine bestimmte Unity-LTS festgelegt ist, muss das vor der Installation selbst prüfen.

Alternative: ein Editor-Add-in mit festem Befehlsvorrat

Der naheliegende Vergleich ist ein klassisches Unity-Editor-Add-in, das eine feste Liste von Menübefehlen bereitstellt, etwa Szenen speichern, Assets importieren, Tests starten. Der Unterschied liegt nicht im Umfang, sondern in der Richtung der Kontrolle. Ein Add-in definiert die Befehle zur Entwicklungszeit und der Nutzer wählt daraus aus. Unity-MCP dreht das um: Das Projekt exponiert Methoden, und ein Sprachmodell entscheidet, welche davon in welcher Reihenfolge aufgerufen werden. Das ist mächtiger und schwerer zu überblicken, weil die Aufrufreihenfolge nicht mehr im Code steht, sondern im Dialogverlauf.

Ein zweiter Unterschied betrifft die Kopplung an einen Anbieter. Das README betont ausdrücklich, dass keine Bindung an einen Anbieter besteht und dass Claude Code, Gemini, Copilot, Cursor und weitere Clients unterstützt werden. Das ist ein echter Vorteil gegenüber Werkzeugen, die nur mit einem Assistenten funktionieren. Der Preis dafür ist, dass die Qualität der Tool-Nutzung vom jeweiligen Modell abhängt. Ein Add-in verhält sich bei jedem Nutzer gleich, ein MCP-Server tut das nicht.

Wartung, Versionierung und Lizenz

Die Release-Historie im Material zeigt drei Versionen innerhalb von knapp drei Wochen im August 2026: 0.88.0, 0.89.0 und 0.90.0, gefolgt von einem Push Anfang September. Die Versionsnummern liegen alle unter 1.0.0. Das bedeutet nicht automatisch Instabilität, aber es bedeutet, dass die API-Oberfläche noch als vorläufig behandelt wird. Wer eigene Tools über das Attribut registriert, sollte bei jedem Update prüfen, ob sich die Signatur oder das Registrierungsverhalten geändert hat. Ein Upgrade ist über den CLI-Befehl install-plugin erneut ausführbar, sofern das Projektverzeichnis angegeben wird.

Lizenziert ist das Projekt unter Apache-2.0. Diese Lizenz erlaubt kommerzielle Nutzung und Modifikation, verlangt aber die Beibehaltung von Copyright-Hinweisen und stellt eine Klausel zu Patenten bereit. Für Teams, die das Plugin in ein kommerzielles Spiel einbinden, ist das in der Regel unkritisch. Zu beachten ist die Trennung zwischen dem Repository und dem gehosteten Dienst ai-game.dev, für den die Apache-2.0-Lizenz keine Aussage trifft. Wer den Login-Schritt nutzt, geht eine Beziehung zu einem Dienst ein, die nicht durch die Repository-Lizenz geregelt ist. Das ist keine Rechtsberatung, sondern ein Hinweis auf die Stelle, an der eine Prüfung ansetzen sollte.

Für wen sich der Einstieg lohnt

Der stärkste Grund für Unity-MCP ist die Kombination aus einer einzigen Registrierungszeile pro Tool und der Unabhängigkeit vom MCP-Client. Wer bereits mit einem Agenten arbeitet und ihm bisher über Umwege Zugriff auf den Editor verschafft hat, bekommt hier einen definierten Weg. Die CLI senkt die Einstiegshürde auf vier Befehle, und mit OpenUPM, dem Unity-Paket und dem Docker-Image existieren mehrere Bezugswege für unterschiedliche Arbeitsweisen.

Der schwächste Punkt ist die Nachvollziehbarkeit. Ein Agent, der eine frei wählbare Folge von Methoden aufruft, erzeugt Fehler, die nicht im Quelltext stehen. Wer den Laufzeitmodus nutzt, verschiebt diese Frage zusätzlich in das ausgelieferte Build. Für reine Editor-Automatisierung ist ein Add-in mit festem Befehlsvorrat die besser kontrollierbare Wahl. Für alles, was einen Sprachmodell-Zugriff auf Szenen, Assets und Tests benötigt, ist Unity-MCP der direktere Ansatz. Vor dem ersten Commit lohnt der Blick in docs/default-mcp-tools.md, um zu sehen, welche Tools ohne eigenes Zutun aktiv sind.

Redaktionelles Fazit

Wer Unity-Projekte mit einem MCP-fähigen Agenten bearbeitet und den Einstieg über eine einzige CLI-Zeile sucht, findet hier den passenden Weg. Wer eine reine Editor-Automatisierung ohne Laufzeitanteil braucht, trägt mit dem Runtime-Teil zusätzliche Angriffsfläche in das Build. Vor dem ersten produktiven Einsatz sollte geprüft werden, welche Default-Tools der Server tatsächlich registriert, ob der OAuth-Login gegen ai-game.dev für das eigene Team akzeptabel ist und ob die installierte Unity-Version von den generierten Skills abgedeckt wird.

Offizielle Quellen

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