Qu'est-ce que le MCP (Model Context Protocol) et comment il fonctionne

Tout assistant d'IA se heurte à la même limite : il connaît beaucoup de choses sur le monde jusqu'à la date de coupure de l'entraînement, mais il ne sait rien de vos fichiers, de votre base de données ou de l'API interne de votre entreprise. Le Model Context Protocol (MCP) est né pour combler exactement cette lacune. Depuis qu'Anthropic l'a lancé comme standard ouvert fin 2024, il est devenu, en pratique, une sorte d'USB-C pour connecter les modèles de langage à des outils et données externes.

Qu'est-ce que le MCP

Le Model Context Protocol est un protocole ouvert, basé sur JSON-RPC 2.0, qui définit une façon standardisée pour un modèle de langage (ou l'application qui l'héberge) de se connecter à des sources de données et outils externes. Au lieu que chaque assistant d'IA réinvente sa propre façon de lire un fichier, interroger une base de données ou déclencher une automatisation, le MCP offre une interface commune que tout serveur peut implémenter et tout client peut consommer.

En pratique, cela signifie que celui qui construit une intégration, par exemple un connecteur pour GitHub ou Google Drive, fait ce travail une seule fois, sous la forme d'un serveur MCP. Toute application compatible, comme Claude Desktop, Claude Code, un IDE ou un agent personnalisé, peut alors utiliser cette intégration sans écrire de code spécifique pour elle. Le protocole organise la communication en trois blocs : tools (actions que le modèle peut exécuter), resources (données que le modèle peut lire) et prompts (modèles d'instructions réutilisables), tous décrits dans un format que le modèle lui-même interprète à l'exécution.

Le problème que le MCP résout

Avant le MCP, connecter un LLM à un système externe signifiait généralement écrire une intégration sur mesure : un plugin par-ci, un function calling personnalisé par-là, un agent entouré de wrappers d'API spécifiques. Chaque application d'IA avait sa propre façon d'exposer des outils, et chaque outil devait être adapté à chaque application. Si une entreprise maintenait 5 outils internes et voulait qu'ils fonctionnent sur 3 assistants différents, le résultat était 15 intégrations séparées à maintenir, chacune avec son propre schéma d'authentification et format de requête.

C'est le problème classique de "M fois N" : M outils multipliés par N applications génèrent M×N ponts d'intégration. Le MCP aplatit cette équation à M+N. Chaque outil devient un serveur MCP, construit une seule fois ; chaque application devient un client MCP compatible, également construit une seule fois ; et toute combinaison entre les deux côtés fonctionne sans travail supplémentaire. C'est essentiellement le même raisonnement derrière le Language Server Protocol, créé des années plus tôt pour que les éditeurs de code cessent d'avoir besoin d'implémenter un support natif pour chaque langage de programmation séparément.

Architecture du protocole

Le MCP suit une architecture client-serveur avec trois rôles bien définis :

• Host : l'application que l'utilisateur final utilise directement, comme Claude Desktop, un IDE avec IA intégrée ou un agent personnalisé.
• Client MCP : un composant au sein du host qui maintient une connexion individuelle et isolée avec un serveur MCP spécifique.
• Serveur MCP : un processus séparé, local ou distant, qui expose tools, resources et prompts sur un système externe.

Un même host peut maintenir plusieurs clients MCP en même temps, chacun connecté à un serveur différent : un pour le système de fichiers, un autre pour Slack, un autre pour une base de données Postgres. Cette règle d'un client par serveur est délibérée, car elle garantit l'isolement. Une panne ou un blocage sur un serveur ne fait pas tomber la connexion avec les autres.

Le diagramme ci-dessous résume cette conception :

La communication entre client et serveur se fait par deux transports principaux. Pour les serveurs locaux, le standard est stdio, l'entrée et sortie standard du processus, simple et rapide car il ne nécessite pas de réseau. Pour les serveurs distants, le transport est HTTP avec Streamable HTTP, l'évolution de l'ancien transport basé sur Server-Sent Events, ce qui permet d'héberger un serveur MCP dans le cloud et de servir plusieurs clients en même temps.

