MCP a désormais un calendrier de publication : ce que SEP-3398, Server Cards et la vague de sécurité d'octobre signifient pour les déploiements B2B

À retenir

• La spécification MCP publie désormais sur un calendrier fixe — SEP-3398, adopté le 14 octobre 2026, fixe des versions tous les six mois le dernier mardi de mars et de septembre et déplace la cible de décembre 2026 à fin mars 2027.
• Server Cards est Final — SEP-2127 fusionné en Final le 6 octobre 2026, donnant aux serveurs MCP un document de métadonnées standardisé pour la découverte pré-connexion des transports, des versions du protocole et des consignes de connexion.
• 31 avis de sécurité en 28 jours sur les dépôts officiels — d'après le décompte State of MCP October d'eSEOspace, dont deux critiques dans MCP Inspector corrigés dans la version de sécurité 1.0.3 du 21 octobre.
• Le proxy de Smithery et l'identité managée se sont arrêtés le 31 octobre 2026 — l'avis de Smithery lui-même a retiré les URLs run.tools et server.smithery.ai — la preuve la plus nette du mois que les routes de distribution louées sont un risque opérationnel.
• Planifiez sur la spécification 2026-07-28 pour tout l'hiver — le cœur sans état n'est pas affecté ; la prochaine version arrive fin mars 2027, si bien que les étapes de migration se mettent au calendrier au lieu de réagir au changelog.

Le proxy MCP de Smithery et le service d'identité managée se sont arrêtés le 31 octobre 2026 — aujourd'hui. Tout déploiement d'agents résolvant encore ses serveurs via des URLs run.tools ou server.smithery.ai a cessé de fonctionner avec ; l'avis de Smithery lui-même énumère ce qui est mort : les URLs de serveurs hébergés, l'API, Connect et Toolbox, les comptes, les clés API et la CLI. La migration passe par l'endpoint du fournisseur lui-même — mcp.linear.app/mcp au lieu de linear.run.tools — et les équipes qui n'en avaient jamais écrite une ont dû en écrire une aujourd'hui.

Dans les mêmes 28 jours, les mainteneurs de MCP ont adopté le premier calendrier de publication fixe du protocole, ont fusionné le standard de découverte Server Cards en Final et — d'après le décompte d'eSEOspace — enregistré 31 avis de sécurité dans les dépôts officiels de MCP, dont deux classés critiques dans MCP Inspector.

Cette combinaison est une seule transition vue sous trois angles — le calendrier, la découverte et les opérations. MCP a cessé de se comporter comme une colle à itération rapide et a commencé à se comporter comme une infrastructure managée. Cet article lit le relevé d'octobre comme un signal unique et cartographie le rythme opérationnel qu'il implique : épingler la version de la spécification, inscrire les jalons de publication au calendrier, tenir les SDK sur la voie des correctifs de sécurité, et cesser de louer des routes de distribution.

Cet article s'appuie sur MCP 2026-07-28 : ce que le protocole sans état signifie pour les déploiements d'agents B2B, qui couvrait le cœur sans état, le motif des handles explicites et la comptabilité de déploiement de la spécification du 28 juillet. Ici, l'accent porte sur ce qui a changé autour de cette spécification en octobre — la cadence, la couche de découverte, le flux des avis et la panne de distribution. La thèse sans état elle-même n'est touchée par rien de tout cela.

Le relevé d'octobre en une vue

Légende : cinq événements en 28 jours ont transformé MCP, d'une spécification déroulante, en une plateforme avec un calendrier, un standard de découverte, une voie de versions de sécurité et sa première panne de distribution tierce.

Un calendrier de publication adopté puis consolidé

SEP-3398 est un SEP de processus, et les SEP de processus font rarement des titres — celui-ci aurait dû en faire. Adopté le 14 octobre et fusionné le 27 octobre, il fixe par écrit le rythme de publication de MCP : des releases de la spécification tous les six mois, « généralement le dernier mardi de mars et de septembre », avec un cycle de travail de huit mois par release — deux mois de planification, une fenêtre de revue des Core Maintainers programmée, et une phase de stabilisation — où les cycles successifs se recouvrent de deux mois. La clause de transition fait le reste : la cible de publication de décembre 2026 passe à fin mars 2027.

