Chapitre 2 — Dévoiler le Model Context Protocol (MCP)

Deuxième billet de la tournée chapitre par chapitre de LLM Primer IV : Concevoir la cognition de l'IA avec MCP. Le chapitre où l'on bâtit le modèle mental — trois rôles, un format JSON-RPC sur le fil, une surface de découverte dynamique et un cycle de vie de session — avec assez de soin pour que tout le reste du livre puisse s'y appuyer.

Pourquoi ce chapitre existe

Le Chapitre 1 a nommé le problème. Ce chapitre bâtit le modèle mental de la réponse. MCP peut se résumer en une phrase et se comprendre de travers en un paragraphe, alors le chapitre prend son temps : ce qu'est le protocole au niveau du fil, ce que veulent dire les trois rôles et ce que chacun possède, en quoi il diffère d'une API REST dans les cas qui comptent vraiment en production, et ce qui se passe pendant une session, de la connexion au démontage. L'objectif est qu'à la fin, vous puissiez prédire — avant de lire le chapitre suivant — ce que doit être une primitive serveur, ce que doit être une primitive client, et pourquoi MCP mérite la structure qu'il a.

2.1 Ce qu'est MCP et ce que veut vraiment dire « USB-C pour l'IA »

Le Model Context Protocol est une spécification ouverte de la façon dont les applications LLM découvrent, décrivent et invoquent des capacités externes. Sur le fil, c'est du JSON-RPC 2.0 sur un petit nombre de transports. Au niveau architectural, c'est le contrat qui permet à un hôte de travailler avec n'importe quel serveur conforme sans code d'intégration sur mesure. Un outil construit une fois sur le protocole fonctionne avec tous les hôtes qui le parlent. Un hôte construit une fois sur le protocole peut utiliser tous les outils qui le parlent.

Le raccourci qui s'est imposé est « USB-C pour l'IA ». La forme structurelle imite vraiment l'USB-C — un standard de connexion unique qui médiatise entre une population ouverte d'appareils et une population ouverte d'hôtes. Les limites de la métaphore méritent d'être nommées : l'USB-C standardise un connecteur plus une pile au-dessus ; MCP ne standardise que le protocole. L'USB-C fonctionne à des échelles de temps électriques avec un cadrage matériellement imposé ; MCP fonctionne à des échelles de temps réseau avec un cadrage défini par logiciel, ce qui rend MCP plus souple et l'oblige aussi à gérer des connexions perdues et des pairs lents que l'USB-C ne rencontre pas.

Une comparaison plus proche, pour les ingénieurs, est LSP. Le Language Server Protocol a défini un protocole que tout éditeur et tout serveur de langage peuvent parler ; MCP en définit un que tout hôte LLM et tout fournisseur de capacités peuvent parler. La forme du gain est identique — un graphe plusieurs-à-plusieurs effondré par un protocole partagé en quelque chose qui se met à l'échelle additivement. Le choix de baser MCP sur JSON-RPC 2.0 plutôt que d'inventer un format de fil neuf est délibéré : JSON-RPC est petit, mûr, indépendant du langage et peu glamour. Les choix architecturaux intéressants ne sont pas au niveau du fil. Ils sont dans la façon dont Hôtes, Clients et Serveurs se répartissent la responsabilité.

2.2 Hôtes, Clients et Serveurs — ce que chaque rôle possède

MCP définit trois rôles, et la première chose à comprendre, c'est que « Client » et « Serveur » ne signifient pas ce qu'ils signifient souvent ailleurs. Un Serveur expose des capacités — outils, ressources, prompts. Un Client est une seule connexion qui parle le protocole, vers un seul Serveur, gérée à l'intérieur d'une application plus grande. Cette application plus grande, c'est l'Hôte. L'Hôte possède le modèle, la session de l'utilisateur, et la politique qui définit ce que le modèle a le droit de faire. Les Serveurs possèdent leurs surfaces de capacités. Les Clients sont les fils entre eux, un par Serveur.

Le découpage compte parce que chaque rôle a une responsabilité différente et une posture de confiance différente. L'Hôte est la frontière de confiance qui importe du point de vue de l'utilisateur ; tout le reste est ce que l'Hôte a décidé de laisser entrer. Un Hôte qui parle à cinq Serveurs a cinq Clients qui tournent à l'intérieur de lui, chacun avec son état de session propre, ses abonnements, sa vue des capacités négociées. Si un Serveur tombe, le Client correspondant tombe ; les autres Clients continuent de tourner ; l'Hôte reste vivant. Les Clients sont des isolateurs par connexion qui empêchent qu'un mauvais Serveur empoisonne toute la session.

Il y a aussi un argument de sécurité au découpage. Chaque Serveur est, au minimum, du code écrit par quelqu'un d'autre. Le Client médiatise tout ce que le Serveur peut faire qui affecte l'Hôte — notifications, élicitations, demandes de sampling, ressources publiées — et c'est là que la politique propre à chaque Serveur doit vivre. Hôtes, Clients et Serveurs sont des rôles logiques, pas strictement physiques : en installation locale, le Serveur est souvent un sous-processus sur stdio ; en déploiement distant, c'est un service sur un transport fondé sur HTTP. Le protocole s'en moque ; les frontières de rôle, non.