Le client MCP

Le client vit à l'intérieur du host et s'occupe de trois choses : ouvrir et maintenir la connexion avec un serveur, traduire les décisions du modèle en messages JSON-RPC, et renvoyer les réponses du serveur dans le contexte de la conversation. En pratique, le client effectue également la poignée de main initiale, l'étape d'initialize où client et serveur échangent des informations de version du protocole et des capacités supportées, ainsi que le processus de découverte, où il demande au serveur quels tools, resources et prompts il offre.

Un détail peu évident est que le client ne décide pas seul quand utiliser un outil. Cette décision revient au modèle : le client fournit au LLM la liste des tools disponibles, formatée comme partie du contexte de la conversation, et c'est le modèle lui-même qui choisit, en fonction de ce que l'utilisateur a demandé, si et quel outil appeler. Le client n'exécute l'appel technique qu'après que le modèle a décidé.

Le serveur MCP

De l'autre côté, le serveur est celui qui sait vraiment interagir avec le système externe, que ce soit une base de données, une API tierce ou le système de fichiers local. Un serveur MCP bien construit expose ses capacités de manière auto-descriptive : chaque tool vient avec un nom, une description en langage naturel et un schéma, généralement JSON Schema, qui définit les paramètres qu'il accepte.

Cette auto-description est ce qui rend le MCP plug-and-play. Le serveur n'a pas besoin de savoir quel modèle va le consommer, et le client n'a besoin d'aucun code spécifique pour ce serveur autre que de parler le protocole. Aujourd'hui, il existe déjà des centaines de serveurs MCP publiés par des entreprises comme GitHub, Stripe, Cloudflare et Sentry, ainsi qu'un vaste écosystème de serveurs communautaires pour les bases de données, les outils de productivité et les services internes.

Les outils (tools) du MCP

Les tools sont le type de capacité le plus utilisé dans le MCP : des actions que le modèle peut exécuter et qui ont généralement un effet secondaire ou retournent un résultat calculé, comme consulter une prévision météo, créer une carte dans Trello ou exécuter une requête SQL. Le protocole définit deux autres types de capacités qui méritent d'être connus :

• Resources : des données que le serveur expose en lecture, comme le contenu d'un fichier, une ligne de base de données ou le résultat d'une requête. Contrairement aux tools, les resources n'ont généralement pas d'effet secondaire, ce sont simplement des éléments de contexte que le host peut joindre à la conversation.
• Prompts : des modèles d'instructions réutilisables que le serveur met à disposition, comme un script prêt à l'emploi pour réviser une pull request ou résumer un ticket de support, que l'utilisateur peut invoquer directement.

Chaque tool est décrit par un objet avec name, description et inputSchema. C'est cette description, écrite en langage naturel mais structurée, qui permet au modèle de comprendre ce que fait l'outil sans que personne n'ait à programmer de règles explicites sur quand l'utiliser.

Flux complet d'un appel MCP

Pour comprendre comment tout cela se connecte en pratique, suivons le cycle de vie d'un appel réel, tel qu'il circule entre client et serveur via JSON-RPC 2.0.

D'abord, lors de la connexion, le client demande quels outils le serveur propose :

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

Le serveur répond avec la liste complète, incluant déjà le schéma de chaque outil :

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "Retourne la prévision météo actuelle d'une ville",
        "inputSchema": {
          "type": "object",
          "properties": {
            "city": { "type": "string" }
          },
          "required": ["city"]
        }
      }
    ]
  }
}

Ce catalogue est remis au modèle comme partie du contexte disponible. Lorsque l'utilisateur fait une demande que le modèle interprète comme nécessitant l'outil get_weather, le client construit et envoie un appel tools/call :

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "city": "São Paulo" }
  }
}