Pour les mainteneurs, c'est de la gestion de capacité de revue. Pour un déploiement B2B, c'est de l'infrastructure de planification :

• Les fenêtres de dépréciation sont désormais programmables au calendrier. Roots, Sampling, Logging et le transport HTTP+SSE déprécié portaient déjà une fenêtre d'annotation de 12 mois depuis la spécification du 28 juillet. Un calendrier fixe transforme « 12 mois à compter du 28 juillet » en un jalon sur la même feuille de route que les fenêtres de release des ERP.
• Le travail inachevé glisse, la date ne bouge pas. Les propositions liées à la release doivent être Final et fusionnées avant le soft freeze ; les propositions inachevées glissent à un cycle ultérieur sans déplacer la date de release. C'est le comportement que les équipes attendent d'un fournisseur de plateforme — la prévisibilité avant l'exhaustivité.

La déclaration pratique immédiate est celle qu'eSEOspace a tirée des données d'octobre : aucune nouvelle version de la spécification n'est sortie — la plus récente reste 2026-07-28, et le calendrier déplace la suivante à fin mars 2027. Le cœur sans état que votre déploiement cible aujourd'hui reste d'actualité tout l'hiver.

Server Cards : la découverte cesse d'être un fichier de configuration

SEP-2127 (MCP Server Cards) a fusionné en Final le 6 octobre — avant le SEP du calendrier — et ferme la seconde moitié du problème de déploiement. La spécification sans état définissait comment un agent parle à un serveur une fois connecté. Server Cards définit comment un agent trouve un serveur sans configuration manuelle : un document de métadonnées standardisé décrivant transports, versions du protocole et consignes de connexion, exposé par le serveur et lisible par les clients avant toute ouverture de connexion.

La mécanique, d'après le SEP lui-même : chaque serveur expose sa card — les cards peuvent être hébergées sur tout URI non réservé, avec <streamable-http-url>/server-card comme emplacement recommandé — sous l'identifiant d'extension io.modelcontextprotocol/server-card. Un « AI Catalog » au niveau du domaine peut lier ou embarquer les cards pertinentes, ce qui rend possibles le crawl d'annuaires et l'auto-détection de services sans toucher chaque endpoint à la main.

Le parallèle B2B est l'agent card d'A2A — .well-known/agent-card.json — que notre couverture d'A2A traite déjà comme le socle de la découverte machine à machine. La Server Card est la même idée pour les serveurs de protocole, et elle supprime l'artefact que la plupart des déploiements d'agents entretiennent aujourd'hui : la liste écrite à la main des endpoints de serveurs et de leurs schémas d'outils. Quand cette liste devient des métadonnées découvrables, la posture opérationnelle change selon trois axes — les nouveaux serveurs annoncent leur propre surface ; les endpoints périmés deviennent auditables (une card qui ne correspond plus au serveur vivant est un constat en soi) ; et les mises à niveau des fournisseurs cessent de requérir une reconfiguration côté client.

Le support SDK et client est l'étape suivante déclarée du SEP ; le geste pragmatique est donc de concevoir dès maintenant : construire les endpoints en prévoyant un emplacement de card, et garder la liste de serveurs prête à devenir des métadonnées plutôt que de la configuration.

La vague de sécurité d'octobre : les avis font partie du rythme opérationnel

Les lignes les plus acérées du relevé d'octobre sont des lignes de sécurité, et elles se lisent comme le mardi des correctifs d'un fournisseur de plateforme plutôt que comme le changelog d'un projet amateur. Deux critiques de MCP Inspector sont parues le 21 octobre, toutes deux corrigées dans la version de sécurité 1.0.3 :

• GHSA-6x67-4w4w-9f3w — une MCP App distante peut voler le jeton d'authentification du proxy et exécuter des commandes locales arbitraires (RCE). Versions affectées : Inspector 0.20.0 à 1.0.2.
• GHSA-4fc4-wcmh-4g86 — un callback OAuth de MCP malveillant peut basculer le transport en stdio et exécuter des commandes locales arbitraires (RCE). Versions affectées : 0.13.0 à 1.0.2.

