Epovest
Deutsch English Français Español Italiano Português
← Alle Leitfäden

Leitfaden

MCP 2026-07-28: die zustandslose Überarbeitung und was sie von Ihrem Server verlangt

Von Simon Vasconcelos Lee

Gründer von Epovest

Am 28. Juli 2026 hat das Model Context Protocol seine größte Überarbeitung seit der Einführung der Autorisierung erhalten. Ein einziger Satz trägt fast alles: das Protokoll hat keinen Handshake mehr. Die Version, die Identität des Clients und seine Fähigkeiten reisen ab sofort auf jeder Anfrage mit, und der Server nimmt jede Anfrage für sich an oder weist sie zurück.

Alles Weitere folgt aus diesem Satz. Es folgt, was die Überarbeitung entfernt, was an die Stelle tritt, und die Handvoll Anforderungen, die man leicht übersieht, weil nichts laut scheitert, wenn man sie auslässt. Wir haben unseren eigenen MCP-Server am 2. August 2026 auf 2026-07-28 gehoben: die Prüfliste am Ende ist die, die wir dabei abgearbeitet haben.

Was die Überarbeitung entfernt

  • Protokollsitzungen und den Header Mcp-Session-Id. Listenergebnisse unterscheiden sich nicht mehr von Verbindung zu Verbindung. Ein Server, der Zustand über mehrere Aufrufe hinweg braucht, prägt einen ausdrücklichen Schlüssel und reicht ihn als gewöhnliches Werkzeugargument weiter.
  • Den Handshake initialize und die Bestätigung notifications/initialized, die ihn abschloss.
  • ping, logging/setLevel und notifications/roots/list_changed. Die Protokollstufe wird jetzt pro Anfrage in _meta gesetzt.
  • Den eigenständigen GET-Strom. Änderungsbenachrichtigungen laufen über eine einzige langlebige Anfrage subscriptions/listen, und der Client abonniert genau die Typen, die er empfangen will.
  • Die Wiederaufnahme eines abgerissenen Stroms. Last-Event-ID und die SSE-Ereigniskennungen entfallen. Ein abgerissener Strom verliert die laufende Anfrage, und der Client stellt sie mit einer neuen Kennung erneut.

Begründet wird das mit der Betriebsform. Ein Server ohne Sitzungszustand steht hinter einem gewöhnlichen Lastverteiler und skaliert wie jeder andere HTTP-Dienst, ohne gemeinsamen Speicher und ohne klebendes Routing. Das war das Ziel der Roadmap 2026, und mit dieser Überarbeitung ist es erreicht.

Was an die Stelle des Handshakes tritt

server/discover. Server MÜSSEN diese Methode anbieten. Sie antwortet in einem einzigen Aufruf mit den Protokollversionen, die der Server bedient, seinen Fähigkeiten und seiner Identität. Ein Client KANN sie zuerst aufrufen, um die Version vorab zu wählen, oder darauf verzichten und einen Versionsfehler unterwegs behandeln.

Metadaten pro Anfrage. Jede Anfrage trägt ihren eigenen Kontext:

"_meta": {
  "io.modelcontextprotocol/protocolVersion": "2026-07-28",
  "io.modelcontextprotocol/clientInfo": { "name": "example-client", "version": "1.0.0" },
  "io.modelcontextprotocol/clientCapabilities": {}
}

Über HTTP steht dieselbe Version zusätzlich im Header MCP-Protocol-Version, und beide müssen übereinstimmen.

Austausch über mehrere Runden. Ein Server, der Sampling, eine Rückfrage an den Nutzer oder die Liste der Wurzeln braucht, schickt keine eigene Anfrage mehr über einen Strom. Er liefert ein Ergebnis mit resultType: "input_required" und einem Feld inputRequests, und der Client wiederholt die ursprüngliche Anfrage mit den passenden inputResponses. Die vom Server ausgehende Anfrage verlässt als Form das Protokoll.