Le serveur exécute la logique réelle derrière l'outil, dans ce cas probablement un appel à une API météo réelle, et renvoie le résultat dans le même format JSON-RPC :

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      { "type": "text", "text": "23°C, ciel dégagé à São Paulo" }
    ]
  }
}

Le client injecte ce résultat dans la conversation, et le modèle utilise l'information pour formuler la réponse finale à l'utilisateur. Du point de vue de la personne qui discute avec l'assistant, tout cela se produit de manière transparente : on ne voit que la question et la réponse, sans savoir qu'en coulisses, il y a eu toute une négociation de protocole.

MCP vs API traditionnelle

Il est courant de se demander : si tout outil externe a déjà une API REST, pourquoi ne pas utiliser cette API directement ? La réponse réside dans la différence entre intégrer un système pour qu'un développeur humain lise la documentation et intégrer un système pour qu'un modèle le découvre et l'utilise tout seul, en temps réel.

Aspect	API REST traditionnelle	MCP
Découverte des capacités	Documentation externe (Swagger/OpenAPI), lue par un humain	Le client interroge le serveur en temps réel sur les tools existants (tools/list)
Intégration par système	Un connecteur dédié pour chaque API	Un seul protocole standard pour tout serveur MCP
Format de communication	HTTP + JSON, schéma varie par fournisseur	JSON-RPC 2.0 standardisé
Contexte pour le modèle	Le développeur décide manuellement ce qui est exposé au LLM	Le serveur décrit les tools de manière à ce que le modèle décide lui-même quoi utiliser
Transport	Presque toujours HTTP	stdio (local) ou HTTP avec Streamable HTTP (distant)
Réutilisation entre apps d'IA	Faible, chaque app réimplémente l'intégration	Élevée, tout hôte compatible utilise le même serveur

En pratique, le MCP ne remplace pas l'API REST derrière le serveur, c'est une couche de standardisation par-dessus. Un serveur MCP pour GitHub, par exemple, appelle probablement l'API REST de GitHub en interne. La différence est que le modèle n'a jamais besoin de le savoir : il ne voit que des tools avec des noms et schémas cohérents, peu importe l'API sous-jacente.

Exemple pratique : un serveur MCP simple

Pour concrétiser le protocole, un serveur MCP minimal en Python, utilisant le SDK officiel avec la classe FastMCP, tient en quelques lignes :

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("clima-server")
@mcp.tool()
def get_weather(city: str) -> str:
    """Retourne la prévision météo actuelle d'une ville."""
    # l'appel réel à une API météo irait ici
    return f"23°C, ciel dégagé à {city}"
if name == "main":
    mcp.run(transport="stdio")

Ce serveur expose un seul outil nommé get_weather. Le décorateur @mcp.tool() se charge de générer le schéma JSON à partir de la signature de la fonction et du docstring, il n'est donc pas nécessaire d'écrire le JSON Schema à la main. En exécutant ce script, il écoute via stdio, prêt à ce que tout client MCP, comme Claude Desktop configuré localement, se connecte et découvre l'outil automatiquement.

Cet exemple est délibérément simple, mais le même modèle s'applique à des serveurs plus complexes : la logique métier (interroger une base de données, appeler une API payante, déclencher une automatisation) entre dans le corps de la fonction, et le SDK s'occupe de toute la partie protocole, poignée de main et sérialisation.

Sécurité dans le MCP

Donner à un modèle de langage un accès direct à des outils qui lisent des fichiers, écrivent dans des bases de données ou appellent des API tierces soulève une question évidente : qui garantit que cela ne dérape pas ? Le protocole définit quelques garde-fous, mais la responsabilité finale est partagée entre le serveur, le client et celui qui configure le système.

