FR
Réserver un appel

Technologie

MCP v2 sans état vs MCP v1 avec état (2026) : Python en 2.2.0, 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.

Vérifié par Michael Kerkhoff, état au

Définition
Le 28 juillet 2026 était l'échéance de migration MCP, et la réponse honnête a changé dans les heures qui ont suivi. Vérification refaite sur les registres le 1er août : le tag 2026-07-28 du dépôt de spécification est désormais final (prerelease=false, publié le 2026-07-28T16:47:49Z), et PyPI a fait passer mcp en 2.0.0 le même jour. Les deux objections qui définissaient le jour de l'échéance — une spécification seulement en RC et un écosystème Python bloqué en 1.28.1 — ont donc disparu. Une lacune subsiste : le SDK TypeScript principal, @modelcontextprotocol/sdk, reste en 1.30.0 depuis le 27 juillet. MCP v2 fait passer le cœur du protocole à un modèle requête/réponse sans état et ajoute Extensions, Tasks, MCP Apps, un durcissement de l'autorisation et une politique de dépréciation formelle. MCP v1 reste la ligne de base maintenue — et, si votre code importe le SDK TypeScript principal, la seule chose que vous puissiez installer. Revérifié le 08/09/2026 : mcp sur PyPI est désormais en 2.2.0 (avec un backport v1.30.0 le même jour), tandis que @modelcontextprotocol/sdk stagne en 1.30.0 sur npm depuis six semaines.
Catégorie
Technologie
Options
MCP v2 sans étatMCP v1 avec état

Comparaison Détaillée

Une analyse comparative des facteurs clés pour vous aider à faire le bon choix.

MCP v2 sans état vs MCP v1 avec état
FacteurMCP v2 sans étatMCP v1 avec état
Montée en charge horizontaleChaque requête peut viser n'importe quelle instance compatible dès que l'état applicatif sort du serveur de protocole GagnantLes sessions longues et l'affinité de connexion sont plus simples à comprendre, mais compliquent l'autoscaling et le basculement
Stabilité du SDKLivraison 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 principalToujours 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èrePensé 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 GagnantFonctionne mieux quand un processus peut conserver le contexte de session ; possible en serverless, mais plus lourd en exploitation
Modèle de gestion de l'étatForce l'état dans des contextes clients explicites, des stockages partagés ou des bases applicatives ; plus propre, mais demande une refontePermet 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'huiLa 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 GagnantLa 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 gouvernanceLa 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 GagnantL'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 migrationRé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 obligatoiresFaible si vous épinglez — mais le risque est désormais réel sur npm et sur PyPI, plus seulement sur npm Gagnant
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 GagnantUne base de compatibilité avec une sortie de secours nommée (server-legacy), mais livrée déjà dépréciée
Durcissement sécurité (septembre 2026)2.x est la ligne de durcissement : redirections liées à l'origine depuis la 2.2.0, vérification de l'émetteur sur chaque chemin OAuth, validation du token-resource en option, expiration des sessions — les leçons de confinement des incidents SSRF à agents, livrées dans le client Gagnantv1.30.0 ne backporte que la liaison d'origine des redirections ; la vérification de l'émetteur sur le chemin legacy et les nouveaux contrôles d'auth/session restent hors de 1.x, qui ne reçoit plus que de la maintenance
Score Total · 2 égalités6 / 91 / 9

Statistiques Clés

