~/ / KI-Artikel / MCP-Spezifikation 2026-07-28: Was sich geändert hat und was Sie in Ihren eigenen Dateien prüfen sollten
MCP-Spezifikation 2026-07-28: Was sich geändert hat und was Sie in Ihren eigenen Dateien prüfen sollten
Die Revision 2026-07-28 der Spezifikation des Model Context Protocol (MCP) entfernt Sitzungen auf Protokollebene, stuft den älteren Transport HTTP+SSE und mehrere Funktionen als veraltet ein und lockert die Regeln für Tool-Schemas. Dieser Artikel fasst den offiziellen Changelog zusammen und zeigt, wie Sie zwei Dateien prüfen, die Sie selbst schreiben: Ihre MCP-Konfiguration und Ihre Tool-Schemas.
Veröffentlicht: · Gegen die offizielle Spezifikation geprüft am 2026-10-24. Dieser Artikel fasst sie zusammen und ersetzt sie nicht.
Die wichtigsten Änderungen
- Sitzungen auf Protokollebene und der Header Mcp-Session-Id werden aus dem Transport Streamable HTTP entfernt. Ein Server, der Zustand über mehrere Aufrufe hinweg braucht, verwendet explizite Handles, die er selbst erzeugt und als gewöhnliche Tool-Argumente weitergibt.
- MCP wird zustandslos: Der Handshake initialize entfällt. Jede Anfrage trägt ihre Protokollversion und die Fähigkeiten des Clients in _meta, und eine nicht passende Version liefert UnsupportedProtocolVersionError zurück.
- Server müssen einen neuen Aufruf server/discover implementieren, der ihre unterstützten Protokollversionen, Fähigkeiten und ihre Identität bekannt gibt.
- Der HTTP-GET-Endpunkt und resources/subscribe werden durch subscriptions/listen ersetzt, einen langlebigen Antwortstrom für die Änderungsbenachrichtigungen, die ein Client abonniert.
- Vom Server ausgehende Anfragen wie roots/list, sampling/createMessage und elicitation/create werden durch ein Muster namens Multi Round-Trip Requests ersetzt: Der Server liefert ein Ergebnis, das eine Eingabe anfordert, und der Client wiederholt die ursprüngliche Anfrage mit seinen Antworten.
- Experimentelle Tasks wandern aus dem Kernprotokoll in eine offizielle Erweiterung.
- Fortsetzbare SSE-Streams (Last-Event-ID) werden entfernt. Ein abgebrochener Antwortstrom verliert die laufende Anfrage, und der Client muss sie als neue Anfrage erneut senden.
Was jetzt als veraltet gilt
| Funktion | Als veraltet eingestuft in | Frühestes Entfernen | Empfohlene Migration |
|---|---|---|---|
| Roots | 2026-07-28 | Erste Revision, die am oder nach dem 2027-07-28 veröffentlicht wird | Verzeichnisse oder Dateien über Tool-Parameter, Ressourcen-URIs oder die Serverkonfiguration übergeben |
| Sampling | 2026-07-28 | Erste Revision, die am oder nach dem 2027-07-28 veröffentlicht wird | Direkt in die APIs der LLM-Anbieter integrieren |
| Logging | 2026-07-28 | Erste Revision, die am oder nach dem 2027-07-28 veröffentlicht wird | Bei stdio nach stderr protokollieren oder OpenTelemetry verwenden |
| Dynamic Client Registration | 2026-07-28 | Erste Revision, die am oder nach dem 2027-07-28 veröffentlicht wird | Client ID Metadata Documents |
| HTTP+SSE transport | 2025-03-26 | Drei Monate, nachdem SEP-2596 den Status Final erreicht | Streamable HTTP |
| includeContext-Werte thisServer und allServers | 2025-11-25 | Folgt auf Sampling | Das Feld weglassen oder none verwenden |
Eine als veraltet eingestufte Funktion bleibt Teil der Spezifikation. Das früheste Entfernen markiert den Zeitpunkt, ab dem sie für eine Entfernung infrage kommt; die tatsächliche Entfernung wird bei der Vorbereitung einer Revision entschieden. Die neue Richtlinie zum Lebenszyklus von Funktionen legt ein Mindestfenster von zwölf Monaten für die Einstufung als veraltet fest.
Prüfen Sie Ihre MCP-Konfiguration
Wenn Ihre Konfiguration noch den Transport HTTP+SSE verwendet, steht sie auf der Liste der veralteten Funktionen. Auch die Dokumentation von Claude Code bezeichnet ihren Typ sse als veraltet und rät, wo verfügbar HTTP-Server zu verwenden. Die Spezifikation beschreibt den Nachfolger Streamable HTTP: Der Server stellt einen einzigen Endpunkt bereit, der POST akzeptiert, und der Client sendet jede JSON-RPC-Nachricht als eigenen HTTP-POST.
- Jeder POST muss einen Accept-Header enthalten, der sowohl application/json als auch text/event-stream aufführt.
- Jeder POST muss einen Header MCP-Protocol-Version enthalten, dessen Wert zur Protokollversion im Anfragekörper passt.
- Anfragen tragen einen Header Mcp-Method und, bei tools/call, resources/read und prompts/get, zusätzlich einen Header Mcp-Name.
- Der Server beantwortet jede Anfrage mit einem einzelnen JSON-Objekt oder mit einem SSE-Stream, der auf diese Anfrage begrenzt ist.
Welche Protokollrevision Ihr Client unterstützt, klären Sie in der Dokumentation Ihres Clients. Der folgende Checker liest eine .mcp.json oder claude_desktop_config.json und meldet Einträge wie einen Remote-Server ohne type oder einen, der noch sse verwendet.
Jetzt ausprobieren: MCP Config Checker
Regeln geprüft anhand der Dokumentation am 2026-10-23.
Dokumentation: Claude Code / Model Context Protocol / VS Code
Nicht geprüft: ob ein Befehl existiert, ob sich ein Paket installieren lässt, ob ein entfernter Server antwortet, und Einstellungen, die andere Anwendungen anders lesen.
Alles läuft in Ihrem Browser. Die Konfiguration wird nicht hochgeladen.
Tool-Schemas können das gesamte JSON Schema 2020-12 nutzen
- inputSchema und outputSchema erlauben jetzt jedes Schlüsselwort von JSON Schema 2020-12, und structuredContent kann ein beliebiger JSON-Wert sein. Die Spezifikation ergänzt Anforderungen für das Auflösen von $ref und Grenzen für die Ressourcen, die Kompositionsschlüsselwörter verbrauchen dürfen.
- Ein Server kann einen Tool-Parameter mit x-mcp-header markieren, damit sein Wert in einen HTTP-Header Mcp-Param-{name} kopiert wird. Der markierte Parameter muss ein String, eine Ganzzahl oder ein Boolean sein, keine allgemeine Zahl.
- Die markierte Eigenschaft muss von der Schema-Wurzel aus ausschließlich über properties-Schlüssel erreichbar sein. Die Kette darf nicht über items, oneOf, anyOf, allOf, not, if/then/else oder $ref führen.
- Ein Client, der Streamable HTTP verwendet, muss eine Tool-Definition ablehnen, deren Annotation x-mcp-header gegen diese Regeln verstößt. Das bedeutet, dass das Tool im Ergebnis von tools/list fehlt.
Um ein Tool-Schema zu testen, fügen Sie es zusammen mit einem Beispiel für die Argumente in den Validator unten ein. Er prüft die gängigen Schlüsselwörter von Draft 2020-12 und sagt Ihnen, welche er nicht prüft.
Jetzt ausprobieren: JSON Schema Validator
Folgt für die unterstützten Schlüsselwörter JSON Schema Draft 2020-12. $ref wird nur innerhalb desselben Schemas gelesen.
Alles läuft in Ihrem Browser. Schema und Daten werden nicht hochgeladen.
Sicherheitshinweise für Server
- Ein Server muss den Header Origin bei allen eingehenden Verbindungen validieren, um DNS-Rebinding-Angriffe zu verhindern. Ist der Header vorhanden und ungültig, muss er mit HTTP 403 Forbidden antworten.
- Ein Server, der lokal läuft, sollte nur an localhost (127.0.0.1) gebunden sein, nicht an alle Netzwerkschnittstellen (0.0.0.0).
- Server sollten für alle Verbindungen eine angemessene Authentifizierung umsetzen.
- Ein Server, der den Anfragekörper verarbeitet, muss eine Anfrage ablehnen, deren Header nicht zum Körper passen, und zwar mit HTTP 400 und dem JSON-RPC-Fehler HeaderMismatch (Code -32020).
- Autorisierungsserver sollten den Parameter iss in Autorisierungsantworten angeben (RFC 9207), und ist ein iss vorhanden, müssen Clients ihn prüfen, bevor sie den Autorisierungscode einlösen.
- Clients müssen gespeicherte Client-Zugangsdaten nach dem Aussteller (Issuer) ablegen, der sie ausgegeben hat, und dürfen sie nicht bei einem anderen Autorisierungsserver wiederverwenden.