Unity-MCP : brancher un agent LLM sur l'éditeur Unity et sur le jeu compilé

Le problème visé : un agent qui ne voit que des fichiers

Un agent de code classique travaille sur du texte. Il lit des scripts C#, propose des correctifs, et s'arrête là. Dans Unity, la partie qui compte n'est pas dans les fichiers : elle est dans la scène, les prefabs, les composants attachés aux GameObjects, les réglages de build. Un agent qui ne peut pas ouvrir un GameObject ne peut pas non plus diagnostiquer pourquoi un collider ne répond pas.

Unity-MCP attaque précisément cet écart. Le projet se présente comme un assistant de développement de jeu pour l'éditeur et pour le runtime, et il expose Unity à des clients MCP. Le public visé est donc double. D'un côté des développeurs solo ou de petites équipes qui utilisent déjà Claude Code, Cursor, Copilot, Gemini, Windsurf ou Codex et veulent que l'agent ait une prise sur le projet Unity réel. De l'autre, un cas plus inhabituel : ceux qui veulent appeler un LLM depuis l'intérieur du jeu compilé, pour du comportement de PNJ ou du débogage en cours d'exécution.

Le README insiste sur cette différence : le plugin fonctionnerait, selon ses auteurs, à l'intérieur du jeu compilé, là où d'autres outils s'arrêtent à l'éditeur. C'est la revendication qui mérite l'examen le plus attentif, parce qu'elle change la nature du produit.

MCP comme couche de transport, pas comme bibliothèque métier

Le mécanisme repose sur le Model Context Protocol. Unity-MCP n'est pas un serveur MCP isolé qui piloterait Unity par un canal propriétaire : c'est un plugin installé dans le projet Unity, qui expose des outils au client MCP, lequel est votre agent. Le README décrit deux modes de déploiement, local via stdio et distant via http, choisis par configuration.

Le flux est donc le suivant. Le client MCP déclare le serveur Unity-MCP. L'agent découvre la liste des outils exposés. Quand il appelle un outil, la requête traverse le transport jusqu'au plugin, qui exécute l'opération dans Unity et renvoie un résultat que l'agent réinjecte dans son contexte. Rien de ce cycle n'est propre à Unity-MCP : c'est le fonctionnement normal de MCP. Ce qui est propre au projet, c'est l'ensemble d'outils par défaut et la possibilité d'en ajouter.

Cette architecture a une conséquence pratique souvent sous-estimée : la qualité de l'expérience dépend autant du client MCP que du plugin. Un client qui tronque les résultats d'outils ou qui gère mal les réponses volumineuses dégradera l'usage, quelle que soit la qualité du serveur. Le README mentionne un usage efficace des tokens et des outils avancés, sans détailler la méthode employée. C'est une affirmation à prendre telle quelle, non vérifiable à partir du matériel fourni.

Transformer une méthode C# en outil : ce que dit le README

L'argument le plus concret du projet tient en une phrase du README : n'importe quelle méthode C# peut devenir un outil en une seule ligne. Le README renvoie à une section « Add custom tool » pour la marche à suivre, mais le matériel fourni ici ne contient ni le nom de l'attribut, ni un exemple de code complet, ni la signature attendue. Je ne peux donc pas décrire la syntaxe exacte sans inventer.

Ce que l'on peut dire, c'est ce que cette promesse implique. Si l'ajout d'un outil se fait par annotation sur une méthode existante, alors l'extension ne demande pas d'écrire un adaptateur MCP à la main, ni de maintenir un schéma séparé. Le code du jeu devient lui-même la surface exposée à l'agent. C'est un choix de conception qui réduit la friction à l'adoption, et qui déplace le risque : plus la surface exposée est large, plus il faut réfléchir à ce que l'agent peut déclencher. Le README ne traite pas ce point.

Le projet fournit par ailleurs une liste d'outils MCP par défaut, documentée dans docs/default-mcp-tools.md. Ce fichier n'est pas inclus dans le matériel fourni, donc je ne peux pas en énumérer le contenu. Si vous évaluez le projet, c'est le premier document à ouvrir : il détermine ce que l'agent sait faire dès l'installation, avant toute personnalisation.

Installation : la CLI plutôt que le paquet .unitypackage

Le README propose deux voies. La première est un installeur téléchargeable, AI-Game-Dev-Installer.unitypackage, depuis la page des releases. La seconde est la CLI, et c'est celle que le README met en avant avec un bloc de commandes :

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

La troisième commande ouvre le navigateur pour une authentification sur ai-game.dev via OAuth device flow, précise le README. Le bloc fourni s'arrête à l'étape 4, « Open Unity p », tronquée dans le matériel dont je dispose : je ne connais donc pas la commande suivante ni la procédure de configuration du client MCP. Il faudra consulter le README complet pour cette partie.

Le paquet est aussi publié sur OpenUPM sous le nom com.ivanmurzak.unity.mcp, et une image Docker existe sous aigamedeveloper/mcp-server. Ces deux canaux correspondent probablement aux deux modes de transport : le paquet Unity pour l'intégration dans l'éditeur, l'image Docker pour un serveur MCP distant. Le README ne fait pas ce lien explicitement, donc je le présente comme une hypothèse de lecture, pas comme un fait.

Un point à noter : la commande login implique un service hébergé, ai-game.dev, alors que le projet se présente comme fonctionnant « absolutely for free » avec n'importe quel client. Ces deux éléments ne sont pas contradictoires, mais ils ne sont pas non plus expliqués dans le matériel fourni. Si vous travaillez dans un environnement sans accès réseau sortant, c'est une question à trancher avant de commencer.

