Qu'est-ce que le Model Context Protocol (MCP) ?

Le protocole de contexte de modèle (MCP) a été développé pour relever un défi essentiel dans la conception d’applications d’IA agentiques : permettre aux grands modèles de langage (LLM) isolés d’interagir avec le monde extérieur. Si les grands modèles de langage (LLM) sont par nature de puissants moteurs de raisonnement, leurs connaissances restent figées, en raison de la date butoir de leur entraînement. Ils ne peuvent donc pas accéder à des données en temps réel ni exécuter des actions dans des systèmes externes.

Pour connecter les grands modèles de langage (LLM) à des systèmes externes, on a généralement recours à des intégrations API directes et sur mesure. Bien que cette approche soit efficace, elle exige de chaque développeur d’applications qu’il apprenne l’API spécifique de chaque outil, qu’il écrive du code pour gérer les requêtes et analyser les résultats, et qu’il assure la maintenance de cette connexion au fil du temps. La multiplication des applications d’IA et des outils disponibles crée une occasion de mettre en place une méthode plus standardisée et efficace.

MCP fournit ce protocole standardisé, inspiré de normes éprouvées telles que REST pour les services Web et le Language Server Protocol (LSP) pour les outils de développement. Le MCP a été créé pour établir un langage commun pour cette couche de connectivité. Ainsi, plus besoin d’obliger chaque développeur d’applications à devenir un expert de l’API de chaque outil.

Cette approche permet une séparation des préoccupations claire. Cela donne la possibilité aux plateformes et aux fournisseurs d’outils d’exposer leurs services via un serveur MCP unique et réutilisable, intrinsèquement compatible avec les grands modèles de langage. La responsabilité de la maintenance de l’intégration peut ainsi passer du développeur d’applications d’IA au propriétaire du système externe. Un écosystème robuste et interopérable se développe, ce qui permet à toute application conforme de se connecter à n'importe quel outil conforme. Le développement et la maintenance s'en trouvent ainsi grandement simplifiés.

Architecture MCP

MCP fonctionne selon un modèle client-serveur conçu pour connecter un moteur de raisonnement (le LLM) à un ensemble de fonctionnalités externes. L’architecture commence par le LLM et révèle progressivement les composants qui lui permettent d’interagir avec le monde extérieur.

Cette architecture comprend trois composants principaux :

1. Les hôtes sont des applications LLM qui souhaitent accéder aux données via MCP (par exemple, Claude Desktop, IDE, agents IA).
2. Les serveurs sont des programmes légers qui présentent chacun des fonctionnalités spécifiques via MCP.
3. Les clients assurent la maintenance de connexions individuelles avec les serveurs, à l'intérieur de l'application hôte.

Clients ou hôtes MCP

Les clients ou hôtes MCP sont les applications qui orchestrer l'interaction entre les LLM et un ou plusieurs serveurs MCP. Le client est essentiel ; il contient la logique spécifique à l'application. Alors que les serveurs fournissent les capacités brutes, le client est responsable de leur utilisation. Pour ce faire, elle utilise les fonctionnalités suivantes :

• Assemblage de l'invite : collecte de contexte à partir de divers serveurs pour construire l'invite finale et efficace pour le LLM
• Gestion de l'état : assurer la maintenance de l'historique des conversations et du contexte utilisateur lors de multiples interactions
• Orchestration : décider quels serveurs interroger pour quelles informations et exécuter la logique lorsqu'un LLM décide d'utiliser un outil

Les clients MCP se connectent aux serveurs via des requêtes réseau standard (généralement via HTTPS) vers un point de terminaison serveur connu. La soutenir du protocole est qu’il standardise le contrat de communication entre eux. Le protocole lui-même est indépendant du langage, avec un format basé sur JSON. Ainsi, tout client, quelle que soit la langue sur laquelle il est basé, peut communiquer correctement avec n'importe quel serveur.

Exemples de clients issus des spécifications du MCP

Serveurs MCP