Hors Inspector, l'avis d'octobre du TypeScript SDK est celui qui a des dents B2B : GHSA-jm63-cq47-j5jp — « un transport partagé ou des instances de serveur livraient les messages d'un client HTTP à un autre » — classé élevé, vulnérable à partir de 2.0.0 et corrigé en 2.3.0. Une fuite de données inter-clients via transport partagé est exactement la classe de défaut qu'un déploiement B2B ne peut pas tolérer, et elle a débarqué dans le paquet central du SDK, pas dans un coin expérimental.

Les dates de publication racontent l'histoire de la plateforme aussi nettement que les sévérités. Python SDK 2.3.0 est sorti le 2 octobre avec des contrôles d'en-têtes plus stricts à l'enregistrement des outils ; TypeScript SDK 2.4.0 est sorti le 23 octobre en ajoutant la prise en charge de Skills-over-MCP (SEP-2640) ; Kotlin 0.16.0 est sorti le 27 octobre refermant les fuites mémoire et dépréciant SSE (release ; la caractérisation d'après la revue des notes de release d'eSEOspace). Tous les SDK officiels majeurs ont publié au moins une fois dans le mois, et d'après la revue d'eSEOspace, le thème qui les traverse est le durcissement : limites dures sur la taille des requêtes, le nombre de sessions et la mémoire. Leur décompte des avis sur les dépôts officiels — 31 en 28 jours — est leur propre comptabilité, mais la forme qu'il décrit est vérifiable : la voie des versions de sécurité est désormais continue, non épisodique.

La lecture pour l'exploitant est simple. Si votre parc MCP a une politique de mise à jour des SDK, octobre est le mois où la politique a dû se déclencher deux fois. Sinon, les avis ci-dessus sont ce qui s'accumule.

Smithery : le contrat de la couche de distribution a expiré

Le troisième événement est celui que votre équipe d'exploitation ressent aujourd'hui. L'avis de Smithery est sans ambiguïté : le 31 octobre 2026, Smithery a éteint ses services de gestion des connexions — ce qui veut dire que chaque URL de serveur run.tools et server.smithery.ai, le chemin de proxy hébergé, l'API, les comptes, les clés API et la CLI ont cessé de fonctionner. L'annuaire smithery.ai reste en ligne comme annuaire public, désormais propulsé par Arcade.dev.

La migration est directe pour les serveurs dotés d'endpoints natifs du fournisseur — l'exemple de Smithery lui-même consiste à pointer vers mcp.linear.app/mcp au lieu de linear.run.tools. C'est un sprint pour les déploiements qui ont bâti sur un proxy comme stratégie de distribution : pas d'URL native du fournisseur, pas de contrat sur ce qui la remplace dans votre plan de contrôle, et pas d'audit de qui se connecte maintenant que le proxy qui enregistrait le trafic n'est plus.

La leçon se généralise au-delà d'un fournisseur : si l'endpoint par lequel votre flotte d'agents résout les serveurs MCP appartient à un tiers, le cycle de vie de cet endpoint est une dépendance que vous n'avez ni choisie ni suivie. Octobre a livré cette preuve dans le même mois où le protocole standardisait les métadonnées de découverte et fixait son propre calendrier de publication. La position durable, ce sont les endpoints natifs du fournisseur, conformément aux consignes de migration de Smithery, ou des endpoints opérés par votre équipe — la ligne buy-vs-build que notre analyse de protection des serveurs MCP trace pour la frontière, et que ce relevé prouve pour la distribution.

La liste de contrôle opérationnelle pour les déploiements MCP B2B

Légende : six contrôles qui convertissent le signal d'octobre en politique de déploiement — chacun répond à un événement daté du mois.