Le runtime : la vraie différence, et la vraie zone d'ombre

C'est ici que Unity-MCP se distingue de la plupart des intégrations MCP pour moteurs de jeu. Le README annonce que le plugin fonctionne dans le jeu compilé, ce qui permettrait du débogage en temps réel et de l'interaction PNJ-IA. Il liste aussi le support du débogage parmi les fonctionnalités, avec la formulation « Let AI debug and fix the problems in a project ».

Le matériel fourni ne permet pas d'aller plus loin. Aucune information sur la façon dont les identifiants du LLM sont embarqués dans un build, sur le coût par appel en production, sur la latence, ni sur ce qui se passe si le joueur n'a pas de connexion. Ce sont pourtant les questions qui décident si un usage runtime est viable ou seulement démontrable. Un jeu qui appelle un LLM distant à chaque décision de PNJ a un profil de coût et de latence très différent d'un jeu qui appelle une fonction locale.

Il y a aussi une asymétrie de maturité à signaler. Les outils d'éditeur sont documentés dans un fichier dédié et correspondent à un usage bien compris : l'agent agit sur un projet, un humain valide, les erreurs se corrigent. Le runtime déplace l'agent dans un environnement où les erreurs sont vues par des joueurs. Le README traite les deux avec le même ton. Ce n'est pas la même chose.

Pour un prototype, un outil de test interne ou une démo, l'usage runtime est un terrain d'expérimentation légitime. Pour un jeu commercial, la documentation disponible ne suffit pas à se prononcer.

Skills générés et compatibilité annoncée

Deux autres éléments du README méritent d'être isolés. Le premier est la génération de « skills » pour l'IA, présentée comme dépendante du système d'exploitation, de la version d'Unity et des plugins présents dans le projet. Autrement dit, le projet ne se contente pas d'exposer des outils : il produirait un contexte adapté à l'environnement détecté. C'est cohérent avec l'objectif affiché d'économie de tokens, puisqu'un contexte généré peut être plus court qu'un contexte générique. Le README ne décrit pas le format de ces skills ni la façon dont ils sont injectés dans le client. À vérifier dans la documentation si ce point conditionne votre choix.

Le second est la neutralité vis-à-vis des fournisseurs. Le README liste Anthropic, OpenAI, Microsoft et d'autres, avec la mention « no vendor lock-in », et affiche les logos de Claude, Codex, Cursor, GitHub Copilot, Gemini, Antigravity, VS Code, Rider, Visual Studio, Open Code, Cline et Kilo Code. Cette liste est une liste de clients MCP compatibles, pas une liste d'intégrations testées une par une. La distinction compte : MCP est un protocole, donc la compatibilité est attendue par construction, mais le comportement réel dépend de l'implémentation de chaque client. Le README ne fournit pas de tableau de compatibilité avec des versions.

Un détail de licence : le projet est sous Apache-2.0, ce qui autorise l'usage commercial et la modification, avec conservation des mentions de copyright et des brevets concédés. Le README ne signale pas de clause additionnelle. Je ne donne pas d'avis juridique : si vous redistribuez le plugin dans un produit, faites lire le fichier LICENSE.

Ce à quoi il faut comparer : les ponts TCP maison

L'alternative la plus directe n'est pas un autre projet MCP pour Unity, c'est ce que beaucoup d'équipes Unity bricolent déjà : un petit serveur TCP ou HTTP lancé dans l'éditeur, avec un ensemble de commandes en JSON, appelé depuis un script externe. Le principe est le même que celui d'Unity-MCP, à une différence près, et elle est structurante.

Dans un pont maison, c'est vous qui définissez le protocole d'appel, la découverte des commandes, le format des erreurs et la gestion du contexte côté agent. Vous payez ce travail une fois, puis vous le maintenez. Dans Unity-MCP, ce travail est remplacé par MCP : le client connaît déjà le protocole, découvre les outils, et vous n'écrivez que les méthodes métier. C'est le principal argument en faveur du projet, et il est réel.

Le revers est symétrique. Un pont maison n'a aucune dépendance à un écosystème de clients, aucune CLI à installer globalement, aucun service d'authentification externe, et vous contrôlez chaque octet échangé. Unity-MCP vous lie au rythme de publication de MCP et à celui du projet lui-même. Les trois versions publiées entre le 16 et le 24 août 2026 (0.88.0, 0.89.0, 0.90.0) donnent une idée du rythme. Ce n'est pas un signal de mauvaise qualité en soi, mais c'est un signal de jeunesse : sur une version 0.x, les ruptures d'API sont attendues.

Si votre besoin se limite à trois commandes que vous appellerez depuis un script, un pont maison reste plus simple. Si vous voulez que n'importe quel client MCP puisse piloter Unity sans que vous écriviez la plomberie, Unity-MCP fait le travail à votre place.

Conclusion éditoriale

Adoptez Unity-MCP si vous voulez qu'un agent MCP agisse dans l'éditeur Unity et, surtout, si le scénario runtime vous intéresse. Évitez-le si vous cherchez un outil stable pour une équipe : les versions 0.88 à 0.90 sorties en août 2026 indiquent un rythme de publication rapide, et le README ne documente pas de politique de compatibilité entre versions. Vérifiez d'abord que votre client MCP accepte le transport que vous voulez utiliser, que le paquet OpenUPM com.ivanmurzak.unity.mcp s'installe dans votre version d'Unity, et que la licence Apache-2.0 couvre bien votre cas d'usage avant de l'intégrer à une chaîne de build.

Sources officielles

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