Un serveur MCP est un programme back-end qui agit comme un wrapper standardisé pour une source de données ou un outil spécifique. Il met en œuvre la spécification MCP pour exposer des capacités, comme des outils exécutables ou des ressources de données, sur le réseau. En substance, il traduit le protocole unique d’un service spécifique (comme une requête de base de données ou une API REST tierce) dans le langage commun du MCP, le rendant ainsi compréhensible pour n’importe quel client MCP.

Exemples de serveurs issus des spécifications du MCP

Pratique : Comment pouvez-vous créer votre premier serveur MCP ?

Prenons l’exemple d’un serveur qui expose des outils (plus d’informations sur les outils ci-dessous). Ce serveur doit gérer deux requêtes principales émanant du client :

1. Installez le SDK.
   

   # Python
   pip install mcp
   
   # Node.js
   npm install @modelcontextprotocol /sdk
   
   # Ou explorez les spécifications
   git clone https://github.com/modelcontextprotocol/specification
   

2. Créez votre premier serveur.
   

   from mcp.server.fastmcp import FastMCP
   import asyncio
   
   mcp = FastMCP("weather-server")
   
   @mcp.tool()
   async def get_weather(city: str) -> str:
       """Get weather for a city."""
       return f"Weather in {city}: Sunny, 72°F"
   
   if __name__ == "__main__":
       mcp.run()
   
   
   

3. Connectez-vous à Claude Desktop.
   

   {
     "mcpServers": {
       "weather": {
         "command": "python",
         "args": ["/full/path/to/weather_server.py"],
         "env": {}
       }
     }
   }
   
   

SDK et ressources officiels

Vous pouvez commencer à créer vos propres clients et serveurs MCP à l'aide des SDK officiels et open source :

• SDK Python
• SDK TypeScript
• Spécification MCP officielle
• Implémentations de serveurs communautaires

Outils MCP

Un outil est une capacité spécifique et exécutable qu'un serveur MCP met à la disposition d'un client. Alors que les ressources de données sont passives (fichier, document, etc.), les outils représentent des actions que le LLM peut invoquer : envoyer un e-mail, créer un ticket de projet ou interroger une base de données en direct.

Les outils interagissent avec les serveurs de la manière suivante : un serveur MCP déclare les outils qu’il propose. Par exemple, un serveur Elastic exposerait un outil list_indices, en définissant son nom, son objectif et les paramètres requis (par ex. list_indices, get_mappings, get_shards et search).

Le client se connecte au serveur et découvre ces outils disponibles. Le client présente les outils disponibles au LLM dans le cadre de l'invite ou du contexte de son système. Lorsque la sortie du LLM indique une intention d’utiliser un outil, le client l’analyse et fait une demande formelle au serveur approprié pour exécuter cet outil avec les paramètres spécifiés.

Exemple de modèles d'outils de la spécification MCP

Pratique : implémentation d'un serveur MCP de bas niveau

Bien que cet exemple de bas niveau soit utile pour comprendre les mécanismes du protocole, la plupart des développeurs utiliseront un SDK officiel pour créer des serveurs. Les SDK gèrent les éléments standard du protocole, comme l'analyse des messages et le routage des requêtes, vous permettant de vous concentrer sur la logique noyau de vos outils.

L'exemple suivant utilise le SDK Python MCP officiel pour créer un serveur simple qui utilise un outil get_current_time. Cette approche est nettement plus concise et explicite que l'implémentation de bas niveau.

import asyncio
import datetime
from typing : AsyncIterator

from mcp.server import (
 MCPServer,
 Tool,
 tool,
)

# --- Implémentation de l'outil ---
# Le décorateur @tool du SDK gère l'enregistrement et la génération de schéma.
# Nous définissons une fonction asynchrone simple qui sera exposée comme un outil MCP.

@tool
async def get_current_time() -> AsyncIterator[str]:
 """
 Renvoie l'heure et la date UTC actuelles sous forme de chaîne ISO 8601.
    
    Cette docstring est automatiquement utilisée comme description de l'outil pour le LLM.
    """
 # Le SDK attend un itérateur asynchrone, nous produisons donc le résultat.
    yield datetime.datetime.now(datetime.timezone.utc).isoformat()


