29. Juli 2026

Warum MCP dich ab heute vergisst

Die neue MCP-Spec wirft Sessions raus. Was das für deinen Server bedeutet und was du bis wann anpassen musst.

Transparenz

Alle Blogeinträge entstehen mit Hilfe von KI und werden von einem Menschen nachbearbeitet und geprüft.

Du kennst das vom Amt. Du ziehst eine Wartemarke und wirst Schalter 4 zugeteilt. Ab dann gehörst du dort hin, egal wie lang die Schlange davor ist.

Schalter 7 ist frei? Egal. Deine Akte liegt bei Schalter 4.

Und wenn der Sachbearbeiter Feierabend macht, bevor du dran bist, fängst du morgen wieder von vorne an. Nicht weil dein Anliegen kompliziert wäre, sondern weil ein Stück Papier entschieden hat, wer für dich zuständig ist.

Genau so hat das Model Context Protocol bisher funktioniert. Heute ändert sich das.

Wobei MCP eigentlich hilft

MCP ist die Steckdose zwischen einem KI-Modell und deiner Software. Du beschreibst einmal, welche Funktionen dein System anbietet. Danach kann jedes Modell damit arbeiten, das MCP spricht.

Ohne so ein Protokoll bräuchtest du für Claude, ChatGPT und Copilot je eine eigene Anbindung. Mit MCP baust du eine. Das ist der Grund, warum es in zwei Jahren fast überall gelandet ist. Und der Grund, warum eine Änderung daran so viele Leute auf einmal betrifft.

Seit heute gilt eine neue Fassung. Der Entwurf lag seit Ende Mai vor, damit die Teams hinter den Programmierbibliotheken zehn Wochen Zeit hatten, ihn gegen echte Systeme zu testen. Es ist der größte Umbau, seit es das Protokoll gibt.

Die Wartemarke ist weg

Bisher begann jede Verbindung mit einem kurzen Hallo, in dem Modell und Server austauschten, wer sie sind und was sie können. Der Server merkte sich das Ergebnis und gab eine Marke zurück.

Ab jetzt fällt dieses Hallo weg. Und die Marke gleich mit.

Stattdessen bringt jede einzelne Anfrage alles mit, was der Server über sie wissen muss: wer da fragt, welche Fassung des Protokolls gesprochen wird, was erlaubt ist. Jedes Mal aufs Neue.

Der Preis dafür ist etwas mehr Ballast pro Anfrage, und den zahlst du bei jedem einzelnen Aufruf. Dafür ist der Server hinterher wieder komplett vergesslich.

Und wo stehen die Infos dann? Sie reisen in einem Metadaten-Feld jeder Anfrage mit. Was der Server kann, fragt das Modell bei Bedarf über eine eigene Methode ab. Beides steht weiter unten im Detail.

Was das für den Betrieb heißt

Links ein Nutzer mit fester Linie zu einem von drei Servern und einem gemeinsamen Speicher, rechts derselbe Nutzer mit Pfeilen zu allen drei Servern ohne Speicher — Links das alte Modell, rechts das neue. Der Unterschied ist eine ganze Infrastrukturschicht weniger.

Das klingt nach Protokoll-Kosmetik. Es ist die Stelle, an der sich Betriebskosten entscheiden.

Wenn jeder Schalter zuständig ist, kannst du beliebig viele davon aufmachen, ohne dass sie voneinander wissen müssen. Drei Server, ein Verteiler davor, fertig. Keine Extra-Datenbank, die sich merkt, wer gerade wo bedient wird.

Noch wichtiger ist, was beim Aktualisieren passiert. Bisher nahm ein Server beim Neustart alle laufenden Sitzungen mit ins Grab, und die Nutzer durften ihre Arbeit noch einmal von vorne beginnen. Ab jetzt merkt das schlicht niemand, weil es nichts mitzunehmen gibt.

Die Extra-Datenbank ist bei dieser Sorte Problem nie die eigentliche Schwierigkeit. Es sind die Momente, in denen ein Server neu startet und der Rest der Anwendung fröhlich so tut, als wäre nichts gewesen. Wer das einmal nachts gesucht hat, vergisst es nicht.

Vergesslich ist nicht dasselbe wie hilflos

Eine Person hält einen kleinen Zettel in der Hand und tritt damit vor drei gleichwertige Schalter — Die Marke war ein Befehl, das Aktenzeichen ist ein Werkzeug. Du trägst es, nicht der Server.

Jetzt die Frage, die sofort kommt: Was ist mit Warenkörben, Uploads und allem anderen, das über mehrere Schritte läuft?

Bleib beim Amt. Die Wartemarke ist weg, das Aktenzeichen nicht.

Dein Programm legt etwas an und gibt dem Modell eine Kennung zurück. Die schickt es beim nächsten Aufruf einfach wieder mit. Jeder Schalter kann damit arbeiten, weil die Kennung alles ist, was er braucht. Das Protokoll verwaltet den Zustand also nicht mehr für dich, hindert dich aber auch nicht daran, es selbst zu tun.

