MCP : le protocole qui connecte les modèles IA aux outils

Le MCP (Model Context Protocol) est un protocole ouvert qui standardise la manière dont un modèle de langage accède à des données et à des outils externes. Plutôt que de multiplier des intégrations propriétaires entre chaque modèle et chaque service, il définit une interface commune : un client MCP (généralement l’application qui héberge le modèle) dialogue avec un ou plusieurs serveurs MCP qui exposent des ressources, des outils et des invites réutilisables.

→ Lire l’explication complète de la marmotte

Rôle du MCP dans une architecture d’agents

Un agent IA (Intelligence Artificielle) enchaîne des raisonnements et des actions concrètes : lire un fichier, interroger une base, appeler une API (Application Programming Interface). Le MCP fournit la couche de transport et de description qui rend ces capacités découvrables. Le modèle reçoit la liste des outils disponibles, leurs paramètres et leur documentation, puis décide lesquels invoquer. Cette approche s’articule directement avec les mécanismes décrits dans la page MCP et outils et avec la logique des agents.

Le protocole distingue trois primitives principales :

Ressources : données lisibles exposées par le serveur (documents, enregistrements, résultats de requête).
Outils (tools) : fonctions exécutables que le modèle peut appeler avec des arguments typés.
Invites (prompts) : gabarits de messages paramétrables, réutilisables par le client.

Client, serveur et transport

L’architecture repose sur un modèle client-serveur. Le client MCP est intégré à l’hôte du modèle ; le serveur MCP expose les capacités d’un domaine précis (système de fichiers, base de données, moteur de recherche). Les échanges utilisent JSON-RPC (JSON Remote Procedure Call), un format d’appel de procédure distante fondé sur JSON. Le transport se fait le plus souvent via l’entrée/sortie standard (stdio) pour un serveur local, ou via HTTP (HyperText Transfer Protocol) avec flux d’événements pour un serveur distant.

Le déroulement typique d’une session suit une progression précise :

D’abord, une phase de négociation où client et serveur annoncent leurs capacités.
Ensuite, le client demande la liste des outils disponibles.
Puis le modèle en sélectionne un et le client transmet l’appel au serveur.
Enfin, le serveur renvoie un résultat structuré, que le client peut vérifier avant de le transmettre au modèle.

Autorisation et sécurité

L’accès à un serveur MCP distant s’appuie sur OAuth 2.1. Le cadre d’autorisation, déjà présent dans la révision de mars 2025 (2025-03-26) de la spécification, a été durci par celle de juin 2025 (2025-06-18) : les serveurs MCP y sont classés comme resource servers OAuth, et l’emploi des Resource Indicators (RFC 8707) devient obligatoire. Chaque jeton d’accès est ainsi lié à un serveur cible précis, ce qui empêche sa réutilisation abusive vers un autre serveur.

Exemple de configuration d’un serveur MCP

La configuration côté client déclare les serveurs à lancer. Voici un extrait au format JSON déclarant deux serveurs, l’un pour le système de fichiers, l’autre pour une base PostgreSQL :

{
  "mcpServers": {
    "fichiers": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/data/documents"]
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "postgresql://lecture:motdepasse@localhost:5432/corpus"
      }
    }
  }
}

Dans cet exemple, le serveur de fichiers ne rend accessible que le répertoire /data/documents, et le serveur PostgreSQL utilise un compte en lecture seule. Ces restrictions limitent la surface exposée au modèle.

MCP et Retrieval-Augmented Generation

Le MCP se combine naturellement avec la Retrieval-Augmented Generation (RAG). Un serveur MCP peut exposer un outil de recherche sémantique qui interroge une base vectorielle et renvoie les passages pertinents au modèle. La différence de responsabilité est nette : le RAG décrit la stratégie d’enrichissement du contexte, tandis que le MCP fournit le canal standardisé pour appeler cet enrichissement. Les notions associées sont détaillées dans les pages RAG et RAG (IA locale).

Points de vigilance

Périmètre des outils : chaque serveur MCP élargit ce qu’un modèle peut lire ou modifier. Restreindre les chemins, les tables et les droits d’accès est indispensable pour éviter les fuites ou les actions non désirées.
Validation des arguments : le serveur doit valider les paramètres reçus, un modèle pouvant produire des appels malformés ou dangereux.
Supervision humaine : pour les outils qui écrivent ou déclenchent des effets de bord, une confirmation explicite reste recommandée, comme le rappelle la page supervision.
Journalisation : conserver la trace des appels d’outils facilite l’audit et le diagnostic ; ce besoin rejoint les principes d’observabilité.

FAQ

Le MCP dépend-il d’un fournisseur de modèle précis ?

Non. Le MCP est un protocole ouvert, indépendant d’un modèle ou d’un éditeur donné. Tout client conforme peut dialoguer avec tout serveur conforme, ce qui permet de réutiliser un même serveur d’outils avec des modèles différents, y compris des modèles locaux servis via Ollama.

Quelle différence entre un outil MCP et un appel d’API classique ?

Un appel d’API classique suppose une intégration codée spécifiquement pour chaque service. Un outil MCP est décrit de façon standardisée (nom, description, schéma des paramètres) et découvert dynamiquement par le modèle, ce qui réduit le couplage entre le modèle et les services qu’il utilise.

Un serveur MCP peut-il fonctionner entièrement en local ?

Oui. Avec un transport via l’entrée/sortie standard, un serveur MCP s’exécute comme un processus local et n’expose aucun port réseau, ce qui convient à une architecture privilégiant le traitement local des données.

🐝 Ce qui arrive si on s’en passe

Sans ces garde-fous, le modèle hérite de tout ce que le processus du serveur peut atteindre : un serveur de fichiers pointé sur un répertoire trop large lui ouvre clés, fichiers de configuration et historiques, et une base exposée avec un compte en écriture devient modifiable par une simple consigne mal comprise. Sans journal des appels d’outils, une modification déclenchée par le modèle reste indiscernable d’une action de l’utilisateur ; l’audit constate le résultat sans pouvoir reconstituer quel outil, avec quels arguments, l’a produit. La configuration elle-même mérite surveillance : les identifiants de base de données y figurent volontiers en clair, lisibles par quiconque accède au fichier.

🦫 Explication de la marmotte 🍫

Un modèle de langage est un programme qui produit du texte ; seul, il ne peut ni lire un fichier ni interroger une base de données. Le MCP, pour protocole de contexte de modèle, fixe une manière commune de lui donner accès à ces ressources. D’un côté se trouve le client, intégré à l’application qui fait tourner le modèle. De l’autre se trouvent des serveurs, chacun spécialisé dans un domaine : fichiers, base de données, moteur de recherche. Un serveur propose trois sortes d’éléments : des ressources à lire, des outils à exécuter avec des paramètres précis, et des modèles de messages réutilisables. La session suit un ordre fixe. Client et serveur annoncent d’abord ce qu’ils savent faire. Le client demande ensuite la liste des outils, avec leur description, et la transmet au modèle. Le modèle choisit un outil ; le client envoie l’appel au serveur, qui renvoie un résultat que le client peut vérifier avant de le remettre au modèle. Un serveur local échange directement avec le programme client, sans ouvrir d’accès réseau. Un serveur distant passe par le web et exige une autorisation, avec un jeton d’accès valable pour ce seul serveur. Le risque vient de ce qu’on connecte : chaque serveur étend ce que le modèle peut lire ou modifier. Il faut donc limiter les dossiers et les droits, contrôler les paramètres reçus, demander une confirmation humaine avant toute modification et garder la trace des appels.