# --- Définition du serveur ---
# Nous créons une instance du serveur MCP en lui transmettant les outils que nous voulons exposer.
# Le SDK Discover automatiquement toutes les fonctions décorées avec @tool.

SERVER = MCPServer(
 tools=[
 # Le SDK détecte automatiquement notre fonction décorée.
        Tool.from_callable(get_current_time),
 ],
)


# --- Bloc d'exécution principal ---
# Le SDK fournit un point d'entrée principal pour exécuter le serveur.
# Ceci gère toute la logique de communication sous-jacente (stdio, HTTP, etc.).

async def main() -> None:
 """Exécute le serveur d’outils simple."""
    await SERVER.exécution()


if __name__ == "__main__":
 asyncio.run(main())

Cet exemple pratique montre à quel point il est puissant d'utiliser un SDK pour créer des serveurs MCP :

1. @tool Décorateur : ce décorateur enregistre automatiquement la fonction get_current_time en tant qu’outil MCP. Il inspecte la signature et la docstring de la fonction pour générer le schéma et la description nécessaires pour le protocole, ce qui vous évite de les écrire manuellement.
2. Instance MCPServer : la classe MCPServer est le noyau du SDK. Il vous suffit de lui fournir une liste des outils que vous souhaitez exposer, et il s’occupe du reste.
3. SERVER.exécution(): Cette commande unique démarre le serveur et gère toutes les communications de bas niveau, y compris la gestion des différents modes de transport comme stdio ou HTTP.

Comme vous pouvez le voir, le SDK fait abstraction de presque toute la complexité du protocole, vous permettant de définir des outils puissants avec seulement quelques lignes de code Python.

Le MCP normalise la façon dont un LLM interagit avec le monde extérieur en définissant trois primitives de base qu’un serveur peut exposer. Ces primitives fournissent un système complet qui permet de connecter les LLM à des fonctionnalités externes.

1. Ressources : fournir un contexte
   • Fonction : Accès aux données
   • Analogie : points de terminaison GET
   • Les ressources sont le principal mécanisme permettant de fournir du contexte à un LLM. Ils représentent des sources de données que le modèle peut récupérer et utiliser pour éclairer ses réponses, comme des documents, des enregistrements de base de données ou les résultats d'une requête de recherche. Il s’agit généralement d’opérations en lecture seule.
2. Outils : faciliter l'action
   • Fonction : actions et calcul
   • Analogie : points de terminaison POST ou PUT
   • Les outils sont des fonctions exécutables qui permettent à un LLM d’effectuer des actions et d’avoir un impact direct sur les systèmes externes. C'est ce qui permet à un agent d'aller au-delà de la simple récupération de données et d'effectuer des tâches telles que l'envoi d'un e-mail, la création d'un ticket de projet ou l'appel d'une API tierce.
3. Instructions : Guider l'interaction
   • Fonction: modèles d’interaction
   • Analogie : recettes de workflow
   • Les invites sont des modèles réutilisables qui guident l’interaction du LLM avec un utilisateur ou un système. Ils permettent aux développeurs de standardiser les flux conversationnels courants ou complexes, afin de garantir un comportement plus cohérent et plus fiable à partir du modèle.

Concepts noyau

Le MCP fournit un moyen standardisé aux applications LLM (hosts) pour s'intégrer à des données et des capacités externes (servers). La spécification se fonde sur le format de message JSON-RPC 2.0 et définit des composants obligatoires et facultatifs qui permettent des interactions riches et avec état.

Protocole et fonctionnalités noyau

Le cœur du MCP consiste à standardiser la couche de communication. Le protocole de base et la gestion du cycle de vie doivent être pris en charge par toutes les implémentations.

