La spécification MCP 2.0 du 28 juillet, que nous racontions le 1er août, retire les sessions du serveur : une seule requête HTTP suffit pour invoquer un outil. Dans son récapitulatif hebdomadaire, Latent.Space identifie précisément ce passage stateless comme le fil qui tient ensemble les thèmes de la semaine : agents qui se messagent entre eux, orchestration multi-agente, gestion de l’état.

Pour qui scale des agents, l’état persistant sur le serveur était le goulot d’étranglement invisible. Chaque session ouverte consommait des ressources, chaque connexion devait être gérée et maintenue. Avec le protocole stateless, cent agents peuvent appeler les mêmes outils sans que le serveur devienne le point d’étranglement.

La semaine le démontre sur le terrain. Claude Code permet aux sessions d’échanger des messages, et dans Codex tu peux @-mentionner un thread pour mettre en file d’attente un message à un autre agent. Ce sont des patterns qui ne fonctionnent que si l’infrastructure sous-jacente ne retient pas d’état. Latent.Space baptise cette tendance « loi de Zawinski des agents multiples » : chaque agent cherche à s’étendre tant qu’il peut échanger des messages avec d’autres agents.

Si tu veux l’essayer : la spécification MCP 2.0 est publique sur le repository officiel du protocole. Compare le flux basé sur session de la version précédente avec celui HTTP stateless pour comprendre ce qui change dans ton architecture.

En détail

Le Model Context Protocol (MCP) est le standard qu’Anthropic a publié fin 2024 pour connecter les assistants IA à des outils externes : bases de données, API, systèmes de fichiers, n’importe quelle ressource qu’un agent doit lire ou écrire. Dans sa première version, chaque connexion entre un agent et un outil ouvrait une session persistante sur le serveur. Le serveur gardait trace de qui était connecté, ce qu’il faisait, quel état de conversation il avait accumulé. Ça fonctionnait bien pour une conversation, mais devenait un problème quand les agents se multipliaient.

Le problème de l’état. Si tu as dix agents qui appellent simultanément le même serveur MCP, le serveur doit gérer dix sessions actives. Chaque session occupe de la mémoire. Si un agent se déconnecte sans fermer la session, le serveur reste avec une connexion fantôme. Si tu veux scalabiliser à cent agents, le serveur devient le goulot d’étranglement. C’est le même problème que le web a affronté il y a des années en passant des sessions serveur-side aux tokens stateless.

Ce qui change avec MCP 2.0. La spécification du 28 juillet retire l’état du serveur. Une requête HTTP contient tout ce qui est nécessaire : quel outil appeler, avec quels paramètres, avec quel contexte. Le serveur répond et oublie. Pas de session, pas de mémoire persistante, pas de connexion à maintenir. C’est la même différence qu’il y a entre un appel téléphonique (tu ouvres une ligne, tu la maintiens, tu la fermes) et un SMS (tu envoies le message, le système le livre, c’est terminé).

Pourquoi maintenant. Les patterns de la semaine montrent que les agents deviennent des systèmes distribués, pas des assistants isolés. Claude Code fait communiquer les sessions entre elles. Codex permet de @-mentionner des threads pour mettre en file d’attente des messages vers d’autres agents. OpenAI a documenté au Black Hat comment ses agents en training ont découvert eux-mêmes comment utiliser un repository partagé comme tableau d’affichage pour se coordonner. Ce sont des exemples qui vont dans la même direction : des agents qui parlent avec d’autres agents, pas seulement avec un humain. Et pour que ça fonctionne à l’échelle, le protocole sous-jacent ne peut pas retenir d’état.

Latent.Space synthétise tout ça avec ce qu’elle appelle la « loi de Zawinski des agents multiples », une riff de la célèbre loi de Jamie Zawinski sur le logiciel qui s’étend tant qu’il peut lire les e-mails. Dans le cas des agents : chaque agent cherche à s’étendre tant qu’il peut échanger des messages avec d’autres agents. MCP 2.0 stateless est l’infrastructure qui rend cette expansion praticable au lieu de l’étouffer.

Ce qui reste ouvert. La spécification est active, mais l’adoption réelle exige que serveurs et clients se mettent à jour. Certaines implémentations MCP existantes pourraient ne pas être encore compatibles avec le nouveau modèle stateless. Et le passage de session-based à stateless déplace le problème de l’état du serveur au client : c’est l’agent, ou celui qui l’orchestre, qui doit le gérer. L’état ne disparaît pas, il change de propriétaire.