En bref

Le Model Context Protocol (MCP) est un protocole ouvert qui standardise la connexion entre les modèles de langage et les outils ou données externes. Avant MCP, chaque intégration exigeait un développement spécifique. Avec MCP, un serveur écrit une fois fonctionne avec n’importe quel client compatible — Claude, GPT, Gemini. Lancé par Anthropic en novembre 2024, le protocole a été cédé à la Linux Foundation fin 2025 et compte aujourd’hui des adoptants chez la quasi-totalité des grands acteurs de l’IA.

Le problème avant MCP

Un modèle de langage, seul, ne peut pas lire un fichier local, interroger une base de données ou appeler une API. Il génère du texte — rien d’autre. Pour lui donner accès à des outils, les développeurs écrivaient des intégrations sur mesure : un connecteur GitHub ici, un accès PostgreSQL là, une couche Slack ailleurs.

Chaque intégration était spécifique à un modèle. Si l’équipe changeait de fournisseur d’IA, les connecteurs étaient à réécrire. Si un nouvel outil apparaissait, un nouveau connecteur était à construire. La fragmentation était structurelle.

La comparaison souvent citée est celle du Language Server Protocol (LSP), qui a résolu un problème analogue pour les IDE : avant LSP, chaque éditeur implémentait son propre support pour chaque langage de programmation. LSP a introduit une interface unique. MCP fait la même chose pour les LLM.

Architecture : trois entités, deux directions

MCP repose sur une architecture client-serveur avec trois composants.

Le MCP Client est l’application LLM : Claude Code, Cursor, VS Code Copilot, Replit. C’est lui qui initie les connexions et consomme les capacités exposées.

Le MCP Server est un processus indépendant qui expose des outils, des données ou des templates. Chaque serveur tourne séparément. Il peut donner accès à un dépôt Git, une base de données, une API SaaS, un système de fichiers.

Le Transport est le canal entre les deux. Deux mécanismes sont actifs dans la spec actuelle :

  • stdio : le client lance le serveur en sous-processus, les messages transitent par stdin/stdout. Utilisé pour les outils locaux, les plugins d’IDE.
  • Streamable HTTP : le serveur expose un endpoint HTTP unique supportant POST et GET, avec streaming optionnel. Standard pour les connexions distantes.

Un troisième mécanisme, SSE pur, a été déprécié en 2025 au profit de Streamable HTTP. La raison : deux endpoints distincts créaient des complications de déploiement que l’endpoint unique résout.

Le protocole de messages est JSON-RPC 2.0. Le schéma est défini d’abord en TypeScript, puis exposé en JSON Schema pour une compatibilité étendue.

Les six primitives

La spec MCP définit six types de capacités qu’un serveur peut exposer.

Tools : actions que le LLM peut déclencher — lire un fichier, appeler une API, exécuter une requête SQL. C’est la primitive la plus utilisée.

Resources : données exposées en lecture seule. Le serveur met à disposition un contenu (contenu d’un dépôt, schéma d’une base de données) que l’application contrôle quand et comment charger.

Prompts : templates de prompts paramétrables. Le serveur expose des structures de prompt réutilisables que le client peut instancier.

Sampling : mécanisme inverse — un serveur MCP délègue une inférence LLM au client. Utile dans les architectures multi-tenant où le serveur n’a pas accès direct au modèle.

Roots : délimite les périmètres d’accès autorisés. Par exemple, les répertoires de fichiers qu’un serveur est autorisé à lire. Opt-in explicite.

Elicitation : permet à un serveur de demander des informations supplémentaires à l’utilisateur via le client. Primitive récente, peu implémentée en pratique.

Les deux premières (Tools et Resources) couvrent l’essentiel des cas d’usage courants. Les quatre autres adressent des architectures plus avancées.

MCP contre function calling : deux niveaux différents

Une confusion revient régulièrement dans les discussions techniques : MCP serait juste du function calling rebrandé. La distinction mérite d’être posée clairement.

Le function calling est un mécanisme côté modèle : il transforme une intention exprimée en langage naturel en un appel de fonction structuré. Il reste spécifique au fournisseur — le format OpenAI et le format Anthropic ne sont pas identiques.

MCP opère à un niveau différent : il standardise l’exécution de ces appels et la découverte des outils disponibles. Un serveur MCP fonctionne sans modification avec Claude, GPT-4o ou Gemini. La logique d’intégration n’est écrite qu’une fois.

Les deux mécanismes sont complémentaires. Le function calling transforme le langage en appel structuré. MCP standardise ce que cet appel déclenche et comment le résultat remonte.

Écosystème : de quelques serveurs à des centaines

Anthropic a publié des serveurs officiels pour Google Drive, Slack, GitHub, Git, PostgreSQL et Puppeteer. Ce sont les implémentations de référence, disponibles sur modelcontextprotocol/servers.

