MCP (Model Context Protocol) : explication simple, serveurs, clients, outils et ressources

Le Model Context Protocol (MCP) est un standard ouvert qui permet à un assistant IA d'utiliser des outils et des données externes par une seule interface commune, au lieu d'une intégration spécifique pour chaque application. Un serveur MCP expose des capacités (outils, ressources, modèles de prompts) ; le client MCP intégré à Claude, Cursor, ChatGPT ou un autre assistant les découvre et les appelle quand une question le demande. Pour une entreprise, cela veut dire qu'une base de connaissances ou un logiciel métier se branche une fois, puis sert dans tous les assistants compatibles.

Le MCP, c'est quoi exactement ?

Un modèle de langage raisonne très bien sur du texte, mais il ne voit ni votre intranet, ni votre ERP, ni la dernière mise à jour du Code du travail. Pendant longtemps, chaque éditeur d'assistant a proposé son propre système d'extensions : un éditeur de logiciel qui voulait être présent dans trois assistants devait développer et maintenir trois connecteurs. C'est le problème classique « N fois M » : N assistants multipliés par M sources de données.

Le MCP remplace tout cela par un contrat unique. Publié sous forme de spécification ouverte fin 2024, il est documenté sur modelcontextprotocol.io. On le compare souvent à une prise USB-C pour l'IA : l'assistant dispose d'une seule prise, et tout ce qui parle le protocole peut s'y brancher. Vous développez un serveur MCP une fois, il fonctionne avec tous les clients compatibles.

Techniquement, les échanges sont des messages JSON-RPC 2.0 : le client envoie un nom de méthode et des paramètres, le serveur renvoie un résultat ou une erreur. L'apport du MCP est un vocabulaire partagé (lister les outils, les appeler, lire des ressources) et une poignée de main initiale où chacun annonce ce qu'il sait faire.

Hôte, client, serveur : l'architecture du MCP

La spécification distingue trois rôles. Une fois qu'on les a en tête, tous les tutoriels deviennent plus clairs.

• L'hôte : l'application dans laquelle travaille l'utilisateur, par exemple une application de chat, un éditeur de code comme Cursor ou un agent en ligne de commande. C'est lui qui pilote le modèle, la conversation et les demandes d'autorisation.
• Le client : un connecteur interne à l'hôte, qui maintient une connexion avec un seul serveur. Un hôte relié à cinq serveurs fait donc tourner cinq clients.
• Le serveur : le programme qui expose des capacités. Il peut tourner en local sur votre poste (fichiers, dépôt git) ou à distance comme un service web (logiciel SaaS, base documentaire, API interne).

Transport local ou distant

Le protocole prévoit deux transports standard. Avec stdio, l'hôte lance le serveur comme un sous-processus et dialogue avec lui par l'entrée et la sortie standard : c'est la solution des outils locaux. Avec Streamable HTTP, le serveur est une adresse web appelée en HTTPS, le plus souvent avec une clé API ou un jeton OAuth dans les en-têtes. Ce second mode est celui qui intéresse les équipes : pour ajouter un serveur, il suffit d'une URL et d'une clé, sans rien installer sur chaque poste.

Le déroulé d'une session

1. Initialisation : le client se connecte, les deux parties échangent leur version du protocole et leurs capacités.
2. Découverte : le client demande la liste des outils, chacun décrit par un nom, une description et un schéma JSON de ses paramètres.
3. Décision : face à la demande de l'utilisateur, le modèle lit ces descriptions et juge si un outil peut l'aider.
4. Appel : le client transmet l'appel avec ses arguments, le serveur l'exécute et renvoie un contenu, en général du texte.
5. Réponse : le modèle s'appuie sur ce résultat pour rédiger sa réponse, idéalement en citant la source.

Outils, ressources et prompts : ce qu'expose un serveur MCP

Un serveur peut proposer trois types de capacités. Leur principale différence tient à qui décide de les utiliser.

