Les serveurs MCP : comprendre le Model Context Protocol

Le Model Context Protocol (MCP) est un standard ouvert qui connecte les modèles de langage aux outils et aux données. Ce premier article explique simplement ce qu'est un serveur MCP, son architecture et pourquoi il change la donne pour les agents IA.

Les modèles de langage sont brillants pour raisonner sur du texte, mais ils sont, par nature, coupés du monde. Un modèle ne peut pas lire vos fichiers, interroger votre base de données ou appeler une API tant qu’on ne lui en donne pas explicitement les moyens. Le Model Context Protocol (MCP) est le standard qui résout ce problème de façon générique. Ce premier article pose les bases ; les suivants entreront dans le détail de la construction d’un serveur et de son intégration à un écosystème.

I. Le problème : connecter les LLM au monde réel  

Un modèle de langage, seul, ne sait faire qu’une chose : produire du texte à partir de texte. Dès qu’on veut lui faire effectuer une action utile — consulter un agenda, lire un dépôt Git, envoyer un message — il faut lui brancher un outil extérieur.

Historiquement, chaque application réinventait cette tuyauterie. Pour relier M modèles à N outils, on se retrouvait à écrire M × N intégrations sur mesure : une pour Claude + GitHub, une autre pour un autre modèle + GitHub, une autre encore pour Claude + Slack, etc. Chaque connexion avait son propre format, sa propre authentification, sa propre logique. Ce travail était coûteux, fragile et impossible à mutualiser.

L’idée de MCP est de remplacer ce M × N par un M + N : un protocole commun que chaque modèle parle d’un côté et que chaque outil expose de l’autre.

II. Qu’est-ce que le Model Context Protocol ?  

Le Model Context Protocol est un standard ouvert, publié par Anthropic fin 2024, qui définit comment une application d’IA communique avec des sources de données et des outils externes.

Concrètement, MCP normalise trois choses :

• Le format des échanges : MCP s’appuie sur JSON-RPC 2.0, un protocole d’appel de procédure distant simple et éprouvé.
• Le vocabulaire : ce qu’un outil peut offrir à un modèle est décrit avec des concepts communs (outils, ressources, prompts — voir section IV).
• Le transport : la manière dont les messages circulent (en local ou à distance).

Comme c’est un standard ouvert, n’importe qui peut écrire un serveur MCP, et celui-ci fonctionnera avec n’importe quel client compatible — sans accord préalable entre les deux camps.

III. L’architecture : hôte, client, serveur  

MCP repose sur trois rôles bien distincts :

• L’hôte (host) : l’application que l’utilisateur manipule et qui embarque le modèle. Par exemple Claude Desktop, un IDE, ou Claude Code.
• Le client : un composant qui vit à l’intérieur de l’hôte et maintient une connexion un-à-un avec un serveur. Un hôte qui parle à trois serveurs gère donc trois clients.
• Le serveur (server) : un programme léger qui expose des capacités précises (l’accès à un système de fichiers, à une base PostgreSQL, à l’API GitHub…).

┌─────────────────────────────┐
│           HÔTE              │   (Claude Desktop, IDE, Claude Code…)
│   ┌─────────┐ ┌─────────┐   │
│   │ Client A│ │ Client B│   │
│   └────┬────┘ └────┬────┘   │
└────────┼───────────┼────────┘
         │           │
   ┌─────▼────┐  ┌───▼──────┐
   │ Serveur  │  │ Serveur  │
   │ GitHub   │  │ Postgres │
   └──────────┘  └──────────┘

Cette séparation est essentielle : l’hôte ne sait rien des détails internes d’un serveur, il sait seulement dialoguer avec lui via le protocole. On peut ajouter, retirer ou remplacer un serveur sans toucher à l’hôte.

IV. Ce qu’un serveur MCP expose : outils, ressources, prompts  

Un serveur MCP met à disposition trois types de primitives. C’est le cœur du protocole :

