Vom Kiwop-Team · Digitalagentur spezialisiert auf Softwareentwicklung und angewandte Künstliche Intelligenz · Veröffentlicht am 29. Juli 2026 · Zuletzt aktualisiert: 29. Juli 2026
TL;DR — Am 28. Juli 2026 erschien die fünfte Revision von MCP, und sie verändert mehr als alles seit der Geburt des Protokolls. Sitzungen und der `initialize`-Handshake entfallen: Jede Anfrage reist allein und trägt ihre Version und Capabilities in `_meta`. Die Anfragen, die früher der Server initiierte (Sampling, Elicitation, Roots), wechseln zum Multi-Round-Trip-Muster. Neu sind Pflicht-Header fürs Routing ohne Body-Parsing, cachebare Listen und eine strengere Autorisierung. Läuft Ihr Server lokal über stdio, eilt es nicht. Ist er remote und hält eine Sitzung, beginnt der Umbau heute. Veraltetes hält zwölf Monate.
Es gibt Protokoll-Updates, die in eine Changelog-Zeile passen, und andere, die verändern, wie die Software ausgerollt wird, die sie spricht. Revision 2026-07-28 von Model Context Protocol gehört zur zweiten Sorte. Sie fügt einem bekannten Protokoll keine weitere Funktion hinzu: Sie nimmt ihm das Gedächtnis. Und wenn ein Protokoll aufhört, sich zu erinnern, ändert sich nicht die API, sondern die Architektur von allem, was darunter läuft.
Im April haben wir unseren Vergleich von MCP, WebMCP und A2A veröffentlicht und geschrieben, der nächste relevante Meilenstein sei die Konsolidierung des Streamable-HTTP-Transports und das Auslaufen des Legacy-SSE. Beides ist eingetreten, und nebenbei kam deutlich mehr, als wir erwartet hatten. Dieser Artikel ist die technische Lesart davon, was sich genau ändert, was bricht und was ein Team tun muss, das bereits MCP-Server in Produktion betreibt. Mit der Spezifikation in der Hand, nicht mit der Zusammenfassung der Pressemitteilung.
Was am 28. Juli erschien
MCP entstand im November 2024, damit ein Modell mit externen Werkzeugen sprechen kann, ohne dass jede Integration ein maßgeschneiderter Adapter wird. Seit Dezember 2025 regiert Anthropic es nicht mehr allein: Das Protokoll lebt unter der Agentic AI Foundation innerhalb der Linux Foundation, mit Anthropic, OpenAI, Google, Microsoft, AWS, Block, Cloudflare und Bloomberg unter den Mitgliedern. Diese geteilte Governance erklärt den Ton dieser Revision, die viel mehr nach Infrastrukturstandard klingt als nach der API eines Anbieters.
Revision 2026-07-28 ist die fünfte der Spezifikation und bringt zwei Prozessneuerungen mit, die genauso wichtig sind wie die technischen Änderungen. Erstens: Es gibt endlich eine formale Feature-Lifecycle-Policy mit drei Zuständen (Aktiv, Veraltet, Entfernt) und einem Mindestfenster von zwölf Monaten, bevor etwas verschwindet. Zweitens: Es gibt ein öffentliches Register veralteter Funktionen mit dem frühesten Datum, an dem jede fallen darf. Wer Software in Produktion betreut, für den ist das so viel wert wie das Protokoll selbst, denn es macht Planung zu etwas, das in eine Roadmap passt.
Die grundlegende Änderung: von der Sitzung zur eigenständigen Anfrage
Bis zu dieser Revision hieß MCP sprechen, ein Gespräch zu eröffnen. Der Client schickte initialize, der Server antwortete mit seinen Capabilities, der Client bestätigte mit notifications/initialized, und von da an setzten beide den Kontext als bekannt voraus: welche Version gesprochen wird, was jeder kann, wer wer ist. Über HTTP wurde dieses Gespräch zu einem Mcp-Session-Id-Header, den der Server vergab und der Client bei jedem Aufruf wiederholte.
All das ist verschwunden.
Was entfällt
Der initialize-Handshake und seine Benachrichtigung notifications/initialized entfallen. Der Header Mcp-Session-Id entfällt und mit ihm das Konzept einer Sitzung auf Protokollebene. Der GET-Endpunkt des Streamable-HTTP-Transports entfällt, über den der Server seinen Kanal öffnete, um aus eigener Initiative zu sprechen. resources/subscribe und resources/unsubscribe entfallen. ping, logging/setLevel und notifications/roots/list_changed entfallen. Und die Wiederaufnahme von SSE-Streams entfällt: Last-Event-ID und Event-Identifikatoren gibt es nicht mehr, ein abgerissener Stream verliert also die laufende Anfrage, und der Client muss sie als neue Anfrage mit neuer Kennung erneut senden.
Die Liste ist lang, und das ist kein Zufall. Alles, was gegangen ist, hatte dieselbe Eigenschaft: Es setzte voraus, dass die Verbindung etwas bedeutet.
Was an seine Stelle tritt
Jetzt erklärt sich jede Anfrage selbst. Was früher einmal zu Beginn festgelegt wurde, reist im Feld _meta jedes Aufrufs, unter von der Spezifikation reservierten Schlüsseln:
protocolVersion und clientCapabilities sind in jeder Anfrage Pflicht: Fehlt eines davon, muss der Server mit -32602 ablehnen und über HTTP mit 400 Bad Request. clientInfo ist empfehlenswert, sofern Sie keinen Grund haben, sich nicht zu identifizieren. Auf Serverseite lautet die Empfehlung, io.modelcontextprotocol/serverInfo in das _meta jedes Ergebnisses aufzunehmen. Lesen Sie die Anmerkung der Spezifikation zu diesen beiden Feldern genau: Sie sind selbst deklariert, niemand prüft sie, und sie dürfen weder Sicherheitsentscheidungen tragen noch Verhalten ändern.
Auch die Versionsverhandlung ändert ihren Charakter. Es gibt keinen Moment der Einigung mehr: Der Client erklärt in jeder Anfrage, welche Version er spricht, und der Server nimmt jede einzeln an oder ab. Unterstützt er sie nicht, antwortet er mit UnsupportedProtocolVersionError (Code -32022) und einer Liste der Versionen, die er unterstützt, damit der Client mit einer kompatiblen erneut anfragt.
Für Clients, die es vorab wissen wollen, gibt es eine neue Methode, server/discover, die unterstützte Versionen, Capabilities und Identität in einem Aufruf zurückgibt. Server müssen sie implementieren. Clients können sie nutzen oder nicht: Es ist völlig gültig, den gewünschten Aufruf abzusetzen und den Versionsfehler zu behandeln, falls er auftaucht.
Warum das eine gute Nachricht ist
Die praktische Folge: Ein MCP-Server braucht kein Gedächtnis mehr zwischen Aufrufen, und das ändert alles beim Deployment. Ohne Sitzung braucht es kein Sticky Routing im Load Balancer, keinen gemeinsamen Speicher zwischen Instanzen, keine langlebigen Prozesse. Ein MCP-Server wird zu dem, was jedes Plattformteam seit Jahren zu betreiben weiß: ein zustandsloser HTTP-Endpunkt, der horizontal skaliert, serverless oder am Edge ausgerollt wird und ohne Altlasten hoch- und runterfährt.
Die Spezifikation sagt ausdrücklich, dass nicht einmal ein offener stdio-Prozess als Gespräch zu verstehen ist: Der Client darf unzusammenhängende Anfragen über denselben Transport verschachteln, und der Server darf die Prozessidentität nicht als Ersatz für Kontinuität verwenden. Braucht Ihr Server echten Zustand zwischen Aufrufen (eine Arbeitssitzung, einen Warenkorb, einen Analysekontext), ist der richtige Weg jetzt explizit: Vergeben Sie selbst eine Kennung und lassen Sie den Client sie als normales Argument des Werkzeugs übergeben.
Multi Round-Trip Requests: das Ende der Server-Anfragen
Die zweite große Änderung ist die, die in Servern mit interessanter Logik den meisten Code berührt.
Brauchte ein Server bisher mitten in einer Operation etwas vom Client (eine Nutzerantwort per Elicitation, einen Modellaufruf per Sampling, die Verzeichnisliste per Roots), öffnete er seine eigene JSON-RPC-Anfrage in Gegenrichtung. Das erzwang einen offenen Kanal und in der Praxis, dass dieselbe Instanz die gesamte Operation bediente.
Das neue Muster heißt Multi Round-Trip Requests und dreht den Ablauf um: Der Server fragt nicht, der Server beendet die Anfrage mit einer Rückfrage. Er liefert ein Ergebnis mit resultType: "input_required", das eine Map inputRequests mit dem Benötigten enthält, und optional ein undurchsichtiges requestState. Der Client sammelt diese Information und wiederholt die ursprüngliche Anfrage mit den Antworten in inputResponses und dem unverändert zurückgegebenen requestState.
Drei Details, die man beim schnellen Lesen übersieht und die später einen Nachmittag Debugging kosten. Die JSON-RPC-id der Wiederholung muss sich unterscheiden von der ursprünglichen Anfrage, denn es sind unabhängige Anfragen. requestState ist für den Client undurchsichtig, er darf es weder inspizieren noch verändern, aber aus Serversicht ist es vom Angreifer kontrollierte Eingabe: Beeinflusst es Autorisierung oder Geschäftslogik, muss es mit HMAC oder AEAD geschützt, kurz befristet, an den authentifizierten Principal und die Ursprungsanfrage gebunden und bei fehlgeschlagener Prüfung abgelehnt werden. Und InputRequiredResult darf nur bei prompts/get, resources/read und tools/call zurückgegeben werden, sonst nirgends.
Als Nebeneffekt tragen alle Ergebnisse jetzt ein Pflichtfeld resultType, im Normalfall "complete". Sprechen Sie mit einem Server einer früheren Revision, der es weglässt, gilt es als "complete".
Die übrigen Änderungen, die Sie merken werden
Pflicht-Header fürs Routing. Jede POST-Anfrage über Streamable HTTP muss Mcp-Method mit der Methode tragen und Mcp-Name mit dem Werkzeugnamen oder der Ressourcen-URI bei tools/call, resources/read und prompts/get. Das klingt nach Bürokratie, bis man überlegt, wer vor Ihrem Server steht: Ein Load Balancer, ein Gateway oder eine WAF kann jetzt routen, messen und Richtlinien anwenden, ohne den JSON-Body zu öffnen. Der Server ist verpflichtet zu prüfen, dass Header und Body übereinstimmen, und andernfalls mit 400 und HeaderMismatch (-32020) abzulehnen. Es gibt sogar einen Mechanismus, um bestimmte Werkzeugparameter in Header zu spiegeln (x-mcp-header), gedacht etwa fürs Routing nach Region.
Cachebare Listen. Die Ergebnisse von tools/list, prompts/list, resources/list, resources/read und resources/templates/list tragen jetzt ttlMs und cacheScope (public oder private). Ersteres ist ein Frischehinweis, damit der Client cacht statt zu fragen; Letzteres sagt, ob ein gemeinsamer Zwischenknoten es speichern darf. Und es gibt eine kleine Empfehlung mit großer Wirkung: Werkzeuge in tools/list in deterministischer Reihenfolge zurückgeben, damit der Prompt des Modells zwischen Aufrufen gleich bleibt und der Prompt-Cache des LLM häufiger trifft.
Subscriptions. Was früher über ein GET lief, wird jetzt mit subscriptions/listen angefordert, einer Anfrage, deren Antwort ein offen bleibender Stream ist. Der Client wählt, was er abonniert (toolsListChanged, promptsListChanged, resourcesListChanged, resourceSubscriptions), und der Server markiert jede Benachrichtigung mit io.modelcontextprotocol/subscriptionId. Fortschritts- und Log-Benachrichtigungen laufen weiterhin über den Stream der Anfrage, zu der sie gehören, nicht hierüber.
Autorisierung. Drei Verschärfungen. Autorisierungsserver sollten den Parameter iss gemäß RFC 9207 mitgeben, und der Client muss ihn gegen den hinterlegten Issuer prüfen, bevor er den Code einlöst. Zugangsdaten sind an den ausstellenden Issuer gebunden: nach ihm indiziert gespeichert, nie mit einem anderen wiederverwendet, und bei Wechsel des Autorisierungsservers ist eine Neuregistrierung fällig. Und die dynamische Client-Registrierung (DCR, RFC 7591) gilt zugunsten der Client ID Metadata Documents als veraltet, bleibt aber für Autorisierungsserver verfügbar, die CIMD noch nicht unterstützen.
Fehler. Es gibt endlich eine Vergabepolitik: -32000 bis -32019 bleibt Altbestand, den niemand neu verwenden sollte, und -32020 bis -32099 gehört exklusiv der Spezifikation. Die drei neuen Codes sind HeaderMismatch (-32020), MissingRequiredClientCapability (-32021) und UnsupportedProtocolVersion (-32022). Außerdem wandert der Fehler für nicht gefundene Ressourcen von -32002 zu -32602, wobei Clients den alten von älteren Servern weiterhin akzeptieren sollten.
Tasks außerhalb des Kerns. Die experimentellen Tasks verlassen das Basisprotokoll und werden eine offizielle Erweiterung (io.modelcontextprotocol/tasks), mit Polling über tasks/get statt des blockierenden tasks/result. In derselben Linie erhalten Client- und Server-Capabilities ein Feld extensions, um alles außerhalb des Kerns auszuhandeln.
Was bricht und was nicht
Diese Tabelle sollten Sie vor sich haben, bevor Sie etwas anfassen. Die Spezifikation nennt modern die Versionen, die Metadaten in jeder Anfrage tragen (ab 2026-07-28), und legacy jene mit Handshake (2025-11-25 und früher).
Entscheidend sind die zwei Zeilen, die fehlschlagen: Ein alter Client kann nicht mit einem rein modernen Server sprechen, und er kann nichts dagegen tun. Deshalb verlangt die Spezifikation, dass ein rein moderner Server in dem Fehler, mit dem er auf ein initialize antwortet, die unterstützten Versionen nennt: Es kann die einzige Diagnose sein, die der Nutzer dieses Clients je zu sehen bekommt.
Ein Server, der beide Welten bedienen will, kann das und entscheidet danach, wie der Client eröffnet: Trägt die Anfrage modernes _meta, bedient er sie zustandslos; kommt ein initialize, geht er in den alten Modus. Ein Client, der dasselbe will, erkennt die Ära des Servers je nach Transport: bei stdio durch eine Sondierung mit server/discover und Rückfall auf initialize bei jedem Fehler, der kein erkennbar moderner ist; über HTTP durch eine moderne Anfrage und einen Blick in den Body des 400, bevor er entscheidet. Dieses Ergebnis wird pro Server gecacht, nicht pro Anfrage.
Was Sie ändern müssen, je nach Fall
Wenn Sie MCP-Server lokal über stdio nutzen, was auf die meisten persönlichen Assistenten und fast alles zutrifft, was in einer IDE läuft, eilt es nicht. Ihr Client und Ihre Server verhandeln die Version, die beide sprechen, und die vorige Revision bleibt gültig. Fällig ist, das SDK zu aktualisieren, wenn Sie diesen Server ohnehin aus anderem Grund anfassen, keine eigene Migration. Genau das werden wir mit den Servern des persönlichen Assistenten machen, den wir mit Claude Code gebaut haben.
Wenn Sie einen Remote-Server mit Sitzung betreiben, gibt es hier Architekturarbeit, und zwar jetzt. Das ist kein Bibliothekswechsel: Es geht darum, den Zustand aus dem Prozess zu holen. Inventarisieren Sie, was Sie heute zwischen Aufrufen halten, und entscheiden Sie für jedes Element, ob es entfällt (weil der Client es jetzt in _meta schickt), ob es ein expliziter Handle wird, den der Client als Argument mitführt, oder ob es in einen externen Speicher wandert, indiziert nach diesem Handle. Alles, was darauf beruht, dass zwei Aufrufe auf derselben Instanz landen, gilt als tot. Der Lohn ist real: Am Ende läuft Ihr Server serverless.
Wenn Ihr Server Anfragen an den Client öffnet (Sampling, Elicitation oder Roots), müssen Sie diesen Ablauf mit MRTR neu bauen. Das ist die Änderung, die am meisten Logik bewegt, denn Sie wechseln von einem Gesprächsmodell zu einem, in dem jeder Versuch eigenständig ist und der Kontext im requestState reist, das Sie signieren und prüfen. Fangen Sie damit an, nicht mit dem Rest.
Wenn Sie einen neuen MCP-Server beginnen, bauen Sie direkt auf 2026-07-28. Es gibt keinen Grund, heute auf dem Sitzungsmodell zu bauen, und einen dagegen: In zwölf Monaten würden Sie migrieren, was Sie gerade geschrieben haben.
Wenn Sie einen Client pflegen, ist die Arbeit anders und wahrscheinlich größer: Sie müssen beide Ären lange Zeit unterstützen, cachen, was jeder Server spricht, und die Degradierung mit Augenmaß behandeln. Die vier Tier-1-SDKs (TypeScript, Python, Go und C#) unterstützen die neue Revision bereits, das Rust-SDK ist in Beta, ein guter Teil davon kommt also fertig, wenn Sie aktuell bleiben.
Der reale Zeitplan
Das Beste an der Lifecycle-Policy: Man kann mit Daten planen statt mit Gerüchten. Das ist veraltet, und so lange hält es:
Achten Sie auf die letzte Zeile, das ist die wirklich eilige. Der HTTP+SSE-Transport galt seit März 2025 als veraltet und tritt jetzt formal in die Policy ein, mit einem Fenster von nur drei Monaten. Wenn bei Ihnen noch etwas darüber spricht, ist das die dringende Migration, nicht die anderen.
Entfernbar heißt nicht, dass es an diesem Tag entfernt wird: Die Entscheidung treffen die Maintainer bei jedem Release, und sie kann später fallen. Aber es ist das Datum, mit dem sich planen lässt.
Was wir tun würden
Drei Kriterien, die wir bei dieser Art von Änderung anwenden und die hier besonders gelten.
Migrieren Sie nicht, um aktuell zu sein, sondern aus einem Grund. Ein funktionierender stdio-Server muss diese Woche nicht angefasst werden. Die Kosten einer grundlosen Migration sind nicht nur die Zeit: Sie bringen Risiko in etwas, das lief. Das Zwölf-Monats-Fenster existiert, um genutzt zu werden.
Dringend ist, was jetzt entworfen wird. Jeder neue MCP-Server und jede Plattform, die ihre API für Agenten öffnet, wird ab dem ersten Tag zustandslos entworfen. Das ist die Entscheidung, deren spätere Änderung am teuersten wird, denn sie ist keine Bibliothek, sondern die Frage, wie Sie Arbeit über Instanzen verteilen. Bei uns fließt das direkt ein, wie Nexo seine Fähigkeiten für die Agenten seiner Kunden bereitstellen wird: Der Entwurf entsteht gegen die neue Revision, nicht gegen die uns bekannte.
Vorsicht beim Bauen von Produkt auf experimentellen Oberflächen. Das haben wir mit WebMCP gelernt: Wir setzten auf einen Chrome Origin Trial, und eine Änderung auf Browserseite zerlegte die Navigation unserer eigenen Website, bei grünen Health Checks. MCP 2026-07-28 ist nicht experimentell, aber die Lehre gilt genauso: Wenn Sie frisch Veröffentlichtes übernehmen, wissen Sie, wie Sie es abschalten, falls es schiefgeht, und prüfen Sie das Ergebnis mit Händen und Augen, nicht nur mit einem Statuscode 200.
Häufige Fragen
Bricht heute etwas, wenn ich nichts tue? Nein, sofern Ihr Client und Ihre Server dieselbe Revision sprechen. Was lief, läuft weiter, und die vorige Revision bleibt unterstützt. Es bricht, wenn Sie Ären mischen: ein alter Client gegen einen Server, der nur die neue spricht, oder umgekehrt.
Wie viel Zeit habe ich wirklich? Mindestens zwölf Monate für Roots, Sampling, Logging und die dynamische Client-Registrierung, gerechnet ab dem 28. Juli 2026. Die Ausnahme ist der HTTP+SSE-Transport, der drei Monate nach Finalisierung seines Vorschlags fallen kann.
Muss ich `server/discover` implementieren? Wenn Sie einen Server schreiben, ja: Es ist Pflicht. Wenn Sie einen Client schreiben, nein: Sie können den gewünschten Aufruf absetzen und den Versionsfehler behandeln, falls er auftaucht. Bei stdio ist es zudem der empfohlene Weg zu erkennen, ob der Server gegenüber modern oder alt ist.
Was mache ich mit dem Zustand, den ich in der Sitzung hielt? Holen Sie ihn aus dem Prozess. Was Protokollkontext war, reist jetzt im _meta jeder Anfrage. Was Anwendungszustand ist, wird eine explizite Kennung, die Sie vergeben und der Client als Argument zurückgibt, mit den echten Daten bei Bedarf in einem externen Speicher.
Betrifft das WebMCP? Nein. WebMCP ist der Browser-Vorschlag, getrieben von Chrome und bearbeitet im W3C, und geht seinen eigenen Weg. Es ist eine andere Schicht: MCP verbindet den Agenten mit serverseitigen Werkzeugen, WebMCP stellt Aktionen der Website bereit, die der Nutzer offen hat.
Und Desktop-Clients wie Claude oder ChatGPT? Die Produkte übernehmen die neue Revision in ihrem Tempo, und keines hat konkrete Daten veröffentlicht. Bis dahin verhandeln sie mit jedem Server eine Version, die Koexistenz ist also von Haus aus vorgesehen.
Fazit
Die kurze Lesart von 2026-07-28: MCP verhält sich nicht mehr wie ein Gespräch, sondern wie eine API. Jede Anfrage erklärt sich selbst, der Server erinnert sich nicht, und alles, was Gedächtnis brauchte, wurde neu entworfen oder gestrichen. Das macht das Protokoll langweiliger zu lesen und ungleich einfacher zu betreiben, und genau das braucht etwas, das Infrastruktur sein will.
Für die meisten Teams lautet die praktische Antwort dieser Woche: nichts Dringendes tun und gut planen. Für alle mit Remote-Servern samt Sitzung oder kurz davor, den Zugang ihrer Plattform für Agenten zu entwerfen, gilt das Gegenteil: Die Arbeit beginnt jetzt, und sie beginnt damit, den Zustand aus dem Weg zu räumen.
Wenn Sie zur zweiten Gruppe gehören und den Entwurf mit jemandem prüfen wollen, der es bereits getan hat, sprechen wir. Wir bauen seit zwei Jahren produktiv auf LLMs, betreiben MCP-Server und haben die Rechnung dafür bezahlt, Dinge zu früh zu übernehmen.
