Le 23 juillet, GitHub a annoncé que son serveur MCP prenait déjà en charge la prochaine version du protocole, dont la publication finale est prévue le 28 juillet 2026. La nouveauté principale tient en un mot : stateless.
Ce n’est pas le genre d’annonce qui produit une démo spectaculaire. Pourtant, pour les développeurs qui veulent déployer un serveur Model Context Protocol sur leur propre infrastructure, c’est probablement l’évolution la plus importante du protocole depuis son lancement.
## MCP avait recréé les contraintes d’une application stateful
MCP standardise la communication entre une application utilisant un modèle de langage et des services capables de lui fournir des données, des ressources ou des outils. Un serveur peut par exemple exposer une fonction de recherche, un accès à des issues ou une action sur une base de données.
Dans la précédente version du protocole, un client devait commencer par envoyer une requête initialize. Le serveur répondait avec un identifiant Mcp-Session-Id, ensuite transmis avec les appels suivants. La documentation de la release candidate montre précisément ce cycle : initialisation, création d’une session, puis appels liés à cette session.
Sur une seule machine, ce fonctionnement reste gérable. Dès que plusieurs instances du serveur tournent derrière un load balancer, il faut cependant conserver le client sur la même instance ou partager l’état entre les nœuds. On retrouve alors les sessions persistantes, le stockage distribué et les règles de routage que les API HTTP modernes essaient souvent d’éviter.
## Une requête contient désormais tout ce dont elle a besoin
Avec la spécification 2026-07-28, le handshake `initialize`, l’identifiant de session et l’état géré au niveau du protocole disparaissent. La version utilisée, les informations du client et ses capacités voyagent directement avec chaque requête.
Le résultat ressemble davantage à une API HTTP classique :
- une requête peut arriver sur n’importe quelle instance du serveur ;
- un load balancer peut fonctionner en round-robin sans sticky session ;
- le serveur n’a plus besoin d’écrire en base lors de la connexion d’un client ;
- plusieurs requêtes peuvent commencer leur négociation en parallèle.
Le retour d’expérience publié par GitHub est concret : son serveur MCP a supprimé les écritures effectuées pendant initialize ainsi que les lectures de session réalisées à chaque appel. GitHub explique également ne plus devoir inspecter profondément le corps des requêtes pour identifier certaines informations, désormais disponibles dans des en-têtes HTTP obligatoires.
## Stateless ne veut pas dire sans état métier
Un agent qui pilote un navigateur, construit un panier ou lance une tâche longue doit toujours conserver un contexte. La différence est que cet état devient explicite dans les arguments des outils.
Un outil peut retourner un browser_id ou un task_id, puis demander au modèle de le renvoyer lors de l’appel suivant. L’état n’est plus caché dans la couche de transport : il fait partie du contrat fonctionnel de l’outil.
C’est généralement plus simple à déboguer. Un identifiant présent dans les paramètres peut être journalisé, validé et rejoué. Une session implicite, attachée à une connexion ou à un en-tête technique, est plus difficile à suivre lorsqu’une requête traverse plusieurs services.
## Le protocole devient plus exploitable en production
La nouvelle version ajoute des en-têtes Mcp-Method et Mcp-Name. Ils permettent aux reverse proxies, gateways et systèmes de limitation de débit d’identifier une opération sans lire le JSON. Les réponses de découverte peuvent aussi annoncer une durée de cache avec ttlMs et une portée avec cacheScope.
La spécification documente également la propagation du contexte de traces vers un backend compatible avec OpenTelemetry. Un appel peut ainsi être suivi depuis l’application hôte jusqu’au serveur MCP, puis dans les services contactés en aval.
Enfin, une suite officielle de tests de conformité accompagne désormais le protocole. Elle doit limiter les implémentations approximatives et permettre aux SDK de vérifier automatiquement leur comportement. Le serveur de GitHub s’appuie par exemple sur le SDK Go officiel, qui conserve une compatibilité avec les anciens clients.
## Ce que je retiens pour un déploiement sur VPS
Pour un petit serveur MCP auto-hébergé, rien n’oblige à lancer plusieurs instances dès maintenant. Mais cette évolution enlève une contrainte structurelle : le jour où le trafic augmente, la réplication ne nécessite plus de reconstruire toute la gestion des sessions.
Le point de vigilance se déplace vers l’application. Les identifiants métier doivent être imprévisibles, liés au bon utilisateur, expirables et vérifiés à chaque appel. Le protocole devient stateless ; les autorisations, elles, ne le deviennent pas.
C’est une bonne direction pour MCP : moins de magie dans le transport, davantage de données explicites et une architecture qui se comporte enfin comme une API HTTP ordinaire.
## Pour aller plus loin
- Annonce du support par GitHub MCP Server
- Présentation complète de la spécification MCP 2026-07-28
- Brouillon de la prochaine spécification MCP
- Suite officielle de tests de conformité
- SDK Go officiel de MCP
Veille rédigée avec l'aide d'une IA — sources vérifiées et liées ci-dessus.