Das Model Context Protocol hat seit seiner Veröffentlichung die größte architektonische Überarbeitung erfahren. MCP wurde ursprünglich als u...
Das Model Context Protocol erfährt die größte architektonische Überarbeitung seit seiner Einführung.
MCP wurde ursprünglich als universelle Möglichkeit eingeführt, KI-Anwendungen mit Tools, APIs, Datenquellen, Dateien und externen Systemen zu verbinden. In weniger als zwei Jahren hat es sich von einem von Anthropic dominierten Integrationsprojekt zu einem breiteren Open-Source-Protokoll mit eigenem Governance-Prozess, SDK-Ökosystem, Arbeitsgruppen, Erweiterungen und Implementierungen in zahlreichen KI-Produkten entwickelt.
Die Revision 2026-07-28 konzentriert sich auf Probleme, die auftreten, wenn MCP den Laptop von Entwicklern verlässt und in große Produktionsumgebungen gelangt.
Die wichtigste Änderung lässt sich wie folgt zusammenfassen:
MCP wird auf der Protokollebene zustandslos.
Diese Änderung entfernt den protokollbezogenen Sitzungs- und Initialisierungs-Handshake aus dem neuen Wire-Format und ermöglicht es Remote-MCP-Servern, einfacher hinter herkömmlichen Load Balancern, serverloser Infrastruktur, Edge-Computing-Knoten und horizontal skalierenden Architekturen bereitgestellt zu werden.
Aber zustandslose Übertragung ist nur ein Teil dieses Updates.
Die Revision formalisiert außerdem ein Erweiterungs-Framework, gestaltet langlaufende Aufgaben neu, führt mehrstufige Round-Trip-Anfragen ein, fügt routbare HTTP-Header und Cache-Hinweise hinzu, stärkt Autorisierungsmechanismen, erweitert die JSON-Schema-Unterstützung und legt eine formale Funktions-Einstellungsrichtlinie fest.
Über das Protokoll selbst hinaus erweitert das MCP-Ökosystem sein Angebot um interaktive Anwendungen, Enterprise-Hosting-Autorisierung, private Netzwerktunnel und leistungsfähigere Entwicklerwerkzeuge.
An diesem Punkt beginnt MCP, sich weniger wie ein praktischer Agenten-Konnektor und mehr wie produktionsreife Infrastruktur anzufühlen.
Der Quellbericht hebt die Wachstumsrate der MCP-Nutzung hervor.
Laut den im Quellartikel zitierten Ankündigungen für Claude-Entwickler:
Diese konkreten Zahlen von Ende Juli stammen aus den Metriken der Ankündigung und nicht aus dem Kern-Spezifikationsdokument.
Eine frühere offizielle Ankündigung von Anthropic bietet einen nützlichen Bezugspunkt: Im Januar 2026 gab Anthropic an, dass MCP 100 Millionen Downloads pro Monat erreicht hat.
Das bedeutet, dass das Ökosystem bereits vor dem Protokoll-Redesign im Juli beträchtlich war.
Die Bedeutung dieses Updates liegt daher nicht darin, dass MCP versucht, in ferner Zukunft nützlich zu werden, sondern darin, dass die Maintainer das Protokoll um Probleme herum neu gestalten, die bereits in Produktionsgrößenordnung sichtbar sind.
Zu diesen Problemen gehören:
Frühere Remote-MCP-Bereitstellungen konnten protokollbezogenen Sitzungsstatus aufrechterhalten.
Clients initialisierten typischerweise eine
Verbindung und erhielten eine Sitzungskennung. Nachfolgende Anfragen mussten dann dieser Sitzung zugeordnet bleiben.
Ein vereinfachter 2025-11-25-Ablauf sah wie folgt aus:
POST /mcp HTTP/1.1
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-11-25",
"capabilities": {},
"clientInfo": {
"name": "my-app",
"version": "1.0"
}
}
}
Nach der Initialisierung konnten nachfolgende Aufrufe Folgendes enthalten:
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Diese Methode funktionierte für viele Anwendungen, brachte jedoch einige Infrastrukturanforderungen mit sich.
Produktionsbereitstellungen könnten erfordern:
Die MCP-Maintainer kamen zu dem Schluss, dass diese Anforderungen zu eng mit dem Protokoll selbst gekoppelt waren.
Die neue Revision entfernt diese Annahme.
Im 2026-07-28-Protokolldesign trägt jede Anfrage alle Informationen, die der Server zur Verarbeitung benötigt.
Das offizielle Beispiel sieht wie folgt aus:
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "search",
"arguments": {
"q": "otters"
},
"_meta": {
"io.modelcontextprotocol/clientInfo": {
"name": "my-app",
"version": "1.0"
}
}
}
}
Es gibt keine protokollbezogene Mcp-Session-Id mehr.
Es gibt keine verbindungsgebundene Sitzung mehr, die Anfragen an eine einzelne Serverinstanz bindet.
Jede kompatible Serverinstanz kann die Anfrage verarbeiten.
Dies ist eine erhebliche Verbesserung für Cloud-Bereitstellungen.
Remote-MCP-Server können jetzt in traditionelle Architekturen passen:
Client
↓
API-Gateway / Load Balancer
↓
MCP-Serverinstanz A
MCP-Serverinstanz B
MCP-Serverinstanz C
Anfragen müssen nicht mehr zu einer bestimmten Instanz zurückkehren, nur weil eine frühere Anfrage dort gelandet ist.
initialize-Handshake wurde aus dem neuen Wire-Format entferntDas zustandslose Redesign entfernt außerdem den alten initialize- / initialized-Lebenszyklus aus dem 2026-07-28-Wire-Format.
Informationen, die zuvor nur während der Initialisierung übertragen wurden, werden jetzt als Metadaten mit jeder Anfrage übermittelt.
Wenn Clients Serverfähigkeiten im Voraus entdecken möchten, können sie die neue Methode server/discover verwenden.
Das bedeutet nicht, dass ältere Clients sofort aufhören zu funktionieren.
Die aktuellen SDK-Dokumentationen enthalten Kompatibilitätshinweise für frühere Protokollversionen. Das C#-SDK kann beispielsweise das neue zustandslose
Verhalten unterstützen, während weiterhin das ältere sitzungsbasierte Verhalten mit Clients ausgehandelt wird, die das 2025-11-25-Protokoll verwenden.
Der wichtige Migrationsunterschied ist:
2026-07-28：
Zustandsloses Anfragemodell, keine Protokollsitzung.
Ältere Versionen:
Initialisierungs-Handshake und sitzungsbewusstes Verhalten können weiterhin unterstützt werden
durch Versionsaushandlung und SDK-Kompatibilitätspfade.
Entwickler sollten beide Enden der Integration testen, anstatt nur den Server zu aktualisieren und anzunehmen, dass alle Clients die neue Version verstehen.
## Zustandsloses Protokoll bedeutet nicht zustandslose Anwendung
Einer der häufigsten Fehler ist es, diese Änderung so zu verstehen:
> MCP-Anwendungen dürfen keinen Zustand mehr halten.
Das ist nicht die Bedeutung der Spezifikation.
**Die Protokollebene** ist zustandslos.
Anwendungen können weiterhin Zustand dort halten, wo er sinnvoll ist.
Angenommen, ein Shopping-Tool erstellt einen Warenkorb.
Der Server kann zurückgeben:
```JSON
{
"basket_id": "basket_8472"
}
Das Modell kann diesen Wert in späteren Aufrufen übergeben:
{
"basket_id": "basket_8472",
"item_id": "item_123"
}
Dadurch wird Anwendungszustand als normale Tool-Daten sichtbar, anstatt ihn in Transport-Metadaten zu verstecken.
Dasselbe Muster kann für Browsersitzungen, Berichtsaufgaben, Warenkörbe, Workflow-IDs, Bereitstellungs-IDs, Dokumentbearbeitungszustände und langlaufende Analyseaufgaben verwendet werden.
Sichtbare Handles haben mehrere Vorteile.
Das Modell kann:
Der Server kann:
Daher verlagert zustandsloses MCP die Zustandsverwaltung von der Transportebene in ein explizites Anwendungsdesign.
Der Quellartikel hebt serverlose Bereitstellungen hervor, eines der praktischsten Ergebnisse des neuen Protokolls.
Wenn Anfragen in sich geschlossen sind, können MCP-Server leichter in folgenden Umgebungen ausgeführt werden:
Das bedeutet nicht, dass jede MCP-Workload automatisch auf jeder serverlosen Plattform läuft.
Entwickler müssen weiterhin Ausführungsdauer, Streaming-Unterstützung, Kaltstarts, persistenten Anwendungszustand, Schlüssel, ausgehenden Netzwerkverkehr, langlaufende Aufgaben, Dateisystemanforderungen und Datenbankverbindungen berücksichtigen.
Das Protokoll erzwingt keine Sitzungsarchitektur mehr, was ein großes Hindernis beseitigt.
Horizontal skalierte Server müssen Clients auf Protokollebene nicht mehr an eine einzelne Instanz binden.
Das bedeutet, dass einfache Round-Robin-Lastverteiler Anfragen auf mehrere Instanzen verteilen können.
Das verbessert:
Das ändert auch die Denkweise der Server-Autoren über versteckten In-Memory-Zustand.
Wenn ein Tool nur deshalb funktioniert, weil eine vorherige Anfrage ein Wörterbuch in einem Prozess befüllt hat, kann die Implementierung fehlschlagen, wenn die nächste Anfrage auf einer anderen Instanz ankommt.
Ein guter Migrationstest ist:
Wenn jeder Tool-Aufruf auf einem anderen Serverprozess landen würde, würde derselbe Workflow weiterhin funktionieren?
Wenn die Antwort nein ist, enthält der Server eine Anwendungszustandsabhängigkeit, die explizit gemacht oder in persistenten gemeinsamen Speicher migriert werden muss.
Das zustandslose Design benötigt weiterhin eine Möglichkeit, dass der Server den Client um weitere Informationen bittet.
Beispiele sind Benutzerbestätigungen, zusätzliche Parameter, geführte Fragen, modellgenerierte Antworten oder arbeitsbereichsbezogene Werte.
Der neue Mechanismus sind Multi-Round-Trip-Requests (MRTR).
Ein Tool kann ein unvollständiges Ergebnis zurückgeben:
{
"resultType": "input_required",
"inputRequests": {
"confirm": {
"type": "elicitation",
"message": "3 Dateien löschen?",
"schema": {
"type": "boolean"
}
}
},
"requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}
Der Client sammelt die benötigten Antworten.
Dann wiederholt er den ursprünglichen Aufruf mit inputResponses und dem zurückgegebenen requestState.
Da der Zustand im Anfragefluss mitgeführt wird, kann eine andere Serverinstanz die nächste Runde verarbeiten.
Das entspricht eher einer zustandslosen Architektur als langlaufende Server-zu-Client-Verbindungen zu erfordern.
Das neue Streamable-HTTP-Format fügt Operations-Metadaten direkt zu HTTP-Headern hinzu.
Wichtige Header umfassen:
Mcp-Method: tools/call
Mcp-Name: search
Das ist wichtig für Produktionsinfrastruktur.
API-Gateways, Web Application Firewalls, Rate-Limiter oder Observability-Ebenen können Operationen erkennen, ohne den JSON-Body zu parsen.
Mögliche Verwendungen umfassen:
Die Protokollspezifikation verlangt außerdem Konsistenz zwischen Headern und JSON-RPC-Body.
Server sollten Anfragen ablehnen, bei denen beide nicht übereinstimmen.
MCP-Clients fragen häufig relativ stabile Metadaten ab, wie Tool-Listen, Ressourcen, Prompt-Listen und Ressourcen-Lesevorgänge.
Wiederholt dieselben Informationen abzurufen, verschwendet Netzwerkverkehr und Serverkapazität.
Die neue Überarbeitung führt Cache-Metadaten ein, wie:
ttlMs
cacheScope
Diese Werte ermöglichen es dem Server anzugeben, wie lange ein Ergebnis frisch bleiben soll und ob es über Benutzer oder Kontexte hinweg gemeinsam genutzt werden kann.
Das ähnelt dem Prinzip gewöhnlichen HTTP-Cachings.
Für tool-intensive Agenten kann dies redundante Metadaten-Ladevorgänge reduzieren.
Die Überarbeitung dokumentiert auch die W3C-Trace-Context-Ausbreitung.
Schlüssel wie:
traceparenttracestatebaggagekönnen über MCP-Metadaten verbreitet werden.
Dadurch kann eine einzelne verteilte Ablaufverfolgung Arbeit über folgende Kette verfolgen:
Host-Anwendung
→ MCP-Client
→ MCP-Gateway
→ MCP-Server
→ Downstream-API
→ Datenbank
Für Unternehmensbereitstellungen ist das wichtig, weil langsame Tool-Aufrufe leichter zu debuggen sind, wenn Teams sehen können, wo die Latenz tatsächlich auftritt.
Das Protokoll ändert auch, wie optionale Funktionen sich weiterentwickeln.
Der aktuelle Rahmen gibt Erweiterungen:
Das ist wichtig, weil das Kernprotokoll nicht jede neue Idee absorbieren muss.
Eine Funktion kann zuerst als Erweiterung reifen, und bewährte Fähigkeiten können später näher an den Kern rücken.
Eine der sichtbarsten MCP-Erweiterungen sind MCP-Apps.
MCP-Tools gaben traditionell Text, strukturiertes JSON oder Ressourcen zurück.
Manche Aufgaben benötigen Oberflächen.
Beispiele umfassen Dashboards, Diagramme, Karten, Formulare, Aufgaben-Boards, Konfigurationspanels, Design-Canvases und Videoplayer.
MCP-Apps ermöglichen es dem Server, eine UI-Ressource zu deklarieren, die der Host in einer Sandbox-iFrame rendert.
![Das Bild zeigt den Interaktionsfluss von MCP-Apps. Der Benutzer sendet die Anweisung „show me analytics“ an den Agenten, der die interaktive App im Chat rendert. Die App interagiert über Tool-Aufrufe mit dem MCP-Server, der Tool-Eingaben/Ergebnisse zurückgibt, und die Ergebnisse werden an die App übertragen.]
Der Benutzer interagiert mit der App, die App fordert einen Tool-Aufruf an, der Server gibt frische Daten zurück, und die App aktualisiert sich mit den neuen Daten. Dieses Diagramm steht in engem Zusammenhang mit dem Kontext und veranschaulicht direkt den vollständigen Interaktionsprozess von MCP-Apps, von der Benutzeranweisung bis zur App-Aktualisierung.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/c7e4e5a5-3b69-4999-be13-41aa3f213186-be0c3bc3-5210-4e7e-971e-c9b0e2d35daf.png)
Der vereinfachte Ablauf sieht wie folgt aus:
MCP-Apps werden bereits von mehreren kompatiblen Hosts unterstützt, darunter Claude und andere Entwicklungslösungen mit MCP-Unterstützung.
Das offizielle Erweiterungspaket kann mit dem folgenden Befehl installiert werden:
npm install -S @modelcontextprotocol/ext-apps
Das offizielle Beispiel-Repository kann lokal ausgeführt werden:
git clone https://github.com/modelcontextprotocol/ext-apps.git
cd ext-apps
npm install
npm start
Diese Befehle stammen aus der offiziellen MCP-Apps-Dokumentation und können sich mit der Weiterentwicklung der Erweiterung ändern.
Agent-Tools starten zunehmend Arbeiten, die nicht innerhalb einer normalen HTTP-Anfrage abgeschlossen werden können.
Beispiele hierfür sind CI-Pipelines, große Datenverarbeitungsaufgaben, Cloud-Bereitstellungen, langwierige Rechercheaufgaben, Videorendering und menschliche Genehmigungsprozesse.
Die MCP-Tasks-Erweiterung ermöglicht es dem Server, einen persistenten Task-Handle zurückzugeben, anstatt blockierend auf den Abschluss des Vorgangs zu warten.
Die offiziell von der Erweiterung definierten Methoden umfassen:
tasks/get
tasks/update
tasks/cancel
Tasks können zwischen den folgenden Zuständen wechseln:
working
input_required
completed
cancelled
failed
Der Client kann tasks/get abfragen.
Wenn der Server Benutzereingaben benötigt, kann der Task in den Zustand input_required übergehen.
Der Client kann Eingaben über tasks/update übermitteln.
Dieses Design funktioniert auch bei getrennten Verbindungen zuverlässig und erfordert keine dauerhaft geöffnete Verbindung.
Die Task-Funktion war in der Kern-Spezifikation von 2025-11-25 als experimentelle Funktion vorhanden.
Die neue Tasks-Erweiterung ist keine einfache Umbenennung der alten API.
Die offiziellen SDK-Dokumente warnen davor, dass die neuere Tasks-Erweiterung auf der Drahtprotokoll-Ebene nicht mit früheren experimentellen Implementierungen kompatibel ist.
Anwendungen, die die alten Tasks-Funktionen verwenden, sollten migriert werden und dürfen nicht auf automatische Kompatibilität hoffen.
Die Autorisierungsprobleme bei Unternehmensbereitstellungen unterscheiden sich von denen bei Verbraucher-Integrationen.
Ein Unternehmen kann Tausende von Mitarbeitern und dutzende genehmigte MCP-Server haben.
Es möchte nicht, dass jeder Mitarbeiter jeden Connector unabhängig autorisiert.
Die Erweiterung Unternehmensverwaltete Autorisierung ermöglicht es Organisationen, die Zugriffskontrolle zentral über einen Identitätsanbieter zu verwalten.
Unterstützte Unternehmens-IdP-Muster können Produkte wie Microsoft Entra ID, Okta und Unternehmens-SSO-Systeme umfassen.
Organisationen können festlegen, welche Mitarbeiter auf welche MCP-Server zugreifen dürfen und wann der Zugriff widerrufen werden soll.
Mitarbeiter authentifizieren sich mit ihrer Unternehmensidentität, ohne für jeden MCP-Server eine separate OAuth-Genehmigung durchführen zu müssen.
Die offizielle MCP-Dokumentation beschreibt die unternehmensverwaltete Autorisierung als eine Erweiterung, die nicht standardmäßig für jeden Client aktiviert ist.
Sowohl die Client- als auch die Identitätsinfrastruktur der Organisation müssen die Erweiterung unterstützen.
Die zentrale Autorisierungsarbeit hat zudem mehrere Sicherheitsverbesserungen erhalten.
Autorisierungsantworten können den iss-Ausstellerparameter enthalten.
Der Client überprüft den Aussteller, bevor er den Autorisierungscode einlöst.
Dies hilft, Angriffe durch Verwechslung von Autorisierungsservern zu verhindern.
Beschreibe deine Idee einmal, und We0 AI erstellt eine Showcase-Website, Seiten und ein CMS und hilft nach dem Launch bei Kunden und Traffic.
Eine komplette Projektgeneration zur kostenlosen Registrierung
Am besten geeignet, um einen vollständigen Generierungsablauf auszuprobieren und schnell einen ersten Projektentwurf zu sehen.
Registrierte Client-Anmeldedaten sollten nicht zwischen nicht zusammenhängenden Autorisierungsservern wiederverwendet werden.
Wenn Ressourcen zu anderen Ausstellern übertragen werden, sollte der Client eine ordnungsgemäße Registrierung bei diesem Aussteller vornehmen.
Diese Revision klärt das Verhalten von application_type während der dynamischen Client-Registrierung.
Dies hilft, Situationen zu vermeiden, in denen Autorisierungsserver native CLI- oder Desktop-Anwendungen als Web-Clients behandeln und lokale Redirect-URIs ablehnen.
Das MCP-Autorisierungsprojekt hat sich in Richtung Client-ID-Metadatendokumente (Client ID Metadata Documents, kurz CIMD) für neue Implementierungen bewegt, während DCR-Kompatibilität dort erhalten bleibt, wo sie benötigt wird.
Die tatsächliche Empfehlung lautet, den aktuellen Autorisierungsdokumenten zu folgen und Client-Registrierungen nicht auf der Grundlage älterer MCP-Tutorials umzusetzen.
Auch die Tool-Schemata sind ausdrucksstärker geworden.
inputSchema und outputSchema unterstützen die vollständigen JSON-Schema-2020-12-Funktionen.
Eingabeschemata können Folgendes verwenden:
oneOf
anyOf
allOf
$ref
$defs
Bedingte Anweisungen
Ausgabeschemata sind nicht mehr auf eine einzige enge Objektform beschränkt.
structuredContent kann beliebige JSON-Werte darstellen, die vom Schema unterstützt werden.
Dies ermöglicht es MCP-Tools, Typen wie Union-Typen, bedingte Felder, verschachtelte wiederverwendbare Definitionen, mehrere Ausgabeformen sowie Array- oder Skalarergebnisse in APIs präziser zu beschreiben.
Drei ältere Kernfunktionen wurden offiziell als veraltet eingestuft:
| Funktion | Empfohlene Alternative |
|---|---|
| Roots | Tool-Parameter, Ressourcen-URIs oder Serverkonfiguration |
| Sampling | Direkte Integration des LLM-Anbieters |
| Logging | stderr bei stdio; OpenTelemetry für strukturierte Beobachtbarkeit |
Die Einstufung als veraltet bedeutet nicht eine sofortige Entfernung.
Die neue Lebenszyklusrichtlinie legt fest, dass veraltete Funktionen vor einer möglichen Entfernung mindestens zwölf Monate Übergangszeit erhalten.
Aktuelle SDKs unterstützen diese Funktionen möglicherweise weiterhin, um Kompatibilität zu gewährleisten.
Das zustandslose Redesign enthält bahnbrechende Änderungen.
Die Maintainer geben an, dass sie sich diese Art von Unterbrechungen nicht als Norm wünschen.
Der neue Funktionslebenszyklus definiert die folgenden Phasen:
Aktiv (Active)
Veraltet (Deprecated)
Entfernt (Removed)
Veraltete Funktionen erhalten vor ihrer Entfernung eine Mindestunterstützungsdauer.
Erweiterungen können sich auch unabhängig vom Kern weiterentwickeln.
Dies bietet Teams eine vorhersehbarere Migrationsplanung.
Die Protokollrevision erleichtert die Skalierung öffentlicher Remote-MCP-Server.
Unternehmen stehen oft vor dem gegenteiligen Problem: Sie möchten Server gar nicht erst öffentlich zugänglich machen.
Die MCP-Tunnel-Funktion von Anthropic adressiert dieses Szenario für gehostete Claude-Agenten und unterstützte Claude-Plattform-Workflows.
Ein leichtgewichtiges Gateway läuft innerhalb des Unternehmensnetzwerks und baut ausgehende Verbindungen auf.
Anthropic beschreibt dieses Muster wie folgt:
Interne Datenbanken, ERP-Systeme, private APIs, Wissensdatenbanken und Ticketsysteme können innerhalb der Unternehmensgrenzen bleiben.
MCP-Tunnel bleibt ein Produktfeature von Claude und keine Anforderung des MCP-Kernprotokolls.
Anthropic bezeichnet es derzeit als Forschungsvorschau.
Beide Funktionen verbessern MCP in Produktionsumgebungen, lösen jedoch unterschiedliche Probleme.
| Funktion | Gelöstes Problem |
|---|---|
| MCP-Apps | Umfangreiche interaktive Oberflächen innerhalb von MCP-Hosts |
| Aufgaben | Persistente langlaufende Tool-Operationen |
| Enterprise Managed Authorization | Zentrale unternehmensweite |
Zugriffsrichtlinien |
| MCP-Tunnel | Zugriff auf private MCP-Server ohne öffentliche Offenlegung |
| Zustandsloser MCP-Kern | Skalierbarer Protokolltransport |
| MRTR | Client-Eingaben während eines Anrufs ohne langfristige Protokollsitzungen |
Server können eine, mehrere oder alle dieser Funktionen nutzen.
Wenn Server bereits mit älteren MCP-Clients funktionieren, müssen Entwickler nicht sofort alles neu schreiben.
Sie sollten eine strukturierte Migration durchführen.
Suchen Sie nach Code, der abhängig ist von:
Mcp-Session-IdBewerten Sie, ob es sich bei jeder Abhängigkeit um Protokollzustand, Anwendungszustand, Authentifizierungszustand oder temporären Ausführungszustand handelt.
Verschieben Sie Anwendungszustand in explizite Handles oder geeignete persistente Speicherung.
Verwenden Sie SDK-Versionen, die die Revision 2026-07-28 unterstützen.
Testen Sie anschließend mit mehreren Serverinstanzen.
Eine nützliche Testkonfiguration ist:
Client
↓
Round-Robin-Lastverteiler
↓
Server A / Server B / Server C
Senden Sie einen mehrstufigen Workflow und bestätigen Sie, dass aufeinanderfolgende Anfragen verschiedene Instanzen erreichen können, ohne die Aufgabe zu unterbrechen.
Geben Sie für zustandsbehaftete Workflows eine stabile Kennung zurück:
{
"job_id": "job_7f18c9"
}
Verlangen Sie, dass nachfolgende Aufrufe diese Kennung enthalten:
{
"job_id": "job_7f18c9",
"action": "continue"
}
Validieren Sie jedes Handle serverseitig.
Gute Handles verfügen über starke Entropie, Mandantenbindung, Autorisierungsprüfungen, Ablaufzeiten, Widerrufsmechanismen und klare Fehlerbehandlung.
Wenn Sie Streamable HTTP verwenden, nutzen Sie die folgenden Header:
Mcp-Method
Mcp-Name
Fügen Sie Routing, Ratenbegrenzung, Metriken, WAF-Richtlinien und Zugriffsprotokolle hinzu.
Befolgen oder generieren Sie für geeignete Listen- und Leseantworten:
ttlMs
cacheScope
Teilen Sie keine sensiblen Cache-Inhalte mit benutzerspezifischen Daten über Benutzer hinweg.
Wenn die Anwendung die experimentelle 2025-11-25-Tasks-API verwendet, aktualisieren Sie sie auf den erweiterten Lebenszyklus.
Testen Sie:
tasks/get
tasks/update
tasks/cancel
sowie den Zustand input_required.
Suchen Sie nach Roots, Sampling und MCP-Logging.
Planen Sie die Migration zu expliziten Tool-Parametern oder Ressourcen-URIs, direkten Modellanbieter-Aufrufen sowie stderr oder OpenTelemetry.
Validieren Sie Ausstellerprüfung, Weiterleitungs-URIs, Client-Registrierung, Aktualisierungstokens, Scope-Behandlung und Identitätsanbieter-Kompatibilität.
Enterprise-Bereitstellungen sollten bewerten, ob EMA anwendbar ist.
Abwärtskompatibilität ist ein Ökosystemproblem und nicht nur ein Serverproblem.
Pflegen Sie eine Testmatrix:
| Client | Protokollrevision | Ergebnis |
|---|---|---|
| Aktueller Client | 2026-07-28 | Erwarteter zustandsloser Pfad |
| Alter Client | 2025-11-25 | Kompatibilitätspfad |
| Nicht unterstützter Client | Alte/unbekannte Version | Eindeutiger Aushandlungsfehler |
Gehen Sie nicht stillschweigend davon aus, dass jeder
Client gleichzeitig aktualisiert wird.
Messen Sie mindestens:
Zustandslose Systeme sind einfacher zu skalieren, aber verteilte Systeme benötigen dennoch gute Beobachtbarkeit.
Der Server speichert Berichtsobjekte im Arbeitsspeicher:
sessions[session_id]["report"] = report
Der nächste Tool-Aufruf erwartet, denselben Prozess zu erreichen.
Der Server speichert persistenten Zustand:
report_id = save_report(report)
return {"report_id": report_id}
Das nächste Tool empfängt:
{
"report_id": "report_123"
}
Jede Serverinstanz kann den Bericht laden.
Die wesentliche Änderung liegt auf Architekturebene:
Versteckter Transportsitzungszustand
→ Expliziter Anwendungszustand
Möglicherweise, aber nicht automatisch.
Zustandslose Bereitstellungen können die Infrastrukturkomplexität reduzieren:
Caching kann zudem wiederholte Metadatenaufrufe reduzieren.
Anwendungszustand verursacht jedoch weiterhin Kosten.
Wenn Workflows persistenten Zustand benötigen, benötigen Entwickler möglicherweise weiterhin Redis, SQL-Datenbanken, Objektspeicher, Aufgabenwarteschlangen oder Workflow-Engines.
Das neue Design gibt Entwicklern die Wahl, welche Speicherarchitektur sie verwenden möchten, anstatt dass die Protokollsitzung eine bestimmte Variante erzwingt.
Der Quellartikel verwendet diese Analogie.
Die Analogie ist nützlich, sollte aber nicht wörtlich genommen werden.
HTTP ist der grundlegende Web-Übertragungsstandard, der in nahezu allen Internetsystemen verwendet wird.
MCP ist ein spezialisiertes Protokoll, das KI-Clients und Agenten mit Tools, Ressourcen, Prompts, Schnittstellen und externen Diensten verbindet.
Was die Analogie erfasst, ist die Entwicklungsrichtung:
Das Redesign vom 2026-07-28 verstärkt diese Analogie, da MCP-Traffic nun natürlicher in die traditionelle zustandslose HTTP-Infrastruktur passt.
Ob MCP eine ähnliche Verbreitung wie HTTP erreichen wird, bleibt eine offene Frage.
MCP stammt ursprünglich von Anthropic, wird aber heute als breiteres Open-Source-Protokollprojekt verwaltet.
Das Ökosystem umfasst unabhängige Maintainer, Arbeitsgruppen, Spezifikationsverbesserungsvorschläge, SDKs in mehreren Sprachen, MCP-Apps, Aufgaben, Unternehmensautorisierungserweiterungen, Registries sowie Implementierungen in mehreren KI-Produkten.
MCP-Apps werden beispielsweise gemeinsam mit Mitwirkenden aus der MCP-Community sowie Teilnehmern von Anthropic, OpenAI und MCP-UI entwickelt.
Dies ist wichtig, weil ein Protokoll an Wert gewinnt, wenn sowohl Clients als auch Server es implementieren können, ohne von einem einzigen Anbieter abhängig zu sein.
Das offizielle MCP-Projekt pflegt oder anerkennt SDK-Implementierungen in mehreren Sprachen.
Zu den Haupt-Repositories gehören SDKs für TypeScript, Python, Go, C# sowie weitere Ökosysteme.
Juni 2026
Die Kandidaten-Release-Ankündigung hob insbesondere die Beta-Unterstützung für vier SDKs der ersten Stufe hervor:
Bis Ende Juli enthalten die aktuellen SDK-Dokumentationen das Verhalten von 2026-07-28.
Da die SDK-Einführung unabhängig erfolgt, schauen Sie immer in die Release-Notes der von Ihnen verwendeten Sprache und Version.
Für Produktionssysteme vermeiden Sie Migrationen nach dem „Umstellungstag“-Prinzip.
Ein sichererer Prozess ist:
2026-07-28-Clients testen.Dies ist besonders wichtig, da die neue Revision das Kernverhalten des Lebenszyklus bewusst geändert hat.
Das Protokoll unterstützt serverlose Bereitstellungen natürlicher.
Ihre Anwendung benötigt möglicherweise weiterhin Datenbanken, persistente Aufgabenausführer, Dateispeicher oder längere Ausführungszeiten.
Nur der Status auf Protokollsitzungsebene wird aus dem neuen Online-Modell entfernt.
Der Anwendungsstatus bleibt weiterhin ein Problem der Anwendung selbst.
Erweiterungen werden ausgehandelt, und die Unterstützung der Hosts variiert.
Die aktuelle Tasks-Erweiterung unterscheidet sich von früheren experimentellen Implementierungen.
Roots, Sampling und Logging bleiben während des Abkündigungszeitraums verfügbar.
2026-07-28 bereits unterstützenSDK- und Produktübernahmen schreiten unterschiedlich schnell voran.
MCP kann leistungsstarke Tools ausführen.
Autorisierung, Benutzereinwilligung, Sandboxing, Tool-Design, Geheimnisverwaltung und Auditierung bleiben unerlässlich.
MCP 2026-07-28 ist die größte architektonische Revision des Model Context Protocol seit seiner Einführung. Zu den wichtigsten Änderungen gehören ein zustandsloser Protokollkern, die Entfernung des Sitzungshandshakes im neuen Online-Format, Erweiterungen der ersten Stufe, MCP-Apps, neu gestaltete Tasks, MRTR, stärkere Autorisierung, Cache-Metadaten sowie eine formale Abkündigungsstrategie.
Die Protokollebene von 2026-07-28 ist als zustandslos konzipiert. Anwendungen können weiterhin Status über explizite Handles, Datenbanken, Workflow-Systeme oder andere persistente Speicher halten.
Mcp-Session-Id passiert?Das Online-Format von 2026-07-28 entfernt den Mcp-Session-Id-Mechanismus auf Protokollebene. Aktuelle SDKs können zur Abwärtskompatibilität beim Aushandeln älterer Protokollrevisionen weiterhin sitzungsbasiertes Verhalten unterstützen.
Das zustandslose Protokoll erleichtert serverlose und Edge-Bereitstellungen, da Anfragen keine Protokollsitzungs-Affinität mehr benötigen. Ihr Server muss weiterhin die Ausführungs-, Netzwerk-, Speicher- und Dauerbeschränkungen der Laufzeit erfüllen.
MCP-Apps sind eine offizielle Erweiterung,
die es Tools ermöglicht, in kompatiblen MCP-Hosts interaktive Oberflächen wie Dashboards, Formulare, Diagramme und andere HTML-Erlebnisse zurückzugeben. Diese Oberfläche läuft in einem sandboxed iframe und kommuniziert über den MCP-Host.
Die Aufgabenfunktion ermöglicht es Servern, persistente asynchrone Aufgaben-Handles für langlaufende Arbeiten zurückzugeben. Clients können den Status per tasks/get abfragen, benötigte Eingaben per tasks/update bereitstellen oder Vorgänge per tasks/cancel abbrechen.
Unternehmensgehostete Autorisierung ist eine Erweiterung von MCP, die zentrale Zugriffskontrolle über den Identitätsanbieter einer Organisation ermöglicht. Sie erlaubt IT-Administratoren, den Zugriff auf MCP-Server gemäß Unternehmensidentitätsrichtlinien zu verwalten, ohne dass jeder Benutzer jeden Server einzeln autorisieren muss.
Nicht unbedingt. SDKs unterstützen über Versionsaushandlung ältere Protokollrevisionen, und abgekündigte Funktionen erhalten ein klares Unterstützungsfenster. Produktionsteams sollten dennoch mit Tests beginnen, da das zustandslose Design Annahmen über Sitzungen, langlaufende Operationen und Infrastruktur verändert.
io/): Offizielle Registry-Infrastruktur zur Entdeckung veröffentlichter MCP-Server.
Offizielle Aufgabenspezifikation, Lebenszyklus, Sicherheitsmodell und unterstützte Methoden.
Die MCP-Revision 2026-07-28 bringt das Protokoll auf Infrastrukturmuster, die in großen Websystemen bereits weit verbreitet sind. Anfragen werden eigenständig, Protokoll-Sitzungen verschwinden aus dem neuen Drahtformat, Gateway-Routing wird einfacher, und gewöhnliche horizontale Skalierung erfordert keine sticky MCP-Sitzungen mehr.
Gleichzeitig entwickelt sich das Ökosystem weiter nach oben. MCP-Apps fügen interaktive UIs hinzu, Tasks unterstützen persistente asynchrone Arbeitsabläufe, Enterprise Managed Authorization zentralisiert Unternehmenszugriffe, und MCP-Tunnel bieten Claude-Plattformnutzern Zugang zu internen privaten Servern.
Die Migration besteht nicht einfach darin, „Sitzungs-IDs zu entfernen“. Teams müssen versteckte Zustandsabhängigkeiten identifizieren, Anwendungszustand auf explizite Handles oder persistenten Speicher migrieren, MRTR und Tasks testen, Autorisierung aktualisieren, Kompatibilität mit alten Clients aufrechterhalten und angemessene Beobachtbarkeit hinzufügen.
Die wichtigste Änderung ist architektonischer Natur: MCP wandelt sich von einem verbindungsorientierten Agentenintegrationsmuster zu einem zustandslosen, skalierbaren Protokoll, das sich natürlicher in moderne Cloud-Infrastrukturen einfügt.
Starte mit einem Satz und erhalte in wenigen Minuten eine vollständige Website.
