MCP

MCP hat jetzt einen Release-Kalender: Was SEP-3398, Server Cards und die Sicherheitswelle im Oktober für B2B-Deployments bedeuten

Von IdeaBosqueZuletzt aktualisiert: 2026年10月31日

Kernaussagen

Die MCP-Spezifikation erscheint jetzt auf festem Kalender — SEP-3398, angenommen am 14. Oktober 2026, legt Releases alle sechs Monate am letzten Dienstag von März und September fest und verschiebt das Dezember-2026-Ziel auf Ende März 2027.
Server Cards sind Final — SEP-2127 am 6. Oktober 2026 als Final gemergt und gibt MCP-Servern ein standardisiertes Metadatendokument, um Transports, Protokollversionen und Verbindungshinweise vor dem Verbindungsaufbau zu entdecken.
31 Security-Advisories in 28 Tagen in den offiziellen Repositories — laut der State-of-MCP-October-Zählung von eSEOspace, darunter zwei kritische Lücken in MCP Inspector, behoben im Security-Release 1.0.3 vom 21. Oktober.
Smithery-Proxy und verwaltete Identität wurden am 31. Oktober 2026 abgeschaltet — Smitherys eigene Mitteilung hat die run.tools- und server.smithery.ai-Server-URLs zurückgezogen — der klarste Beweis des Monats, dass gemietete Distributionsrouten Operating-Risiko sind.
Planen Sie den Winter auf der Spezifikation 2026-07-28 — der zustandslose Kern bleibt unberührt; das nächste Release kommt Ende März 2027, damit werden die Migrationsschritte kalenderplanbar statt changelog-reaktiv.

Der Smithery-MCP-Proxy und der Dienst für verwaltete Identität wurden am 31. Oktober 2026 — heute — abgeschaltet. Jede Agent-Deployment, das Server noch über run.tools- oder server.smithery.ai-URLs auflöst, ist mit ihnen ausgefallen; Smitherys eigene Mitteilung listet, was starb: die gehosteten Server-URLs, die API, Connect und Toolbox, Konten, API-Keys und die CLI. Der Migrationsweg führt zum Endpoint des Anbieters selbst — mcp.linear.app/mcp statt linear.run.tools — und Teams, die so einen nie hatten, mussten ihn heute erst schreiben.

In denselben 28 Tagen haben die MCP-Maintainer den ersten festen Release-Kalender des Protokolls angenommen, den Server-Cards-Entdeckungsstandard als Final gemergt und — laut eSEOspace-Zählung — 31 Security-Advisories in den offiziellen MCP-Repositories verzeichnet, zwei davon als kritisch in MCP Inspector eingestuft.

Diese Kombination ist ein einziger Übergang aus drei Blickrichtungen — Timing, Entdeckung und Betrieb. MCP hört auf, sich wie schnell bewegter Klebstoff zu verhalten, und verhält sich wie verwaltete Infrastruktur. Dieser Artikel liest den Oktober-Rekord als ein einziges Signal und zeichnet den Betriebsrhythmus nach, den er verlangt: die Spezifikationsversion pinnen, die Release-Termine in den Kalender bringen, die SDKs auf der Security-Release-Schiene halten und auf gemietete Distributionsrouten verzichten.

Er baut auf MCP 2026-07-28: Was das zustandslose Protokoll für B2B-Agenten-Deployments bedeutet auf, das den zustandslosen Kern, das explizite-Handles-Muster und die Deployment-Mathematik der Spezifikation vom 28. Juli behandelt hat. Hier geht es um das, was sich im Oktober um diese Spezifikation herum geändert hat — die Kadenz, die Entdeckungsschicht, den Advisory-Fluss und den Distribution-Ausfall. Die zustandslose These selbst wird von keinem davon berührt.

Der Oktober-Rekord in einem Blick

Bildunterschrift: Fünf Ereignisse in 28 Tagen haben MCP von einer rollenden Spezifikation in eine Plattform mit Kalender, Entdeckungsstandard, Security-Release-Schiene und erstem Drittanbieter-Distributionsausfall verwandelt.

Ein angenommener und dann konsolidierter Release-Kalender

