← #mcp

MCP (Model Context Protocol) : comment les LLM se connectent aux outils externes

C'est quoi

MCP, pour *Model Context Protocol*, est un protocole de communication ouvert publié par Anthropic en novembre 2024. Il définit une interface standardisée permettant à un modèle de langage (LLM) d'interagir avec des outils, des sources de données et des services externes — fichiers locaux, bases de données, APIs REST, dépôts Git, etc. — sans qu'il soit nécessaire d'écrire une intégration sur mesure pour chaque combinaison modèle × outil.

Avant MCP, chaque éditeur de LLM ou d'agent IA devait concevoir son propre mécanisme de *tool use* : OpenAI a ses *function calls* (introduits en juin 2023), LangChain a ses *tools*, AutoGPT avait ses plugins. Ces approches sont fonctionnellement proches mais syntaxiquement incompatibles, ce qui oblige les développeurs à réécrire les connecteurs à chaque changement de modèle ou de framework. MCP propose une couche d'abstraction commune : un serveur MCP expose des capacités (outils, ressources, prompts), un client MCP — typiquement l'application qui orchestre le LLM — les consomme via un protocole JSON-RPC 2.0 transporté sur stdio ou HTTP+SSE.

Comment ça marche

L'architecture MCP repose sur trois entités : le **client**, le **serveur** et l'**hôte**. L'hôte est l'application utilisateur (Claude Desktop, un IDE, un agent custom). Le client est la bibliothèque embarquée dans l'hôte qui parle le protocole MCP. Le serveur est un processus séparé — souvent un script Node.js ou Python — qui expose des *primitives* : des **outils** (fonctions appelables), des **ressources** (données lisibles, comme un fichier ou une URL) et des **prompts** (templates réutilisables).

Le transport par défaut est **stdio** : l'hôte lance le serveur MCP comme un sous-processus, et les deux communiquent via stdin/stdout en JSON-RPC 2.0. Pour les scénarios distants, MCP supporte HTTP avec Server-Sent Events (SSE), ce qui permet d'héberger un serveur MCP sur un endpoint web. La négociation de capacités se fait au démarrage via un *handshake* `initialize` / `initialized` : le client annonce sa version du protocole (actuellement `2024-11-05`), le serveur répond avec les primitives qu'il supporte.

Exemple concret : un développeur configure Claude Desktop pour utiliser le serveur MCP officiel `@modelcontextprotocol/server-filesystem` (disponible sur npm). Ce serveur expose un outil `read_file` et un outil `write_file`. Lorsque l'utilisateur demande à Claude « Lis mon fichier `config.yaml` et corrige les erreurs de syntaxe », Claude génère un appel d'outil structuré, le client MCP le route vers le serveur filesystem, qui lit le fichier sur le disque et retourne le contenu. Claude reçoit ce contenu dans son contexte et produit la réponse corrigée — sans qu'Anthropic ait eu à coder une intégration filesystem spécifique dans Claude Desktop.

Le schéma de description des outils est proche du JSON Schema standard. Chaque outil déclare un `name`, une `description` en langage naturel (utilisée par le LLM pour décider quand l'appeler) et un `inputSchema` JSON Schema. Cette description est injectée dans le contexte du modèle lors de l'inférence, ce qui signifie que la qualité de la `description` influence directement la fiabilité du *tool use*. Les serveurs MCP peuvent aussi exposer des **ressources** avec un URI (ex. `file:///home/user/notes.md`) que le client peut lire à la demande, et des **prompts** paramétrés que l'utilisateur peut invoquer directement depuis l'interface hôte.

Pourquoi ça compte maintenant

Le problème que MCP résout est celui de la fragmentation des intégrations dans les systèmes agentiques. Un agent IA qui doit accéder à GitHub, Slack, une base PostgreSQL et un système de fichiers local doit aujourd'hui maintenir quatre connecteurs différents, souvent couplés à un framework spécifique (LangChain, LlamaIndex, CrewAI). Si l'équipe change de modèle — de GPT-4o à Claude 3.5 Sonnet, par exemple — les connecteurs doivent être réécrits ou adaptés. MCP découple le serveur (qui connaît l'outil) du client (qui connaît le modèle) : un serveur MCP écrit une fois fonctionne avec n'importe quel client MCP, quel que soit le LLM sous-jacent.

Pour les équipes qui construisent des agents en production, cela réduit la dette technique et accélère l'ajout de nouvelles capacités. Pour les éditeurs d'outils (Notion, Linear, Brave Search…), cela ouvre un canal standardisé pour rendre leurs produits accessibles aux agents IA sans dépendre d'un partenariat avec OpenAI ou Anthropic. Début 2025, des acteurs comme Block, Replit, Sourcegraph et Zed ont annoncé des intégrations MCP natives, et le dépôt officiel `modelcontextprotocol/servers` recense déjà plusieurs dizaines de serveurs de référence couvrant filesystem, Git, bases de données SQL, Brave Search, Google Drive ou encore Puppeteer.

Les acteurs

**Anthropic** est l'auteur du protocole et maintient les SDKs officiels en TypeScript (`@modelcontextprotocol/sdk`, v1.x) et Python (`mcp`, v1.x sur PyPI), ainsi qu'une collection de serveurs de référence sur GitHub. **Claude Desktop** (macOS et Windows) est le premier hôte MCP grand public. **Zed** (éditeur de code) et **Replit** ont intégré MCP côté IDE. **LangChain** a publié un adaptateur MCP pour ses *tools* (`langchain-mcp-adapters`). **OpenAI** n'a pas adopté MCP officiellement à ce jour (mars 2025) et maintient son propre format de *function calling*, mais la communauté a produit des ponts. Du côté des serveurs tiers notables : `mcp-server-git` (Anthropic), `mcp-server-postgres` (Anthropic), `mcp-server-brave-search` (Anthropic), et `mcp-server-github` (GitHub/community).

Pour aller plus loin

Résumé généré par Claude — vérifié par l'humain