Edgegap
officielDéployez des serveurs de jeu multijoueur depuis votre agent de codage. Dix outils qui font passer un serveur dédié Unity, Unreal ou Godot d'une image conteneur à des joueurs connectés.
Que pouvez-vous faire avec Edgegap MCP ?
- Déployer un serveur de jeu à partir d’une image conteneur — Demandez à l’assistant d’enregistrer votre image conteneur avec les paramètres de CPU, de mémoire et de port, puis de la lancer à proximité de joueurs spécifiques.
- Suivre l’état du déploiement et les détails de connexion — Demandez à l’assistant d’interroger jusqu’à ce que votre déploiement soit prêt et de renvoyer l’adresse de connexion, ou de vérifier l’état et les journaux d’une instance en cours d’exécution.
- Gérer les versions d’application — Demandez à l’assistant de lister les applications et versions existantes, ou de créer une nouvelle version à partir des paramètres d’une version fonctionnelle pour éviter la duplication.
- Arrêter les déploiements proprement — Demandez à l’assistant de terminer un déploiement spécifique par ID de requête, en envoyant un signal d’arrêt propre plutôt qu’un arrêt forcé.
- Trouver et nettoyer les serveurs orphelins — Demandez à l’assistant de lister tous les déploiements des sessions précédentes afin d’identifier et d’arrêter les instances inutilisées.
Serveur MCP hébergé
npx add-mcp 'https://mcp.edgegap.dev/mcp'S’installe dans Claude Code, Codex, Cursor et plus
Documentation
edgegap-mcp
Un serveur MCP pour Edgegap qui permet à un agent de codage d'emmener un développeur de « j'ai un conteneur de serveur de jeu » à « les joueurs y sont connectés » sans que le développeur ait à lire la référence de l'API.
Dix outils, choisis à la main. Non générés à partir de la spécification OpenAPI — voir Portée pour savoir pourquoi.
Installation
Deux façons de l'exécuter. Choisissez en fonction de l'importance que vous accordez à l'endroit où votre jeton va — voir Où va votre jeton.
Point de terminaison distant
Hébergé par Edgegap en tant que Cloudflare Worker. Rien à installer.
{
"mcpServers": {
"edgegap": {
"type": "http",
"url": "https://mcp.edgegap.dev/mcp",
"headers": { "Authorization": "token YOUR_API_TOKEN" }
}
}
}
Fonctionne également comme connecteur personnalisé dans claude.ai : ajoutez
https://mcp.edgegap.dev/mcp et fournissez le même jeton.
Local
S'exécute sur votre propre machine, lancé par votre éditeur. Une ligne dans la configuration de votre client MCP, rien à cloner, rien à construire.
{
"mcpServers": {
"edgegap": {
"command": "npx",
"args": ["-y", "@edgegap/mcp"]
}
}
}
Fonctionne dans Claude Code, Cursor, Codex et VS Code. Épinglez une version en production (@edgegap/mcp@0.1.5) plutôt que de flotter sur la dernière version.
Enregistré dans le registre MCP officiel sous le nom dev.edgegap/mcp.
Version de Node : le serveur local nécessite Node 18+. Déployer votre propre copie du Cloudflare Worker nécessite Node 22+, car
wranglerl'exige.
Où va votre jeton
Cela diffère selon le mode, et cette différence est la raison pour laquelle les deux modes existent.
Local. Le serveur s'exécute comme un processus sur votre propre ordinateur. Le premier appel d'outil vous demande un jeton, affiche ce qu'il autorise et exige une reconnaissance explicite avant de l'accepter. Où ce jeton vit ensuite, de manière exhaustive :
- une variable dans la mémoire de ce processus, pour la durée de votre session d'éditeur
C'est toute la liste. Pas sur le disque. Pas dans un fichier de configuration. Pas dans les journaux. Pas sur un serveur Edgegap — la seule chose envoyée à Edgegap est l'appel API lui-même, exactement comme si vous aviez exécuté curl. Fermer votre éditeur révoque complètement l'accès de ce serveur.
Distant. Votre jeton est envoyé à mcp.edgegap.dev à chaque requête et transmis de là à l'API Edgegap. Il transite par l'infrastructure qu'Edgegap exploite. Le worker le conserve pendant la durée de la requête et ne le persiste pas, mais c'est une affirmation « nous ne le stockons pas » plutôt qu'une affirmation « nous ne le voyons jamais ». Les deux sont différentes, et seul le mode local permet la seconde.
Générez un jeton à https://app.edgegap.com/user-settings?tab=tokens.
En mode local, définir EDGEGAP_API_TOKEN a priorité sur l'invite, pour les environnements CI et pour les clients qui ne peuvent pas afficher d'invites. Ne passez pas de jeton comme argument de ligne de commande — les arguments sont visibles par d'autres processus via ps, et le serveur émet un avertissement s'il en détecte un.
Lequel utiliser. Distant pour un premier essai, une démonstration ou une session supervisée où la friction de configuration importe plus que la garde. Local pour tout ce qui est sans surveillance, tout ce qui se trouve dans une organisation avec un jeu en production, et tout ce où vous préférez ne pas étendre une confiance que vous n'avez pas à étendre. Les garde-fous décrits ci-dessous n'existent qu'en mode local.
Lisez ceci avant de connecter un agent
Le jeton API Edgegap ne peut pas être limité. Un seul jeton autorise chaque application, chaque version, chaque déploiement en cours et votre utilisation dans toute l'organisation. Il n'existe pas de jeton de déploiement uniquement ni de jeton par application.
Conséquences à considérer délibérément :
- Un agent détenant ce jeton peut arrêter des déploiements de production, pas seulement ceux de test qu'il a créés.
- L'injection d'invite atteignant l'agent — depuis un fichier de dépôt, un problème, une page récupérée — atteint aussi le jeton.
- Tout ce que l'agent journalise, fait écho ou envoie à un fournisseur de modèle est un endroit où le jeton pourrait se retrouver. Ce serveur ne le journalise pas, mais il ne peut pas contrôler ce que le reste de l'agent fait.
- Sur le point de terminaison distant, le même jeton non limité est en plus géré par le worker d'Edgegap à chaque appel.
Configuration recommandée, par ordre décroissant de prudence :
| Situation | Configuration |
|---|---|
| Agent sans surveillance ou autonome | Mode local. Organisation distincte hors production, plus EDGEGAP_READ_ONLY=1 |
| Agent supervisé, jeu en production dans l'organisation | Mode local. EDGEGAP_APP_ALLOWLIST limité à l'application travaillée, plus EDGEGAP_MAX_DURATION_MINUTES. Lisez Portée de la liste d'autorisation d'abord — les déploiements déjà en cours ne sont pas couverts |
| Développeur solo, aucune charge de production | L'un ou l'autre mode. Les valeurs par défaut conviennent ; révoquez le jeton une fois terminé |
La liste d'autorisation et le drapeau lecture seule sont appliqués dans le serveur local, ce qui signifie qu'ils protègent contre un agent qui fait une erreur, pas contre un agent compromis qui appellerait l'API directement. Ils réduisent le rayon d'explosion ; ils ne le suppriment pas.
Portée de la liste d'autorisation
EDGEGAP_APP_ALLOWLIST est appliqué par les quatre outils qui prennent un nom d'application : edgegap_create_app, edgegap_list_app_versions,
edgegap_create_app_version et edgegap_deploy.
Il n'est pas appliqué par les cinq outils clés sur request_id :
edgegap_get_deployment, edgegap_wait_for_deployment,
edgegap_list_deployments, edgegap_stop_deployment et
edgegap_get_deployment_logs. Un agent fonctionnant avec une liste d'autorisation définie peut lister chaque déploiement de l'organisation puis inspecter, lire les journaux ou arrêter n'importe lequel d'entre eux — y compris les déploiements appartenant à des applications hors liste.
Ainsi, la liste d'autorisation limite ce qu'un agent peut créer et déployer, pas ce qu'il peut toucher une fois en cours d'exécution. C'est plus étroit que ce que les versions précédentes de ce document laissaient entendre.
Pour une garantie plus forte aujourd'hui, utilisez EDGEGAP_READ_ONLY=1, qui n'enregistre jamais les cinq outils de mutation du tout, ou pointez l'agent vers une organisation distincte hors production. Les deux ne sont pas affectés par cette lacune.
Signalé par Syed Anas Mohiuddin, septembre 2026.
Variables d'environnement
Elles configurent le serveur local. Sur le point de terminaison distant, elles sont définies par Edgegap et ne peuvent pas être modifiées par développeur — si vous en avez besoin, exécutez localement.
| Variable | Défaut | Objectif |
|---|---|---|
EDGEGAP_API_TOKEN | (invité) | Jeton API. Optionnel — omettez-le et le développeur est invité à la première utilisation. Le préfixe token est ajouté pour vous. |
EDGEGAP_READ_ONLY | 0 | Définissez à 1 et les cinq outils de mutation ne sont jamais enregistrés. L'agent ne peut pas les voir, donc il ne peut pas être incité à les appeler. |
EDGEGAP_APP_ALLOWLIST | (vide) | Noms d'applications séparés par des virgules. Lorsqu'elle est définie, les quatre outils clés sur application refusent de toucher autre chose. Ne limite pas les cinq outils clés sur request_id — voir Portée de la liste d'autorisation. |
EDGEGAP_MAX_DURATION_MINUTES | 60 | Plafond sur max_duration que l'agent peut définir sur une version. Limite les coûts incontrôlés d'un agent sans surveillance. |
EDGEGAP_TIMEOUT_MS | 30000 | Délai d'expiration HTTP par requête. |
Outils
Dix outils, listés dans l'ordre où ils se placent le long du chemin doré. Les mêmes dix dans les deux modes.
| Outil | Mutation | À quoi il sert |
|---|---|---|
edgegap_list_apps | S'orienter avant de faire quoi que ce soit. Empêche les applications en double. | |
edgegap_create_app | ● | Créer le conteneur pour les versions. |
edgegap_list_app_versions | Trouver une version déployable, ou copier les paramètres d'une version fonctionnelle. | |
edgegap_create_app_version | ● | Enregistrer une image de conteneur avec CPU, mémoire et ports. |
edgegap_deploy | ● | Démarrer une instance près des joueurs spécifiés. |
edgegap_get_deployment | Lecture de statut unique. | |
edgegap_wait_for_deployment | Interroger jusqu'à prêt avec backoff, puis retourner l'adresse de connexion. | |
edgegap_list_deployments | Trouver les serveurs orphelins des sessions précédentes. | |
edgegap_stop_deployment | ● | SIGTERM gracieux, un déploiement à la fois. |
edgegap_get_deployment_logs | Sortie du conteneur et code de sortie de crash après un échec. |
Décisions de conception
Curaté, non généré. L'API Edgegap a environ soixante opérations. Auto-générer un outil par opération met les soixante descriptions dans le contexte de l'agent à chaque tour et dégrade mesurablement la sélection d'outils. Ces dix couvrent le chemin qui convertit un nouveau développeur.
wait_for_deployment est un outil, pas une boucle. Laissé à lui-même, un agent appellera un point de terminaison de statut en boucle serrée, brûlera des tours et abandonnera tôt. Intégrer l'interrogation et le backoff dans un seul appel élimine l'échec le plus courant dans les déploiements pilotés par agent.
Les erreurs sont écrites pour l'auto-correction. Un 424 revient en disant que l'image n'a pas pu être tirée et quels champs vérifier. Un 422 dit d'essayer des coordonnées différentes ou de réduire la demande de ressources. L'agent peut agir sur ces erreurs sans aller-retour vers l'humain.
Validation locale avant le fil. Le ratio mémoire-CPU et l'emplacement de joueur manquant sont détectés ici plutôt que de remonter comme un 400 opaque.
Les opérations en masse sont délibérément absentes. stop prend un request_id.
Il n'y a pas d'outil d'arrêt en masse, car un agent avec une expression de filtre et un bug peut arrêter une flotte de production.
À la fois un point de terminaison hébergé et un package local. Le point de terminaison hébergé supprime chaque étape entre la découverte de ce serveur et l'appel d'un outil, là où la plupart des développeurs abandonnent. Le package local est la seule façon d'exécuter le serveur sans étendre la garde d'un jeton non limité à un tiers, y compris nous. Aucun ne domine l'autre, donc les deux sont livrés. Voir worker/DECISION.md pour la version plus longue.
Portée
Non exposé, volontairement : matchmaking, relais, flottes privées, flottes intelligentes, stockage de points de terminaison, entrées ACL/liste blanche, balises de déploiement, métriques, gestion du registre de conteneurs, configuration DNS.
Ce sont de vraies capacités, mais elles appartiennent à des studios déjà opérant sur la plateforme, pas à un développeur déployant son premier serveur. Les ajouter échangerait le chemin de conversion contre la surface.
Limitation connue : demander le jeton du tout
Cela s'applique au mode local, où le jeton est collecté par élicitation plutôt que lu depuis la configuration.
La spécification MCP dit que les serveurs ne devraient pas utiliser l'élicitation pour collecter des données sensibles, et un jeton API est sensible. Ce serveur le fait quand même, car exiger un jeton dans un fichier de configuration avant que quoi que ce soit fonctionne est la plus grande chute dans l'entonnoir d'intégration, et tout l'intérêt du serveur est de supprimer la friction de configuration.
C'est un compromis délibéré plutôt qu'un modèle à copier. Ce qui le rend défendable, c'est l'ensemble des atténuations dans src/auth.ts — stockage en mémoire uniquement, divulgation en langage clair, reconnaissance requise, rédaction de toutes les sorties, et la variable d'environnement qui gagne toujours lorsqu'elle est présente. En retirer une seule brise le compromis.
Le vrai correctif est du côté d'Edgegap et améliorerait les deux modes : des identifiants limités, révocables, de déploiement uniquement, délivrés via OAuth plutôt que collés comme un secret. Jusqu'à ce qu'ils existent, l'invite interactive est un contournement et est étiquetée comme tel dans le code.
Développement
npm run typecheck
node smoke.mjs # handshake, tool registration, read-only mode
node guards.mjs # local validation and allowlist enforcement
node elicit.mjs # token prompt: accept, refuse acknowledgement, decline, no support
Aucun de ces éléments ne fait d'appels réseau. elicit.mjs affirme que l'invite indique la portée à l'échelle de l'organisation, que la reconnaissance est requise, que le jeton n'apparaît jamais dans la sortie des outils, et que le refus produit un message d'arrêt et de rapport plutôt qu'une boucle de nouvelle tentative.