MCP — le protocole universel pour vos agents IA

MCP (Model Context Protocol) est le standard ouvert publié par Anthropic en novembre 2024 pour connecter les agents IA à n’importe quel outil ou source de données. Là où chaque intégration LLM-outil se négociait manuellement, MCP pose un protocole unique basé sur JSON-RPC 2.0 : un seul serveur suffit pour rendre un outil accessible à Claude, ChatGPT, VS Code ou Cursor simultanément. Cet article ouvre la série MCP-101 en posant les fondations architecturales.

Prérequis

Pourquoi MCP a-t-il été créé ?

Imaginons la situation classique du développeur qui veut donner à son agent IA l’accès à une base de données Postgres, à l’API GitHub et à un moteur de recherche web. Sans protocole commun, il écrit trois connecteurs séparés : un adapté à l’API Anthropic, un autre pour l’API OpenAI s’il veut tester GPT-4, un troisième si son équipe préfère Gemini. Dix LLMs, dix outils : cent connecteurs à écrire, tester et maintenir. C’est le problème N×M que MCP résout de façon structurelle.

Anthropic a publié MCP en novembre 2024 comme protocole ouvert et agnostique du modèle. L’idée fondatrice : séparer l’implémentation de l’outil (le serveur MCP) de l’agent qui l’utilise (l’hôte MCP), et les faire communiquer via un standard unique. Du côté outil, on déclare ses fonctions une seule fois. Du côté agent, n’importe quel hôte compatible les consomme sans modification. Un serveur MCP écrit pour Claude Desktop fonctionne aussi dans VS Code, Cursor et ChatGPT sans toucher une ligne de code serveur.

La documentation officielle MCP compare le protocole à un port USB-C : là où chaque fabricant imposait autrefois son propre connecteur propriétaire, USB-C a standardisé les échanges. MCP joue ce rôle pour l’écosystème IA. L’analogie est précise : avant USB-C, on achetait des câbles pour chaque appareil ; avant MCP, on écrivait un wrapper API pour chaque modèle.

L’adoption a suivi rapidement. En moins d’un an, les principaux acteurs de l’industrie ont publié des serveurs MCP officiels pour leurs plateformes : GitHub, Sentry, les SDKs AWS, les services Google, Stripe et Cloudflare pour leurs APIs. Côté clients MCP, Claude Desktop et Claude Code (Anthropic), ChatGPT (OpenAI), VS Code avec GitHub Copilot (Microsoft), Cursor et Continue.dev supportent tous le protocole nativement. Pour un développeur Python qui construit un outil, écrire un serveur MCP plutôt qu’un wrapper spécifique ouvre l’outil à tout cet écosystème d’un seul coup.

Comment MCP s’organise-t-il ?

L’architecture MCP distingue trois participants aux rôles clairement séparés. Comprendre cette séparation est le premier pas pour concevoir des serveurs corrects et éviter les confusions courantes.

L’hôte MCP est l’application IA qui pilote la conversation. Claude Desktop, Claude Code, Visual Studio Code sont des hôtes. L’hôte orchestre les échanges, décide quels outils appeler selon le contexte, intègre les résultats dans la réponse finale et gère le cycle de vie de ses connexions. Un hôte peut maintenir des connexions simultanées avec plusieurs serveurs MCP, en instanciant un client dédié pour chacun.

Le client MCP est un composant interne à l’hôte, créé pour chaque connexion avec un serveur. Quand VS Code établit une connexion avec le serveur MCP de Sentry, il instancie un objet client MCP qui maintient cette connexion. Si VS Code se connecte ensuite au serveur de fichiers local, un second client MCP distinct est créé. Chaque paire (client, serveur) fonctionne sur une connexion dédiée, ce qui isole les communications et les erreurs entre elles.