Le protocole permet aussi au client d'offrir des services au serveur, par exemple demander une précision à l'utilisateur. Mais dans la pratique, ce sont les outils qui portent l'essentiel des usages : ils permettent au modèle d'aller chercher l'information de lui-même, pendant que l'hôte garde la main sur les validations.

Comment Claude, Cursor ou ChatGPT interrogent une base de connaissances via MCP

Un assistant généraliste ignore vos procédures internes, vos tarifs du trimestre ou le détail d'un régime fiscal récemment modifié. C'est précisément ce que comble le RAG (génération augmentée par récupération) : chercher d'abord les bons passages dans des documents fiables, puis répondre à partir d'eux. Le MCP est la façon la plus simple de mettre une base RAG à disposition des assistants que vos équipes utilisent déjà.

Prenons Kopik comme exemple concret. Son serveur MCP, à l'adresse https://kopik.io/api/mcp, utilise le transport Streamable HTTP et expose trois outils : list_bases (gratuit, liste les bases publiques, avec un filtre facultatif par thème ou par mots), ask_base (renvoie une réponse rédigée et les passages sources numérotés) et search_base (renvoie seulement les passages, au même prix, pour les agents qui préfèrent raisonner eux-mêmes). Voici un échange typique :

1. Dans Cursor, un utilisateur demande : « Un micro-entrepreneur doit-il facturer la TVA dès le premier euro ? »
2. Le modèle constate qu'un outil de base de connaissances est disponible et appelle ask_base sur une base comme Micro-entrepreneur : impôts, TVA, CFE et cotisations.
3. Le serveur retrouve les passages pertinents dans les documents indexés et renvoie une réponse fondée sur eux, avec des citations numérotées.
4. Le modèle rédige sa réponse et renvoie l'utilisateur vers les passages cités, qu'il peut vérifier.

Le même serveur fonctionne dans Claude Code, Cursor, ChatGPT et les autres clients MCP, puisque le contrat est identique. Dans Claude Code, une commande suffit : claude mcp add --transport http kopik https://kopik.io/api/mcp --header "Authorization: Bearer kpk_…". Dans Cursor, on ajoute une entrée « kopik » sous mcpServers dans le fichier .cursor/mcp.json, avec l'URL et l'en-tête Authorization. Le pas à pas complet, client par client, se trouve dans notre guide pour connecter une base de connaissances aux agents IA avec MCP.

Sécurité et RGPD : les vérifications avant de brancher un serveur

Un serveur MCP est un tiers à qui votre assistant confie des données et parfois des actions. Traitez-le comme n'importe quel sous-traitant : si des données personnelles transitent, le RGPD s'applique, et les recommandations de la CNIL sur l'IA constituent un bon point de départ. L'AI Act européen ajoute, selon les usages, des obligations de transparence et de maîtrise des risques.

• Cartographier les flux : quel serveur reçoit quelles informations, avec ou sans données personnelles ? Mettez à jour votre registre des traitements et, si le risque est élevé, votre AIPD.
• Limiter les droits : une clé API par serveur et par usage, avec le minimum d'accès, révoquée en fin de projet.
• Se prémunir contre l'injection de consignes : le contenu renvoyé par un serveur peut contenir du texte qui tente de piloter le modèle. Préférez les serveurs qui balisent ce contenu comme non fiable et gardez une validation humaine pour les outils qui écrivent, envoient ou suppriment.
• Plafonner les coûts : pour les outils payants, fixez une limite ; chez Kopik, l'argument maxPriceCents refuse l'appel sans frais si la base coûte plus cher.
• Respecter les quotas : les serveurs distants limitent le nombre de requêtes par minute et par jour ; vos agents doivent patienter plutôt que boucler.

MCP ou API REST : faut-il choisir ?

Non, les deux se complètent. Une API REST convient au code déterministe : une tâche planifiée, un formulaire, une intégration entièrement maîtrisée par vos développeurs. Le MCP convient quand c'est un modèle qui choisit, en pleine conversation, quelle capacité utiliser. Beaucoup de services proposent les deux. Règle simple : si c'est une personne qui pose la question dans un assistant, MCP ; si c'est un programme, l'API.