Spezifikations-Update: MCP wird erwachsen

Seit dem 21. Mai 2026 liegt der Release Candidate der nächsten MCP-Spezifikation vor, datiert auf den Versionsnamen 2026-07-28; die finale Fassung erscheint am 28. Juli. Inhaltlich ist es nicht der übliche additive Changelog, sondern die größte Strukturänderung seit Einführung des Protokolls: Der Core wird stateless, der initialize-Handshake entfällt, die Mcp-Session-Id verschwindet ganz.

In diesem Post gehe ich die zentralen Neuerungen an praktischen Beispielen durch; vom self-contained Tool-Call über explizite State-Handles bis zur server-gerenderten UI einer MCP App.

Ein Hinweis vorweg: Das volle 2026-07-28-Protokoll implementiert zum Zeitpunkt des Schreibens dieses Blogposts noch kein offizielles SDK – das Python-SDK liegt erst als v2.0.0a1 vor und deckt nur die alte 2025-11-25-Spec ab. Die Beispiele sind deshalb nach Spezifikation von Hand gebaut. Für den Zweck passt das gut: Ein MCP-Request ist letztlich ein HTTP-POST mit JSON-Body – von Hand nachgebaut wird genau das sichtbar, was ein SDK später hinter einer API verbirgt.

Vorher/Nachher: ein Tool-Call ohne Handshake

Der Kontrast zur bisherigen Welt macht die Änderung greifbar. In der Spec 2025-11-25 benötigte ein einzelner Tool-Aufruf einen Handshake und eine Session drei Schritte:

# 1) initialize -> der Server vergibt eine Session-ID
POST /mcp
   <- Mcp-Session-Id: sess-0001

# 2) tools/call OHNE Session -> abgelehnt
{"error":{"code":-32600,"message":"Mcp-Session-Id fehlt -- zuerst initialize"}}

# 3) tools/call MIT Session-Header -> erst jetzt erlaubt
POST /mcp
Mcp-Session-Id: sess-0001
{"method":"tools/call","params":{"name":"search","arguments":{"query":"mcp"}}}

Wie ein Server der alten Spec eine fehlende Session genau quittierte, war nicht normiert; der Fehlercode oben ist illustrativ. Verbindlich ist allein der erzwungene Dreischritt: ohne vorheriges initialize und ohne mitgeführte Session-ID kein Tool-Call.

Für horizontale Skalierung war dieses Modell aufwendig. Es erforderte entweder sticky routing, damit jeder Request derselben Session auf derselben Instanz landet, oder einen geteilten Session-Store, auf den alle Instanzen zugreifen. Beides ist Infrastruktur, die ausschließlich existiert, weil das Protokoll sie voraussetzt.

Im RC entfällt dieser erste Teil vollständig. Ein Tool-Call ist self-contained:

POST /mcp
Mcp-Method: tools/call
Mcp-Name: search
MCP-Protocol-Version: 2026-07-28

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"query":"mcp"},
           "_meta":{"client":{"name":"demo","version":"1.0.0"}}}}

Kein initialize, keine Mcp-Session-Id. Die Protokoll-Metadaten, die früher einmalig beim Handshake ausgetauscht wurden (Protokoll-Version, Client-Info, Capabilities), reisen jetzt pro Request mit: teils als Header (Mcp-Method, Mcp-Name, MCP-Protocol-Version), teils im _meta-Feld des Bodys. Der Beispielserver liest genau diese Header aus und protokolliert pro Request eine Zeile:

[MCP] method='tools/call'  name='search'  client=demo@1.0.0  protocol='2026-07-28'  session='NONE (stateless!)'

Die fehlende Session ist der entscheidende Punkt: Jeder Request kann auf jeder beliebigen Server-Instanz landen. Die neuen Header sind kein Selbstzweck: Mcp-Method und Mcp-Name erlauben einem Gateway, Requests zu routen, ohne den JSON-RPC-Body zu parsen. Horizontale Skalierung wird damit zur Aufgabe gewöhnlicher HTTP-Infrastruktur statt zur Frage der Session-Affinität.

„Stateless” bedeutet nicht „kein State”

… vielmehr wird der State jetzt sichtbar.

Damit stellt sich die naheliegende Frage: Wenn die Session entfällt, wo lebt der Zustand? Ein Warenkorb, eine mehrstufige Interaktion, ein halb ausgefüllter Vorgang verschwinden ja nicht.

Die Antwort des RC: Anwendungsstate bleibt zulässig, wandert aber aus dem Transport in die Anwendung. Statt einer impliziten Session-Eigenschaft vergibt ein Server ein explizites Handle. Eine schlichte ID also, die einen serverseitig gehaltenen Zustand benennt und die das Modell zwischen den Tool-Calls wie jedes andere Argument weiterreicht. Der Beispielserver bildet das mit einem Mini-Warenkorb ab: create_basket gibt eine basket_id zurück, add_item und checkout verlangen sie wieder. Genau dieses Muster führt die Spezifikation (SEP-2575) selbst als Referenzbeispiel (SEP-2567). Der Ablauf zeigt, wie das Handle durch die Calls fließt:

Schritt 1: create_basket()           -> basket_id = 'b_001'
Schritt 2: add_item(basket_id='b_001', kaffee x2)
Schritt 3: add_item(basket_id='b_001', kuchen x1)
Schritt 4: checkout(basket_id='b_001') -> Summe: 14.50 EUR

