Le Model Context Protocol, ou MCP, est devenu en deux ans le standard de fait pour brancher des outils sur des assistants IA. Si vous utilisez Claude Code, Cursor, ou un agent maison, vous croisez le sigle partout sans toujours en mesurer l’enjeu. Cet article explique le problème que MCP résout, comment il fonctionne, et quels serveurs essayer dès cette semaine pour comprendre l’intérêt par la pratique. À la fin, vous saurez configurer un client en trente secondes et identifier l’effet de levier que MCP apporte à un développeur en 2026.
Le problème : N agents × M outils, sans standard
Avant MCP, chaque agent IA (Claude, ChatGPT, un agent maison) devait apprendre à parler à chaque outil (GitHub, une base Postgres, Slack, un système de fichiers) via une intégration sur mesure. Cette explosion combinatoire portait un nom dans les architectures distribuées : le problème N×M. Pour brancher 5 agents sur 30 outils, il fallait écrire 150 connecteurs, chacun avec sa logique propre, ses formats, ses bugs.
Anthropic a publié MCP fin 2024 comme spécification ouverte pour casser cette explosion. L’idée : un protocole universel entre un client (l’agent) et un serveur (l’outil), basé sur JSON-RPC. Une fois qu’un outil expose un serveur MCP, tout agent compatible peut le consommer sans intégration spécifique. On passe de N×M à N+M.
Le pari a réussi. En 2026, MCP est implémenté par Claude, Cursor, Zed, Continue, plusieurs agents open source, et plusieurs centaines de serveurs communautaires. La spécification officielle est maintenue collégialement, ce qui rassure les éditeurs. Pour comprendre pourquoi ce protocole change la donne, il faut entrer un peu dans la mécanique.
MCP en une phrase et trois schémas
Le Model Context Protocol définit un langage commun entre un agent IA (le client) et un fournisseur d’outils ou de données (le serveur). Le client demande, le serveur répond. Tout passe par des messages JSON-RPC structurés, ce qui rend la communication prévisible, traçable, et facile à débugger.
Le client (l’agent), le serveur (l’outil), le protocole
Le client est l’application qui héberge le modèle d’IA. Claude Code, Cursor, ou votre script Python qui consomme l’API Anthropic. Le serveur est un programme indépendant qui expose des capacités : lire un fichier, interroger une base, poster un message Slack. Le protocole est la grammaire JSON-RPC qui régit leur conversation : initialisation, découverte des capacités, appels, réponses, erreurs.
Tools, resources, prompts — la trinité
Un serveur MCP expose trois primitives, et il faut les distinguer pour comprendre la suite.
- Tools : des fonctions exécutables que l’agent peut appeler avec des arguments typés. Exemple :
create_issue(repo, title, body). Le tool produit un effet (lecture, écriture, calcul). - Resources : des données que l’agent peut lire à la demande. Exemple : le contenu d’un fichier, une page de documentation, un enregistrement de base. Une resource est identifiée par un URI.
- Prompts : des modèles de conversation préconfigurés que l’utilisateur peut déclencher. Exemple : un prompt « audit de sécurité » qui injecte automatiquement le bon contexte et la bonne instruction.
Cette séparation est volontaire. Les tools agissent, les resources informent, les prompts orientent. Un serveur peut exposer les trois ou seulement une.
Transports : stdio, HTTP+SSE
Un transport est le canal physique par lequel client et serveur s’échangent les messages. Deux options en 2026 : stdio (le serveur tourne en local, le client lance le processus et lui parle via l’entrée et la sortie standard) et HTTP+SSE (le serveur tourne sur le réseau, le client se connecte via HTTP avec Server-Sent Events pour le flux). Le premier est idéal pour un usage personnel, le second pour partager un serveur en équipe.
Ce que ça change pour un dev en 2026
Le bénéfice se mesure à deux niveaux : la productivité individuelle et la capitalisation d’équipe.
Côté Claude Code : configurer un serveur en 30 secondes
L’ajout d’un serveur MCP dans Claude Code se fait via une commande ou un fichier de configuration. Voici un exemple minimal pour brancher le serveur officiel filesystem, qui donne à l’agent un accès contrôlé à un dossier de votre disque :
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/dev/projects"
]
}
}
}Trois lignes utiles. Au démarrage, Claude Code lance le serveur, négocie les capacités, et expose les tools dans la conversation. Aucun code à écrire pour bénéficier d’une lecture-écriture sécurisée du système de fichiers.
Côté équipe : un serveur MCP interne devient réutilisable
L’autre effet, moins visible mais structurant, concerne la capitalisation. Quand votre équipe expose un outil interne (un CRM maison, un wiki, une API métier) en serveur MCP, n’importe quel développeur, n’importe quel agent, n’importe quel client compatible peut s’y brancher. Le coût d’intégration s’amortit sur tous les usages futurs. C’est précisément le sujet de notre créer son propre serveur MCP (sous-pilier), qui montre la mise en pratique.
5 serveurs MCP à essayer
Plutôt que de théoriser, voici cinq serveurs officiels ou très populaires à installer en moins d’une heure. Tous sont disponibles sur le dépôt officiel des serveurs MCP.
Filesystem, GitHub, Slack, Postgres, Memory
| Serveur | Capacités | Cas d’usage typique | Niveau requis |
|---|---|---|---|
| filesystem | Lire, écrire, lister un dossier | Donner accès à un projet local sans pull/push permanent | Débutant |
| github | Issues, PR, branches, fichiers | Ouvrir une PR depuis une conversation Claude | Débutant (token requis) |
| slack | Lire canaux, poster, threads | Diffuser un résumé de PR à l’équipe automatiquement | Intermédiaire |
| postgres | Schéma, requêtes en lecture seule | Explorer une base sans accès psql | Intermédiaire |
| memory | Persistance entre sessions | Donner une mémoire long terme à un agent personnel | Débutant |
L’ordre suggéré : filesystem en premier pour saisir le mécanisme, github pour mesurer l’effet sur le quotidien, memory pour comprendre le potentiel des resources persistantes. Le tout en une après-midi.
Limites et zones grises actuelles
MCP n’est pas magique et il faut connaître ses zones d’ombre avant d’investir.
- La sécurité reste votre responsabilité. Un tool qui supprime des fichiers le fera si l’agent le décide. Le protocole prévoit des prompts de confirmation, mais les politiques d’autorisation dépendent du client.
- L’observabilité est encore jeune. Tracer ce qu’un agent a fait via MCP demande de logger côté serveur. Les standards d’audit s’écrivent en ce moment.
- La performance varie. Un serveur stdio démarre vite mais ne scale pas. Un serveur HTTP scale mais ajoute de la latence et des questions d’authentification.
- Les schémas évoluent. Le protocole reste en mouvement : certaines primitives (sampling, roots) bougent encore. Vérifier la compatibilité de versions reste utile.
Pour autant, ces limites n’interdisent pas l’usage en production : elles imposent une discipline d’ingénierie. La plupart sont traitables avec des conventions claires, comme nous le détaillons dans le guide Claude Code (pilier) et dans notre panorama 2026 des agents IA.
Pour aller plus loin
Trois ressources s’imposent une fois les bases acquises. La documentation Anthropic sur MCP pour la mise en œuvre côté Claude. Le dépôt GitHub officiel pour explorer le code des serveurs existants. Et notre sous-pilier qui détaille la création de votre propre serveur, étape par étape, avec trois exemples gradués allant du tool simple au cas métier complet.
Le moment d’investir dans MCP est venu. La spécification est stable, l’écosystème actif, les SDK officiels en TypeScript et Python sont matures. Pour une équipe qui veut sortir de l’ère des connecteurs ad hoc, c’est l’inflexion structurante de la décennie. Chaque outil interne exposé en MCP devient un actif réutilisable, transversal à tous les agents que votre équipe utilisera, présents et futurs.
Foire aux questions sur MCP
Qu’est-ce que le Model Context Protocol (MCP) ?
MCP est un protocole ouvert, publié par Anthropic fin 2024, qui standardise la communication entre un agent IA et les outils ou données qu’il consomme. Il s’appuie sur JSON-RPC et définit trois primitives : tools, resources, prompts. L’objectif est de remplacer les connecteurs sur mesure par un langage universel client-serveur.
Quelle différence entre tools, resources et prompts dans MCP ?
Les tools sont des fonctions exécutables avec effet (créer une issue, requêter une base). Les resources sont des données identifiées par URI que l’agent peut lire (un fichier, une page). Les prompts sont des modèles de conversation préconfigurés que l’utilisateur déclenche. Un serveur peut exposer les trois ou seulement une.
Comment configurer un serveur MCP avec Claude Code ?
L’ajout se fait via un fichier de configuration JSON ou la commande dédiée du client. Vous y déclarez le nom du serveur, la commande pour le lancer, et les arguments éventuels. Au démarrage, Claude Code lance le serveur en tâche de fond et expose ses tools dans la session courante.
Quels sont les meilleurs serveurs MCP à essayer en 2026 ?
Pour découvrir : filesystem (accès dossier), github (PR et issues), slack (messagerie d’équipe), postgres (lecture de base), memory (persistance entre sessions). Tous sont officiels, gratuits, et installables en quelques minutes via npx ou pip. L’ordre conseillé : filesystem, puis github, puis memory.
MCP est-il propre à Claude ou utilisable ailleurs ?
Le protocole est ouvert et plusieurs clients l’implémentent : Cursor, Zed, Continue, des agents open source, et de plus en plus d’outils internes d’entreprise. Les serveurs MCP sont portables : un serveur écrit pour Claude fonctionne sans modification avec n’importe quel client compatible. C’est précisément l’argument central du protocole.
Vous voulez exposer un outil interne en MCP pour vos équipes ou pour vos clients ? Nous prototypons un serveur opérationnel en 2 à 3 jours selon le périmètre. Contactez WebCreatid pour cadrer le besoin.