#	Contrôle	L'événement d'octobre auquel il répond	À quoi cela ressemble dans le déploiement
1	Épinglez la version de la spécification	Aucune nouvelle version de spécification en octobre ; prochaine version fin mars 2027	Ciblez explicitement 2026-07-28 ; faites tourner des SDK déclarant cette version comme supportée ; revoyez l'épingle à chaque jalon du calendrier
2	Inscrivez les jalons de release au calendrier	SEP-3398 : dernier mardi de mars et de septembre	Placez le soft freeze (T−2,5 mois) et le hard freeze (T−1 mois) dans la feuille de route de l'équipe comme fenêtres de revue, pas comme surprises
3	Restez sur la voie des correctifs de sécurité des SDK	31 avis en octobre ; deux critiques dans Inspector 1.0.3	Épinglez le plancher des SDK à la version de sécurité (TS ≥ 2.3.0, Inspector ≥ 1.0.3) ; abonnez-vous aux flux d'avis des dépôts officiels
4	Préférez les endpoints natifs du fournisseur ou opérés par vous	L'EOL de run.tools / server.smithery.ai de Smithery le 31 octobre	Inventoriez chaque endpoint tiers de la liste de serveurs ; supprimez les routes dépendantes d'un proxy ou exploitez-les vous-même
5	Concevez pour les métadonnées Server Cards	SEP-2127 Final le 6 octobre, support SDK/client à venir	Concevez les endpoints avec un emplacement de card ; tenez la liste de serveurs prête à devenir des métadonnées découvrables, pas de la configuration
6	Traitez l'inscription au registre comme non vérifiée	52 141 serveurs dans le registre officiel, 66 % avec endpoints distants (selon le décompte d'eSEOspace)	Une inscription n'est pas un signal de sécurité ; appliquez la porte d'approbation de modules de la checklist de gouvernance avant de connecter un serveur tiers

Où cela laisse le modèle de déploiement 2026-07-28

Le cœur sans état que notre analyse antérieure a posé est la partie de MCP qu'octobre n'a pas touchée — et c'est le point qui mérite d'être énoncé sans détour. SEP-3398 re-programme les versions futures ; il ne dérange pas la spécification à laquelle vous êtes épinglé tout l'hiver. Server Cards ajoute la découverte sans toucher au transport. Les avis durcissent les SDK sur la même version du protocole. L'arrêt de Smithery est une décision commerciale tierce, pas un événement du protocole.

Si votre modèle de déploiement supposait que MCP va trop vite pour être épinglé et est trop jeune pour être calendaire, octobre est le relevé de la disconfirmation. Les équipes qui passent de la veille du changelog à la veille du calendrier traiteront la version de fin mars 2027 comme une revue programmée ; les autres l'apprendront par une panne.

Lectures connexes

• MCP 2026-07-28 : ce que le protocole sans état signifie pour les déploiements d'agents B2B — l'analyse d'origine : le cœur sans état, le motif des handles explicites et la comptabilité de déploiement de la spécification du 28 juillet, plus la proposition Server Cards dans son état pré-Final
• Sécurité MCP : modules gouvernés — la couche de gouvernance qui convertit les flux d'avis et d'approbation en contrôles au niveau du module
• Protection des serveurs MCP : acheter ou construire — la question de la frontière que ce relevé d'octobre étend à la distribution : quelles parties du chemin de connexion vous appartiennent

---

Une réalisation représentative : la plateforme d'agents d'un distributeur connectant NetSuite, BigCommerce et trois catalogues fournisseurs fait tourner chaque module MCP sur un endpoint natif du fournisseur ou opéré en propre, épinglé à la spécification 2026-07-28, avec les jalons de release de mars/septembre et les flux d'avis dans son runbook — de sorte qu'un arrêt de type Smithery et une version de sécurité de type 1.0.3 soient tous deux des tickets de routine, pas des pannes. Cette réalisation suit la méthode en quatre étapes Découverte → Gouvernance → Automatisation → Extension et est typiquement opérationnelle en 5–8 semaines.

Demandez une réalisation à périmètre défini. Une semaine de découverte. Vous recevez un inventaire des systèmes, une carte des flux de travail et un périmètre fixe — que vous construisiez avec nous ou non.