Im Server-Log trägt jeder dieser Calls basket_id=b_001 und keine Session. Der Zustand ist damit ein sichtbares Element, das durch die Konversation fließt, statt ein verstecktes Attribut des Transports zu sein. Wichtig: Das Handle ist kein neues Protokoll-Konstrukt! Aus Sicht der Spec ist basket_id schlicht ein String im Tool-Ergebnis und ein String im Tool-Argument. Das ist architektonisch sauberer, bedeutet für Bestandsserver aber Migrationsaufwand: Alles, was bisher stillschweigend an der Session hing, braucht künftig ein explizites Handle. Die Komplexität verschwindet nicht, sie verlagert sich an die Stelle, an die sie gehört.

MCP Apps: vom Text-Tool zur gerenderten Oberfläche

Der visuell auffälligste Teil des RC sind MCP Apps (SEP-1865). Anders als der stateless Core stehen sie bereits seit Anfang 2026 als stabile Extension bereit. Das Konzept: Ein Tool liefert nicht nur Text, sondern ein server-deklariertes HTML-Interface, das der Host in einem sandboxed iframe rendert.

Als Beispiel dient ein Währungsrechner: ein convert-Tool mit serverseitiger Kurstabelle, dazu ein Formular aus Betragsfeld, zwei Dropdowns und Ergebnisfeld. Entscheidend ist, was beim Klick auf „Umrechnen” geschieht: das UI rechnet nicht selbst. Es sendet eine ui/tool-call-Nachricht an den Host, der daraus serverseitig einen tools/call macht; dort wird gerechnet, und das Ergebnis kehrt in den iframe zurück. Die Kurse liegen ausschließlich auf dem Server, das UI muss ihn also aufrufen.

Der Währungsrechner im sandboxed iframe (links) und der Host-Trace (rechts): UI-Discovery per _meta, das resources/read der ui://-Resource und der ui/tool-call, der serverseitig zum tools/call wird

Genau dieser Roundtrip iframe → Host → Server ist die Kernaussage. Das Trace-Panel zeigt die ganze Kette: Der Host liest aus dem Tool-_meta die UI-Resource-URI und holt das HTML per resources/read (MIME-Typ text/html;profile=mcp-app). Nach dem Klick geht der ui/tool-call raus, wird serverseitig zum tools/call und liefert 100 EUR = 108 USD zurück. Die UI-Aktion läuft über dieselbe JSON-RPC-Schiene – und damit denselben Audit- und Consent-Pfad … wie ein direkter Tool-Call. Da die UI-Templates vorab als ui://-Resource deklariert werden, kann der Host sie prefetchen und einem Security-Review unterziehen, bevor etwas ausgeführt wird.

Der Mock-Host im Beispiel bildet diesen Ablauf spec-nah ab; vereinfacht bleibt allein die Sandbox-Schichtung: eine iframe-Ebene statt der spezifizierten zwei (Proxy plus Guest).

Einordnung: Fundament-Umbau statt Glanz-Feature

In der Summe wird MCP nicht durch ein spektakuläres Feature produktionsreif, sondern durch die unauffälligen Änderungen: einen stateless Core, der horizontales Skalieren auf gewöhnliche HTTP-Infrastruktur reduziert, und explizite Handles, die Anwendungsstate sichtbar machen. Hinzu kommen (in diesem Beitrag nur gestreift, weil ohne lauffähiges Beispiel) ein Auth-Hardening, das den Server formal zum OAuth-2.0-Resource-Server macht, sowie erstmals eine Deprecation-Policy mit garantierten zwölf Monaten zwischen Deprecation und Removal. Das sind keine Features, sondern Infrastruktur. Genau daran lässt sich Produktionsreife erkennen.

Universell ist der Umbau dabei nicht. Wer einen MCP-Server als einzelne Instanz hinter einem internen Load Balancer betreibt, für den ist sticky routing kein Problem: der stateless-Vorteil zielt auf horizontale Skalierung, und die braucht nicht jeder. Der Aufwand lohnt sich vor allem dort, wo mehrere Instanzen im Spiel sind.

Wer seine Server auf die neue Spec umbauen will, hat drei Aufgaben.

Erstens: den State-Umgang auf explizite Handles umstellen. Alles, was bisher implizit an der Session hing, wird zu einem Handle, das das Modell durchreicht.

Zweitens: den Auth-Layer gegen die neuen Authorization-SEPs abgleichen.

Drittens: prüfen, ob eines der abgekündigten Features im Einsatz ist, und es gegebenenfalls ersetzen. Drei Features gehen mit diesem Release als Erste in die Deprecation:

• Roots – der Client teilt dem Server mit, welche Verzeichnisse oder URIs er freigibt. Ersatz: Tool-Parameter, Resource-URIs oder Server-Konfiguration.
• Sampling – der Server bittet den Client (Host), einen LLM-Aufruf für ihn auszuführen, statt selbst ein Modell anzubinden. Ersatz: der direkte Aufruf einer LLM-Provider-API.
• Logging – ein protokoll-eigener Kanal, über den der Server Log-Nachrichten an den Client schickt. Ersatz: stderr bei stdio, OpenTelemetry für strukturierte Observability.

Die in diesem Beitrag aufgeführten Änderungen sind die, mit dem größten Hebel … und die, die sich am besten am Beispiel zeigen lassen. Der RC bringt darüber hinaus noch mehr mit: eine Tasks-Extension für langlaufende Operationen, das formalisierte Extensions-Framework, Multi-Round-Trip-Requests für mehrstufige Server-Rückfragen sowie Betriebs-Details wie Caching-Direktiven (ttlMs/cacheScope) und W3C Trace Context im _meta.

Quellen

• Release Candidate 2026-07-28
• SEP-2575 (Make MCP Stateless)
• SEP-2567 (Sessionless MCP via Explicit State Handles)
• SEP-1865 (PMCP Apps)
• Python-SDK v2.0.0a1 (Release Notes)