• Protocole de base : toutes les communications utilisent des messages JSON-RPC standard (demandes, réponses et notifications).
• Fonctionnalités des serveurs : Les serveurs peuvent offrir aux clients n'importe quelle combinaison des capacités suivantes :
  • Ressources : Données contextuelles que l'utilisateur ou le modèle peut consommer
  • Invitations : modèles de messages et flux de travail
  • Outils : fonctions exécutables que le LLM peut invoquer
• Fonctionnalités des clients : les clients peuvent proposer ces fonctionnalités aux serveurs pour des workflows bidirectionnels plus avancés :
  • Échantillonnage : permet à un serveur d'initier des comportements agentiques ou des interactions LLM récursives
  • Élicitation : Permet à un serveur de solliciter des informations supplémentaires auprès de l’utilisateur

Protocole de base MCP

Le MCP a été conçu sur une base obligatoire, à savoir un protocole de base et une gestion du cycle de vie. Toutes les communications entre les clients et les serveurs doivent respecter la spécification JSON-RPC 2.0, qui définit trois types de messages :

• Requêtes : envoyées pour lancer une opération. Pour des raisons de suivi, un id unique (chaîne ou entier) est nécessaire et ne doit pas être réutilisé au cours de la même session.
• Réponses : envoyées en réponse à une demande. Elles doivent contenir l'ID de la requête d'origine et un objet result pour les opérations réussies ou un objet error pour les échecs.
• Notifications : messages unidirectionnels envoyés sans identifiant et ne nécessitant pas de réponse de la part du destinataire.

Fonctionnalités client : activation de workflows avancés

Pour une communication bidirectionnelle plus complexe, les clients peuvent également proposer des fonctionnalités aux serveurs :

• Échantillonnage : l'échantillonnage permet à un serveur de demander une inférence au LLM via le client. Cette fonctionnalité est un atout puissant pour les flux de travail d’agents en plusieurs étapes. Un outil peut alors « renvoyer une question » au grand modèle de langage afin d’obtenir plus d’informations avant de terminer sa tâche.
• Élicitation : l'élicitation fournit un mécanisme formel permettant à un serveur de demander plus d'informations à l'utilisateur final. C’est un atout essentiel pour les outils interactifs susceptibles de demander une clarification ou une confirmation avant de lancer une action.

Fonctionnalités du serveur : exposition des capacités

C’est par le biais d’un ensemble de fonctionnalités standardisées que les serveurs exposent leurs capacités aux clients. Un serveur peut implémenter n’importe quelle combinaison des éléments suivants :

• Outils : les outils sont le principal mécanisme qui permet à un LLM d'effectuer des actions. Ce sont des fonctions exécutables qu'un serveur expose, qui permettent au LLM d'interagir avec des systèmes externes, par exemple en appelant une API tierce, en interrogeant une base de données ou en modifiant un fichier.
• Ressources : les ressources représentent les sources de données contextuelles qu'un LLM peut récupérer. Contrairement aux outils, qui exécutent des actions, les ressources servent principalement à récupérer des données en lecture seule. Ce mécanisme sert à ancrer un grand modèle de langage dans des informations externes en temps réel, et forme un élément clé des pipelines RAG avancés.
• Invites : les serveurs peuvent exposer des modèles d'invites prédéfinis que le client peut utiliser. Cette approche permet de standardiser et de partager des invites courantes, complexes ou hautement optimisées, ce qui assure la cohérence des interactions.

Security et confiance

La spécification met fortement l'accent sur la sécurité et définit les principes clés que les implémenteurs doivent suivre. Le protocole lui-même ne peut pas faire respecter ces règles ; la responsabilité incombe au développeur de l’application.

• Consentement et contrôle de l'utilisateur : les utilisateurs doivent explicitement consentir à l'accès à toutes les données et à l'utilisation de tous les outils, et en conserver le contrôle. Des interfaces utilisateur claires pour l’autorisation sont essentielles.
• Confidentialité des données : les hébergeurs ne doivent pas transmettre de données utilisateur à un serveur sans consentement explicite et doivent mettre en œuvre des contrôles d’accès appropriés.
• Sécurité des outils : l'invocation d'un outil représente l'exécution de code arbitraire et doit être traitée avec prudence. Les hôtes doivent obtenir le consentement explicite de l’utilisateur avant d’invoquer un outil.

