MCP : connecter Claude à de vrais outils, pas à des prompts plus longs
Avant de connaître MCP, la seule façon de donner à un agent l'accès à un service externe était de décrire cet accès en texte dans le prompt, ou de coder une intégration ad hoc pour chaque service, chaque fois. Ça marche pour un outil. Ça devient ingérable à cinq, parce que chaque intégration est écrite différemment et que rien ne garantit qu'elles cohabitent proprement dans le même contexte.
Le problème que ça résout#
Model Context Protocol standardise l'accès aux outils externes : un serveur MCP expose un ensemble de capacités (lire un email, chercher un fichier, lister des déploiements) dans un format commun, que n'importe quel client compatible peut consommer sans code d'intégration spécifique. Le gain n'est pas seulement pratique, il est architectural : l'agent ne reçoit plus une description textuelle d'un outil qu'il doit interpréter, il reçoit une interface structurée qu'il peut appeler directement.
Sur mon usage courant de Claude Code, j'ai des serveurs MCP connectés pour Gmail, Google Calendar, Vercel et WordPress.com. Concrètement, ça veut dire que je peux demander à l'agent de vérifier mes déploiements Vercel récents ou de retrouver un échange par email avant un appel client, sans jamais avoir décrit moi-même comment interroger ces services : le serveur MCP porte cette responsabilité, pas mon prompt.
Ce qui change par rapport à un outil codé en dur#
| Intégration codée en dur | Serveur MCP | |
|---|---|---|
| Réutilisabilité | Spécifique à un projet ou un agent | Réutilisable par n'importe quel client MCP |
| Maintenance | À la charge de chaque intégration | Centralisée côté serveur |
| Découverte des capacités | Décrite manuellement dans le prompt | Exposée par le serveur, lue dynamiquement |
| Changement de fournisseur | Réécriture de l'intégration | Changement de serveur, interface stable |
La ligne qui compte le plus est la troisième : un serveur MCP expose ce qu'il sait faire, l'agent le découvre au lieu de le deviner à partir d'un texte écrit par un humain qui a pu oublier un cas.
Le vrai risque : l'accès, pas le protocole#
Un serveur MCP donne à l'agent un accès réel à un système réel. La question à se poser avant de connecter un serveur n'est pas « est-ce que ça marche », c'est « qu'est-ce que je suis prêt à laisser cet agent faire sans supervision directe ». Un serveur mal scope (accès en écriture là où seule la lecture était nécessaire) transforme un gain de productivité en risque de sécurité.
C'est la raison pour laquelle je distingue toujours, avant de connecter un serveur MCP, les actions réversibles (lister, chercher, lire) des actions qui ne le sont pas (envoyer, publier, supprimer). Les premières peuvent tourner sans confirmation systématique. Les secondes doivent rester derrière une validation explicite, quel que soit le niveau de confiance dans le serveur.
MCP et skills ne jouent pas le même rôle#
Un skill encode un comportement : une méthode, une checklist, une façon de faire une tâche récurrente. Un serveur MCP encode un accès : une capacité à agir sur un système externe. Les deux se combinent naturellement, un skill peut très bien s'appuyer sur un serveur MCP pour accomplir sa tâche, mais confondre les deux mène à une erreur classique : essayer de packager un accès système dans un skill plutôt que dans un serveur MCP dédié, ce qui rend cet accès non réutilisable ailleurs.
Ce qui reste un vrai frein#
Le protocole résout le problème de la description d'outils, pas celui du jugement de l'agent sur quand les utiliser. Un serveur MCP mal documenté (des noms de capacités vagues, des paramètres non expliqués) reproduit exactement le problème qu'il était censé éviter, sous une forme différente. La qualité de la description reste déterminante, elle a simplement changé d'emplacement : elle n'est plus dans mon prompt, elle est dans le serveur.
Ce que ça généralise#
MCP ne change rien à la nature probabiliste de l'agent : il reste libre de décider quand appeler un outil, et peut se tromper. Ce qu'il change, c'est le coût de connecter un nouvel outil : d'une réécriture d'intégration à chaque fois, à une simple connexion à un serveur qui expose déjà une interface propre. La question à se poser avant chaque nouvelle connexion reste la même que pour un accès humain à un système : quel périmètre, quelle réversibilité, quelle supervision, indépendamment du protocole utilisé pour l'exposer.