SEP-3398 ist ein Prozess-SEP, und Prozess-SEPs machen selten Schlagzeilen — dieses hätte es verdient. Am 14. Oktober angenommen und am 27. Oktober gemergt, schreibt es den Release-Rhythmus von MCP verbindlich fest: Spezifikations-Releases alle sechs Monate, „in der Regel am letzten Dienstag von März und September", mit einem achtmonatigen Arbeitszyklus je Release — zwei Monate Planung, ein terminiertes Core-Maintainer-Review-Fenster und eine Stabilisierungsphase — wobei sich aufeinanderfolgende Zyklen um zwei Monate überlappen. Die Übergangsklausel erledigt den Rest: das vorgeschlagene Dezember-2026-Release-Ziel rückt auf Ende März 2027.

Für die Maintainer ist das Review-Kapazitätsmanagement. Für ein B2B-Deployment ist es Planungsinfrastruktur:

Die Deprecation-Fenster sind jetzt kalenderplanbar. Roots, Sampling, Logging und der veraltete HTTP+SSE-Transport tragen seit der Spezifikation vom 28. Juli bereits ein 12-Monate-Annotationsfenster. Ein fester Kalender macht aus „12 Monate ab dem 28. Juli" einen Termin auf derselben Roadmap wie die Release-Fenster der ERP-Systeme.
Unfertige Arbeit rutscht, das Datum nicht. Release-gebundene Vorschläge müssen bis zum Soft Freeze Final sein und gemergt sein; unfertige Vorschläge rutschen in einen späteren Zyklus, ohne das Release-Datum zu verschieben. Das ist das Verhalten, das Teams von Plattformanbietern erwarten — Vorhersehbarkeit vor Vollständigkeit.

Die unmittelbar praktische Aussage ist die, die eSEOspace aus den Oktober-Daten gezogen hat: Es ist keine neue Spezifikationsversion erschienen — die neueste ist weiterhin 2026-07-28, und der Kalender verlegt die nächste auf Ende März 2027. Der zustandslose Kern, auf den Ihr Deployment heute zielt, ist durch den Winter hindurch aktuell.

Server Cards: Entdeckung hört auf, eine Konfigurationsdatei zu sein

SEP-2127 (MCP Server Cards) wurde am 6. Oktober — vor dem Kalender-SEP — als Final gemergt und schließt die zweite Hälfte des Deployment-Problems. Die zustandslose Spezifikation definierte, wie ein Agent nach dem Verbindungsaufbau mit einem Server spricht. Server Cards definiert, wie ein Agent ohne manuelle Konfiguration einen Server findet: ein standardisiertes Metadatendokument, das Transports, Protokollversionen und Verbindungshinweise beschreibt, vom Server exponiert und von Clients lesbar, bevor irgendeine Verbindung geöffnet wird.

Die Mechanik, aus dem SEP selbst: Jeder Server exponiert seine Card — Cards können auf jeder nicht reservierten URI gehostet werden, <streamable-http-url>/server-card ist der empfohlene Ort — unter der Erweiterungskennung io.modelcontextprotocol/server-card. Ein domänenweiter „AI Catalog" kann die relevanten Cards verlinken oder einbinden — genau das macht Registry-Crawling und Service-Autoerkennung möglich, ohne jeden Endpoint handanzufassen.

Das B2B-Gegenstück ist die A2A-Agent-Card — .well-known/agent-card.json — die unsere A2A-Berichterstattung bereits als Basisausrüstung für Maschine-zu-Maschine-Entdeckung behandelt. Die Server Card ist dieselbe Idee für Protokollserver, und sie löscht das Artefakt, das die meisten Agent-Deployments heute pflegen: die handgeschriebene Liste der Server-Endpoints und ihrer Tool-Schemas. Wenn diese Liste zu entdeckbaren Metadaten wird, ändert sich die Betriebshaltung in drei Punkten — neue Server künden ihre eigene Oberfläche selbst an; veraltete Endpoints werden auditierbar (eine Card, die nicht mehr zum lebenden Server passt, ist ein Befund); und Anbieter-Upgrades brauchen keine Neukonfiguration mehr auf der Client-Seite.