La communauté a suivi rapidement. Des registres tiers — claudemcp.com, glama.ai, mcp.run — agrègent plusieurs centaines de serveurs couvrant des bases de données (Supabase, Neon), des cloud providers, des APIs SaaS, des outils de monitoring, des browsers headless.

Côté clients, le support MCP s’est diffusé dans les environnements de développement majeurs : Claude Code par fichier de configuration .claude/settings.json, Cursor nativement, VS Code Copilot depuis juin 2025, Zed, Replit, Codeium, Sourcegraph.

Une innovation technique notable : le MCP Tool Search (lazy loading). Au lieu d’injecter la définition de tous les outils disponibles dans chaque prompt, le client ne charge une définition que quand elle est nécessaire. Résultat mesuré : jusqu’à 95 % de réduction de consommation de contexte pour les environnements avec de nombreux serveurs actifs.

Adoption institutionnelle et gouvernance

La trajectoire d’adoption de MCP est inhabituelle pour un protocole technique. En mars 2025, quatre mois après son lancement, OpenAI l’intègre dans son Agents SDK, sa Responses API et ChatGPT Desktop. En avril 2025, Google DeepMind confirme le support dans Gemini.

En décembre 2025, Anthropic cède la gouvernance à l’Agentic AI Foundation (AAIF), un directed fund sous la Linux Foundation. Les co-fondateurs sont Anthropic, Block et OpenAI. AWS, Google, Microsoft, Cloudflare et Bloomberg figurent parmi les membres supporters.

En janvier 2026, le SDK Python et le SDK TypeScript totalisent 97 millions de téléchargements mensuels.

Ce rythme d’adoption s’explique en partie par le fait que le problème résolu — la fragmentation des intégrations — est structurel et partagé par tous les acteurs. MCP offre une solution qui bénéficie à l’ensemble de l’écosystème, y compris aux concurrents de son créateur.

Limites et problèmes ouverts

Sélection d’outil

Les LLM restent peu fiables pour choisir le bon outil parmi de nombreuses options. Multiplier les serveurs MCP aggrave ce problème en exposant de nombreuses définitions d’outils. Le lazy loading atténue l’effet sur le contexte, mais le problème fondamental de sélection n’est pas résolu dans la spec.

Sessions stateful

La spec actuelle implique des sessions avec état, ce qui complique le déploiement horizontal : load balancers et instances multiples nécessitent de synchroniser l’état de session. La feuille de route 2026 vise un protocole stateless avec sessions résumables. Cette évolution n’est pas finalisée.

Sécurité : surface d’attaque non maîtrisée

C’est le problème le plus sérieux. Plusieurs catégories de vulnérabilités sont documentées :

Le tool poisoning consiste à injecter des instructions malveillantes dans les métadonnées d’un outil — dans les champs de description, invisibles à l’utilisateur mais lus par le modèle. Le LLM exécute alors des actions non prévues. Ce vecteur est structurellement difficile à détecter.

Le path traversal affecte les serveurs donnant accès au système de fichiers : une implémentation incorrecte des Roots permet de lire des fichiers hors du répertoire autorisé.

En 2025, 492 serveurs MCP publiquement exposés sans authentification ont été recensés par des chercheurs en sécurité. Une CVE a été publiée (CVE-2025-6514) pour une exécution de code à distance via mcp-remote.

La source du problème structurel : la spec MCP ne définit pas de mécanisme d’authentification obligatoire entre client et serveur. Des approches ad hoc (OAuth, tokens Bearer en HTTP header) sont documentées par des tiers, mais il n’existe pas de standard normatif dans la spec actuelle. Microsoft a publié des recommandations contre l’injection indirecte, sans établir de standard de fait.

Note : un chiffre fréquemment cité dans les discussions — “43 % des implémentations testées vulnérables” — circule dans plusieurs articles mais sans référence identifiable à l’étude primaire. À traiter avec précaution.

Ce qu’il faut retenir

  • MCP résout un problème réel : la fragmentation des intégrations entre LLM et outils. Chaque intégration custom est remplacée par un serveur qui fonctionne avec tous les clients compatibles.
  • L’architecture est simple : client (l’app LLM), serveur (le connecteur), transport (stdio pour le local, HTTP pour le distant). Six primitives couvrent l’essentiel des besoins.
  • L’adoption est large et rapide : OpenAI, Google, Microsoft, AWS soutiennent le protocole. La gouvernance a été transférée à la Linux Foundation fin 2025.
  • Les limites sont réelles : sélection d’outil difficile à grande échelle, sessions stateful qui compliquent le déploiement, et surtout une surface d’attaque de sécurité non maîtrisée faute de standard d’authentification dans la spec.

Sources