Le principal atout du MCP est de standardiser la couche de communication et d'interaction entre les modèles et les outils. Cela crée un écosystème prévisible et fiable pour les développeurs. Les principaux domaines de normalisation comprennent :

• API de connecteur uniforme : une interface unique et cohérente pour connecter n'importe quel service externe
• Contexte normalisé : format de message universel pour transmettre des informations critiques telles que l'historique des sessions, les intégrations, les sorties des outils et la mémoire à long terme
• Protocole d’appel d’outil : modèles de demande et de réponse convenus pour l’appel d’outils externes, garantissant la prévisibilité
• Contrôle du flux de données : règles intégrées pour le filtrage, la hiérarchisation, le streaming et le contexte de traitement par lots afin d'optimiser la rapidité de construction
• Modèles de sécurité et d’authentification : points d’ancrage communs pour l’authentification par clé API ou OAuth, la limitation du débit et le chiffrement afin de sécuriser l’échange de données
• Règles de cycle de vie et de routage : conventions qui définissent quand récupérer le contexte, combien de temps le mettre en cache et comment acheminer les données entre les systèmes
• Métadonnées et observabilité : champs de métadonnées unifiés qui permettent une journalisation, des mesures et un traçage distribué cohérents sur tous les modèles et outils connectés
• Points d’extension : crochets définis pour ajouter une logique personnalisée, telle que des étapes de pré- et post-traitement, des règles de validation personnalisées et l’enregistrement de plug-ins

À grande échelle : résoudre le problème de l’intégration « M×N » ou le cauchemar de la montée en charge multiplicative

Dans un paysage de l’IA en pleine expansion, les développeurs font face à un défi d'intégration de taille. Les applications d’IA (M) doivent accéder à une multitude de sources de données et d'outils externes (N), tels que des bases de données, des moteurs de recherche, des API et des dépôts de code. En l’absence de protocole standardisé, les développeurs doivent résoudre le « problème M×N » et bâtir et maintenir une intégration unique et personnalisée pour chaque paire application-source.

Cette approche entraîne plusieurs problèmes critiques :

• Des efforts redondants pour les développeurs : les équipes résolvent à plusieurs reprises les mêmes problèmes d'intégration pour chaque nouvelle application d'IA, ce qui fait perdre un temps et des ressources précieux.
• Complexité écrasante : différentes sources de données gèrent des fonctions similaires de manière unique, créant ainsi une couche d'intégration complexe et incohérente.
• Maintenance excessive : l'absence de standardisation entraîne la fragilité de l'écosystème d'intégrations personnalisées. Une mise à jour ou une modification mineure de l'API d'un seul outil peut interrompre les connexions, ce qui nécessite une maintenance constante et réactive.

Le MCP résout le problème M×N en le transformant en une équation beaucoup plus simple, M+N. En établissant une norme universelle, les développeurs n’ont qu’à créer M clients (pour leurs applications) et N serveurs (pour leurs outils), ce qui réduit grandement la complexité et les coûts de maintenance.

MCP n’est pas une alternative aux modèles populaires comme Retrieval-Augmented Generation (RAG) ou aux frameworks comme LangChain ; c’est un protocole de connectivité fondamental qui les rend plus puissants, modulaires et plus faciles à maintenir. Il résout le problème universel de la connexion d’une application à un outil externe en standardisant le « dernier kilomètre » de l’intégration.

Voici comment MCP s'intègre dans la pile IA moderne :

Pour un RAG avancé et performant

Le RAG standard est puissant, mais il se connecte souvent à une base de données vectorielle statique. Pour les cas d’utilisation plus avancés, vous devez récupérer des informations dynamiques à partir de systèmes complexes en direct.

