La mise à jour la plus intéressante de MCP cet été consiste à retirer quelque chose.

Depuis la spécification du 28 juillet, le transport HTTP de Model Context Protocol n'impose plus de session au niveau du protocole. Un agent peut envoyer une requête à un endpoint, recevoir sa réponse, puis revenir plus tard sans que l'infrastructure ait à se souvenir de la connexion précédente.

Sur le papier, c'est une ligne de plomberie. Dans la pratique, c'est précisément le genre de plomberie qui décide si un petit outil reste un script local ou peut être posé proprement sur une infra serverless.

Theo Browne, qui a longtemps été plutôt allergique à MCP, résume bien le déplacement dans une vidéo récente : ce n'est pas une nouvelle catégorie de tool call qui l'intéresse, c'est le fait que le protocole arrête enfin de demander au serveur de retenir une conversation réseau dont beaucoup d'outils n'avaient pas besoin.

Avant, une petite fonction traînait une session derrière elle

Dans l'ancienne version du transport Streamable HTTP, un serveur pouvait créer un identifiant de session. Les requêtes suivantes devaient alors revenir avec cet identifiant.

Dès qu'on met plusieurs instances derrière un load balancer, une question pénible apparaît : où vit cette session ? Il faut soit renvoyer le même client vers la même machine, soit partager l'état entre les machines. On vient de transformer un outil qui prend trois paramètres et renvoie du JSON en petit problème d'infrastructure distribuée. Félicitations, la météo était trop calme.

La spécification 2026-07-28 retire cette couche. Les messages JSON-RPC partent individuellement en POST vers un endpoint HTTP. La réponse peut être un JSON classique ou un flux SSE limité à cette requête. L'ancien endpoint GET qui pouvait maintenir un flux séparé disparaît lui aussi.

Le serveur n'a donc plus besoin d'un identifiant de session MCP pour savoir à quelle conversation réseau appartient la requête suivante.

Cette phrase n'est pas très sexy. Elle rend pourtant beaucoup de déploiements nettement moins spéciaux.

Stateless ne veut pas dire amnésique

Il faut faire attention au mot « stateless », parce qu'il donne très vite envie de raconter n'importe quoi.

MCP n'interdit pas à une application de conserver un état. La documentation officielle insiste même sur ce point. C'est le protocole de transport qui n'impose plus sa propre session.

Un outil qui lance un travail long peut toujours renvoyer un identifiant explicite. L'agent garde cet identifiant dans son contexte et le fournit lors d'un appel suivant. Même chose pour un panier, une tâche, un workflow ou n'importe quel objet qui doit survivre à plusieurs requêtes.

La différence est plutôt saine : si l'état est important pour le métier, il devient une donnée visible du métier. Il n'est plus caché dans une relation réseau que le développeur doit conserver par défaut.

Ça paraît presque trop banal. C'est généralement bon signe.

Un MCP distant ressemble enfin davantage à une API normale

C'est là que Theo change franchement de ton.

Dans sa vidéo, il explique que l'ancienne mécanique rendait le scaling et le déploiement inutilement compliqués pour beaucoup de petits serveurs. Avec le nouveau modèle, le même endpoint peut plus naturellement vivre sur une Lambda, un Worker Cloudflare ou une autre infrastructure qui crée et détruit des instances à la demande.

Ce n'est pas parce que « serverless » est magiquement meilleur. C'est parce qu'un serveur sans session implicite demande moins de coordination entre ses instances.

Pour un maker, une petite équipe ou quelqu'un qui publie vingt outils très spécialisés, la différence est concrète. Un service presque jamais appelé peut rester presque gratuit à héberger. Celui qui commence à recevoir du trafic peut multiplier les instances sans devoir d'abord reconstruire le mécanisme de session autour.

Simon Willison, cité par Theo, explique avoir enfin pu publier certains petits outils MCP après plusieurs tentatives. Là encore, il s'agit d'une expérience personnelle, pas d'un benchmark universel. Mais elle illustre bien le problème : parfois l'adoption d'un standard ne bloque pas sur ce qu'il permet de faire. Elle bloque sur le nombre de choses pénibles qu'il exige avant le premier usage utile.

Le meilleur protocole est parfois celui qui disparaît un peu

MCP reste un gros standard. La version de juillet ajoute aussi des changements d'autorisation et un système d'extensions. Rien de tout cela ne garantit qu'un serveur MCP soit bien conçu, sûr ou même préférable à une CLI.

Mais retirer la session du cœur du transport corrige un défaut plus profond : la complexité était payée même lorsque l'application n'en avait aucune utilité.

Je trouve cette direction plus intéressante qu'une nouvelle fonctionnalité spectaculaire. Les agents ont déjà beaucoup de capacités. Ce qui leur manque souvent, ce sont des interfaces assez ordinaires pour qu'on puisse les multiplier sans construire une petite cathédrale autour de chaque bouton.

Un bon protocole d'outils devrait probablement laisser la complexité apparaître seulement quand le problème lui-même est complexe.

Pour une fois, la nouveauté consiste à avoir moins de protocole. Ça me va très bien.