MCP Mastery

1Sans MCP, chaque outil se branche autant de fois qu'il y a d'agents

Le cours part d'une demande faite à un assistant : « résume mes tickets Zendesk, ajoute la fiche client Salesforce, poste le tout dans Slack ». Pour parler à ces trois logiciels, quelqu'un écrit à la main une liaison par logiciel.

Arrive un deuxième assistant, fabriqué par une autre entreprise. Il ne comprend pas les liaisons du premier : il faut refaire les trois pour lui. Trois logiciels et trois assistants font neuf liaisons (3 × 3). Avec dix assistants, trente.

Et il faut les entretenir. Si Salesforce change son API (la porte d'entrée que les programmes utilisent pour lui parler), on répare les liaisons vers Salesforce, une par assistant. Raheja appelle ces assistants des agents : des programmes d'IA qui enchaînent seuls des actions. Il résume : « l'effort ne croît pas avec le nombre d'outils, il croît avec les outils multipliés par les agents » (vidéo 2_1).

MCP change le calcul : une règle commune que tous connaissent, comme la prise USB-C, un seul câble pour tous les appareils (l'image du cours). Chaque logiciel s'y branche une fois, chaque assistant l'apprend une fois : 3 + 3 = 6 au lieu de 9, et 13 au lieu de 30 avec dix assistants.

2Hôte, client, serveur : trois rôles et un client par serveur

Reprenons l'exemple. Pour que la prise commune marche, le cours distingue trois rôles. Un rôle est un travail à faire, pas un logiciel précis : plusieurs logiciels peuvent tenir le même rôle.

• hôte : l'application que vous utilisez, un assistant d'IA ou un éditeur de code. Claude.ai en est un, c'est le cas de l'idée 7.
• client : le morceau de l'hôte qui parle à un serveur.
• serveur : le programme qui offre des actions sur un logiciel. Un serveur Zendesk, un serveur Salesforce, un serveur Slack. Il se contente souvent de traduire : il reçoit la demande commune et la transmet au logiciel par son API.

Un client ne parle qu'à un seul serveur, comme une ligne téléphonique réservée à un correspondant. Claude.ai veut joindre Zendesk, Salesforce et Slack : il ouvre trois lignes, donc trois clients, tous à l'intérieur de Claude.ai (l'hôte).

Un serveur peut offrir trois sortes de briques : des outils pour agir, des ressources pour lire, des prompts pour demander. L'idée 3 les détaille.

D'habitude, l'hôte demande et le serveur répond. Mais le serveur peut aussi avoir besoin de quelque chose : il le demande alors à l'hôte, de deux façons :

• elicitation (sollicitation) : le serveur a besoin d'une information que seul l'utilisateur connaît, comme une date de réservation. Il ne voit pas l'utilisateur, alors il passe par l'hôte : le serveur dit « il me faut la date », l'hôte pose la question à l'utilisateur, puis rend la réponse au serveur (exemple imaginé).
• sampling (échantillonnage) : le serveur a besoin d'un texte écrit par un modèle de langage, comme un résumé, mais il n'en a pas. Il le demande à l'hôte, qui le fait écrire par son propre modèle et rend le texte (exemple imaginé). Le cours déclare ensuite le sampling déprécié (idée 5).

3Agir, lire, demander : les trois briques d'un serveur

Un serveur offre trois sortes de briques, les primitives. Trois acteurs peuvent s'en servir. Le modèle est l'IA qui écrit les réponses. L'application est le programme qui l'entoure : l'hôte de l'idée 2, comme Claude.ai. Le troisième, c'est vous, l'utilisateur. Ce qui distingue les briques, c'est l'intention : agir, lire ou demander. Exemple imaginé, avec un serveur Zendesk :

• Agir : c'est un outil, comme « créer un ticket ». Le modèle le lance de lui-même, en lisant sa description : ce qu'il fait et les informations à lui donner.
• Lire : c'est une ressource, une information que le serveur met à disposition, comme « la liste des tickets ouverts ». Elle a une adresse, du genre file://… ou calendar://…. L'application la lit et la met sous les yeux du modèle.
• Demander : c'est un prompt, une demande toute prête comme « résume mes tickets de la semaine », avec des cases à remplir (la semaine). L'utilisateur la choisit, souvent dans un menu.

D'une brique à l'autre, ce qui change, c'est qui la lance. Raheja le dit ainsi : « les outils sont contrôlés par le modèle, les ressources par l'application » (vidéo 2_3). Autrement dit : le modèle lance les outils (agir), l'application lance les ressources (lire), l'utilisateur lance les prompts (demander). À quoi ça sert de le savoir ? Seul l'outil peut changer quelque chose dans le logiciel, comme créer ou supprimer un ticket, sur simple décision du modèle. C'est pour cela qu'une application peut demander votre accord avant qu'un outil s'exécute (vidéo 2_3).

4Le message MCP reste le même quand le transport change

Reste à savoir comment ces briques circulent. Un message MCP a deux parties :

• Le contenu : ce qu'on demande. Il est écrit en JSON-RPC 2.0. JSON est un format de données en texte, comme {"ville": "Paris"}. Avec JSON-RPC, on envoie une requête, c'est-à-dire une question, et le serveur renvoie une réponse.
• Le transport : le chemin que le message prend pour arriver.

{"jsonrpc": "2.0", "id": 1, "method": "tools/list"}

Exemple imaginé : cette requête demande la liste des outils du serveur. Elle nomme ce qu'on veut, ici « tools/list ». Le cours présente deux transports standard :

• STDIO (entrée et sortie standard) : le serveur tourne sur votre ordinateur, lancé par l'hôte, sans internet.
• HTTP streamable : le serveur est sur un autre ordinateur, joint par une adresse web (URL). Il peut répondre morceau par morceau, comme une vidéo en direct.

L'image du cours : « changer de transport, c'est passer de la poste au coursier, la lettre à l'intérieur ne change pas » (vidéo 2_4). La lettre est le contenu du message.

5Une révision de MCP porte une date, et la date compte

Les règles de MCP changent avec le temps. Chaque nouvelle révision de la spécification, le texte qui définit le protocole, porte donc une date plutôt qu'un numéro comme 1.0 ou 1.1. Un client ancien peut ne pas comprendre un serveur récent (vidéo 2_5). Le cours s'appuie sur la révision du 28 juillet 2026, qui succède à celle du 25 novembre 2025. Cette date désigne le protocole, pas un logiciel comme un serveur en version 1.4.0.

Selon le cours, la révision de 2026 rend le protocole « sans état » (stateless en anglais). Le serveur ne garde plus la mémoire de la conversation : chaque requête porte tout ce qu'il faut pour être comprise.

C'est la différence entre un serveur de restaurant qui vous connaît et un guichet où personne ne vous reconnaît : au guichet, vous redites tout à chaque fois. Concrètement, chaque requête porte elle-même la version du protocole, l'identité du client et ses capacités, ce qu'il sait faire (vidéo 2_5).

L'ouverture de la conversation disparaît aussi. Dans les anciens tutoriels, une poignée de main l'ouvrait par deux messages, « initialize » puis « initialized ». Venait ensuite un identifiant de session, un numéro qui désignait la conversation. Ces deux éléments n'existent plus (vidéo 2_5, confirmée par les diapositives du cours).

Une fonctionnalité dépréciée marche encore, mais on ne s'en sert plus pour un nouveau projet. Elle reste au moins douze mois avant son retrait (vidéo 2_5). La vidéo 2_5 cite trois fonctionnalités dépréciées, et les diapositives du cours donnent la même liste : le sampling, le logging et l'ancien transport HTTP avec SSE, remplacé par HTTP streamable.

Le logging, c'est le serveur qui envoie au client des messages de suivi. SSE (server-sent events) est un flux d'événements envoyés par le serveur.

Un tutoriel écrit pour une ancienne révision peut ne plus marcher. Un indice : l'adresse (URL) des anciens serveurs finit par /sse, celle des récents par /mcp (vidéo 7_3).

6Un test en vrai : c'est le modèle qui choisit l'outil

Les idées 1 à 5 expliquaient le protocole. Reste une question pratique : quand un serveur offre plusieurs outils, qui choisit lequel servir ? L'idée 3 répond : le modèle. Le cours le montre sur un exemple, dans n8n, son outil de démonstration, qui relie des applications avec des blocs.

Raheja y monte un petit serveur MCP. Ses outils créent ou suppriment des buckets, des espaces de stockage du service S3 d'Amazon. Un agent est branché à l'adresse de ce serveur : c'est un modèle d'IA placé dans n8n, avec des outils à sa disposition. On lui parle en chat.

Le test : Raheja part de 23 buckets, demande d'en créer un et en compte 24 à l'arrivée. Le journal du serveur, la liste de ce qu'il a exécuté, montre qu'un seul outil a servi : « create a bucket ». Personne ne l'a désigné à la main : le modèle de l'agent a choisi l'outil. Raheja conclut que « tout est décidé par le serveur MCP » (vidéo 6_8). Je le lis autrement : le serveur offre les outils, le modèle choisit.

Même principe avec un serveur public, qu'on branche sans rien construire, en donnant son adresse. Context7 en est un : il fournit la documentation à jour des bibliothèques de code, des morceaux de code déjà écrits. C'est utile, car un modèle ne connaît que ce qu'il a lu avant son entraînement (vidéo 7_1). L'agent y trouve seul l'identifiant de la bibliothèque de code, puis sa documentation (vidéo 7_2).

7Claude pilote n8n, mais seulement ce qu'on lui ouvre

Cette fois, n8n est le serveur. Claude.ai, l'hôte, s'y branche par un client. Dans Claude.ai, on ajoute n8n en donnant l'adresse de son serveur MCP. Claude compte alors les workflows : trente, dont dix-sept en marche (vidéo 8_1).

Pour agir dans n8n, Claude doit passer trois barrières : trois autorisations à obtenir. D'abord l'accord au branchement : un écran d'accord s'affiche, « Claude demande l'accès à votre instance n8n » (votre installation de n8n), et il faut accepter (vidéo 8_1). Ensuite l'accès par workflow : pour un workflow existant, « Enable MCP access » (activer l'accès MCP), sinon Claude répond qu'il n'a pas accès (vidéo 8_2). Un workflow créé par Claude lui est accessible sans réglage (vidéo 8_3). Enfin l'accord à chaque appel d'outil, chaque fois que Claude lance un outil : « allow once » (autoriser une fois).

Claude crée ainsi un workflow qui liste les buckets S3, en huit appels autorisés un par un (vidéo 8_3).