Serveurs MCP pour Claude, Cursor et VS Code : que connecter en premier
Un guide pratique de MCP : ce qui distingue un serveur d’une extension ou d’une clé d’API, les connexions à privilégier d’abord et la manière d’éviter d’accorder trop d’accès à un agent.
MCP répond à un problème peu séduisant, mais important : il donne à une application d’IA une manière unique de découvrir des outils et des données externes. Au lieu de construire un adaptateur distinct pour GitHub, des fichiers, une base de données ou Slack, un hôte exécute un client MCP qui dialogue avec un serveur compatible. L’architecture officielle de MCP sépare l’hôte, le client et le serveur ; un serveur peut exposer des outils, des ressources et des prompts. Cette frontière compte davantage que la promesse de « tout connecter », car c’est là que l’accès et la responsabilité sont définis.
Un protocole, trois rôles et des connexions séparées
L’hôte est Claude, Cursor, un éditeur ou une autre application dans laquelle l’utilisateur travaille. L’hôte crée un client pour chaque serveur configuré. Chaque serveur expose une capacité précise : lire un répertoire autorisé, interroger GitHub, exécuter des requêtes de base de données sûres ou contrôler un navigateur. Ce n’est pas un tunnel tout-puissant. Plusieurs serveurs étroitement délimités sont plus faciles à désactiver, à inspecter et à provisionner avec des identifiants séparés.
La documentation MCP utilise couramment stdio pour une connexion locale : l’hôte lance un processus et échange des messages via l’entrée et la sortie standard. Un serveur distant utilise Streamable HTTP. Ce choix modifie le déploiement et la confiance. Un processus local hérite des accès de la machine courante ; un service distant reçoit des données sur le réseau et a besoin de sa propre authentification.
Le système de fichiers et GitHub créent la première frontière utile
Connectez le serveur le moins spectaculaire qui supprime une friction fréquente avec un rayon d’impact clair. L’accès au système de fichiers aide lorsque l’hôte ne peut pas lire un répertoire requis ou lorsque la racine doit être strictement limitée. GitHub ajoute les issues, les pull requests, les checks et les dépôts. Pour le développement, cette paire fournit le contexte de la tâche et l’endroit où le travail est consigné.
Commencez par un accès en lecture. Si un serveur peut créer des branches, fermer des issues ou fusionner des pull requests, activez ces actions séparément. Un jeton couvrant toute une organisation est pratique en démonstration et risqué au quotidien. Préférez une identité dédiée, des scopes minimaux et un dépôt bac à sable pour le premier essai.
Les bases de données, Slack et Drive exigent un modèle de confiance plus strict
Un serveur Postgres peut inspecter un schéma, diagnostiquer des requêtes et analyser des données. Toutefois, l’utilisateur en lecture seule doit être imposé par la base de données, et non promis dans un prompt système. Ajoutez des délais d’expiration pour les instructions, bloquez les schémas sensibles et conservez une piste d’audit pour l’accès à la production. Slack et Google Drive peuvent révéler des conversations ou des documents que l’utilisateur n’avait jamais l’intention d’intégrer à la tâche ; limitez donc les espaces de travail, les canaux et les dossiers.
Les ressources MCP sont utiles pour le contexte ; les outils servent aux actions. Si une tâche peut être résolue avec une ressource en lecture seule, n’exposez pas d’outil d’écriture. C’est particulièrement important pour la facturation, le CRM, les shells distants et l’infrastructure.
Browser MCP et PhonePi servent des interfaces, pas des API de masse
Browser MCP permet à un agent de travailler à travers une page web, tandis que PhonePi MCP étend une approche apparentée à un appareil Android. Ils sont utiles pour tester des interfaces, reproduire un parcours client et travailler avec des systèmes dépourvus d’API adaptée. L’automatisation d’interface reste plus lente et plus fragile qu’une API directe, car les sélecteurs, les sessions, les boîtes de dialogue et les permissions changent.
Utilisez une passerelle de navigateur ou de téléphone lorsque l’interface elle-même compte. Pour la synchronisation de masse, la facturation et les écritures critiques, préférez une API officielle avec idempotence et journaux d’opérations.
Un serveur n’est pas une extension, une clé d’API ni une intégration terminée
Une extension ajoute une interface utilisateur ou un comportement à une application. Une clé d’API prouve qui appelle un service. Une intégration décrit un workflow métier finalisé. Un serveur MCP est un contrat programmatique par lequel un hôte découvre et invoque des capacités. Le serveur peut tout de même nécessiter une clé d’API, OAuth ou une autorisation locale. Le protocole n’invente pas les permissions et ne garantit pas la qualité de l’implémentation.
Vérifiez l’éditeur, le dépôt, les dépendances, le chemin de mise à jour et les outils déclarés. Un serveur installé à partir d’un README quelconque exécute du code avec des privilèges locaux. Épinglez sa version et inspectez la configuration avant d’introduire des secrets.
Un petit ensemble vaut mieux qu’un catalogue de vingt serveurs
Une séquence raisonnable pour les développeurs est la suivante : des fichiers locaux dans une racine autorisée, un dépôt GitHub, puis un navigateur pour la validation. Ajoutez des bases de données, des chats et des documents cloud uniquement pour un workflow récurrent précis. Supprimez les connexions qui ne produisent aucune valeur après une semaine.
Avant d’activer les écritures, répondez à cinq questions : quelles données le serveur peut-il voir, quelles actions peut-il effectuer, où les secrets sont-ils stockés, qui confirme les actions irréversibles et où se trouve la piste d’audit ? MCP réduit le coût d’intégration, mais il ne supprime pas le modèle de menace. Une bonne configuration rend un agent plus utile précisément parce qu’elle ne lui accorde pas tout à la fois.