Configuration de Unity MCP

Comprenez le pont vers l'éditeur

CoplayDev/unity-mcp connecte un client MCP à un serveur et à un paquet côté éditeur. Le service de modèle est une dépendance séparée. Le projet documente des outils pour travailler sur les scènes, scripts, assets et tests, mais une capacité listée ne prouve pas qu'elle fonctionne dans votre projet.

Enregistrez le processus qui possède chaque partie de la connexion. Cela compte lorsqu'un client atteint le serveur mais ne peut pas piloter l'éditeur. Gardez les identifiants de compte, la licence de l'éditeur, la compatibilité des paquets et la disponibilité du modèle comme contrôles de configuration séparés. Un changement de modèle ne réparera pas une confusion d'instance éditeur.

Relisez le chemin d'installation et la politique de version

Le guide d'installation du projet documente l'ajout de son paquet via Unity Package Manager et l'utilisation de l'interface de configuration pour paramétrer le serveur et le client. Relisez, pour la révision choisie, ses prérequis Unity, Python et uv avant toute installation.

Pour la reproductibilité, conservez après configuration la révision de paquet résolue, la version de l'éditeur, la version du serveur et les enregistrements de dépendances. Une URL de branche mouvante est un chemin de découverte, et non une identité d'expérience immuable. Relisez les téléchargements et changements de paquets avant de les appliquer à un jeu existant et conservez l'état fonctionnel précédent afin qu'une expérience de connexion reste réversible.

https://github.com/CoplayDev/unity-mcp.git?path=/MCPForUnity#main

Faites correspondre l'endpoint HTTP local au client

Le guide d'installation maintenu documente l'exemple HTTP local ci-dessous. Il suppose que le serveur s'exécute déjà à cette adresse. Confirmez le transport et l'adresse réellement configurés dans l'interface de configuration de l'éditeur avant de les utiliser. L'URL MCP n'est pas une URL de base d'API LLM.

Utilisez le format de configuration documenté par votre client. Certains clients utilisent d'autres clés racine ou déclarations de transport ; cet exemple mcpServers générique n'est donc pas un fichier universel à coller dans chaque agent. Gardez le serveur local sauf besoin d'une configuration distante examinée séparément et n'ajoutez pas d'identifiants de modèle à une connexion éditeur sans rapport.

{
  "mcpServers": {
    "unityMCP": {
      "url": "http://localhost:8080/mcp"
    }
  }
}

Prouvez quelle instance d'éditeur reçoit le travail

Ouvrez le projet prévu et inspectez l'état de la connexion via l'interface du paquet. Utilisez ensuite les opérations de lecture découvertes par le client pour obtenir le contexte du projet et de la scène. Faites correspondre ces informations au projet local avant d'approuver une modification. Plusieurs projets ouverts rendent ce contrôle particulièrement important.

Enregistrez les ressources et schémas d'outils réels de la version installée. N'inventez pas un appel d'outil à partir d'un nom retenu d'une autre release. Un premier résultat utile identifie la scène attendue et ses objets existants sans les modifier. Si l'état renvoyé est obsolète ou ambigu, arrêtez-vous et résolvez le routage au lieu de tenter une mutation visible pour découvrir la cible.

Utilisez une modification réversible comme premier miniflow

Choisissez une scène jetable dont vous détenez les droits, enregistrez son état initial et demandez une modification simple avec une conséquence visible. Inspectez la scène sauvegardée et le diff de fichier, attendez que l'éditeur soit prêt et exercez la scène. Conservez le comportement observé et les erreurs de console.

Rouvrez ensuite la scène pour confirmer que la modification prévue a persisté. Vous distinguez ainsi un effet d'éditeur en mémoire d'une modification sauvegardée du projet. Gardez le flux assez petit pour diagnostiquer l'échec à une frontière : routage, mutation, compilation, exécution ou persistance. Restaurez la scène jetable après la revue et utilisez la configuration fonctionnelle enregistrée pour la tâche suivante.

Dépannez le transport avant le jeu

Lorsque le client ne peut pas se connecter, vérifiez l'URL configurée et si le serveur local fonctionne. Lorsque le serveur démarre mais que l'éditeur est absent, inspectez la connexion du paquet et les journaux de l'éditeur. Lorsque l'éditeur prévu est connecté mais qu'un outil manque, inspectez les groupes d'outils exposés par la version installée.

Ce n'est qu'après le bon fonctionnement de cette frontière que vous devez diagnostiquer la compilation ou le gameplay. Gardez des extraits séparés pour le démarrage du client, le routage du serveur, la disponibilité de l'éditeur et l'action de scène échouée. Le rapport pourra ainsi indiquer où l'exécution s'est arrêtée au lieu d'attribuer chaque échec au modèle ou de réinstaller les composants sans preuve.

Protégez le projet contre l'automatisation large

Une connexion éditeur peut modifier les scènes, scripts et assets. Limitez la première expérience à un répertoire connu et exigez une revue pour les opérations qui suppriment des ressources, modifient les dépendances ou touchent des scènes sans rapport. Préservez un état de travail récupérable avant la première modification.

N'exposez pas publiquement un service de développement local simplement pour résoudre un problème de configuration client. Traitez le contenu d'assets tiers et les résultats d'outils comme des entrées non fiables et gardez les identifiants hors des journaux partagés. Une connexion réussie n'est pas une permission de téléverser des builds ou de modifier des enregistrements boutique. La publication reste un workflow distinct avec une frontière d'autorisation distincte.

Transmettez un enregistrement de connexion reproductible

Enregistrez les révisions de l'éditeur, du projet, du paquet et du serveur, la version du client, le transport, la surface d'outils observée et le miniflow terminé. Conservez le diff exact de la scène et le résultat runtime. Indiquez si la compilation, le comportement PlayMode, les tests et l'export cible ont été examinés ou restent en attente.

Cette configuration suit la documentation du projet maintenu ; vérifiez-la avec votre paquet et client installés. Pour la production du jeu, passez au guide du workflow Unity et testez la boucle complète. Gardez les limites connues dans le relais afin qu'un autre développeur puisse distinguer un problème de connexion d'un problème de projet et reproduire la même configuration fonctionnelle.

Questions fréquentes