MCP 2026-07-28 im Detail: Zustandslose Server, MCP-Anwendungen, Aufgaben, Unternehmensauthentifizierung und neue Agenteninfrastruktur

Das Model Context Protocol hat seit seiner Veröffentlichung die größte architektonische Überarbeitung erfahren. MCP wurde ursprünglich als universelle Möglichkeit eingeführt, KI-Anwendungen mit Modellen und ... zu verbinden.

发布于 2026年7月31日•general•GEO 评分: 0•1 次阅读

选择语言

العربية Deutsch English Español Français Italiano 日本語 한국어 Português Русский 中文

MCP 2026-07-28 im Detail: Zustandslose Server, MCP-Anwendungen, Aufgaben, Unternehmensauthentifizierung und neue Agenteninfrastruktur

MCP 2026-07-28 Analyse: Protokoll wird zustandslos und einfacher erweiterbar

Einleitung

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.

MCP verzeichnet rasantes Adoptionstempo

Der Quellbericht hebt die Wachstumsrate der MCP-Nutzung hervor.

Laut den im Quellartikel zitierten Ankündigungen für Claude-Entwickler:

Die monatlichen Downloads der MCP-SDKs übersteigen 400 Millionen.
Die monatliche SDK-Nutzung hat sich im Jahresverlauf etwa vervierfacht.
Die kumulierten Downloads der TypeScript- und Python-SDKs haben jeweils sehr große Meilensteine überschritten.
Hunderte von MCP-Integrationen sind über das Connector-Ökosystem von Claude verfügbar.

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:

Klebrige Sitzungen.
Gemeinsamer Sitzungsspeicher.
Horizontale Skalierung.
Serverlose Bereitstellungen.
Gateway-Routing.
Authentifizierungskomplexität.
Langlaufende Agentenoperationen.
Interaktive Oberflächen.
Abwärtskompatibilität.
Protokollweiterentwicklung.

Warum das frühere zustandsbehaftete Design die Skalierung erschwerte

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:

Klebriges Load-Balancer-Routing.
Gemeinsamen Sitzungsspeicher.
Sitzungsreplikation.
Ablauf-Logik für Sitzungen.
Failover-Behandlung.
Verbindungsbewusste Beobachtbarkeit.
Besondere Behandlung von Server-Neustarts.

Die MCP-Maintainer kamen zu dem Schluss, dass diese Anforderungen zu eng mit dem Protokoll selbst gekoppelt waren.

Die neue Revision entfernt diese Annahme.

MCP ist jetzt auf Protokollebene zustandslos

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.

Der `initialize`-Handshake wurde aus dem neuen Wire-Format entfernt

Das 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.

Warum explizite Handles besser sein können

Sichtbare Handles haben mehrere Vorteile.

Das Modell kann:

Sie zwischen verwandten Tools übergeben.
Schlussfolgern, welches Handle zu welcher Aufgabe gehört.
Sie in Protokolle aufnehmen.
Sie nach einem Wiederholungsversuch wiederherstellen.
Sie an einen anderen Workflow-Schritt übergeben.

Der Server kann:

Handles validieren.
Sie ablaufen lassen.
Sie an einen Benutzer oder Mandanten binden.
Abgelaufenen Zustand ablehnen.
Den tatsächlichen Zustand in einer Datenbank speichern.

Daher verlagert zustandsloses MCP die Zustandsverwaltung von der Transportebene in ein explizites Anwendungsdesign.

Serverlos und horizontale Skalierung werden wesentlich einfacher

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:

AWS Lambda.
Cloudflare Workers.
Vercel.
Andere serverlose Funktionen.
Container-Autoskalierungsplattformen.
Gewöhnliche zustandslose Kubernetes-Bereitstellungen.
Edge-Umgebungen.

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.

Round-Robin-Lastverteilung wird zum natürlichen Standard

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:

Autoskalierung.
Instanzaustausch.
Fehlerwiederherstellung.
Rollierende Bereitstellungen.
Multi-Region-Routing.
Infrastruktur-Einfachheit.

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.

Mehrfach-Roundtrip-Anfragen ersetzen persistente Call-Verbindungen

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.

Header-basiertes Routing macht MCP Gateway-freundlicher

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:

Alle Suchtools an denselben Pool weiterleiten.
Strengere Limits auf destruktive Operationen anwenden.
Latenz nach Tool-Name protokollieren.
Nutzung nach Methode messen.
Nicht erlaubte Tools am Gateway blockieren.
Unabhängige Zuverlässigkeitsrichtlinien erstellen.