La distinction la plus importante est entre outils et ressources. Un outil fait quelque chose et peut avoir des effets de bord ; c’est le modèle qui décide de l’invoquer. Une ressource ne fait qu’apporter de l’information ; elle est généralement choisie par l’application ou l’utilisateur. Cette séparation aide à raisonner sur la sécurité : on sait précisément ce qui peut modifier l’état du monde.

V. Pourquoi MCP plutôt qu’un function-calling maison ?  

Les modèles savent déjà appeler des fonctions (le function calling). Alors pourquoi un protocole supplémentaire ?

Parce que le function calling brut résout le « comment appeler une fonction » mais pas le « comment standardiser et partager ces fonctions ». Sans standard, chaque équipe redéfinit ses schémas, son authentification et son transport. MCP fournit la couche manquante.

Anthropic résume MCP par une analogie devenue célèbre : « un port USB-C pour les applications d’IA ». Avant l’USB-C, chaque appareil avait son connecteur propriétaire ; il fallait un câble par périphérique. L’USB-C a imposé une prise universelle. MCP joue le même rôle : un connecteur unique entre les modèles et tout ce qu’on veut leur brancher.

Les bénéfices concrets :

• Réutilisabilité : un serveur écrit une fois fonctionne avec tous les clients compatibles.
• Découplage : on change de modèle ou d’outil sans réécrire la tuyauterie.
• Écosystème : on bénéficie des serveurs déjà écrits par la communauté.

VI. Cas d’usage concrets  

MCP prend tout son sens dès qu’un assistant doit toucher à un système réel :

• Développement : un serveur qui expose un dépôt Git, le système de fichiers ou un terminal permet à un assistant de lire le code, proposer des modifications et lancer des tests.
• Données : un serveur PostgreSQL ou un connecteur vers un entrepôt de données laisse le modèle répondre à des questions à partir de vos chiffres réels.
• Productivité : des serveurs vers Slack, un agenda ou un gestionnaire de tickets transforment l’assistant en véritable copilote opérationnel.
• Documentation : un serveur qui indexe une base de connaissances fournit au modèle un contexte à jour, au lieu de le laisser halluciner.

Dans chacun de ces cas, la logique métier vit dans le serveur, pas dans le modèle — ce qui la rend testable, versionnable et réutilisable.

VII. L’écosystème et par où commencer  

Autour de MCP, un écosystème s’est rapidement formé :

• Des SDK officiels (Python, TypeScript, et d’autres langages) pour écrire un serveur en quelques dizaines de lignes.
• Des serveurs prêts à l’emploi pour les services les plus courants (système de fichiers, GitHub, bases de données, etc.).
• Une adoption au-delà d’Anthropic, plusieurs acteurs majeurs de l’IA ayant rallié le standard courant 2025.

Pour débuter, le plus simple est de connecter un serveur existant à un hôte compatible et d’observer le modèle s’en servir. Les deux étapes suivantes — construire son propre serveur et l’intégrer proprement à un écosystème (sécurité, transports distants, bonnes pratiques) — feront l’objet des prochains articles de cette série.

Conclusion  

Le Model Context Protocol n’invente pas l’idée de donner des outils à un modèle ; il la standardise. En transformant un casse-tête d’intégrations sur mesure (M × N) en un branchement universel (M + N), MCP fait pour les assistants IA ce que l’USB-C a fait pour nos appareils : un connecteur commun, ouvert, et réutilisable.

Dans cet article, nous avons posé les fondations : le problème résolu, l’architecture hôte/client/serveur, les trois primitives (outils, ressources, prompts) et l’intérêt par rapport à une intégration maison. Les prochains articles passeront à la pratique en construisant un serveur de bout en bout.

Useful links  

• Spécification du Model Context Protocol
• Annonce officielle de MCP (Anthropic)
• SDK et serveurs de référence (GitHub)
• Spécification JSON-RPC 2.0