MCP v2 sans état vs MCP v1 avec état (2026) : spécification finale, SDK principal toujours en 1.30.0
MCP v2 sans état vs MCP v1 avec état, quatre jours après l'échéance du 28 juillet : le tag de spécification est final et PyPI mcp est en 2.0.0, mais @modelcontextprotocol/sdk reste en 1.30.0. Comparez mise à l'échelle, stabilité des SDK, autorisation et risque de migration.
Quatre jours après l'échéance, le tableau a changé deux fois. La spécification est finale : le tag 2026-07-28 est passé en non-prerelease le 28 juillet à 16h47 UTC, l'objection de gouvernance à la bascule tombe donc. PyPI a suivi le même jour — pip install mcp résout désormais vers 2.0.0 (téléversé le 28 juillet à 13h45 UTC), et non plus vers la 1.28.1 encore en vigueur le matin de l'échéance. Ce qui n'a pas bougé, c'est le SDK TypeScript principal : @modelcontextprotocol/sdk reste en 1.30.0, publié le 2026-07-27 à 17h56 UTC. La ligne de partage n'oppose donc plus TypeScript et Python, mais les paquets serveur et Python d'un côté, et de l'autre l'unique paquet TypeScript principal qu'importe presque tout client sur mesure. Choisissez v2 sans état maintenant si vous développez des serveurs MCP en TypeScript (les paquets à portée @modelcontextprotocol/server, /node et /hono sont en 2.0.0 stable) ou en Python, et s'il vous faut une mise à l'échelle horizontale sans sessions colles, un routage résistant aux redémarrages et une exécution serverless propre. Restez en v1 avec état là où vous dépendez directement de @modelcontextprotocol/sdk — le code client et tout ce qui repose sur le SDK principal n'a aucun 2.x à installer — ou là où vos clients et adaptateurs n'ont pas été testés contre un serveur sans état. Épinglez dans tous les cas : quatre paquets npm à portée et le mcp de PyPI résolvent désormais latest vers 2.0.0, une installation non épinglée franchit donc seule une version majeure. Et rien n'a cassé le 28 juillet : les dépréciations de Roots, Sampling et Logging restent de simples annotations pendant au moins un an — migrez délibérément, paquet par paquet.
Comparaison Détaillée
Une analyse comparative des facteurs clés pour vous aider à faire le bon choix.
| Facteur | MCP v2 sans étatRecommandé | MCP v1 avec état | Gagnant |
|---|---|---|---|
| Montée en charge horizontale | Chaque requête peut viser n'importe quelle instance compatible dès que l'état applicatif sort du serveur de protocole | Les sessions longues et l'affinité de connexion sont plus simples à comprendre, mais compliquent l'autoscaling et le basculement | |
| Stabilité du SDK | Livraison en plusieurs temps : les paquets serveur à portée sont passés en 2.0.0 stable le 27 juillet et PyPI mcp a suivi le 28, mais @modelcontextprotocol/sdk reste en 1.30.0 — v2 est installable partout sauf dans le paquet TypeScript principal | Toujours ce que fournit @modelcontextprotocol/sdk, et toujours la ligne maintenue pour les correctifs de bugs et de sécurité de ce paquet | |
| Hébergement serverless et éphémère | Pensé pour une exécution courte en requête-réponse, ce qui rend plus propres les modèles Vercel, Cloud Run, Lambda et conteneurs autoscalés | Fonctionne mieux quand un processus peut conserver le contexte de session ; possible en serverless, mais plus lourd en exploitation | |
| Modèle de gestion de l'état | Force l'état dans des contextes clients explicites, des stockages partagés ou des bases applicatives ; plus propre, mais demande une refonte | Permet au code serveur de garder en mémoire des hypothèses de session, pratique pour de petits outils internes | |
| Compatibilité de l'écosystème aujourd'hui | La spécification est finale et la surface serveur TypeScript comme Python s'installent en 2.0.0 : une pile multilingue peut désormais bouger presque d'un seul bloc | La plupart des exemples, paquets et serveurs internes supposent encore le comportement v1, et quiconque importe le SDK TypeScript principal n'a pas d'alternative | |
| Autorisation et gouvernance | La spécification finale 2026-07-28 impose OAuth 2.0 Protected Resource Metadata (RFC 9728) pour annoncer l'emplacement du serveur d'autorisation, et inscrit une politique de dépréciation formelle dans la feuille de route du protocole | L'autorisation peut se gérer au niveau de la passerelle, mais la ligne de protocole est plus ancienne et moins explicite sur le nouveau modèle | |
| Risque de migration | Réparti désormais sur les deux registres : une installation non épinglée peut sauter en 2.0.0 sur quatre paquets npm à portée et sur pip install mcp sans que vous le demandiez — bornes de version et tests parallèles sont obligatoires | Faible si vous épinglez — mais le risque est désormais réel sur npm et sur PyPI, plus seulement sur npm | |
| Pérennité | Aligné sur une spécification désormais finale et non plus release candidate ; les paquets serveur et Python sont déjà là, le SDK principal est la seule pièce restante | Une base de compatibilité avec une sortie de secours nommée (server-legacy), mais livrée déjà dépréciée | |
| Score Total | 5/ 8 | 1/ 8 | 2 égalités |
Statistiques Clés
Données réelles provenant de sources vérifiées du secteur pour appuyer votre décision.
registre npm (@modelcontextprotocol/server)
Releases GitHub modelcontextprotocol/modelcontextprotocol
registre npm (@modelcontextprotocol/sdk)
PyPI (mcp)
registre npm (@modelcontextprotocol/server-legacy)
GitHub modelcontextprotocol/python-sdk
Blog Model Context Protocol
Spécification d'autorisation Model Context Protocol
Toutes les statistiques proviennent de sources tierces vérifiées. La source, l'année et le lien direct sont affichés pour chaque chiffre.
Quand Choisir Chaque Option
Un guide clair basé sur votre situation spécifique et vos besoins.
Choisissez MCP v2 sans état quand...
- Vous livrez des serveurs MCP en TypeScript (@modelcontextprotocol/server 2.0.0) ou en Python, où pip install mcp résout maintenant vers 2.0.0
- Vous avez besoin d'une mise à l'échelle horizontale sans sessions colles, ou d'un hébergement serverless et éphémère pour des outils distants
- Vous pouvez déplacer l'état de session vers les clients, des bases de données ou des stockages partagés avant la bascule
- Votre gouvernance exigeait un tag de spécification final avant la bascule — le tag 2026-07-28 est désormais final, plus un release candidate
Choisissez MCP v1 avec état quand...
- Votre code importe directement @modelcontextprotocol/sdk : il reste en 1.30.0 et aucune version 2.x n'est disponible
- Votre logique serveur repose encore sur des sessions longue durée, ou vos clients et adaptateurs ne sont pas testés contre un serveur sans état
- Vous exploitez une infrastructure v1 épinglée où une montée de version majeure sur place est plus risquée que la marge de scalabilité gagnée
- Votre processus de déploiement exige que l'outillage client et les serveurs partagent la même version majeure
Notre Recommandation
Quatre jours après l'échéance, le tableau a changé deux fois. La spécification est finale : le tag 2026-07-28 est passé en non-prerelease le 28 juillet à 16h47 UTC, l'objection de gouvernance à la bascule tombe donc. PyPI a suivi le même jour — pip install mcp résout désormais vers 2.0.0 (téléversé le 28 juillet à 13h45 UTC), et non plus vers la 1.28.1 encore en vigueur le matin de l'échéance. Ce qui n'a pas bougé, c'est le SDK TypeScript principal : @modelcontextprotocol/sdk reste en 1.30.0, publié le 2026-07-27 à 17h56 UTC. La ligne de partage n'oppose donc plus TypeScript et Python, mais les paquets serveur et Python d'un côté, et de l'autre l'unique paquet TypeScript principal qu'importe presque tout client sur mesure. Choisissez v2 sans état maintenant si vous développez des serveurs MCP en TypeScript (les paquets à portée @modelcontextprotocol/server, /node et /hono sont en 2.0.0 stable) ou en Python, et s'il vous faut une mise à l'échelle horizontale sans sessions colles, un routage résistant aux redémarrages et une exécution serverless propre. Restez en v1 avec état là où vous dépendez directement de @modelcontextprotocol/sdk — le code client et tout ce qui repose sur le SDK principal n'a aucun 2.x à installer — ou là où vos clients et adaptateurs n'ont pas été testés contre un serveur sans état. Épinglez dans tous les cas : quatre paquets npm à portée et le mcp de PyPI résolvent désormais latest vers 2.0.0, une installation non épinglée franchit donc seule une version majeure. Et rien n'a cassé le 28 juillet : les dépréciations de Roots, Sampling et Logging restent de simples annotations pendant au moins un an — migrez délibérément, paquet par paquet.
Questions Fréquentes
Réponses aux questions courantes sur cette comparaison.
Besoin d'aide pour décider ?
Réservez une consultation gratuite de 30 minutes et nous vous aiderons à déterminer la meilleure approche pour votre projet spécifique.