En bref. Model Context Protocol (MCP) est un protocole ouvert permettant aux applications d’IA d’accéder à des données externes et à des outils qu’elles peuvent appeler, par l’intermédiaire de serveurs.

Définition : Model Context Protocol (MCP) est un protocole ouvert qui normalise la manière dont les applications d’IA accèdent au contexte et aux outils de systèmes externes. Un serveur MCP fournit des données ou des fonctions qu’un client intégré à une application d’IA peut appeler.

Points clés

La spécification du 28 juillet 2026 définit une communication par messages JSON-RPC 2.0, un format structuré pour les requêtes et les réponses.
La présentation de l’architecture du projet MCP distingue l’application hôte, ses clients et les serveurs qui fournissent le contexte.
La spécification des ressources associe à chaque ressource une URI, un identifiant utilisé pour demander son contenu.
La spécification des outils définit tools/list pour lister les fonctions disponibles et tools/call pour en appeler une.

Comment les échanges fonctionnent-ils ?

La présentation de l’architecture décrit une organisation client-serveur. L’hôte coordonne les clients ; chaque client communique avec un serveur. Un serveur est un programme qui fournit du contexte, qu’il s’exécute localement ou à distance.

Le mécanisme de communication est appelé transport. Les entrées et sorties standard, ou stdio, acheminent les messages entre des processus locaux sur une même machine. Streamable HTTP transmet les messages du client par des requêtes HTTP POST et prend en charge la transmission en continu au moyen de Server-Sent Events.

Dans cette révision, les requêtes sont autonomes. Chacune contient la version du protocole et les informations sur les capacités dans un champ _meta, ce qui permet au serveur de la traiter indépendamment. La documentation de l’architecture laisse à l’application le choix de la manière d’utiliser les modèles de langage et de gérer le contexte fourni.

Que peut exposer un serveur ?

La spécification définit les ressources comme des données contextuelles, les prompts comme des modèles de messages ou de flux de travail, et les outils comme des fonctions exécutables. Le guide d’architecture donne un exemple de base de données : un serveur peut proposer un outil de requête, une ressource contenant le schéma de la base et un prompt comportant des exemples d’utilisation des outils.

La documentation des outils prend pour exemple une fonction météo. Cette définition abrégée conserve son nom, sa description et son schéma d’entrée, qui décrit les paramètres acceptés :

{
  "name": "get_weather",
  "description": "Get current weather information for a location",
  "inputSchema": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "City name or zip code"
      }
    },
    "required": ["location"]
  }
}

Ici, location est un paramètre textuel obligatoire. Un client liste les outils pour obtenir leurs définitions, puis appelle la fonction choisie par son nom, en lui transmettant ses arguments. Pour un responsable de site web qui envisage une intégration, ces définitions rendent les choix de mise en œuvre concrets : quelles données exposer et quelles opérations rendre accessibles par un appel.

Qu’est-ce qui contrôle l’accès aux données et aux actions ?

Les principes de sécurité de la spécification imposent le consentement explicite de l’utilisateur pour l’accès aux données et les opérations. Les hôtes doivent obtenir ce consentement avant d’exposer des données utilisateur aux serveurs ou d’appeler des outils. Le même document considère les descriptions du comportement des outils comme non fiables, sauf si elles proviennent d’un serveur de confiance.

La spécification des ressources impose aux serveurs de valider les URI des ressources et recommande des contrôles d’accès pour les ressources sensibles. Elle exige aussi l’assainissement des chemins de fichiers lors de la mise à disposition de ressources du système de fichiers, afin d’empêcher la traversée de répertoires, qui consiste à tenter d’atteindre, par un chemin, des fichiers situés hors de l’emplacement autorisé.

Termes associés

Questions fréquentes

Avez-vous besoin de MCP pour qu’un site apparaisse dans les fonctionnalités d’IA de Google ?

En octobre 2026, la documentation de Google sur les fonctionnalités d’IA indique qu’AI Overviews et AI Mode n’imposent aucune exigence technique supplémentaire. Votre page doit être indexée et admissible à l’affichage dans Google Search avec un extrait.

Comment pouvez-vous lire une ressource exposée par MCP ?

La spécification des ressources définit resources/list pour lister les ressources disponibles et resources/read pour récupérer leur contenu à partir de leur URI. Votre application détermine comment ce contenu entre dans le contexte du modèle, notamment par sélection explicite de l’utilisateur ou par inclusion automatique.

Sources

Vérifiez comment une page se lit pour les moteurs de réponse. Ouvrir l’analyseur de score GEO