Au niveau du serveur, la bonne pratique est d'appliquer le principe du moindre privilège : un serveur MCP pour le système de fichiers, par exemple, doit restreindre l'accès à des répertoires spécifiques, jamais au disque entier. Les serveurs distants utilisant le transport HTTP exigent généralement une authentification via OAuth 2.1, et la spécification du protocole traite cela avec beaucoup de détails, précisément parce que les serveurs mal configurés sont le vecteur d'attaque le plus évident.

Au niveau du client et du host, la couche de sécurité la plus visible pour l'utilisateur final est le consentement humain : des hôtes comme Claude Desktop demandent une confirmation avant d'exécuter des tools sensibles, comme écrire un fichier ou envoyer un message, surtout la première fois qu'un outil est utilisé. Il existe également le risque d'injection de prompt via les resources, lorsqu'un contenu malveillant intégré dans un document que le modèle lit tente de manipuler le modèle lui-même pour exécuter une action inappropriée. Les serveurs qui exposent du contenu provenant de sources non fiables, comme des pages web ou des e-mails reçus, méritent une attention redoublée de la part de ceux qui construisent le serveur et de ceux qui décident de le connecter à un agent avec des permissions étendues.

Limites du MCP

Le MCP résout le problème de standardisation, mais ce n'est pas une solution miracle pour tout. Il vaut la peine de connaître les limites réelles avant de décider de construire dessus.

Premièrement, le protocole est encore relativement nouveau, lancé fin 2024, et l'écosystème, bien qu'il croisse rapidement, a encore des lacunes : tous les outils populaires n'ont pas encore un serveur MCP mature et maintenu officiellement. Deuxièmement, plus de tools disponibles en même temps signifie plus de tokens dépensés pour décrire ces tools dans le contexte de la conversation, ce qui peut renchérir les appels et, dans des cas extrêmes, disputer l'espace de contexte avec le reste de la conversation. Troisièmement, le protocole ne résout pas à lui seul le problème de fiabilité du modèle : il peut toujours choisir le mauvais outil, monter des arguments incorrects ou mal interpréter un résultat retourné par le serveur, donc l'orchestration minutieuse reste le travail de celui qui construit l'agent.

Enfin, l'authentification et la gouvernance d'accès dans les environnements d'entreprise, c'est-à-dire qui peut connecter quel serveur, avec quelles permissions, audité de quelle manière, est encore un espace en maturation, avec beaucoup de travail en cours dans la communauté et les entreprises qui adoptent le protocole en production.

FAQ

Le MCP est-il exclusif à Anthropic et Claude ?

Non. Le MCP est un protocole ouvert, avec une spécification publique, et d'autres entreprises d'IA et frameworks d'agents ont déjà annoncé leur support, bien qu'il soit né chez Anthropic.

Faut-il savoir programmer pour utiliser un serveur MCP ?

Pour utiliser un serveur déjà prêt, comme celui d'accès aux fichiers ou à Google Drive, dans une application comme Claude Desktop, non. La programmation n'est nécessaire que pour ceux qui veulent construire un nouveau serveur à partir de zéro.

Le MCP remplace-t-il le function calling ?

Pas exactement. Le function calling est la capacité du modèle à choisir et formater un appel d'outil. Le MCP utilise cette capacité en dessous, mais ajoute la couche de découverte, de standardisation et de transport entre client et serveur que le function calling seul ne définit pas.

Un serveur MCP peut-il fonctionner dans le cloud ?

Oui. Les serveurs distants utilisent le transport HTTP et peuvent être hébergés normalement, servant plusieurs clients en même temps, avec authentification via OAuth.

Le véritable gain du MCP n'est pas technique dans le sens d'"une API de plus", c'est organisationnel : il transforme un problème qui croissait de manière multiplicative, chaque outil pour chaque application, en un problème qui croît de manière additive. Pour ceux qui construisent des agents d'IA aujourd'hui, comprendre ce protocole a cessé d'être facultatif. Il est déjà la pièce d'infrastructure la plus proche d'un standard de fait pour connecter les modèles à tout ce qui existe en dehors du modèle lui-même.