Tasks werden zur Erweiterung. Die experimentellen Tasks verlassen den Kern und werden zur offiziellen Erweiterung io.modelcontextprotocol/tasks, mit einem abfragbaren tasks/get statt eines blockierenden tasks/result.

Fünf leicht übersehene Anforderungen

Es sind die, die eine Code-Durchsicht überstehen und an einem strengen Client scheitern.

  1. resultType auf jedem Ergebnis. Ein gewöhnliches Ergebnis trägt "complete". Fehlt das Feld, weil der Server auf einer früheren Überarbeitung geblieben ist, muss der Client es als "complete" lesen.
  2. Cache-Hinweise sind Pflicht, nicht Kür. ttlMs und cacheScope gehören auf die Ergebnisse von server/discover, tools/list, prompts/list, resources/list, resources/templates/list und resources/read. ttlMs ist eine Frischedauer in Millisekunden; cacheScope ist "public" oder "private" und entscheidet, ob ein gemeinsam genutzter Vermittler die Antwort ablegen darf.
  3. Zwei Anfrage-Header, die der Server prüfen muss. Mcp-Method auf jeder Anfrage, Mcp-Name auf tools/call, resources/read und prompts/get. Sie spiegeln Werte aus dem Rumpf, damit ein Gateway routen und autorisieren kann, ohne ihn zu lesen, und genau deshalb MUSS ein Server jede Abweichung zwischen Header und Rumpf mit 400 zurückweisen. Ein Wert, der nicht in einen druckbaren ASCII-Header passt, reist base64-kodiert zwischen =?base64? und ?=, und der Server dekodiert ihn vor dem Vergleich.
  4. Neue Fehlercodes in einem für die Spezifikation reservierten Bereich. -32020 für einen Header, der dem Rumpf widerspricht, -32021 für eine geforderte, aber fehlende Client-Fähigkeit, -32022 für eine nicht bediente Protokollversion. Der letzte wiegt schwerer, als er aussieht: er TRÄGT die Liste der Versionen, die der Server bedient, und diese Liste ist es, die dem Client einen zweiten Versuch erlaubt, statt ihn schließen zu lassen, der Server sei kaputt. Die nicht gefundene Ressource wandert außerdem von -32002 auf das übliche -32602.
  5. Eine unbekannte Methode antwortet 404, mit dem JSON-RPC-Fehler im Rumpf. Dieses Paar sagt einem sondierenden Client, dass er mit einem aktuellen Server spricht und nicht mit einem Endpunkt, der diese Route schlicht nicht führt.

Die Autorisierung

Die dynamische Client-Registrierung gilt als veraltet, zugunsten der Client ID Metadata Documents. Die Client-Kennung wird zu einer https-URL mit Pfad, die auf ein JSON-Dokument zeigt, das der Client selbst bereitstellt und pflegt. Der Autorisierungsserver liest dieses Dokument, prüft, dass die darin stehende client_id genau die URL ist, von der es stammt, und validiert die Rücksprungadresse gegen die dort erklärte Liste. Nichts zu registrieren vor dem ersten Ablauf, nichts aufzuräumen danach, und dieselbe Kennung gilt bei jedem Autorisierungsserver. Ein Server kündigt die Fähigkeit über client_id_metadata_document_supported in seinen Metadaten an.

Eine Folge gehört klar ausgesprochen, weil die Spezifikation sie als Erwägung und nicht als Regel führt: dieser Mechanismus lässt den Autorisierungsserver eine vom Aufrufer gewählte URL lesen, und an einem öffentlichen Token-Endpunkt kann dieser Aufrufer jeder sein. Lösen Sie die Adresse selbst auf, weisen Sie alles zurück, was nicht im öffentlichen Internet liegt, und verankern Sie die aufgelöste Adresse in der ausgehenden Anfrage, statt sie nur zu prüfen. Prüfen ohne Verankern lässt den Namen ein zweites Mal auf der Seite des HTTP-Clients auflösen, und genau darin besteht ein DNS-Rebinding-Angriff. Weisen Sie Weiterleitungen zurück, deckeln Sie den Rumpf, halten Sie die Zeitgrenzen kurz, und legen Sie das Ergebnis für eine feste Dauer ab statt für die, die das Dokument verlangt.