SDK- und Client-Unterstützung ist der vom SEP erklärte nächste Schritt; der pragmatische Zug ist deshalb, jetzt darauf zu entwerfen: Endpoints mit einem Card-Ort bauen und die Server-Liste bereit halten, um Metadaten statt Konfiguration zu werden.

Die Sicherheitswelle des Oktober: Advisories sind Teil des Betriebsrhythmus

Die schärfsten Zeilen des Oktober-Rekords sind Sicherheitszeilen, und sie lesen sich wie der Patch-Tuesday eines Plattformanbieters statt wie das Changelog eines Hobbyprojekts. Zwei kritische Lücken in MCP Inspector wurden am 21. Oktober veröffentlicht, beide behoben im Security-Release 1.0.3:

GHSA-6x67-4w4w-9f3w — eine entfernte MCP App kann das Proxy-Auth-Token stehlen und beliebige lokale Befehle ausführen (RCE). Betroffene Versionen: Inspector 0.20.0 bis 1.0.2.
GHSA-4fc4-wcmh-4g86 — ein bösartiger MCP-OAuth-Callback kann den Transport auf stdio umschalten und beliebige lokale Befehle ausführen (RCE). Betroffene Versionen: 0.13.0 bis 1.0.2.

Außerhalb von Inspector ist die Oktober-Advisory des TypeScript SDK die mit B2B-Zähnen: GHSA-jm63-cq47-j5jp — „Ein geteilter Transport oder Server-Instanzen lieferten die Nachrichten eines HTTP-Clients an einen anderen" — hoch eingestuft, ab 2.0.0 anfällig, behoben in 2.3.0. Ein geteilter-Transport-Cross-Client-Datenleck ist genau die Defektklasse, die ein B2B-Deployment nicht tolerieren kann — und sie landete im Kernpaket des SDK, nicht in einer experimentellen Ecke.

Die Release-Daten erzählen die Plattformstory so deutlich wie die Schweregrade. Python SDK 2.3.0 erschien am 2. Oktober mit strengeren Header-Prüfungen bei der Tool-Registrierung; TypeScript SDK 2.4.0 erschien am 23. Oktober und fügte Skills-over-MCP (SEP-2640) hinzu; Kotlin 0.16.0 erschien am 27. Oktober, schloss Memory-Exhaustion-Löcher und stufte SSE als veraltet ein (Release; die Charakterisierung nach eSEOspaces Review der Release-Notes). Jedes große offizielle SDK hat im Monat mindestens einmal released, und laut eSEOspaces Review ist das Thema durch alle: Härtung — harte Grenzen für Request-Größe, Session-Anzahl und Speicher. Ihre Zählung der Advisories über die offiziellen Repositories — 31 in 28 Tagen — ist ihre eigene Bilanz, aber die Form, die sie beschreibt, ist verifizierbar: Die Security-Release-Schiene ist jetzt kontinuierlich, nicht sporadisch.

Die Lesart für Operatoren ist einfach. Wenn Ihr MCP-Bestand eine SDK-Update-Policy hat, ist der Oktober der Monat, in dem die zweimal auslösen musste. Hat sie das nicht, sind die Advisories oben das, was sich ansammelt.

Smithery: Der Vertrag der Distributionsschicht ist abgelaufen

Das dritte Ereignis ist das, das Ihr Betriebsteam heute spürt. Smitherys Mitteilung ist eindeutig: Am 31. Oktober 2026 hat Smithery seine Verbindungsverwaltungsdienste abgeschaltet — das heißt, jede run.tools- und server.smithery.ai-Server-URL, der gehostete Proxy-Pfad, die API, Konten, API-Keys und die CLI fielen aus. Das Verzeichnis smithery.ai bleibt als öffentliches Verzeichnis online, jetzt betrieben von Arcade.dev.

Die Migration ist geradlinig für Server mit anbieter-nativen Endpoints — Smitherys eigenes Beispiel ist, auf mcp.linear.app/mcp statt linear.run.tools zu zeigen. Für Deployments, die einen Proxy als Distributionsstrategie gebaut haben, ist es ein Sprint: keine anbieter-native URL, kein Vertrag darüber, was sie in Ihrer Steuerungsebene ersetzt, und keine Prüfung, wer sich verbindet, jetzt, da der Proxy, der den Verkehr aufzeichnete, weg ist.