Le serveur MCP est le programme qui expose des tools, des resources ou des prompts. Il peut s’exécuter localement sur la même machine que l’hôte, ou à distance en tant que service web. Un serveur MCP n’est pas une API REST : il parle le protocole MCP, un dialecte de JSON-RPC 2.0, avec un cycle de vie de connexion géré. La distinction est importante : un serveur MCP expose des primitives que le LLM peut découvrir dynamiquement, là où une API REST expose des endpoints que le code appelle statiquement.

La figure suivante présente l’architecture MCP :

 

Un hôte MCP est une application supportant le protocole MCP : cela peut-être un agent IA ou une application telle que Claude Desktop ou Gemini.

Le protocole MCP est structuré en deux couches superposées. La couche données (data layer) définit le format JSON-RPC 2.0 des messages, le cycle de vie de connexion et les primitives échangées. La couche transport (transport layer) gère les mécanismes de communication physique entre les participants, en isolant ces détails de la couche données.

MCP supporte deux transports. Le transport STDIO fait communiquer client et serveur via stdin et stdout : le serveur est un processus lancé par l’hôte sur la même machine, sans latence réseau. C’est le transport que nous utilisons dans les articles 5 à 10 de cette série. Le transport HTTP Streamable utilise HTTP POST pour les requêtes client vers serveur, avec des Server-Sent Events optionnels pour les notifications temps réel. Ce transport autorise les serveurs distants, accessibles depuis plusieurs clients simultanément. La spec MCP recommande OAuth pour sécuriser les échanges HTTP, que nous traitons en article 12.

La différence pratique est simple : un serveur STDIO sert un seul client à la fois, localement. Un serveur HTTP peut servir N clients en parallèle depuis n’importe où sur le réseau. Ce critère dicte le choix du transport selon le cas d’usage.

Chaque connexion MCP débute par un handshake d’initialisation. Le client envoie sa version de protocole (par exemple "protocolVersion": "2025-06-18") et la liste de ses capacités. Le serveur répond avec sa version et ses propres capacités. Cette négociation détermine quelles primitives seront disponibles dans la session. Si les versions sont incompatibles, la connexion s’arrête proprement avant tout échange de données.

Afin de visualiser rapidement le format d’échange, vous trouverez ci-dessous une requête d’invocation d’outil sur un serveur MCP et sa réponse (ici l’outil est une fonction de conversion de devise).

Exemple de requête, appel de convert_currency(« dollar », « euros », 5)  :

{
   "jsonrpc": "2.0",
   "id": 1,
   "method": "tools/call",
   "params": {
     "name": "convert_currency",
     "arguments": {
       "source": "dollar",
       "target": "euros",
       "amount": 5
     }
   }
}

La réponse associée, résultat retourné par le serveur MCP:

{
   "jsonrpc": "2.0",
   "id": 1,
   "result": {
     "content": [
       {
         "type": "text",
         "text": "4.31"
       }
     ],
     "isError": false
   }
}

Note : la spécification MCP évolue en 2026, voir l’article MCP 2026-07-28 : ce qui change pour vos agents IA

Les trois primitives MCP : tools, resources et prompts

Un serveur MCP peut exposer trois types d’objets au LLM. Ces primitives définissent l’expressivité du protocole : ce que l’on peut faire avec un serveur MCP va bien au-delà du simple appel de fonction.

Les tools sont des fonctions exécutables que le LLM peut invoquer selon le contexte de la conversation. C’est la primitive la plus utilisée. Quand Claude décide qu’une requête nécessite d’interroger une base de données ou d’appeler une API météo, il émet un message tools/call avec le nom du tool et ses arguments. Le serveur exécute la logique, retourne le résultat, et le LLM intègre cette information dans sa réponse. Exemples concrets : query_database(sql), get_weather(city), create_github_issue(title, body).

Le LLM choisit quel tool appeler en lisant les métadonnées que le serveur publie lors de la découverte (tools/list) : le nom du tool, sa description en langage naturel, et le JSON Schema de ses paramètres d’entrée. La description est un élément de conception critique, parce que c’est ce texte que le modèle interprète pour décider si ce tool correspond à la situation. Nous verrons en article 4 que ce champ est aussi un vecteur de sécurité à surveiller attentivement (tool poisoning).

