Configuration MCP : les formats de VS Code et Copilot

Pour partager des serveurs MCP entre Cursor, Visual Studio Code et GitHub Copilot, partez d’une même définition si cela vous convient, mais prévoyez des fichiers adaptés à chaque environnement. Microsoft documente deux formats distincts pour VS Code et Copilot, et le format portable de Copilot ne reprend pas plusieurs fonctions propres à VS Code.

Les formats MCP de VS Code et Copilot

Dans VS Code, le fichier de l’espace de travail est .vscode/mcp.json et sa clé principale est servers. Le format portable destiné à Copilot utilise plutôt .mcp.json et la clé mcpServers. Les deux fichiers ne sont donc pas interchangeables tels quels. Les règles de configuration MCP de Microsoft précisent aussi où placer les fichiers utilisateur et comment référencer les variables d’environnement.

Les sessions du harness Copilot lisent directement le format portable. VS Code peut transmettre certains serveurs de son propre format, mais pas ceux qui dépendent de variables de saisie interactives comme ${input:...}. Un nom de variable écrit sous la forme $NAME reste du texte littéral dans le client MCP de VS Code.

Avant de produire un fichier portable

Vérifiez d’abord si votre configuration VS Code utilise des fonctions propres à son format : invites de saisie, fichier envFile, mode développement ou paramètres de sandbox par serveur. Le format portable ne prend pas en charge ces options. Si votre équipe en dépend, une conversion vers Copilot ne les conservera pas dans ce fichier.

Les autres différences comptent aussi au moment de déplacer des définitions : il faut utiliser la bonne clé de premier niveau et adapter la syntaxe des variables. Une liste de serveurs identique ne suffit pas à rendre les fichiers compatibles.

Un flux de travail pour garder les fichiers cohérents

1. Repérez les fonctions utilisées dans VS Code. Notez notamment les invites, envFile, le mode développement et les réglages de sandbox par serveur. Cela vous indique ce qui ne pourra pas être porté dans le fichier Copilot.
2. Choisissez le fichier correspondant à chaque environnement. Gardez .vscode/mcp.json pour le format VS Code et utilisez .mcp.json ou le fichier utilisateur Copilot pour le format portable.
3. Adaptez les clés et les variables. Le format VS Code attend servers et ${env:NAME} ; le format portable attend mcpServers et ${NAME} ou ${NAME:-default}.
4. Vérifiez les fichiers, puis testez les serveurs. Un contrôle de structure peut repérer un JSON invalide ou des clés incorrectes. Il ne démontre pas qu’un serveur démarre, s’authentifie ou fournit ses outils. Pour le tutoriel publié le 2 novembre 2026, Tech Insider décrit des contrôles de syntaxe JSON, de clés, de variables, de valeurs ressemblant à des secrets et de cohérence entre listes, puis recommande séparément MCP Inspector et un appel d’outil représentatif dans chaque client. Son autrice rapporte avoir exécuté les scripts sous Linux.

Une source commune peut produire des sorties distinctes

Le principe d’un générateur est de conserver une définition de départ, puis de produire des fichiers adaptés aux différents clients au lieu de maintenir une copie universelle. Tech Insider décrit un flux de ce type pour Cursor, VS Code et Copilot. Pour une équipe, les contrôles automatisés peuvent aussi repérer des écarts entre les fichiers générés. Ils restent toutefois des contrôles de configuration : le fonctionnement du serveur se vérifie dans le client où il sera utilisé.

Pour des espaces de développement gérés, Coder décrit une autre approche, limitée à Cursor : son module accepte un fichier JSON MCP et l’écrit dans ~/.cursor/mcp.json au démarrage de l’espace de travail. Dans un article publié le 20 août 2025, l’entreprise présente des modèles Terraform versionnés comme moyen de gérer cette configuration. Cette méthode concerne le provisionnement de Cursor dans les espaces Coder, pas la génération d’une configuration commune à VS Code et Copilot.