Configuration de Godot MCP

Comprenez la connexion fournie par MCP

Coding-Solo/godot-mcp documente des outils pour exécuter des projets Godot, récupérer la sortie de débogage et agir sur les scènes. Il s'agit d'un pont maintenu par un projet, et non d'un service de modèle ni d'une distribution officielle de Godot. L'agent a toujours besoin de son propre accès au modèle et de permissions locales appropriées.

Gardez trois identités dans votre enregistrement de configuration : le client, la révision du serveur MCP et l'exécutable Godot. Une défaillance de l'un ne prouve pas que les autres sont indisponibles. Utilisez le schéma de connexion pour décider où inspecter un problème : authentification du fournisseur, configuration du client, processus d'outil local ou projet du moteur.

Inventoriez les prérequis sans les modifier silencieusement

Avant l'installation, inspectez les exigences amont et sélectionnez une version ou révision précise du serveur à relire. Confirmez que le moteur et le runtime existants peuvent être trouvés depuis le processus client, et pas seulement depuis votre shell interactif. Enregistrez le système d'exploitation et le répertoire de projet prévu.

Relisez la procédure d'installation amont avant d'autoriser des changements de dépendances. Nommez le runtime, la révision du serveur et l'emplacement d'installation et gardez un moyen de restaurer l'environnement précédent. Après la configuration, enregistrez les versions résolues plutôt que la seule URL source mouvante. Vous pourrez ainsi reproduire une connexion fonctionnelle lorsque le client ou le moteur sera mis à niveau.

Utilisez le point d'entrée de build local documenté

Le README amont prend en charge un build source avec build/index.js comme point d'entrée client et GODOT_PATH comme remplacement explicite de l'exécutable. Le JSON ci-dessous illustre cette voie déjà construite avec des placeholders. Remplacez chaque chemin par l'installation locale relue et vérifiez que le processus client peut le lire.

Utilisez le schéma réellement pris en charge par votre client. Un objet mcpServers générique n'est pas automatiquement un fichier de configuration Codex. Traduisez uniquement dans les paramètres documentés de ce client et gardez les identifiants du modèle hors de ce bloc moteur-outils. Un chemin Node absolu peut être utile lorsque l'environnement du client graphique diffère de celui du terminal.

{
  "mcpServers": {
    "godot": {
      "command": "/absolute/path/to/node",
      "args": ["/absolute/path/to/reviewed-godot-mcp/build/index.js"],
      "env": {
        "GODOT_PATH": "/absolute/path/to/godot"
      }
    }
  }
}

Vérifiez d'abord un chemin d'outil en lecture seule

Inspectez les outils renvoyés par le serveur configuré au lieu de vous fier à une liste mémorisée. Le README cite get_godot_version et get_project_info comme opérations d'inspection utiles. Vérifiez le schéma de paramètres découvert, puis ne ciblez que le répertoire de projet approuvé.

Comparez les informations renvoyées sur le moteur et le projet avec l'enregistrement de configuration. Conservez les résultats et erreurs structurés. N'approuvez pas la création de scène avant que l'observation n'identifie l'espace de travail prévu. Si le client affiche un badge connecté mais ne peut pas terminer cette lecture, la connexion n'est pas prête pour une expérience de gameplay. Un badge seul ne montre ni le processus ni le projet atteints.

Autorisez un miniflow de scène réversible

Après vérification de l'accès en lecture, utilisez une scène détenue et jetable pour la première écriture. Enregistrez son état original, demandez une modification visible, inspectez la scène sauvegardée, exécutez-la, récupérez la sortie et arrêtez le projet. Gardez le diff du fichier obtenu et les observations ensemble.

La condition d'acceptation est une chaîne reliant la modification demandée à la ressource sauvegardée et au comportement runtime visible. Lorsqu'un outil signale une réussite mais que la scène ne change pas, inspectez le ciblage du projet et les chemins sauvegardés avant une seconde mutation. Rouvrez la scène après l'enregistrement afin que le contrôle couvre la persistance ainsi que l'état actuel en mémoire.

Diagnostiquez les échecs à la bonne frontière

Si le démarrage du processus échoue, inspectez le runtime et les chemins du point d'entrée. Si Godot est introuvable, vérifiez le remplacement de l'exécutable depuis l'environnement du client. Si un projet ne peut pas être inspecté, vérifiez que le chemin identifie le répertoire contenant project.godot et qu'il est lisible par le processus.

Une fois le projet lancé, traitez les erreurs de scène ou de gameplay comme des problèmes du moteur avec leur contexte de reproduction. Évitez de changer les identifiants du fournisseur pour corriger des problèmes de chemin local. Capturez les journaux du serveur avec soin : masquez les détails sensibles du système de fichiers avant de les partager et gardez le débogage détaillé temporaire au lieu d'enregistrer indistinctement chaque opération de projet.

Gardez étroites les limites d'approbation et de réseau

Un outil moteur peut modifier un projet fonctionnel ou lancer du code. Accordez l'accès au plus petit répertoire approprié et relisez les demandes de mutation jusqu'à compréhension du comportement. Ne copiez pas de larges listes d'auto-approbation simplement parce qu'elles apparaissent dans un exemple de configuration.

Traitez les scripts importés, les plugins et la sortie des outils comme des éléments à inspecter, et non comme des instructions pouvant étendre l'autorité. Les téléchargements de paquets, la suppression de fichiers hors de la scène détenue, les changements d'identifiants et la publication exigent des décisions explicites. Le premier miniflow réussi sert de base à la revue d'une politique, et non de raison pour autoriser chaque future action de l'outil.

Enregistrez les limites de la configuration vérifiée

Un enregistrement de configuration terminé doit identifier la révision du serveur, le client, la version du moteur, le chemin du projet, les outils découverts, la lecture effectuée, la modification réversible et le résultat runtime. Indiquez les actions qui restent non testées. Conservez-le avec les preuves du jeu au lieu de présenter une garantie universelle de compatibilité.

La couche suivante est la boucle de production : implémenter une fonctionnalité, en reproduire le comportement, exporter et tester sur la plateforme cible. La configuration ici suit la documentation amont et doit être validée pour le client et les versions choisis. Conservez ce résultat délimité avec le projet, puis réutilisez le même contrôle d'inspection lorsque le serveur, le moteur ou le client change.

Questions fréquentes