Les resources sont des sources de données exposées via des URIs. Contrairement aux tools, une resource n’est pas une action : c’est du contenu que l’hôte peut injecter dans le contexte du LLM sans que celui-ci ait à décider activement de l’appeler. Le schéma d’URI est libre et défini par le serveur : mcp://docs/readme, file:///home/user/config.toml, postgres://db/schema. Ce pattern convient aux bases de connaissance, aux fichiers de configuration ou aux données de référence que le modèle doit avoir en tête pendant toute une session de travail.

Les prompts sont des templates paramétrés que le serveur met à disposition. Un serveur peut exposer un prompt code_review avec les paramètres language (python/go/typescript) et style (concis/détaillé) : l’utilisateur ou l’hôte instancie ce template pour structurer l’interaction avec le LLM. C’est utile pour encoder des workflows récurrents ou des instructions complexes que toute une équipe veut standardiser sans les resaisir à chaque session.

Type	Qui décide de l’utiliser ?	Usage typique	Analogie REST
Tool	Le LLM (selon le contexte)	Appel d’API, requête DB, action système	POST
Resource	L’hôte (injection automatique)	Documentation, schéma, configuration	GET
Prompt	L’utilisateur ou l’hôte	Template de revue de code, workflow	GET (template)

 

Les trois primitives se combinent et étendent ainsi les capacités de vos agents ou de vos chatbots. Un serveur MCP pour une base de données peut exposer simultanément un tool query_db pour les requêtes dynamiques, une resource mcp://db/schema avec le schéma de la base en lecture, et un prompt sql_helper avec des exemples prêts à l’emploi. L’agent dispose ainsi d’une interface complète : contexte structurel, aide à la formulation, et capacité d’action sur la base.

Pourquoi MCP plutôt que le function calling ou LangChain ?

La réponse directe : MCP, le function calling natif et LangChain ne sont pas en compétition frontale. Ils opèrent à des niveaux d’abstraction différents, et comprendre leurs frontières aide à choisir la bonne approche selon le contexte.

Le function calling natif des APIs LLM (Anthropic, OpenAI, Google) est un mécanisme côté requête API : on déclare des fonctions dans chaque appel, et le modèle décide d’en invoquer une. Ce mécanisme reste couplé à chaque provider. Le format JSON d’Anthropic diffère de celui d’OpenAI. Un tool défini pour l’API Claude doit être adapté pour l’API GPT-4 ou l’API Gemini. Le code qui intègre le LLM et le code qui implémente l’outil restent mélangés dans la même application.

Avec MCP, le serveur (l’outil) et l’hôte (le client LLM) sont séparés par un protocole réseau standard et indépendant du modèle. Le serveur get_weather tourne en STDIO ou en HTTP. Claude Desktop l’appelle via son client MCP. ChatGPT l’appelle via le sien. Les deux consomment le même serveur sans que le serveur sache ou se soucie de quel hôte il s’agit. Cette séparation est structurelle et durable.

LangChain Tools est un framework Python pour organiser des outils dans des pipelines LangChain. C’est utile dans un contexte LangChain, mais c’est du code Python : un LangChain Tool ne peut pas être appelé directement par Claude Desktop sans passer par votre application LangChain. MCP va plus loin en définissant un protocole de communication inter-processus que tout hôte compatible peut utiliser, indépendamment du langage ou du framework dans lequel le serveur est écrit.

Les plugins OpenAI, lancés en mars 2023 et abandonnés en 2024, avaient une ambition similaire à MCP. Mais leur architecture restait centralisée chez OpenAI, limitée à ChatGPT, et leur adoption a stagné. MCP tire les leçons de cet échec : protocole ouvert, spec publique sur modelcontextprotocol.io, gouvernance communautaire sur GitHub, adoption multi-providers dès le départ.

