Seit der Revision laufen damit mindestens zwei Protokollgenerationen nebeneinander. Die vier offiziellen Programmbibliotheken der ersten Stufe für TypeScript, Python, Go und C# unterstützen die neue Fassung laut dem Projektblog seit dem Veröffentlichungstag.

Welche Änderungen die Revision vom 28. Juli 2026 am Protokollkern vornimmt

Die Änderungsübersicht der Spezifikation nennt als größten Einschnitt den Wegfall der Sitzungen. Nach der Revision trägt jede Anfrage ihre Protokollversion und die Fähigkeiten des Clients selbst mit; einen Austausch nach dem Muster initialize und initialized gibt es nicht mehr. Server müssen stattdessen eine neue Abfrage namens server/discover anbieten, über die ein Client unterstützte Versionen und Fähigkeiten erfragen kann. Braucht ein Server Zustand über mehrere Aufrufe, vergibt er nach der Spezifikation eine eigene Kennung, die als gewöhnliches Argument eines Werkzeugaufrufs zurückkommt.

Im Projektblog vom 28. Juli 2026 begründen die Maintainer den Schritt mit dem Betrieb im großen Maßstab. Laut dem Beitrag zählten die Programmbibliotheken der ersten Stufe zu diesem Zeitpunkt knapp eine halbe Milliarde Downloads im Monat, die Bibliotheken für TypeScript und Python überschritten jeweils eine Milliarde Downloads insgesamt. Jede Anfrage kann nach der neuen Fassung auf jeder Serverinstanz hinter einem einfachen Lastverteiler landen, ohne gemeinsamen Speicher.

Warum offen erreichbare Remote-Server das eigentliche Risiko bleiben

Mit der Zustandslosigkeit wird ein entfernt betriebener MCP-Server technisch zu einem gewöhnlichen Webdienst. Welche Integrationen Entwicklerteams im Jahr 2026 besonders häufig anbinden, zeigt der Vergleich zwölf verbreiteter MCP-Server-Integrationen der Provimedia GmbH. Die Frage der Anmeldung wird damit dringlicher, denn ein Webdienst ohne Zugangskontrolle ist für jeden aufrufbar.

Forschende der Fudan-Universität haben am 21. Mai 2026 die nach eigener Angabe erste Messstudie zur Authentifizierung realer Remote-MCP-Server auf dem Preprint-Server arXiv veröffentlicht. Über Suchmaschinen für Internetdienste identifizierten sie 7.973 erreichbare Server; 3.233 davon, also 40,55 Prozent, legten ihre Werkzeuge laut der Studie ohne jede Authentifizierung offen. Jeder Client kann dort Werkzeuge aufrufen oder Anfragen an angebundene Dienste auslösen, ohne sich auszuweisen.

Wie die neue Fassung die Anmeldung von Clients neu ordnet

Für die Server mit OAuth-Anmeldung prüfte das Team der Fudan-Universität 119 testbare Installationen genauer und fand an jeder mindestens einen Fehler, insgesamt 325. Fehler bei der dynamischen Client-Registrierung, also der automatischen Anmeldung unbekannter Clients beim Autorisierungsserver, betrafen laut der Studie vom Mai 2026 96,6 Prozent der geprüften Server. Über die verantwortungsvolle Meldung an die Betreiber erhielten die Forschenden neun Kennungen im Verzeichnis Common Vulnerabilities and Exposures (CVE), der öffentlichen Liste bekannter Sicherheitslücken.

Die Revision 2026-07-28 setzt an genau dieser Stelle an. Die dynamische Client-Registrierung ist dort als abgekündigt eingestuft, bevorzugt werden sogenannte Client ID Metadata Documents nach einem Entwurf der Normungsorganisation IETF. Clients müssen den Aussteller einer Autorisierungsantwort nach RFC 9207 prüfen, bevor sie einen Autorisierungscode einlösen. Gespeicherte Zugangsdaten eines Clients sind nach der Spezifikation an den Autorisierungsserver gebunden, der sie ausgestellt hat.

Was Teams beim Wechsel auf die Revision 2026-07-28 prüfen

Vier Änderungen der Fassung betreffen den Betrieb eines Servers unmittelbar:

• Sitzungen: Der Kopf Mcp-Session-Id und der Handshake entfallen; Zustand wandert in ausdrücklich vergebene Kennungen.
• Kopfzeilen: Anfragen über Streamable HTTP tragen Methode und Werkzeugname in den Kopfzeilen Mcp-Method und Mcp-Name, sodass Gateways danach filtern können.
• Anmeldung: Aussteller-Prüfung nach RFC 9207, an den Aussteller gebundene Zugangsdaten und Client ID Metadata Documents statt dynamischer Registrierung.
• Abkündigungen: Roots, Sampling und Logging sowie der alte Transport HTTP+SSE gelten als abgekündigt und sollen in neuen Implementierungen nicht mehr eingebaut werden.

Die Kopfzeilen erleichtern auch die Absicherung. Eine Firewall für Webanwendungen oder ein Gateway kann Aufrufe nach Methode begrenzen, ohne den Inhalt jeder Anfrage auszulesen.

Ab wann abgekündigte Verfahren aus dem Protokoll fallen

Die Versionsregeln des Projekts legen seit der Revision einen festen Ablauf fest. Abgekündigte Funktionen bleiben mindestens zwölf Monate Teil der Spezifikation, in einer Ausnahme für beschleunigte Entfernung mindestens 90 Tage, bevor eine spätere Revision sie streichen darf. Die Roadmap vom 22. August 2026 setzte die Identität von Agenten und die Härtung des HTTP-Transports als Schwerpunkte; einen Termin für die folgende Revision nannte sie nicht.

„Ein Protokoll ohne Sitzung ist einfacher zu betreiben, aber es verzeiht keinen offenen Server mehr. Wer einen KI-Assistenten an Werkzeuge anbindet, sollte die Anmeldung vor der Skalierung klären. Die abgekündigte Registrierung ist ein guter Anlass, jede bestehende Anbindung einmal durchzugehen“, sagt Alexander Weipprecht, Geschäftsführer der Provimedia GmbH.

Für Teams mit eigenen MCP-Servern ergibt sich daraus eine Reihenfolge. Zuerst klärt ein Blick in die Serverkonfiguration, ob die Werkzeuge ohne Anmeldung erreichbar sind. Danach folgt der Wechsel der Bibliotheken auf die Fassung 2026-07-28 mit den Migrationshinweisen des Projekts, zuletzt der Abschied von der dynamischen Client-Registrierung, solange die Spezifikation sie noch aus Gründen der Rückwärtskompatibilität mitführt.