Das Nebenergebnis ist dabei fast interessanter als die Lösung selbst, denn der Zustand liegt jetzt sichtbar auf dem Tisch statt versteckt im Transport. Das Modell kann mehrere Kennungen gleichzeitig halten und sie zwischen Werkzeugen weiterreichen. Versteckte Sitzungsdaten konnten das nie.

Der Kern wird kleiner

Die zweite große Änderung betrifft nicht den Ablauf, sondern die Bauweise.

Bisher landete jede neue Fähigkeit im Kern des Protokolls. Das macht ihn mit jeder Fassung dicker und schwerer zu ändern.

Ab jetzt gibt es Erweiterungen mit eigenem Namen, eigener Werkstatt und eigener Versionsnummer. Modell und Server einigen sich beim Aufruf darauf, was beide davon beherrschen.

Zwei sind zum Start dabei.

Die eine erlaubt Servern, echte Bedienoberflächen mitzuliefern. Nicht nur Text zurück, sondern ein kleines Fenster mit Knöpfen, das die Anwendung abgeschottet anzeigt.

Die andere kümmert sich um Arbeit, die länger dauert als ein Aufruf: ein Video umrechnen, einen Bericht erzeugen, einen Import durchlaufen lassen. Der Server nimmt den Auftrag an und gibt eine Quittung zurück, mit der das Modell später nachfragen kann. Das Muster kennst du vom Paketdienst. An der Tür gibt es keine Ware, sondern eine Sendungsnummer.

Wie sicher ist so eine mitgelieferte Oberfläche? Die Oberfläche läuft in einer abgeschotteten Umgebung, und die Vorlagen dafür meldet der Server vorher an. Die Anwendung kann sie also vorab laden und prüfen. Jede Aktion daraus geht durch dieselbe Freigabe wie ein direkter Werkzeugaufruf.

Damit hast du das Wesentliche: ein Protokoll, das sich nichts mehr merkt, ein Zustand, der sichtbar durch die Aufrufe wandert, und ein Kern, der schlank bleibt, weil Neues nebenan wächst.

Das war der Teil, den du in der Kaffeeküche erzählen kannst. Ab hier wird es konkret: echte Aufrufe, echte Feldnamen, eine Liste zum Abarbeiten. Wenn du keinen Server betreibst, hast du alles Wichtige.

So sah ein Aufruf aus, so sieht er jetzt aus

Vorher brauchte jeder Aufruf die Sitzungskennung aus dem Handshake:

POST /mcp HTTP/1.1
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Content-Type: application/json

{"jsonrpc":"2.0","id":2,"method":"tools/call",
 "params":{"name":"palette_suchen","arguments":{"typ":"Euro"}}}

Jetzt trägt der Aufruf alles selbst:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: palette_suchen
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"palette_suchen","arguments":{"typ":"Euro"},
           "_meta":{"io.modelcontextprotocol/clientInfo":
                    {"name":"floplo-agent","version":"1.2"}}}}

initialize und initialized sind raus, der Header Mcp-Session-Id ebenfalls. Client-Infos, Protokollversion und Fähigkeiten reisen stattdessen in _meta bei jeder einzelnen Anfrage mit. Wer die Server-Fähigkeiten vorab braucht, holt sie sich über server/discover.

Wenn der Server eine Rückfrage hat

Vier Kästen in einer Reihe, der dritte hat einen Rücksprungpfeil zum zweiten, ein kleines Symbol wandert dabei mit — Der Aufruf wird nicht fortgesetzt, sondern wiederholt. Deshalb ist es egal, welche Instanz antwortet.

Manchmal muss ein Server mitten im Aufruf etwas vom Nutzer wissen, etwa eine Bestätigung vor dem Löschen. Früher hielt er dafür einen Datenstrom offen und wartete auf Antwort.

Ohne Sitzung geht das nicht mehr. Also antwortet er stattdessen so:

{
  "resultType": "inputRequired",
  "inputRequests": {
    "bestaetigung": {
      "type": "elicitation",
      "message": "3 Buchungen wirklich stornieren?",
      "schema": { "type": "boolean" }
    }
  },
  "requestState": "eyJzY2hyaXR0IjoxfQ=="
}

Der Client sammelt die Antwort ein und schickt denselben Aufruf ein zweites Mal, diesmal mit inputResponses und dem unveränderten requestState. Jede beliebige Instanz kann das übernehmen, weil alles Nötige im Payload steckt.

Dazu kommt eine Regel, die vorher nur eine Empfehlung war: Ein Server darf nur dann etwas vom Client wollen, während er gerade an dessen Anfrage arbeitet.

Drei Felder für den Betrieb

Der Rest der Transport-Änderungen betrifft vor allem die, die das Ding später überwachen dürfen.