Die Protokollspezifikation verlangt außerdem Konsistenz zwischen Headern und JSON-RPC-Body.

Server sollten Anfragen ablehnen, bei denen beide nicht übereinstimmen.

Listen- und Leseergebnisse unterstützen Cache-Bewusstsein

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.

Verteilte Ablaufverfolgung ist standardisiert

Die Überarbeitung dokumentiert auch die W3C-Trace-Context-Ausbreitung.

Schlüssel wie:

traceparent
tracestate
baggage

kö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.

Erweiterungen werden zu Erstklasse-Protokollfunktionen

Das Protokoll ändert auch, wie optionale Funktionen sich weiterentwickeln.

Der aktuelle Rahmen gibt Erweiterungen:

Reverse-DNS-Identifikatoren.
Fähigkeitsaushandlung.
Unabhängige Versionskontrolle.
Dedizierte Code-Repositories.
Delegierte Maintainer.
Einen formalen Erweiterungs-Track im SEP-Prozess.

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.

MCP-Apps: Interaktive UI in Gesprächen

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:

Ein Tool deklariert eine UI-Ressource.
Das Modell ruft dieses Tool auf.
Der Host lädt die UI in der Sandbox.
Die Tool-Daten werden an die Oberfläche übergeben.
Der Benutzer interagiert mit der App.
Die App kann über den Host zusätzliche Tool-Aufrufe anfordern.
Der Host behält Berechtigungs- und Prüfsteuerung für diese Vorgänge.

MCP-Apps werden bereits von mehreren kompatiblen Hosts unterstützt, darunter Claude und andere Entwicklungslösungen mit MCP-Unterstützung.

Grundinstallation von MCP-Apps

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.

Tasks: Langlaufende Arbeiten ohne blockierende Verbindung

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.

Wichtiger Kompatibilitätshinweis

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.

Unternehmensverwaltete Autorisierung

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.

Autorisierungsmechanismen werden breiter abgesichert

Die zentrale Autorisierungsarbeit hat zudem mehrere Sicherheitsverbesserungen erhalten.

RFC 9207-Ausstellerüberprüfung

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.

Client-Anmeldedaten bleiben an ihren Aussteller gebunden

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.

Verbesserte Desktop- und CLI-Registrierung

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.

CIMD ist die neue Client-Registrierungsrichtlinie

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.

Vollständiges JSON-Schema 2020-12 für Tools

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.

Roots, Sampling und Logging sind veraltet

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.

Die formelle Veraltungsrichtlinie verändert das MCP-Upgraderisiko

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.

MCP-Tunnel lösen ein anderes Enterprise-Problem

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:

Kein öffentlicher MCP-Endpunkt.
Keine eingehenden Firewall-Regeln.
Keine öffentliche IP erforderlich.
Ende-zu-Ende-verschlüsselter Datenverkehr.

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.

MCP-Apps und Tunnel sollten nicht verwechselt werden

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

Server können eine, mehrere oder alle dieser Funktionen nutzen.

Was müssen bestehende MCP-Server-Entwickler ändern?

Wenn Server bereits mit älteren MCP-Clients funktionieren, müssen Entwickler nicht sofort alles neu schreiben.

Sie sollten eine strukturierte Migration durchführen.

Schritt 1: Versteckte Sitzungsabhängigkeiten inventarisieren

Suchen Sie nach Code, der abhängig ist von:

Mcp-Session-Id
In-Memory-Sitzungswörterbüchern
Sticky Routing
Verbindungslokalem Client-Zustand
Nur-Initialisierungs-Fähigkeitsspeicher
Server-Instanz-Affinität

Bewerten 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.

Schritt 2: Zustandslose Anfrageverarbeitung testen

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.

Schritt 3: Explizite Zustands-Handles hinzufügen

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.

Schritt 4: Gateway-Regeln aktualisieren

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.

Schritt 5: Cache-Unterstützung hinzufügen

Befolgen oder generieren Sie für geeignete Listen- und Leseantworten:

ttlMs
cacheScope

Teilen Sie keine sensiblen Cache-Inhalte mit benutzerspezifischen Daten über Benutzer hinweg.

Schritt 6: Alte Aufgaben migrieren

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.

Schritt 7: Veraltete Funktionen überprüfen

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.

Schritt 8: Autorisierung erneut testen

Validieren Sie Ausstellerprüfung, Weiterleitungs-URIs, Client-Registrierung, Aktualisierungstokens, Scope-Behandlung und Identitätsanbieter-Kompatibilität.

Enterprise-Bereitstellungen sollten bewerten, ob EMA anwendbar ist.