• Sans MCP : un développeur doit écrire du code personnalisé pour connecter son application RAG directement au langage de requête spécifique d'une API de recherche comme Elasticsearch.
• Avec MCP : le système de recherche expose ses capacités via un serveur MCP standard. L'application RAG peut désormais interroger cette source de données en direct à l'aide d'un client MCP simple et réutilisable, sans avoir besoin de connaître l'API spécifique du système sous-jacent. Cela rend l’implémentation RAG plus propre et plus facile à remplacer par d’autres sources de données à l’avenir.

Intégration à des frameworks agentiques (par exemple, LangChain, LangGraph)

Les frameworks agentiques constituent d'excellents outils pour créer une logique d'application, mais ils nécessitent tout de même un moyen de se connecter à des outils externes.

• Les alternatives :
  • Code personnalisé : rédiger une intégration directe en partant de zéro, ce qui nécessite des efforts d'ingénierie importants et une maintenance continue
  • Boîtes à outils spécifiques à un framework : utiliser un connecteur préconstruit ou écrire un wrapper personnalisé pour un framework spécifique (cela crée une dépendance à l’architecture de ce framework et vous enferme dans son écosystème).
• L'avantage du MCP : le MCP fournit une norme ouverte et universelle. Un fournisseur d’outils peut créer un seul serveur MCP pour son produit. Désormais, n’importe quel framework — LangChain, LangGraph ou une solution personnalisée — peut interagir avec ce serveur à l’aide d’un client MCP générique. Cette approche est plus efficace et empêche le blocage des fournisseurs.

Pourquoi un protocole simplifie tout

En fin de compte, la valeur du MCP est de proposer une alternative ouverte et normalisée aux deux extrêmes de l’intégration :

1. L'écriture de code personnalisé est fragile et entraîne des coûts de maintenance élevés.
2. L'utilisation de wrappers spécifiques à un framework crée un écosystème semi-fermé et une dépendance vis-à-vis du fournisseur.

Le MCP transfère la propriété de l’intégration au propriétaire du système externe, ce qui lui permet de fournir un point de terminaison MCP unique et stable. Les développeurs d’applications peuvent alors se contenter de consommer ces points de terminaison, ce qui simplifie énormément la tâche de créer, d’adapter et de maintenir des applications d’IA performantes et contextuelles.

Comment implémenter un serveur Elasticsearch MCP

Elastic a mis au point un serveur MCP pour Elasticsearch qui vous permet de connecter facilement vos données à n’importe quel hôte compatible MCP. Grâce au serveur, vous pouvez accorder aux modèles l'accès aux indices de requêtes, inspecter les mappings et effectuer des recherches.

La configuration du serveur est très simple. Ce serveur MCP est fourni sous forme d'image Docker à docker.elastic.co/mcp/elasticsearch qui prend en charge les protocoles stdio, SSE et streamable-HTTP de MCP.

La configuration pour Claude Desktop est la suivante :

{
 "mcpServers": {
   "elasticsearch-mcp-server": {
    "command": "docker",
    "args": [
     "run", "-i", "--rm",
     "-e", "ES_URL", "-e", "ES_API_KEY",
     "docker.elastic.co/mcp/elasticsearch",
     "stdio"
    ],
    "env": {
      "ES_URL": "<elasticsearch-cluster-url>",
      "ES_API_KEY": "<elasticsearch-api-key>"
    }
   }
 }
}

Cette commande permet de démarrer le serveur MCP en mode stdio :

docker run -i --rm -e ES_URL -e ES_API_KEY docker.elastic.co/mcp/elasticsearch stdio

Suivez les étapes restantes dans notre dépôt GitHub.

Approfondissez vos connaissances sur la construction avec Elastic

Suivez l’actualité de l’IA et des applications de recherche intelligente. Explorez nos ressources pour en savoir plus sur la création avec Elastic.

• Les fonctions LLM avec Elasticsearch pour une transformation intelligente des requêtes
• Les agents IA et le SDK Elastic AI pour Python
• Protocole de contexte de modèle pour Elasticsearch

Commencez à créer dès maintenant avec l'atelier pratique gratuit "Présentation du MCP avec Elasticsearch MCP Server".