Données réelles provenant de sources vérifiées du secteur pour appuyer votre décision.

  • Les paquets serveur MCP — @modelcontextprotocol/server, /node, /hono et /server-legacy — ont publié leur première version stable 2.0.0 le 27/07/2026 à 23h55 UTC, cinq minutes avant l'échéance, après quatre alphas et cinq bêtas. — registre npm (@modelcontextprotocol/server) (2026)
  • Le tag de spécification 2026-07-28 est final : GitHub indique prerelease=false, publié le 2026-07-28T16:47:49Z — la première spécification MCP finale depuis le 2025-11-25. — Releases GitHub modelcontextprotocol/modelcontextprotocol (2026)
  • Le SDK TypeScript principal n'a toujours pas de 2.x : @modelcontextprotocol/sdk est en 1.30.0 sur le tag latest, publié le 2026-07-27 à 17h56 UTC — il n'a pas bougé quand les paquets serveur, PyPI et la spécification sont passés en final. — registre npm (@modelcontextprotocol/sdk) (2026)
  • Le mcp de PyPI est passé en 2.0.0 le 2026-07-28T13:45:28Z, remplaçant la 1.28.1 publiée le 2026-06-26 — un simple pip install mcp installe désormais v2. — PyPI (mcp) (2026)
  • La porte de sortie v1 a été livrée déjà dépréciée : server-legacy est publié comme « transport SSE v1 gelé et assistants OAuth Authorization Server… Déprécié ; utilisez StreamableHTTP et un serveur OAuth dédié en production. » — registre npm (@modelcontextprotocol/server-legacy) (2026)
  • Selon les mainteneurs, 84 % des plus de 10 000 paquets PyPI dépendant de mcp ne déclarent aucune borne supérieure : une installation non épinglée peut donc tirer une pré-version v2 incompatible. — GitHub modelcontextprotocol/python-sdk (2026)
  • Les dépréciations de Roots, Sampling et Logging au 28 juillet sont de simples annotations : ces méthodes, types et indicateurs de capacité continuent de fonctionner dans cette version et dans toute version publiée dans l'année — les serveurs v1 existants ne cassent donc pas le 28 juillet. — Blog Model Context Protocol (2026)
  • Les serveurs MCP DOIVENT implémenter OAuth 2.0 Protected Resource Metadata (RFC 9728) pour annoncer l'emplacement de leur serveur d'autorisation ; le RC du 28/07/2026 restreint en outre les requêtes initiées par le serveur aux seuls moments où il traite activement une requête client (SEP-2260). — Spécification d'autorisation Model Context Protocol (2026)
  • La ligne Python du SDK est passée à 2.2.0 sur PyPI le 07/09/2026, quatre semaines après que 2.0.0 est devenu le réflexe pip — tandis que @modelcontextprotocol/sdk reste bloqué à 1.30.0 sur npm, six semaines après l'échéance de migration. — PyPI (mcp) + registre npm (@modelcontextprotocol/sdk) (2026)
  • python-sdk v2.2.0 restreint les redirections HTTP client à l'origine du point d'accès (schéma, hôte, port) : une redirection cross-origin échoue désormais avec MCPError — la classe SSRF des évasions d'agents Hugging Face est fermée au niveau bibliothèque. — modelcontextprotocol/python-sdk release v2.2.0 (#3397) (2026)
  • Le durcissement n'est pas réservé à 2.x : un backport v1.30.0 publié le même jour porte la même règle d'origine liée (#3448) — mais la validation de l'émetteur sur le chemin d'auth legacy et les contrôles de session n'existent qu'en 2.x. — modelcontextprotocol/python-sdk release v1.30.0 (07/09/2026) (2026)
  • v2.2.0 ajoute des garde-fous d'exploitation : les sessions Streamable-HTTP stateful inactives expirent après 30 minutes et les serveurs plafonnent à 10 000 sessions simultanées — configurables, sans impact sur les connexions stateless ou spécification 2026-07-28. — notes de version python-sdk v2.2.0 (#3395) (2026)
  • 23 septembre 2026 (15 h 45 UTC) : la ligne TypeScript rejoint l'ère v2 — @modelcontextprotocol/server et @modelcontextprotocol/node publient tous deux la 2.1.0, en phase avec le modèle PyPI 2.2.0 ; l'API serveur stateless-first existe désormais dans les deux familles SDK principales. — npm registry (2026)

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.

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. Septembre 2026 rend l'asymétrie opérationnelle : avec la 2.2.0 et le backport v1.30.0 sortis le même jour, le confinement des redirections est devenu un minimum sur les deux lignes — mais la validation de l'émetteur, les contrôles token-resource et la gestion de session restent réservés à 2.x. La ligne v1 ne reçoit plus que de la maintenance, plus de progression ; si vous attendiez une raison de planifier la bascule, la voilà. Au 23/09/2026 : avec server et node tous deux en 2.1.0, la ligne 2.x est le défaut dans les deux familles de paquets — les épinglages 1.x restants relèvent désormais de la dette de transition plutôt que de la stabilité.

Choisissez MCP v2 sans état quand...
  • @modelcontextprotocol/server 2.0.0) ou en Python, où pip install mcp résout maintenant vers 2.2.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