Ce qui fait la solidité de MCP, c’est la conjonction de trois propriétés qu’aucun des mécanismes précédents ne réunissait : un standard ouvert (la spec est publique et libre), agnostique du modèle (Claude, Gemini, GPT-4, Llama peuvent tous être hôtes MCP), et basé sur un protocole réseau (pas une bibliothèque). L’adoption simultanée par Anthropic, OpenAI et Microsoft en moins d’un an confirme que l’industrie s’est alignée sur ce standard. Pour comprendre comment MCP s’articule avec A2A, le protocole de communication entre agents de Google, notre article A2A et MCP : les deux protocoles clés pour vos agents IA détaille la complémentarité des deux standards.

FAQ

MCP fonctionne-t-il avec tous les LLMs ?

MCP est un protocole côté hôte : il ne dépend pas du modèle de langage utilisé en interne. N’importe quel LLM peut être intégré dans un hôte MCP. Les principaux hôtes qui supportent MCP nativement aujourd’hui sont Claude Desktop et Claude Code (Anthropic), ChatGPT (OpenAI), VS Code avec GitHub Copilot (Microsoft), Cursor et Continue.dev. Si un LLM ou un outil de développement ne supporte pas encore MCP, c’est une question d’implémentation côté SDK, pas une limitation du protocole.

Quelle est la différence entre un serveur MCP et une API REST ?

Une API REST expose des endpoints HTTP que votre code appelle explicitement, avec une logique d’authentification, de pagination et de gestion des erreurs à implémenter côté client. Un serveur MCP expose des primitives (tools, resources, prompts) via JSON-RPC 2.0, avec un cycle de vie de connexion géré : le client négocie les capacités au démarrage, maintient la session et reçoit des notifications en temps réel. Un serveur MCP peut appeler une API REST en interne pour implémenter ses tools : les deux mécanismes sont complémentaires.

La spec MCP est-elle stable en production ?

MCP a connu plusieurs révisions depuis novembre 2024. Une révision majeure est prévue le 28 juillet 2026, qui introduit une architecture stateless pour le transport HTTP et formalise les extensions. Notre article MCP 2026-07-28 : ce qui change pour vos agents IA détaille ces évolutions. Les serveurs officiels (GitHub, Sentry, Stripe) maintiennent la compatibilité. Pour les serveurs communautaires, vérifiez la version de protocole supportée avant d’intégrer.

Peut-on déployer un serveur MCP sur le cloud ?

Oui : c’est précisément le rôle du transport HTTP Streamable. Un serveur MCP HTTP se déploie sur n’importe quel VPS, Railway, Fly.io ou service cloud, et accepte des connexions depuis des hôtes distants. Le transport STDIO reste réservé aux serveurs locaux sur la même machine que l’hôte. Le déploiement HTTP est couvert en article 11, l’authentification OAuth en article 12.

Conclusion — la suite de la série MCP-101

MCP résout un problème structurel de l’écosystème IA : la fragmentation des intégrations LLM-outil. Son protocole JSON-RPC 2.0 avec trois primitives (tools, resources, prompts) et deux transports (STDIO local, HTTP distant) crée un terrain commun sur lequel constructeurs d’outils et développeurs d’agents peuvent se rejoindre sans friction. L’adoption simultanée par Anthropic, OpenAI et Microsoft en moins d’un an confirme que l’industrie a trouvé son standard d’interopérabilité.

Ce que vous venez de lire est la couche conceptuelle. La série MCP-101 passe maintenant à la pratique. L’article 2 couvre l’écosystème des serveurs existants : 15 serveurs de référence, par domaine, avec les instructions d’installation dans Claude Desktop. L’article 3 présente les SDKs et frameworks disponibles pour écrire votre propre serveur. L’article 4 est entièrement consacré à la sécurité : tool poisoning, prompt injection, exfiltration silencieuse. Dès l’article 5, vous écrivez votre premier serveur STDIO en Python avec FastMCP et vous pourrez le tester dans Claude Code CLI.

 

Et enfin, pour suivre l’actualité de l’écosystème MCP entre les articles de cette série, notre revue de presse MCP et IA agentique couvre les principales évolutions hebdomadaires.