2.3 MCP contre REST — ce qu'achètent la découverte dynamique et les descriptions sémantiques

La question raisonnable est « n'est-ce pas juste REST ? » Les différences ne sont pas cosmétiques. Les plus conséquentes sont la découverte dynamique, les descriptions sémantiques écrites pour un LLM, et un modèle de messages bidirectionnel.

Une API REST publie des endpoints dans une documentation écrite pour des développeurs humains. L'ensemble d'endpoints qu'un client utilise est fixé à la compilation ; de nouveaux endpoints exigent un redéploiement. MCP inverse cela. Au début de la session, le Client demande « qu'offrez-vous ? » et le Serveur répond par un catalogue typé — schémas, descriptions, métadonnées — que l'hôte utilise programmatiquement. Si le Serveur ajoute plus tard un outil, une notification listChanged met à jour le Client en cours de session sans redémarrage. Le Serveur est la source faisant autorité sur ses propres capacités ; la description ne peut pas diverger de l'implémentation parce qu'il n'y a pas de copie côté client séparée qui puisse diverger.

Les descriptions sémantiques sont la seconde différence. La doc d'un endpoint REST est écrite pour un développeur qui va la lire et décider. La description d'un outil MCP est écrite pour un LLM qui la lira dans son prompt et décidera de manière autonome. Une description qui dit « POST sur /users/:id/orders » est inutile à un LLM, qui a besoin de savoir quelle opération conceptuelle l'outil effectue, quand il doit être préféré, quels effets de bord il a, et ce que ses entrées veulent dire en termes de domaine. Le travail de traduire l'API en termes lisibles par LLM a été poussé une seule fois, dans le Serveur, là où les personnes les plus proches de la capacité peuvent l'entretenir.

La troisième différence est la bidirectionnalité. REST est requête-réponse ; la connexion se ferme. MCP est bidirectionnel par conception. Le Serveur peut envoyer des notifications à tout moment, peut initier des demandes de sampling vers le Client, peut éliciter des réponses de l'utilisateur en cours de flux. Aucune de ces choses n'est techniquement impossible sur REST. Toutes y sont gauches. En MCP elles font partie du standard.

2.4 Négociation des capacités et cycle de vie de session

Une session commence quand le Client ouvre un transport et envoie une requête initialize portant sa version de protocole et ses capacités. Le Serveur répond avec ses propres capacités — expose-t-il des outils, expose-t-il des ressources, offre-t-il des abonnements, soutient-il des fonctionnalités avancées. Le Client confirme par une notification initialized. La session est alors en état opérationnel, et les types de messages disponibles sont exactement le sous-ensemble que les deux côtés ont accepté.

Cette négociation est ce qui permet à un Client et à un Serveur aux ensembles de fonctionnalités différents de coexister utilement. C'est aussi là que se gère le versionnage : le Serveur choisit la plus haute version que les deux côtés soutiennent. Opérationnellement, le cycle de vie a des conséquences. L'initialisation n'est pas gratuite — il y a un coût d'aller-retour et, pour des serveurs distants, un établissement de connexion par-dessus. Les sessions longues sont le patron préféré ; les changements de capacités passent par notifications plutôt que par reconnexion. Les hôtes qui respectent cela — gardant les sessions chaudes, se reconnectant en arrière-plan après une coupure réseau — obtiennent une latence matériellement meilleure. Les hôtes qui démontent et réinitialisent à chaque requête fonctionnent correctement mais inefficacement.

Une asymétrie à fixer : les requêtes ont des réponses ; les notifications n'en ont pas. Les événements list-changed sont des notifications, donc un Client qui en manque une doit être prêt à rafraîchir sa vue en rappelant list_tools. La notification est une optimisation, pas une garantie. Le code MCP robuste la traite comme un indice, non comme un enregistrement.

Ce que prépare le Chapitre 2

Vous avez maintenant le modèle mental. MCP est un protocole JSON-RPC à trois rôles, avec une découverte dynamique qui rend le Serveur autoritaire pour ses propres capacités, des descriptions écrites pour un public LLM, un modèle de messages bidirectionnel avec notifications et requêtes initiées par le serveur, et un cycle de vie qui s'ouvre par une négociation explicite des capacités et opère à l'intérieur du sous-ensemble que les deux côtés ont accepté. C'est assez d'échafaudage pour parler concrètement de ce que Serveurs et Clients exposent chacun, ce que font les deux chapitres suivants.

Prochaine étape — Chapitre 3 : Primitives du serveur — Ressources, Prompts, Outils. Les trois noms qu'un serveur peut offrir, pourquoi chacun compte, et la discipline de choisir la bonne primitive au lieu d'en surcharger une dans le territoire d'une autre.