Réponses aux questions courantes sur cette comparaison.

Questions Fréquentes

(01)MCP v2 a-t-il réellement été publié le 28 juillet 2026 ?
Oui, par étapes, et l'essentiel est arrivé le jour même. Les paquets serveur TypeScript à portée sont passés en 2.0.0 stable le 27 juillet à 23h55 UTC ; le mcp de PyPI est passé en 2.0.0 le 28 juillet à 13h45 UTC ; et le tag de spécification 2026-07-28 est passé en non-prerelease le 28 juillet à 16h47 UTC. Il ne reste que le SDK TypeScript principal, @modelcontextprotocol/sdk, toujours en 1.30.0.
(02)MCP v2 est-il prêt pour la production aujourd'hui ?
Pour les serveurs, largement oui : la spécification est finale, les paquets serveur TypeScript sont en 2.0.0 stable et Python installe 2.0.0 par défaut. La lacune restante est côté client et bibliothèques — tout ce qui importe @modelcontextprotocol/sdk est encore en 1.30.0. Pilotez d'abord la couche serveur et gardez épinglé le code dépendant du SDK principal.
(03)Faut-il épingler les dépendances MCP maintenant ?
Plus urgemment que le jour de l'échéance. Le tag latest résout maintenant vers 2.0.0 sur quatre paquets npm à portée et sur le mcp de PyPI : une installation non épinglée franchit donc seule une version majeure. Les mainteneurs indiquent que 84 % des plus de 10 000 paquets PyPI dépendant de mcp ne déclarent aucune borne supérieure — cette population est désormais exposée en pratique, plus seulement en théorie.
(04)À quoi sert @modelcontextprotocol/server-legacy ?
C'est la porte de sortie v1 nommée, et elle a été livrée déjà dépréciée : transport SSE v1 gelé et assistants OAuth Authorization Server, publiés avec la consigne d'utiliser StreamableHTTP et un serveur OAuth dédié en production. Utilisez-la pour maintenir un serveur v1 pendant la migration — pas comme destination.
(05)MCP sans état signifie-t-il que l'application ne peut pas conserver d'état ?
Non. Sans état signifie que le serveur de protocole ne doit pas dépendre d'une session longue pour répondre à une requête. Votre application peut toujours conserver un état, mais il doit vivre dans le client, une base de données, un cache ou une autre couche de persistance explicite.
(06)Qui doit migrer en premier vers MCP v2 ?
Les équipes qui exploitent à grande échelle une infrastructure de serveurs MCP distants, en TypeScript comme en Python : elles gagnent un load balancing ordinaire, un routage sans état et une autorisation plus claire, et les deux langages disposent maintenant d'un 2.0.0 stable. Les équipes dont le code importe le SDK TypeScript principal devraient attendre son 2.x, faute de quoi que ce soit à installer.
(07)Que change la version de durcissement des SDK du 7 septembre dans cette décision ?
Elle met fin à l'attente sur les deux lignes. mcp 2.2.0 et le backport v1.30.0 sont sortis le même jour, le confinement des redirections est donc partout standard — mais la validation de l'émetteur, les contrôles token-resource et la gestion de session n'existent qu'en 2.x. Rester en v1 signifie recevoir les correctifs en retard et passer à côté des contrôles, ce qui renforce discrètement le basculement, même pour les équipes prudentes.

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.

Réserver une Consultation GratuiteNous Écrire

Consultation gratuite · Sans engagement · Réponse personnelle