Zwei leisere Ergänzungen im selben Feld: die Autorisierungsantwort SOLLTE den Parameter iss aus RFC 9207 tragen, den der Client bei Vorhandensein prüfen MUSS und der den Mix-up-Angriff gegen einen Client mit mehreren Autorisierungsservern schließt; und der Client MUSS bei der dynamischen Registrierung application_type senden, da ein OIDC-Server einen fehlenden Wert als "web" liest und danach die Rücksprungadressen einer nativen Anwendung ablehnt.

Was veraltet ist, und für wie lange

Die Überarbeitung führt zudem einen Lebenszyklus für Funktionen ein: aktiv, veraltet, entfernt, mit mindestens zwölf Monaten zwischen einer Abkündigung und der frühestmöglichen Entfernung, dazu ein öffentliches Register alles Veralteten. Roots, Sampling, Logging, der Transport HTTP+SSE und die dynamische Client-Registrierung stehen heute in diesem Zustand. Sie funktionieren weiter. Eine neue Umsetzung greift nicht mehr darauf zurück.

Beide Zeitalter an einem Endpunkt bedienen

Die meisten Server werden die neue Überarbeitung und die alten eine Weile gleichzeitig sprechen, und nichts verbietet, sie am selben Ort zu bedienen. Die Regel: die ERKLÄRTE Version wählt das Zeitalter, und sonst nichts. Keine Erklärung bedeutet das Zeitalter des Handshakes; eine Anfrage, die 2026-07-28 erklärt, bekommt das zustandslose.

Zwei Einzelheiten entscheiden, ob das trägt.

initialize darf 2026-07-28 NIE aushandeln. Ein Client, der initialize schickt, spricht keine Überarbeitung, die keinen Handshake mehr hat, gleich welche Version er darin verlangt. Sie ihm zuzugestehen, ließe ihn auf Felder warten, die nie kommen. Führen Sie zwei Listen: die Versionen, die Sie bedienen und die server/discover ankündigt, und die Versionen, die initialize aushandeln darf, also die erste Liste ohne die zustandslose.

Antworten Sie den Versionsfehler VOR der Schlüsselprüfung. Wer sowohl eine nicht bediente Version als auch keine Authentifizierung mitbringt, soll den Versionsfehler lesen. Ein 401 sagt ihm nichts, womit er etwas anfangen kann, und die Liste der bedienten Versionen ist ohnehin öffentlich, da server/discover sie ohne Authentifizierung ausliefert.

Die Prüfliste

Am eigenen Server durchzugehen.

  1. Antwortet server/discover, und ohne Schlüssel, wenn Ihre übrigen öffentlichen Methoden ohne Schlüssel antworten?
  2. Trägt jedes Ergebnis sein resultType?
  3. Tragen server/discover und tools/list ihr ttlMs und ihr cacheScope?
  4. Prüfen Sie MCP-Protocol-Version gegen den Rumpf, und Mcp-Method sowie Mcp-Name gegen ihre Werte im Rumpf, mit -32020 bei Abweichung?
  5. Liefert eine nicht bediente Version 400 und -32022, samt den Versionen, die Sie bedienen?
  6. Liefert eine unbekannte Methode 404 mit -32601?
  7. Antwortet initialize weiterhin älteren Clients, und liefert es nie 2026-07-28?
  8. Falls Sie den Autorisierungsserver betreiben: kündigt er client_id_metadata_document_supported an, und verankert er die aufgelöste Adresse, bevor er ein Client-Dokument liest?

Der MCP-Server von Epovest antwortet in 2026-07-28 ebenso wie in 2025-06-18, 2025-03-26 und 2024-11-05 am selben Endpunkt, und die vollständige Referenz steht auf epovest.com/docs/api.md. Um einen Assistenten daran anzuschließen, führt unser Leitfaden Claude zum persönlichen GEO-Analysten machen durch beide Wege hinein.

Quellen