Die Lehre verallgemeint sich über diesen einen Anbieter hinaus: Wenn der Endpoint, über den Ihre Agenten-Flotte MCP-Server auflöst, einem Dritten gehört, ist dessen Lebenszyklus eine Abhängigkeit, die Sie weder gewählt noch verfolgt haben. Der Oktober hat diesen Beweis geliefert — in demselben Monat, in dem das Protokoll die Entdeckungsmetadaten standardisierte und seinen eigenen Release-Kalender festzog. Die dauerhafte Position sind anbieter-native Endpoints, gemäß Smitherys eigener Migrationsanleitung, oder Endpoints, die Ihr Team betreibt — die Buy-vs-Build-Linie, die unsere MCP-Server-Schutz-Analyse für die Grenze zieht, beweist dieser Rekord für die Distribution.

Die Betriebs-Checkliste für B2B-MCP-Deployments

Bildunterschrift: Sechs Kontrollen, die das Oktober-Signal in Deployment-Politik umsetzen — jede antwortet auf ein datiertes Ereignis des Monats.

#	Kontrolle	Das Oktober-Ereignis, das sie beantwortet	Wie es im Deployment aussieht
1	Pinnen Sie die Spezifikationsversion	Keine neue Spezifikationsversion im Oktober; nächstes Release Ende März 2027	2026-07-28 explizit anvisieren; SDKs laufen lassen, die diese Version als unterstützt deklarieren; das Pin bei jedem Kalendertermin erneut prüfen
2	Bringen Sie die Release-Termine in den Kalender	SEP-3398: letzter Dienstag von März und September	Soft Freeze (T−2,5 Monate) und Hard Freeze (T−1 Monat) als Review-Fenster in die Team-Roadmap aufnehmen, nicht als Überraschungen
3	Bleiben Sie auf der Security-Release-Schiene der SDKs	31 Advisories im Oktober; zwei kritische in Inspector 1.0.3	SDK-Untergrenze auf das Security-Release pinnen (TS ≥ 2.3.0, Inspector ≥ 1.0.3); die Advisory-Feeds der offiziellen Repos abonnieren
4	Bevorzugen Sie anbieter-native oder selbst betriebene Endpoints	Smitherys `run.tools` / `server.smithery.ai` EOL am 31. Oktober	Jeden Nicht-Anbieter-Endpoint in der Server-Liste inventarisieren; proxy-abhängige Routen beenden oder selbst betreiben
5	Bauen Sie mit Blick auf Server-Cards-Metadaten	SEP-2127 Final am 6. Oktober, SDK-/Client-Unterstützung steht noch aus	Endpoints mit einem Card-Ort entwerfen; die Server-Liste bereit halten, damit sie entdeckbare Metadaten statt Konfiguration wird
6	Behandeln Sie die Registry als unüberprüft	52.141 Server im offiziellen Register, 66 % mit Remote-Endpoints (nach eSEOspaces Zählung)	Ein Eintrag ist kein Sicherheitssignal; wenden Sie das Modul-Freigabegate der Governance-Checkliste an, bevor ein Drittanbieter-Server sich verbindet

Was das für das Deployment-Muster 2026-07-28 bedeutet

Der zustandslose Kern, den unsere frühere Analyse festgelegt hat, ist der Teil von MCP, den der Oktober nicht berührt hat — und genau das verdient, ohne Umschweife ausgesprochen zu werden. SEP-3398 verlegt zukünftige Releases; es rüttelt nicht an der Spezifikation, auf die Sie den Winter über gepinnt sind. Server Cards fügt Entdeckung hinzu, ohne den Transport zu ändern. Die Advisories härten die SDKs auf derselben Protokollversion. Smitherys Abschaltung ist eine kommerzielle Entscheidung eines Dritten, kein Protokollereignis.

Wenn Ihr Deployment-Muster annahm, MCP bewege sich zu schnell zum Pinnen und sei zu jung für einen Kalender, ist der Oktober der Widerlegungs-Rekord. Teams, die vom Changelog-Gucken zum Kalender-Gucken konvertieren, werden das Release von Ende März 2027 als geplante Review behandeln; den Rest wird davon durch einen Ausfall erfahren.