# Comment la priorité des configurations MCP varie selon les terminaux et les IDE Les conflits de configuration MCP ne sont pas un problème lié à MCP. C'est un problème lié au client, et cette distinction évite beaucoup de mauvais diagnostics. Le protocole indique à un client comment communiquer avec un serveur une fois celui-ci démarré. Il ne dit pas à Claude Code, VS Code, Cursor, GitHub Copilot CLI ou une extension quel fichier JSON lire en premier, si deux entrées portant le même nom doivent être fusionnées, ni si une extension peut enregistrer un serveur après le chargement de la configuration provenant des fichiers. Si vous supposez qu'il existe une hiérarchie universelle, vous pouvez lancer le mauvais exécutable avec un nom d'outil qui semble correct. Cette erreur passe facilement inaperçue. La liste des outils affiche `github`, l'agent appelle `github.search_code` et l'appel réussit. Pendant ce temps, votre agent de terminal a peut-être lancé un wrapper de projet avec un compte de test, alors que l'IDE a lancé une commande globale avec votre compte personnel. Le nom correspondait. La commande, elle, était différente. Voici la règle de travail que j'utilise : résolvez la configuration MCP pour chaque client, chaque processus et chaque nom de serveur. Traitez la commande du serveur, ses arguments, son environnement, son répertoire de travail, l'URL de transport et la source des identifiants comme une seule définition de lancement. Ne déduisez rien de ces éléments à partir du libellé affiché dans le panneau de l'agent. ## MCP n'a pas de hiérarchie de priorité partagée MCP standardise les messages et les capacités échangés entre les clients et les serveurs. Il ne prescrit ni une organisation portable des fichiers ni une règle pour départager des sources de configuration en désaccord. Un client peut utiliser des fichiers JSON, une base de paramètres, une API d'extension, une politique d'entreprise gérée, une option de ligne de commande, ou plusieurs de ces mécanismes à la fois. Cela signifie que quatre expressions souvent considérées comme interchangeables ne le sont pas : - Une **configuration utilisateur** est une définition globale propre au client, pour un compte ou un profil. - Une **configuration de projet** est une définition associée à un dépôt ou à un espace de travail. - Une **configuration d'extension** est un serveur enregistré ou fourni par une extension installée. - Un **paramètre d'éditeur** appartient à l'éditeur et peut, ou non, contrôler la configuration des serveurs MCP. Cette dernière distinction cause plus de problèmes qu'elle ne devrait. VS Code possède une hiérarchie générale de paramètres bien établie : les paramètres de l'espace de travail remplacent les paramètres utilisateur pour les options ordinaires, et les valeurs objet peuvent être fusionnées tandis que les valeurs primitives et les tableaux les remplacent. C'est le comportement réel de `settings.json`. Cela ne prouve pas que `.vscode/mcp.json` applique les mêmes règles de fusion et de collision. VS Code documente la configuration MCP dans son propre fichier `mcp.json`, situé soit dans un espace de travail, soit dans un profil utilisateur. N'appliquez pas les hypothèses du moteur de paramètres à un autre format de configuration. La conséquence pratique est simple : « l'espace de travail est prioritaire » n'est pas une réponse utile tant que vous n'avez pas indiqué le nom du client, sa version, le format de configuration et la collision exacte. Un fichier d'espace de travail peut ajouter un serveur, masquer un serveur global portant le même nom, coexister avec lui ou ne pas être chargé parce que l'espace de travail n'est pas approuvé. Ce sont des résultats différents, et un schéma générique de priorité les dissimule. ## Le nom du serveur est l'unité de conflit La plupart des clients organisent la configuration MCP sous forme de dictionnaire : un nom de serveur à gauche et une définition de lancement à droite. La clé du dictionnaire est souvent ce que le client utilise pour décider que deux déclarations sont en conflit. Considérez ces deux fichiers : ```json // configuration utilisateur { "mcpServers": { "catalog": { "command": "node", "args": ["/Users/dev/bin/catalog-live.js"], "env": { "CATALOG_TARGET": "production" } } } } ``` ```json // configuration du projet { "mcpServers": { "catalog": { "command": "node", "args": ["./tools/catalog-fixture.js"], "env": { "CATALOG_TARGET": "fixture" } } } } ``` Une personne voit deux services catalog. Un client voit deux valeurs associées à la clé `catalog`. S'il sélectionne une définition, il sélectionne généralement la définition entière. N'attendez pas du client qu'il combine la commande globale avec les arguments du projet, ou la commande du projet avec l'environnement global. Certains systèmes de paramètres fusionnent les objets, mais un client MCP n'y est pas tenu. C'est pourquoi les remplacements partiels sont une mauvaise conception. Un projet qui veut un autre point de terminaison doit déclarer complètement la commande prévue. Un utilisateur qui veut un outil personnel doit utiliser un autre nom. Un remplacement incomplet rend difficile de savoir si le client a remplacé tout l'objet serveur ou fusionné des champs d'une manière que vous n'avez pas testée. Utilisez des noms qui révèlent la responsabilité et l'objectif pendant que vous diagnostiquez encore la configuration : ```json { "mcpServers": { "catalog-user-live": { "command": "node", "args": ["/Users/dev/bin/catalog-live.js"] }, "catalog-repo-fixture": { "command": "node", "args": ["./tools/catalog-fixture.js"] } } } ``` Ces noms ne sont pas élégants. Ils sont honnêtes. Une fois que l'équipe dispose d'une définition canonique unique, vous pouvez la renommer en `catalog`. Avant cela, un nom court et dupliqué transforme chaque appel d'outil en exercice de devinette. Séparez aussi un nom en double d'une capacité en double. Deux serveurs peuvent tous deux exposer un outil appelé `search` tout en restant distincts parce que leurs noms de serveur diffèrent. L'agent peut être perturbé par des descriptions similaires, mais la configuration du client n'est pas forcément en conflit de noms. Résolvez d'abord la sélection du client, puis améliorez les descriptions et les noms des outils. ## Claude Code possède un ordre explicite des portées MCP Claude Code est le cas le plus simple, car sa documentation MCP indique l'ordre applicable aux entrées de serveur portant le même nom. La portée locale est prioritaire sur la portée du projet, qui est elle-même prioritaire sur la portée utilisateur. Sa terminologie actuelle compte : `local` est la portée privée et propre au projet par défaut ; `project` écrit un fichier `.mcp.json` partagé ; `user` s'applique à tous les projets. Anthropic utilisait auparavant d'autres noms pour certaines de ces portées, ce qui explique pourquoi les anciennes notes et l'historique du shell peuvent induire en erreur. Concrètement, si les trois portées contiennent `catalog`, Claude Code démarre la définition locale. La définition du fichier `.mcp.json` partagé vient ensuite, puis la définition utilisateur sert de solution de repli. ```sh # privé pour ce checkout et cet utilisateur claude mcp add catalog --scope local -- node ./tools/catalog-fixture.js # partagé avec le dépôt claude mcp add catalog --scope project -- node ./tools/catalog-service.js # disponible dans tous les dépôts de cet utilisateur claude mcp add catalog --scope user -- node ~/bin/catalog-personal.js ``` Le résultat attendu de l'inspection est un seul serveur actif nommé `catalog`, provenant de la portée locale lorsque les trois définitions existent. Exécutez la commande du client qui liste ou récupère le serveur après chaque modification au lieu de faire confiance au fichier que vous venez de modifier : ```sh claude mcp get catalog ``` La sortie devrait identifier le serveur nommé et afficher les détails de son transport ou de sa commande. Comparez la commande, les arguments et l'environnement réels avec la définition attendue. Si la commande n'est pas celle que vous avez modifiée, cessez de changer les fichiers et cherchez quelle portée possède encore ce nom. Ne confondez pas cette règle de portée MCP avec la priorité générale des paramètres de Claude Code. Anthropic documente une politique d'entreprise gérée, les arguments de ligne de commande, les paramètres locaux du projet, les paramètres partagés du projet et les paramètres utilisateur pour les options générales de Claude Code. Un paramètre géré peut donc limiter le comportement autour de l'utilisation de MCP sans constituer une seconde définition de serveur MCP. Les deux hiérarchies répondent à des questions différentes. La portée du projet comporte un autre piège. Claude Code demande une approbation avant d'utiliser un serveur fourni par `.mcp.json`. Cette approbation concerne le droit du client à utiliser le serveur fourni par le projet. Elle ne change pas la priorité entre deux configurations de serveur portant le même nom. Ne prenez pas une demande d'approbation comme la preuve que la commande partagée est prioritaire. ## VS Code sépare les fichiers MCP des paramètres ordinaires VS Code propose deux emplacements documentés pour la configuration des serveurs MCP : `.vscode/mcp.json` dans l'espace de travail et un fichier `mcp.json` du profil utilisateur, ouvert avec la commande `MCP: Open User Configuration`. Le fichier de l'espace de travail est destiné à être partagé via le contrôle de version, tandis que le fichier du profil suit l'utilisateur et peut varier selon le profil VS Code. Cette organisation crée une attente raisonnable : la configuration d'un dépôt doit définir les outils du dépôt, et le profil doit définir les outils personnels. Elle ne documente pas à elle seule une règle complète de résolution des noms en double. En particulier, la référence publique de configuration MCP décrit le schéma et les emplacements, mais n'indique pas que la priorité ordinaire des paramètres VS Code s'applique champ par champ aux entrées de `servers`. C'est ici que les utilisateurs expérimentés prennent un mauvais raccourci. Ils savent que les paramètres de l'espace de travail remplacent ceux de l'utilisateur. Ils placent le même nom de serveur MCP dans la configuration du profil et celle de l'espace de travail, modifient la commande du projet et concluent que cette commande doit être lancée. C'est possible. Mais une conclusion fondée sur un sous-système voisin reste une conclusion, pas un contrat documenté. Traitez toute collision de noms dans VS Code comme une exigence de test. Rendez les deux candidats visiblement différents et utilisez une commande sans danger qui prouve lequel a démarré : ```json { "servers": { "precedence-probe": { "type": "stdio", "command": "sh", "args": ["-lc", "printf 'workspace probe started\\n' >&2; exec node ./tools/probe-server.js"] } } } ``` Placez un marqueur différent dans la configuration du profil utilisateur : ```json { "servers": { "precedence-probe": { "type": "stdio", "command": "sh", "args": ["-lc", "printf 'profile probe started\\n' >&2; exec node $HOME/bin/probe-server.js"] } } } ``` Redémarrez ensuite complètement le serveur via l'interface de gestion MCP de VS Code, ou redémarrez l'éditeur si l'interface ne permet pas de connaître clairement l'état du processus. Inspectez la sortie ou les journaux du serveur MCP pour trouver le marqueur. Ne faites pas le test avec une vraie base de données ou une vraie cible de déploiement. Un test de priorité doit prouver un chemin de lancement, pas modifier des données. La même prudence s'applique à l'activation. VS Code documente que l'état d'activation et de désactivation est stocké séparément de la configuration du serveur. Un fichier de configuration partagé peut donc être présent alors que le serveur ne démarre pas dans un espace de travail donné. « Je le vois dans `mcp.json` » et « ce client l'a lancé » sont deux faits distincts. Les espaces de travail multi-racines ajoutent une autre source de certitude trompeuse. VS Code possède des portées d'espace de travail et de dossier pour les paramètres généraux, mais un fichier MCP lié à un espace de travail n'est pas automatiquement une déclaration de serveur par dossier. Si un outil a besoin d'une commande relative au dépôt, rendez explicites la racine de l'espace de travail et le répertoire de travail attendu dans votre test. Une commande qui fonctionne dans une racine peut échouer ou atteindre silencieusement un autre fichier lorsque l'éditeur ouvre plusieurs dossiers. ## Cursor ajoute les chemins du projet, du système et des extensions Cursor documente la configuration MCP propre au projet dans `.cursor/mcp.json` et la configuration globale dans `~/.cursor/mcp.json`. Il expose également une API d'extension qui peut enregistrer des serveurs MCP par programme. Il s'agit de trois sources distinctes : un fichier du dépôt, un fichier utilisateur et du code exécuté dans une extension. Les deux premières sont faciles à comprendre lorsque les noms sont uniques. Placez le service de développement partagé d'un dépôt dans `.cursor/mcp.json`. Placez un utilitaire personnel, comme un service local de recherche dans des notes, dans le fichier global. La CLI de Cursor indique qu'elle détecte et respecte `mcp.json`, ce qui rend la configuration partagée utile lorsque l'IDE et son agent de terminal s'exécutent réellement dans le même environnement. Le cas difficile est celui d'un nom en double dans les trois sources. La documentation publique MCP de Cursor indique où placer les fichiers de projet et les fichiers globaux, mais ne publie pas de contrat complet pour toutes les collisions entre configuration globale, configuration du projet et serveur d'extension enregistré dynamiquement. N'en inventez pas un à partir d'un message de forum, d'une ancienne note de version ou d'un comportement observé sur une seule machine. La conception la plus sûre consiste à éviter la collision. Si une extension fournit `issue-tracker`, ne placez pas une seconde entrée `issue-tracker` dans `.cursor/mcp.json` en espérant que la commande du dépôt la remplace. Donnez au serveur géré par le dépôt un autre nom, comme `issue-tracker-fixture`, et expliquez clairement dans les instructions de l'agent ou les descriptions des outils quand il doit l'utiliser. C'est particulièrement important pour les équipes qui utilisent une extension par commodité et un fichier pour assurer la reproductibilité. L'extension peut gérer l'installation, OAuth, les mises à jour ou l'enregistrement selon son propre calendrier. Un fichier de dépôt est visible lors de la revue de code. Il s'agit de deux modèles de responsabilité différents. Décidez lequel possède le serveur avant d'essayer de les faire fonctionner ensemble par hasard. Les frontières entre environnements rendent les conflits Cursor plus étranges qu'ils ne le sont réellement. Un éditeur de bureau peut s'exécuter sur un système d'exploitation, tandis que son terminal, son espace de travail distant ou son conteneur de développement s'exécute ailleurs. Un fichier global présent dans un répertoire personnel peut exister dans un environnement et pas dans l'autre. Dans un fichier de projet, `node`, `python` ou un exécutable relatif peut être résolu grâce à des valeurs `PATH` différentes. Avant de parler de priorité, notez où s'exécute le processus client et où s'exécute le processus serveur. Pour chaque candidat, notez cette courte fiche de lancement : ```text client: Cursor desktop / Cursor CLI environnement du client: macOS local / WSL / hôte distant / conteneur source de configuration: ~/.cursor/mcp.json / .cursor/mcp.json / enregistrement d'extension nom du serveur: issue-tracker commande: node ./tools/issue-mcp.js répertoire de travail: racine du dépôt source des identifiants: OAuth / environnement local / passerelle externe ``` Une fiche de cinq minutes vaut mieux qu'une après-midi passée à activer et désactiver des options dans les panneaux de paramètres. ## GitHub Copilot CLI documente la priorité du projet sur l'utilisateur GitHub Copilot CLI est plus explicite que beaucoup d'autres clients. Sa documentation indique que la configuration MCP au niveau du projet dans `.mcp.json` ou `.github/mcp.json` est prioritaire par rapport à une définition portant le même nom dans `~/.copilot/mcp-config.json`. Il s'agit d'une règle claire de priorité du projet sur l'utilisateur pour les noms de serveurs MCP dans la CLI. Utilisez-la comme une règle propre au client, et non comme une vérité générale sur GitHub Copilot dans tous les éditeurs. Copilot CLI possède son propre répertoire de configuration, ses paramètres de dépôt, ses paramètres locaux, la prise en charge des extensions, son stockage des autorisations et son processus de ligne de commande. Une session Copilot dans VS Code est une autre interface cliente, avec sa propre documentation de configuration MCP et son propre cycle de vie. Une configuration Copilot CLI claire peut ressembler à ceci : ```json // ~/.copilot/mcp-config.json { "mcpServers": { "docs": { "command": "node", "args": ["/Users/dev/bin/company-docs-mcp.js"] }, "catalog": { "command": "node", "args": ["/Users/dev/bin/catalog-live.js"] } } } ``` ```json // .mcp.json dans le dépôt { "mcpServers": { "catalog": { "command": "node", "args": ["./tools/catalog-fixture.js"] } } } ``` Dans ce dépôt, Copilot CLI devrait utiliser la définition `catalog` du projet et conserver la définition utilisateur `docs`, puisqu'aucune entrée du projet n'entre en conflit avec `docs`. C'est le modèle utile : remplacez uniquement le nom dont le projet est responsable et laissez les utilitaires personnels sans rapport inchangés. Les extensions compliquent la situation, car une extension peut apporter son propre comportement d'agent et son propre cycle de vie de serveur MCP. La documentation de configuration de GitHub décrit les extensions activées par le dépôt comme limitées à ce dépôt et indique que le client arrête le serveur MCP d'une extension lorsque le dépôt n'active plus cette extension. Cela montre que le serveur de l'extension dépend de son activation, et n'est pas simplement copié dans votre fichier MCP utilisateur. Si un serveur fourni par une extension et un serveur fourni par un fichier portent le même nom, ne devinez pas quelle commande est prioritaire. Inspectez l'état visible des serveurs dans la CLI, l'état de l'extension et la sortie de démarrage. Si la documentation de la version installée ne précise pas le comportement en cas de collision, renommez l'une des définitions ou supprimez l'un des producteurs. Le conseil souvent donné, « remplacez simplement le serveur de l'extension dans le dépôt », est séduisant parce qu'il est bref. Il est faux lorsque l'extension contrôle l'enregistrement après le chargement des fichiers ou fournit un état de cycle de vie supplémentaire. ## Un éditeur et son terminal sont deux clients MCP distincts Un terminal intégré à un IDE semble faire partie de l'éditeur. Cela reste un processus shell. Lorsque vous exécutez `claude`, `copilot` ou `cursor-agent`, cette commande peut lire ses propres fichiers, son répertoire courant, son environnement, son répertoire personnel et ses variables de remplacement de configuration. L'extension de discussion de l'éditeur est un autre processus avec une autre implémentation cliente. C'est la source du constat bien connu : « Le serveur MCP fonctionne dans l'IDE, mais pas dans le terminal. » Plusieurs explications ordinaires sont possibles : - L'éditeur a ouvert un fichier de l'espace de travail, tandis que le terminal a démarré dans un sous-répertoire ou un checkout voisin. - L'éditeur utilise un hôte distant ou un conteneur, tandis que la commande du terminal s'exécute localement. - Le terminal a hérité d'un `PATH`, d'un `HOME`, d'un paramètre de proxy ou d'une variable d'identifiants propre au shell. - L'éditeur a activé un serveur d'extension que la CLI ne charge jamais. - La CLI a trouvé un serveur de projet portant le même nom et remplacé l'entrée utilisateur. Ne commencez pas par copier chaque fichier de configuration dans chaque emplacement. Vous augmenteriez la surface de collision et masqueriez la première cause. Exécutez plutôt un seul client à la fois et réunissez des éléments vérifiables. Pour les clients de terminal, utilisez la commande intégrée qui liste ou récupère les serveurs MCP. Pour les clients d'éditeur, utilisez la vue de gestion des serveurs MCP et sa sortie ou ses journaux. Notez le nom du serveur, la commande, les arguments, l'emplacement du processus et l'heure de démarrage. Si le terminal et l'éditeur affichent le même nom mais des commandes différentes, vous avez trouvé un problème de résolution de configuration. S'ils affichent la même commande mais ont des comportements différents, examinez le répertoire de travail, les identifiants, l'accès réseau ou le serveur lui-même. Un test utile consiste à remplacer temporairement la commande du serveur prévu par un wrapper qui écrit un marqueur sans ambiguïté sur la sortie d'erreur standard avant d'exécuter le vrai serveur. Gardez-le en lecture seule et supprimez-le après le test. ```sh #!/bin/sh printf '%s client=%s cwd=%s\n' \ "MCP probe started" \ "${MCP_CLIENT_LABEL:-unknown}" \ "$PWD" >&2 exec node "$(dirname "$0")/real-server.js" ``` N'affichez ni jetons, ni en-têtes, ni valeurs d'identifiants, ni vidage complet de l'environnement, ni charges utiles des requêtes. Les journaux survivent souvent à la session du terminal, et un test de priorité ne doit pas créer une fuite de secrets en essayant d'en expliquer une. ## L'enregistrement par une extension n'est pas un remplacement de fichier de configuration Une extension produit une configuration de serveur ; ce n'est pas simplement un autre dossier où se trouve du JSON. Elle peut enregistrer un serveur dynamiquement, gérer l'authentification, choisir une version, réagir aux changements d'espace de travail ou arrêter le serveur lorsqu'elle se désactive. Deux recommandations courantes sont donc risquées. La première est : « mettez le même nom dans le fichier du projet pour remplacer l'extension ». Cela ne fonctionne que lorsque le client documente que les fichiers sont chargés après les extensions et que la collision de noms remplace l'enregistrement de l'extension. Sans ce contrat, le doublon peut produire une erreur, un remplacement invisible, deux outils aux descriptions similaires ou un comportement qui change après une mise à jour. La seconde est : « désactivez le serveur dans l'interface et le projet est propre ». L'état d'activation peut se trouver en dehors du fichier partagé. VS Code sépare explicitement l'état d'activation et de désactivation de la configuration MCP. Un collègue peut cloner le dépôt, recevoir le même fichier et avoir malgré tout un ensemble de serveurs actifs différent. Utilisez plutôt l'un de ces modèles de responsabilité : 1. **Serveur géré par un fichier :** le dépôt versionne la définition du serveur. Tout le monde utilise le fichier et aucune extension n'enregistre le même service. 2. **Serveur géré par une extension :** l'extension s'occupe de l'enregistrement et de l'authentification. Le dépôt ne déclare pas de doublon. 3. **Rôles de serveurs séparés :** une extension possède `tracker-live`, tandis qu'un fichier du projet possède `tracker-fixture`. Les noms, descriptions et autorisations distinguent clairement les cibles. La troisième option est souvent la moins séduisante et la plus sûre. Les équipes ont fréquemment besoin à la fois d'un service personnel en production et d'une fixture de dépôt. Faire comme s'il s'agissait d'un seul serveur parce qu'ils parlent tous deux à un outil de suivi des problèmes augmente seulement le risque d'un appel accidentel en production. ## Une méthode reproductible pour prouver quelle commande est prioritaire Vous pouvez prouver la résolution de la configuration sans vous fier au comportement de l'agent. La méthode ci-dessous utilise un serveur stdio ou un wrapper sans danger et fonctionne aussi bien lorsque le client démarre une commande locale que lorsqu'il pointe vers un service distant. ### Construisez un test à deux sources Choisissez un nom de serveur, par exemple `precedence-probe`. Définissez-le exactement dans les deux sources que vous voulez comparer. Faites produire à chaque candidat un marqueur différent avant de démarrer le même serveur de test sans danger. Pour un serveur fondé sur une commande, distinguez chaque élément important : ```json { "mcpServers": { "precedence-probe": { "command": "sh", "args": ["-lc", "printf 'SOURCE=PROJECT CWD=%s\\n' \"$PWD\" >&2; exec node ./tools/probe.js"], "env": { "MCP_PROBE_SOURCE": "project" } } } } ``` Le candidat utilisateur doit afficher `SOURCE=USER` et pointer vers un autre fichier connu. Ne vous fiez pas uniquement à une variable d'environnement si le client la masque, la filtre ou démarre un processus ancien. Placez également un marqueur visible dans le chemin de commande et dans la sortie. ### Redémarrez le serveur, pas seulement la discussion Les serveurs MCP sont souvent des processus enfants de longue durée. Modifier un fichier JSON alors qu'un serveur continue de fonctionner ne prouve rien sur la prochaine requête. Utilisez le contrôle du client qui arrête et redémarre le serveur. Si ce contrôle n'est pas clair, fermez complètement le client concerné et rouvrez l'espace de travail. Inspectez ensuite d'abord les journaux du client. Les éléments attendus ressemblent à ceci : ```text MCP probe started SOURCE=PROJECT CWD=/path/to/repository ``` Si aucun marqueur n'apparaît, le client a peut-être rejeté la configuration avant de lancer le processus, utilisé un transport distant ou conservé un ancien serveur actif. Ce résultat est utile. Il réduit la question « quelle configuration est prioritaire ? » à « cette configuration a-t-elle été chargée et ce client a-t-il démarré un processus ? » ### Ne changez qu'une frontière à la fois Exécutez le test dans le client de terminal, puis dans le client de l'IDE. Ne modifiez le répertoire courant qu'après avoir établi une référence. Ne désactivez l'extension qu'après avoir mesuré le comportement des fichiers seuls. Testez les sources utilisateur et projet avant d'ajouter des remplacements locaux ou des paramètres gérés. Conservez un petit tableau de résultats dans le ticket du dépôt ou les notes de l'équipe : | Client | Environnement | Sources candidates | Marqueur observé | Commande active | | --- | --- | --- | --- | --- | | Claude Code | shell local | local, projet, utilisateur | LOCAL | `node ./tools/probe-local.js` | | VS Code | conteneur de développement | espace de travail, profil | WORKSPACE | `node ./tools/probe-workspace.js` | | Cursor | bureau | projet, global, extension | marqueur de l'extension | géré par le plugin | Le tableau doit rapporter le comportement observé, pas le comportement attendu. Une équipe peut agir à partir de faits observés. Un schéma copié d'un autre client n'est qu'une hypothèse. ## Gardez les identifiants hors du conflit de priorité Un conflit de commande est un problème d'exécution. Un conflit d'identifiants est un problème de sécurité. Ne résolvez pas le premier en dispersant des secrets dans les configurations de projet, d'extension, utilisateur et d'éditeur jusqu'à ce que quelque chose fonctionne. Une configuration de projet versionnée devrait normalement contenir une commande de serveur, des informations de point de terminaison sans caractère sensible et des instructions pour obtenir les identifiants. Elle ne devrait pas contenir un jeton bearer longue durée dans `env`, le chemin vers une clé SSH privée que les autres membres de l'équipe ne possèdent pas ou la valeur d'un en-tête personnalisé donnant accès à la production. Un fichier de projet devient une invitation à l'exécution pour chaque clone et chaque agent que le client autorise à l'utiliser. Si un serveur a besoin d'un secret, choisissez une frontière d'identifiants adaptée au travail : - OAuth convient lorsque le serveur et le client le prennent en charge et que l'utilisateur doit accorder l'accès de manière interactive. - Un gestionnaire de secrets local ou une injection d'environnement convient à une définition de serveur personnelle. - Une fixture de dépôt doit utiliser des identifiants hors production aux permissions limitées. - Une passerelle d'action convient lorsqu'un agent doit demander une action sans jamais recevoir l'identifiant API ou SSH sous-jacent. C'est ici qu'une commande de serveur peut sembler inoffensive tout en étant dangereuse. `npx some-mcp-server` peut résoudre une version installée différente d'une machine à l'autre. `node ./tools/server.js` peut hériter de `AWS_PROFILE`, `GH_TOKEN` ou d'un proxy d'entreprise transmis par le processus parent. Une déclaration de projet peut être revue, tandis que sa véritable source d'identifiants reste invisible. Lorsque les agents ont besoin d'un accès HTTP ou SSH, Sallyport peut conserver l'identifiant API ou SSH dans son coffre chiffré, tandis que l'agent se connecte via le shim `sp mcp` et ne reçoit que les résultats des actions. Cela ne détermine pas quelle configuration client est prioritaire, mais empêche la commande sélectionnée de transmettre aussi des identifiants bruts à l'agent. Ne considérez pas la priorité de configuration comme un système d'autorisation. Une définition de projet peut sélectionner une commande ; elle ne prouve pas que cette commande doit agir sans contrôle. Gardez l'approbation, le stockage des identifiants et les preuves d'audit comme des contrôles distincts. ## Rendez la commande canonique évidente Les équipes ont besoin d'une réponse à une question simple : quelle commande l'agent de ce dépôt doit-il démarrer pour ce service ? Si la réponse est cachée entre des fichiers utilisateur, le comportement d'une extension, des extraits de README et des paramètres d'éditeur, la configuration est déjà trop floue. Écrivez la définition partagée canonique à un seul endroit. Donnez-lui un nom de serveur stable. Indiquez quels clients la prennent en charge et quelle source en est responsable. Placez les variantes personnelles sous des noms différents. Si une extension doit gérer le service, documentez qu'elle est canonique et ne fournissez pas une définition concurrente dans un fichier. Conservez ensuite une petite commande ou un test de vérification dans le dépôt. Les changements de configuration méritent des tests, comme les scripts de déploiement. Un serveur qui démarre la mauvaise commande peut lire les mauvais fichiers, appeler le mauvais point de terminaison ou hériter des mauvais identifiants avant même que l'agent ne dise un mot. Le résultat utile n'est pas un tableau universel des priorités. C'est une configuration où chaque client possède un chemin de lancement observable, où chaque nom de serveur a un seul responsable et où personne n'a besoin de deviner quelle commande son agent va exécuter.