Schritt 9: Alte Clients testen

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.

Schritt 10: Beobachtbarkeit vor Produktion hinzufügen

Messen Sie mindestens:

Anzahl der Anfragen.
Tool-Namen.
Latenz.
Fehlerraten.
Aufgabendauer.
Häufigkeit von Eingabeanforderungen.
Cache-Trefferquote.
Anzahl fehlgeschlagener Authentifizierungen.
Latenz nachgelagerter APIs.
Trace-IDs.

Zustandslose Systeme sind einfacher zu skalieren, aber verteilte Systeme benötigen dennoch gute Beobachtbarkeit.

Beispiel: Vorher-Nachher-Vergleich der Migration

Vor der Migration

Der Server speichert Berichtsobjekte im Arbeitsspeicher:

sessions[session_id]["report"] = report

Der nächste Tool-Aufruf erwartet, denselben Prozess zu erreichen.

Nach der Migration

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

Bedeutet zustandsloses MCP geringere Kosten?

Möglicherweise, aber nicht automatisch.

Zustandslose Bereitstellungen können die Infrastrukturkomplexität reduzieren:

Kein gemeinsam genutzter MCP-Sitzungsspeicher erforderlich.
Weniger Bedarf an Sticky Routing.
Einfachere automatische Skalierung.
Einfachere Serverless-Bereitstellungen.
Vereinfachtes Failover.

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.

Wird MCP zum „HTTP der KI-Welt“?

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:

Eine Standardschnittstelle.
Zahlreiche unabhängige Server.
Zahlreiche kompatible Clients.
Gemeinsame Konventionen.
Infrastruktur, die Anfragen universell routen und beobachten kann.

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.

Das Ökosystem ist breiter als Claude

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.

Aktuelle SDK-Landschaft

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:

TypeScript.
Python.
Go.
C#.

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.

Sicherere Migrationsstrategie

Für Produktionssysteme vermeiden Sie Migrationen nach dem „Umstellungstag“-Prinzip.

Ein sichererer Prozess ist:

Entwicklungsumgebung aktualisieren.
Konsistenz-Tests ausführen.
2026-07-28-Clients testen.
Legacy-Clients testen.
Zustandslose Bereitstellung in der Pre-Release-Umgebung aktivieren.
Mehrere Serverinstanzen hinzufügen.
Anfragen über Instanzen verteilt erzwingen.
Authentifizierung testen.
Langlaufende Aufgaben testen.
Anwendungsstatus-Handles testen.
Latenz und Fehler überwachen.
Schrittweise ausrollen.

Dies ist besonders wichtig, da die neue Revision das Kernverhalten des Lebenszyklus bewusst geändert hat.

Was nicht angenommen werden sollte

Nicht annehmen, dass jeder Server automatisch serverlos wird

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.

Nicht annehmen, dass aller Status verschwindet

Nur der Status auf Protokollsitzungsebene wird aus dem neuen Online-Modell entfernt.

Der Anwendungsstatus bleibt weiterhin ein Problem der Anwendung selbst.

Nicht annehmen, dass MCP-Apps in jedem Client laufen

Erweiterungen werden ausgehandelt, und die Unterstützung der Hosts variiert.

Nicht annehmen, dass Aufgaben abwärtskompatibel sind

Die aktuelle Tasks-Erweiterung unterscheidet sich von früheren experimentellen Implementierungen.

Nicht annehmen, dass Abkündigung Ungültigkeit bedeutet

Roots, Sampling und Logging bleiben während des Abkündigungszeitraums verfügbar.

Nicht annehmen, dass alle Clients `2026-07-28` bereits unterstützen

SDK- und Produktübernahmen schreiten unterschiedlich schnell voran.

Nicht annehmen, dass „offenes Protokoll“ „keine Sicherheitsarbeit“ bedeutet

MCP kann leistungsstarke Tools ausführen.

Autorisierung, Benutzereinwilligung, Sandboxing, Tool-Design, Geheimnisverwaltung und Auditierung bleiben unerlässlich.

Häufige Fragen

Was ist MCP 2026-07-28?

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.

Ist MCP jetzt vollständig zustandslos?

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.

Was ist mit `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.

Kann ich MCP-Server auf AWS Lambda oder Cloudflare Workers bereitstellen?

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.

Was sind MCP-Apps?

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.

Was sind MCP-Aufgaben?

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.

Was ist Unternehmensgehostete Autorisierung?

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.

Muss ich sofort von älterem MCP migrieren?

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.

Zusammenfassung

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.