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

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.

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 :

1. D’abord, une phase de négociation où client et serveur annoncent leurs capacités.
2. Ensuite, le client demande la liste des outils disponibles.
3. Puis le modèle en sélectionne un et le client transmet l’appel au serveur.
4. 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.