Mcp-Method und Mcp-Name sind Pflicht-Header, damit Verteiler und Ratenbegrenzer nach Operation routen können, ohne den Body zu lesen. Widersprechen Header und Body sich, lehnt der Server ab.
Listen und Resource-Reads liefern ttlMs und cacheScope mit. Der Client weiß damit, wie lange ein tools/list frisch ist und ob er es über mehrere Nutzer hinweg teilen darf.
Trace Context nach W3C-Standard wandert in _meta, mit festgeschriebenen Schlüsselnamen. Ein Trace läuft dadurch vom Host über den Client bis in den Server und landet als ein einziger Span-Baum im OpenTelemetry-Backend.

Der letzte Punkt ist der unterschätzte. Verteiltes Tracing über Werkzeugaufrufe hinweg war bisher Bastelei, und zwar bei jedem, der es versucht hat.

Tasks bekommt einen neuen Lebenszyklus

Die Erweiterung für längere Arbeit ist die Stelle, an der du am ehesten wirklich anfassen musst, denn in der Vorgängerfassung war sie experimenteller Teil des Kerns.

Der Server antwortet auf tools/call mit einem Task-Handle, und der Client steuert ihn danach über tasks/get, tasks/update und tasks/cancel. Ob ein Aufruf überhaupt als Task läuft, entscheidet der Server, nicht der Client.

tasks/list ist ersatzlos gestrichen. Ohne Sitzungen lässt sich nun mal nicht sauber eingrenzen, wessen Tasks da eigentlich aufgelistet würden.

Drei alte Bekannte gehen in Rente

Roots, Sampling und Logging sind als veraltet markiert. Alle drei funktionieren weiter, und zwar mindestens ein Jahr lang.

Veraltet	Nachfolger
Roots	Tool-Parameter, Resource-URIs oder Server-Konfiguration
Sampling	Direkte Anbindung an die API deines Modell-Anbieters
Logging	`stderr` bei stdio, OpenTelemetry für strukturierte Observability

Das ist eine reine Markierung und kein Abschalten. Wer eines davon wirklich entfernen will, braucht dafür einen eigenen Antrag.

Auth rückt näher an OAuth

Sechs Änderungen härten die Autorisierung ab, zwei davon wirst du im Alltag merken.

Clients müssen den iss-Parameter in Autorisierungs-Antworten prüfen, wie es RFC 9207 beschreibt. Das kostet fast nichts und schließt eine Angriffsklasse, die bei MCP besonders greift: Ein Client redet dort typischerweise mit vielen Servern gleichzeitig, und genau da lassen sich Antworten vertauschen.

Bei der Dynamic Client Registration gibt der Client jetzt seinen application_type an. Damit hört der Klassiker auf, dass ein Autorisierungsserver eine Desktop-Anwendung für eine Web-App hält und ihre localhost-Redirect-URI ablehnt.

Eine Zahl, die Nerven kosten wird

Tool-Schemas dürfen jetzt vollständiges JSON Schema 2020-12 nutzen. Input-Schemas bleiben zwar ein Objekt an der Wurzel, erlauben darunter aber oneOf, anyOf, allOf, Bedingungen und Referenzen über $ref und $defs. Output-Schemas sind komplett frei, und structuredContent darf jeder JSON-Wert sein.

Zwei Einschränkungen gehören dazu: Externe $ref-URLs dürfen nicht automatisch aufgelöst werden, und Tiefe wie Prüfdauer der Schemas solltest du begrenzen.

Und dann ist da diese eine Zahl. Der Fehlercode für eine fehlende Ressource wechselt von -32002 auf das JSON-RPC-übliche -32602. Wenn dein Client irgendwo auf die alte prüft, such danach.

Was du jetzt tun solltest

Sortiert nach Aufwand, nicht nach Wichtigkeit:

Suche im Client nach -32002 und ersetze die Zahl.
Prüfe, ob irgendwo initialize oder Mcp-Session-Id fest verdrahtet ist.
Baue Sitzungszustand auf explizite Kennungen um, die als Argument reisen.
Stelle den Verteiler von Session-Affinität auf Routing nach Mcp-Method um.
Wechsle von der experimentellen Tasks-Schnittstelle auf die Erweiterung.
Roots, Sampling und Logging einplanen, nicht hetzen. Du hast mindestens ein Jahr.

Wie es weitergeht

Diese Fassung bricht bewusst mit dem Alten, und die Maintainer sagen ziemlich deutlich, dass das nicht der Normalfall werden soll. Drei Regeländerungen sollen künftige Umbauten abfedern.

Jede Funktion durchläuft ab jetzt einen festen Lebenszyklus aus aktiv, veraltet und entfernt, mit mindestens zwölf Monaten zwischen den letzten beiden Stufen. Neue Fähigkeiten starten als Erweiterung und dürfen dort reifen, statt sofort im Kern zu landen. Und ein Vorschlag wird erst dann endgültig, wenn ein passendes Szenario in der Conformance-Suite liegt.

Übersetzt heißt das: Wer heute gegen 2026-07-28 baut, sollte die nächste Runde ohne Transport-Umbau überstehen.

Quelle: The 2026-07-28 MCP Specification Release Candidate, Model Context Protocol Blog