Le Model Context Protocol (MCP) est un standard ouvert qui connecte les modèles de langage à des outils et des sources de données de façon uniforme. Annoncé par Anthropic le 25 novembre 2024 et souvent décrit comme « un port USB-C pour l'IA », il transforme un modèle passif — qui ne sait que produire du texte — en agent capable d'agir : lire un fichier, interroger une base, appeler une API. Voici comment il fonctionne, et comment on construit ou consomme un serveur MCP.

Le problème : l'explosion combinatoire M×N

Avant MCP, chaque intégration LLM ⇄ outil était recodée pour chaque application : un travail combinatoire et fragile. Connecter M applications IA à N sources de données exigeait jusqu'à M × N connecteurs sur mesure.

MCP renverse la logique : chaque hôte parle MCP une fois, chaque service expose un serveur MCP une fois. On passe de M × N à M + N, et les intégrations deviennent réutilisables et interopérables entre hôtes (Claude, IDE, agents tiers). C'est exactement ce que LSP a fait pour les éditeurs de code : écrite une fois, l'intégration sert partout.

Architecture : hôte ↔ client ↔ serveur

MCP suit une architecture client-host-server, bâtie sur JSON-RPC 2.0 avec une session à état (phase d'initialisation, puis échanges).

Architecture MCP : un hôte pilote des clients qui dialoguent 1 avec des serveurs exposant outils, ressources et prompts. Schéma : architecture MCP (hôte ⇄ client ⇄ serveur).

  • Host : l'application IA (Claude Desktop, extension d'IDE, runtime d'agent). Il gère le contexte du LLM, crée les clients, applique les politiques de sécurité et de consentement, et coordonne le sampling.
  • Client : créé par l'hôte, en relation 1
    avec un serveur     ; il négocie les capacités et route les messages.
  • Server : expose des capacités focalisées via trois primitives. Il peut être local (sous-processus) ou distant (service HTTP).

Un principe de conception est central : un serveur ne voit jamais toute la conversation, ni les autres serveurs — l'isolement est garanti par l'hôte. À l'initialize, client et serveur déclarent ce qu'ils supportent (négociation de capacités).

Les trois primitives serveur

Chaque primitive a un « axe de contrôle » différent :

Primitive Contrôlée par Exemples
Tools le modèle (il décide quand appeler) lire un fichier, lancer une requête SQL, créer un ticket
Resources l'application (l'hôte/l'utilisateur choisit le contexte) documents, schémas, configuration
Prompts l'utilisateur (souvent via slash commands) gabarits réutilisables

Les outils se découvrent via tools/list et s'appellent via tools/call ; leur entrée est décrite en JSON Schema. Les ressources sont identifiées par URI (file://, https://, git://…), lues via resources/read, avec abonnement possible (resources/subscribe). Les prompts se récupèrent via prompts/get avec des arguments.

Côté client, des primitives complémentaires rendent les serveurs « responsables » : sampling (un serveur peut demander une complétion au LLM via le client, sans dépendre du modèle), roots (le client déclare les frontières d'accès, ex. répertoires) et elicitation (demander une information à l'utilisateur en cours d'exécution).

Un échange typique

Le client demande la liste des outils, le modèle en choisit un, le client l'appelle :

{ "jsonrpc": "2.0", "id": 1, "method": "tools/list" }

Le serveur répond avec le schéma de chaque outil ; le client expose ces schémas au LLM, qui produit un appel structuré que le serveur exécute, puis le résultat est réinjecté dans le contexte. Les bonnes implémentations gardent un humain dans la boucle : afficher les outils exposés et demander confirmation avant les actions sensibles.

Transports : stdio (local) et Streamable HTTP (distant)

MCP définit deux transports standard (les transports personnalisés sont permis) :

  • stdio : le client lance le serveur en sous-processus et échange des messages JSON-RPC délimités par des sauts de ligne sur stdin/stdout (stderr réservé aux logs). Idéal pour les outils locaux.
  • Streamable HTTP (révision 2025-03-26, remplace l'ancien HTTP+SSE) : un endpoint unique qui accepte POST et GET ; le serveur répond en JSON simple ou ouvre un flux SSE pour le streaming. En-têtes Mcp-Session-Id et MCP-Protocol-Version. Adapté au distant (multi-clients, identité, audit).

Sécurité du transport : valider l'en-tête Origin (anti DNS-rebinding), binder sur 127.0.0.1 en local, et authentifier toutes les connexions.

Construire un serveur (conceptuel)

Des SDK officiels existent en Python, TypeScript, C#, Java, Go, Rust, etc. En Python, avec FastMCP, exposer un outil tient en quelques lignes — le docstring devient la description, les annotations de type génèrent le schéma d'entrée :

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("meteo")

@mcp.tool()
def get_forecast(city: str) -> str:
    """Renvoie la météo du jour pour une ville."""
    return f"Ensoleillé à {city}, 24°C."

if __name__ == "__main__":
    mcp.run(transport="stdio")

On déclare ensuite la commande de lancement dans la configuration de l'hôte ; celui-ci démarre le sous-processus et découvre les capacités à l'initialize.

Sécurité : un nouveau modèle de menace

Donner des outils à un modèle ouvre une surface d'attaque inédite. À connaître :

  • Tool poisoning / prompt injection : un serveur malveillant peut cacher des instructions dans la description d'un outil pour détourner le modèle. Les clients doivent traiter les annotations d'outils comme non fiables hors serveur de confiance (une démonstration d'Invariant Labs a exfiltré un historique WhatsApp par ce biais).
  • Token passthrough : un serveur ne doit pas accepter de jetons qui n'ont pas été émis explicitement pour lui (cela contourne les contrôles et casse l'audit).
  • Confused deputy et session hijacking : exiger un consentement par client avant tout flux OAuth tiers, utiliser des identifiants de session non devinables et ne pas s'appuyer sur la session pour authentifier.
  • Compromission d'un serveur local : un serveur stdio s'exécute sur la machine — d'où le consentement explicite avant lancement et le sandboxing. La faille CVE-2025-6514 (RCE dans mcp-remote) rappelle le risque de chaîne d'approvisionnement.

Le fil conducteur : consentement et contrôle de l'utilisateur à chaque étape.

Écosystème et adoption en 2026

MCP est devenu un standard de fait. OpenAI l'a adopté (mars 2025, Agents SDK et ChatGPT desktop), suivi de Google DeepMind (Gemini) et Microsoft (Copilot, VS Code). Le support client est de première classe dans Claude, ChatGPT, Cursor, VS Code et JetBrains. La spécification a évolué de 2024-11-05 à 2025-11-25 (opérations asynchrones, identité serveur, registre officiel). En décembre 2025, Anthropic a confié MCP à l'Agentic AI Foundation sous l'égide de la Linux Foundation — gage de gouvernance ouverte.

MCP fait pour les outils IA ce que HTTP a fait pour le web : un protocole, de multiples implémentations. Pour un développeur, exposer une capacité revient à écrire un petit serveur ; la consommer, à pointer un hôte compatible — la sécurité devenant, elle, une responsabilité de premier plan.