MCP wächst heran: Was Produktionsteams bei der neuen Spezifikation berücksichtigen müssen

Eine Überarbeitung, die größer ist als ein einfacher Versionsaufpreis

Laut der Veröffentlichungsmitteilung des Projekts veröffentlichte das Model Context Protocol seine umfangreichste Überarbeitung seit dem Start am 28. Juli 2026. Die Spezifikation streicht Protokoll-Sessions, formalisiert Erweiterungen, fügt dauerhafte asynchrone Arbeitsabläufe hinzu, verschärft die Autorisierung und bietet Implementierern eine echte Deprecierungsrichtlinie. Der Release Candidate war seit dem 21. Mai eingefroren, was den SDK-Betreuern, Client-Entwicklern und Serverbetreibern etwa zehn Wochen Zeit gab, das Neudesign zu testen.

Insgesamt bietet das fertige Dokument einen stateless-Kern, Mehrfach-Request-Verarbeitung, Routing über Header, Entdeckungsfunktionen sowie listbasierte Ergebnisse, die in Cache gespeichert werden können, ein Erweiterungsframework, Tasks, MCP-Apps, strengere Autorisierungsmechanismen sowie einen zuverlässigen Prozess für das schrittweise Abschalten von Funktionen.

„Stateless MCP“ klingt nach einem guten Schlagzeilentitel, doch die Liste der Änderungen ist länger. Mehrere bedeutende Änderungen sind darunter verborgen. Die Ergebnisse erhalten ein resultType-Feld. Der HTTP GET-Stream wird entfernt. subscriptions/listen übernimmt die Funktion der älteren Abonnementsmodelle. SSE-Streams verlieren die Möglichkeit zur Wiederaufnahme durch Last-Event-ID. Listen- und Ressourcenergebnisse müssen Cache-Hinweise enthalten. Tool-Schemata dürfen das gesamte JSON Schema 2020-12 verwenden. Schließlich liefert eine fehlende Ressource nun den standardmäßigen JSON-RPC-Wert -32602, anstatt wie bisher -32002.

Es wäre ein Fehler, dies als „Nur Abhängigkeit aktualisieren und neu deployen“ zu betrachten. Es handelt sich um eine Architekturmigration.

1. Ein stateless-Protokoll macht die Anwendung nicht stateless

Frühere Versionen schufen den Kontext mithilfe eines initialize/initialized-Handshakes. Bei entfernten HTTP-Servern konnte der Server außerdem eine Mcp-Session-Id bereitstellen, die der Client in späteren Anfragen wiederholte. Dadurch wurde ein Client mit einer Server-Sitzung verknüpft, und in tatsächlichen Implementierungen kam es häufig zu „sticky routing“ am Load Balancer, einem gemeinsamen Session-Speicher oder einer Kombination aus beidem.

Ab 2026-07-28 verschwinden sowohl der Handshake als auch die Protokoll-Sitzung. Jede Anfrage enthält ihre eigene Protokollversion, die Fähigkeiten des Clients sowie eine optionalen Client-Identität innerhalb von _meta. Server müssen server/discover implementieren, obwohl Clients dies nicht vor jeder Operation aufrufen müssen. Stattdessen kann ein Client seine bevorzugte Version senden und bei einem UnsupportedProtocolVersionError erneut versuchen.

Über Streamable HTTP enthält eine aktuelle Anfrage Metadaten wie diese:

MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

Dieselbe Version, Methode und Bezeichnung erscheinen auch im JSON-RPC-Body. Der Body bleibt die autoritative Quelle, und Server müssen jede Abweichung zwischen Header und Body ablehnen. Dadurch wird verhindert, dass ein Gateway eine Operation genehmigt oder leitet, während der Server eine andere ausführt.

„Stateless“ bedeutet nicht „nichts speichern“

Die Spezifikation beseitigt den Anwendungsstatus nicht; sie verbirgt ihn lediglich nicht mehr. Wenn ein Server Kontinuität von einem Aufruf zum nächsten benötigt, sollte er einen Domänennamen erstellen, beispielsweise workspace_id, browser_id, basket_id, analysis_run_id oder deployment_id. Der Client oder das Modell gibt diesen dann als gewöhnliches Argument in nachfolgenden Aufrufen an:

create_workspace()
→ { "workspace_id": "ws_7f3..." }

add_file(workspace_id="ws_7f3...", ...)
→ ...

run_analysis(workspace_id="ws_7f3...")
→ ...

Das ist sauberer als ein versteckter Transportzustand, erfordert aber von der Anwendung neue Aufgaben. Es müssen Eigentumsprüfungen, Isolation der Nutzer, Ablaufzeiten, Aufbewahrungsregeln, Autorisierungen sowie Schutzmaßnahmen gegen Raten oder Wiederholungen bewältigt werden. Persistente Workflows benötigen möglicherweise weiterhin eine Datenbank oder einen verteilten Cache, und langlaufende Aufgaben erfordern per Definition eine dauerhafte Speicherung. Die Infrastruktur kann zustandslos sein, während das Produkt weiterhin zustandsbehaftet bleibt.

2. Wo Zustandslosigkeit tatsächlich Vorteile bringt

Einfache horizontale Skalierung

Wenn eine Anfrage ihren eigenen Kontext enthält, kann der Server hinter einem standardmäßigen Round-Robin-Load-Balancer stehen. In Kubernetes reichen in der Regel eine normale Deployment und ein Service aus, ohne Notwendigkeit von Session-Affinity-Annotierungen oder StatefulSeteigenschaften, die ausschließlich zur Verwaltung von MCP-Sessions dienen. Insbesondere profitiert man vom Automasch skalieren: Ein neuer Pod muss keine Protokollsessions neu erstellen, bevor er Verkehr entgegennimmt, und ein Pod, der während eines rolling Deployment ausgetauscht wird, lässt Clients nicht in einer ungültigen Session zurück.

Es gibt jedoch einen Haken: Wenn eine Anwendung Anfragen oder Aufgaben verarbeitet, bleiben diese Objekte weiterhin in einem externen, dauerhaften Speicher gespeichert, falls ein Prozess oder Pod ausgefallen ist.

Routing und Richtlinien am Gateway

Weil Mcp-Method und Mcp-Name einfache Header sind, kann ein Gateway routen, messen und Richtlinien durchsetzen, ohne jemals einen JSON-Körper analysieren zu müssen. In einem Mehr-Mieter-Dienst, der den Weg für getrennte Quoten für tools/list, kostspielige Suchwerkzeuge, Bereitstellungswerkzeuge sowie alles Zerstörerische ebnet, ist das von Vorteil:

tools/list                  → high request allowance
tools/call + search         → standard allowance
tools/call + deploy_prod    → lower rate limit and stronger policy
resources/read              → data-volume quota

Ein Gateway sollte auch niemals clientInfo als Beweis dafür lesen, wer anruft. Das Feld ist selbst deklariert und dient der Anzeige, dem Debuggen sowie dem Protokollieren. Wer der Mieter ist, muss aus einem validierten Token oder einer anderen zuverlässigen Quelle ermittelt werden.

Caching

Antworten auf resources/read, resources/templates/list, resources/list, prompts/list, tools/list und server/discover enthalten jeweils zwei neue Felder, ttlMs und cacheScope. Das erste dient als Hinweis auf die Aktualität, nicht als Abfrageintervall. Das zweite gibt an, ob ein Ergebnis öffentlich oder privat ist. Alles, was je nach Benutzer, Mieter, Bereich oder Autorisierung variiert, darf nicht als gemeinsame öffentliche Daten behandelt werden, und Änderungsbenachrichtigungen können ein sonst aktuelles Ergebnis ungültig machen.

Caching reduziert wiederholte Anfragen nach dem Werkzeugkatalog und stabilisiert die Eingaben für Modellanfragen. Eine falsch gewählte Reichweite führt außerdem zu einer neuen Kategorie von Fehlern im Zusammenhang mit Korrektheit und Privatsphäre.

Beobachtbarkeit

In den Spezifikationsdokumenten wird die Verbreitung des W3C Trace Context über die _meta-Schlüssel traceparent, tracestate und baggage beschrieben. Ein Host, ein MCP-Klient, ein Gateway, ein Server sowie Dienste weiter im Stromlauf teilen somit eine Methode, um einen Werkzeugaufruf entlang des gesamten Ausführungspfades zu korrelieren. Der Trace Context unterstützt die Korrelation, ist jedoch kein Autorisierungsmechanismus und keine Integritätsgarantie; sensible Daten, Token, Rohanfragen sowie persönliche Informationen haben keinen Platz in „baggage“.

3. Erweiterungen werden zu einem Konzept erster Klasse

Jede Erweiterung verfügt nun über einen Identifikator, Verhandlungsregeln, festgelegte Wartungspersonen, ihr eigenes Repository sowie ihren eigenen Veröffentlichungsrhythmus. Clients deklarieren die von ihnen unterstützten Erweiterungen in den über jede Anfrage gesendeten Fähigkeiten, während Server diese über server/discover ankündigen. Eine Erweiterung tritt erst in Kraft, wenn beide Seiten sie unterstützen; fehlt sie beim Gegenüber, muss die Implementierung auf das Kernverhalten zurückgreifen oder mit einem entsprechenden Fehler antworten.

Das ist ein großer Schritt für die Weiterentwicklung des Protokolls, da Funktionen nicht mehr auf eine vollständige Kernversion warten müssen. Zudem entsteht eine Kompatibilitätsmatrix. Ein Server kann nicht davon ausgehen, dass jedes Host-System Tasks, MCP Apps, Enterprise-Managed Authorization oder zukünftige Erweiterungen unterstützt, weshalb Produktionscode explizite Fallback-Mechanismen benötigt:

• Ein Tool, das Aufgaben unterstützt, bietet außerdem einen synchronen Weg für Clients an, die keine Aufgaben anzeigen, oder gibt einen klaren Fehler wegen fehlender Unterstützung zurück.
• Ein durch eine MCP-App unterstütztes Tool liefert nützlichen, strukturierten oder textbasierten Inhalt, wenn der Host seine Benutzeroberfläche nicht darstellen kann.
• Unternehmensweite Autorisierung wird nur dann angewendet, wenn es die organisatorischen Richtlinien zulassen.
• Felder, die spezifisch für Erweiterungen bestimmt sind, gelangen niemals an einen Client, der sie nicht ausgehandelt hat.

Erweiterungen verringern die Kopplung an die Kernspezifikationen, erhöhen aber das Risiko einer Fragmentierung des Ökosystems.

4. Aufgaben machen langlaufende Tools widerstandsfähig

Die Aufgaben wechseln vom experimentellen Kern in eine offizielle Erweiterung, io.modelcontextprotocol/tasks. Wenn der Client angibt, Aufgaben zu unterstützen, darf der Server mit einer normalen Operation antworten, bei der anstelle des endgültigen Ergebnisses ein Task-Handle übergeben wird. Der Client verwendet anschließend tasks/get, um den aktuellen Zustand abzurufen, tasks/update, um die angeforderten Eingaben bereitzustellen, und tasks/cancel, um eine Stornierung anzufragen.

Ein Task durchläuft die Zustände working, input_required, completed, failed und cancelled. Der Server muss den Task persistieren, bevor er den Handle zurückgibt. Die Stornierung erfolgt kooperativ, sodass eine bestätigte Anfrage nicht garantiert, dass die darunterliegende Verarbeitung sofort stoppt.

Natürliche Kandidaten sind Testsuite, Build-Pipelines, Code-Generierung, Cloud-Deployment, Datenimport, Dokumentverarbeitung, Schritte, die auf menschliche Freigabe warten, Batch-Jobs sowie schlanke Wrapper für externe Job-APIs. Was man tatsächlich erhält, ist nicht die asynchrone Ausführung an sich, sondern die Fähigkeit zur Wiederherstellung: Ein Client kann abbrechen, neu starten und mit derselben Task-ID weiterhin abfragen.

Was ein Produktivserver hinzufügen muss

Tasks benötigen weitaus mehr als nur einen Hintergrundthread:

• einen dauerhaften Task-Repository
• eine Autorisierungsprüfung jedes Mal, wenn tasks/get, tasks/update oder tasks/cancel aufgerufen wird
• Isolierung von Eigentum und Nutzern
• Validierung von Statuswechseln
• Aufbewahrung von Ergebnissen und Fehlern
• Durchsetzung von TTL und Bereinigung
• Beschränkungen der Abfragefrequenz
• Verbreitung von Abbruchbefehlen

Wiederherstellung bei Ausfall eines Arbeiters

Idempotente Erstellung von Aufgaben

Schutz vor doppelten Aktualisierungen

Metriken zur Laufzeit der Warteschlange und steckengebliebenen Aufgaben

Betrachten Sie die Aufgaben-ID als Ressourcenidentifikator und nicht als Geheimnis. Die Besitzung der ID darf niemals ausreichen, um etwas zu autorisieren.

5. Mehrfache Round-Trip-Anfragen ersetzen serverseitig initiierte Anfragen

Ein stateless Server kann sich nicht auf eine dauerhafte zweck方向的 Verbindung verlassen, um jederzeit eine Frage an den Client zu stellen. Dafür kommen Mehrfache Round-Trip-Anfragen (MRTR) zum Einsatz. Wenn ein Server Bestätigung, Angaben, Beispiele oder andere vom Client bereitgestellte Eingaben benötigt, gibt er einen InputRequiredResult zurück. Der Client sammelt die Eingaben und versucht die ursprüngliche Operation erneut mit inputResponses sowie ggf. requestState.

Nehmen wir ein zerstörerisches Tool als Beispiel:

delete_resources(resource_ids=[...])

Anstelle einer umgekehrten Anfrage für einen bestehenden Stream antwortet der Server:

input_required:
  "Confirm deletion of 53 resources"

Der Client erhält eine Bestätigung und wiederholt den ursprünglichen Aufruf. Der Neuanlauf ist selbstständig, sodass dies bei verschiedenen Instanzen funktioniert, bedeutet aber auch, dass Server für Neuanläufe konzipiert werden müssen.

Regeln für MRTR in der Produktion

• Führen Sie keine irreversiblen Aktionen durch, bevor alle erforderlichen Eingaben vorliegen.
• Machen Sie Neuanläufe idempotent.
• Binden Sie requestState an die spezifische Operation sowie an den Aufrufer, der sie gestartet hat.
• Lassen Sie alte Request-States ablaufen.
• Lehnen Sie Antworten ab, die auf Schlüssel verweisen, die der Server nie angefordert hat oder bereits erhalten hat.
• Legen Sie eine Obergrenze für die Anzahl der zulässigen Runden fest, damit sich keine Schleifen bilden können.
• Genehmigen Sie die Operation bei jedem Neuanlauf erneut.
• Annahmen darüber, dass der Neuanlauf auf derselben Instanz erfolgt, sind stets unzulässig.

Wenn der Workflow sensibel ist, sollte requestState entweder ein undurchsichtiger Zufallshandle sein, wobei die tatsächlichen Daten auf dem Server gespeichert werden, oder ein Wert, der einen Nachrichtenauthentifizierungscode enthält, damit Manipulationen sichtbar werden.

6. MCP-Apps ändern das Produkt, nicht nur das Protokoll

MCP-Apps ermöglichen es einem Server, ein Tool mit einer interaktiven HTML-Schnittstelle zu verknüpfen. Kompatible Hosts rendern diese in einem sandboxierten iframe. Die App kommuniziert mit dem Host über JSON-RPC mittels postMessage, und der Host bestimmt, welche Funktionen und Tools die App nutzen darf. Dadurch werden Formulare, Dashboards, Bestätigungsdialoge, Medienplayer, Bereitstellungskonfiguratoren, Triage-Bildschirme sowie andere Anwendungen ermöglicht, die sich als reiner Text schwer darstellen lassen.

Für ein Start-up kann dies die Wirtschaftlichkeit des MVP verändern: ein interaktiver, konversationaler Arbeitsablauf, ohne zunächst eine separate Anwendungsstruktur sowie eine Integrationsschicht erstellen zu müssen. Die Frontend-Entwicklung verschwindet jedoch nicht. Die Teams sind weiterhin für das Gestalten einer benutzerfreundlichen Benutzeroberfläche, die Verwaltung des Zustands, die Einrichtung von CSP, den Code, der innerhalb des Sandboxes ausgeführt wird, die Eingabenvalidierung, die Abstimmung auf die Fähigkeiten des Hosts, die sichere Handhabung von Tool-Aufrufen, die Kompatibilitätsprüfung auf verschiedenen Clients sowie einen Ersatz für Hosts ohne App-Unterstützung verantwortlich. Da Apps eine optionale Erweiterung sind, variiert die Host-Unterstützung, weshalb ein Server auch dann sinnvolle, strukturierte Inhalte zurückgeben sollte, wenn die Ansicht nicht angezeigt werden kann.

7. Die Autorisierung wird strenger und schwieriger

Nach den HTTP-Autorisierungsregeln übernimmt ein geschützter MCP-Server die Rolle eines OAuth-Ressourcenservers und der MCP-Client die Rolle eines OAuth-Clients. Die Überarbeitung übernimmt ausgewählte Elemente von OAuth 2.1 sowie verwandten Standards. Server müssen geschützte Ressourcenmetadaten veröffentlichen, damit Clients sie finden können, und sowohl OAuth- als auch OpenID Connect-Autorisierungsservermetadaten werden akzeptiert. PKCE ist zwingend erforderlich, genauso wie Ressourcenindikatoren in Autorisierungs- und Tokenanfragen, und die Prüfungen des Ausstellers sind strenger. Die wichtigsten Regeln sind:

• Client senden einen resource-Parameter, mit dem der gewünschte MCP-Server benannt wird.
• Ein Server überprüft, ob das Token, das er erhält, für seine eigene Zielgruppe erstellt wurde.
• Autorisierungsserver sollten iss enthalten, und Client prüfen bei Vorhandensein diesen Aussteller, bevor sie den Autorisierungscode einlösen.

Die Anmeldeinformationen sind mit dem Autorisierungsserver verknüpft, der sie ausgestellt hat.

Zugriffstoken gehören in den Authorization-Header und niemals in eine Abfragesuche.

Ein vom MCP-Server empfangenes Token darf nicht an eine nicht verwandte nachgelagerte API weitergeleitet werden.

Kunden verwenden PKCE, vorzugsweise S256.

Die Erweiterung des Zugriffsbereichs ist begrenzt und durch Wiederholungsversuche eingeschränkt.

Die dynamische Klientenregistrierung ist veraltet und wird durch Klient-ID-Metadokumente ersetzt.

Ressourcenindikatoren beschränken den Empfängerkreis eines Tokens. Sie sollten nicht als kryptografische Token-Bindung bezeichnet werden.

Die Unternehmensidentität ist eine separate Angelegenheit

Die Kern-MCP-Autorisierung umfasst den standardmäßigen, vom Benutzer delegierten OAuth-Fluss. Eine zentrale Unternehmenszugriffsrichtlinie wird durch die optionale Erweiterung „Enterprise-Managed Authorization“ bereitgestellt, die es dem Identitätsanbieter eines Unternehmens ermöglicht, den Zugriff auf MCP-Server zu steuern – einschließlich Onboarding, Offboarding, bedingten Zugriffs sowie Durchsetzung von Richtlinien. Sowohl der Client als auch das Autorisierungssystem des Servers sowie die Unternehmensidentitätsumgebung müssen dies unterstützen. Zur Sicherheitsprüfung ist die Architektur wie folgt aufgeteilt:

Core authorization
  OAuth flow
  issuer validation
  resource/audience validation
  scopes and step-up
  Protected Resource Metadata

Optional enterprise extension
  corporate IdP policy
  SSO
  centralized approval and revocation
  identity-assertion exchange

Die Spezifikation klärt die Architektur, macht den OAuth-Betrieb jedoch nicht operativ einfacher. Das Abrufen von Client-Metadaten führt zu Problemen im Zusammenhang mit SSRF und Vertrauensrichtlinien. Tokens sowie Erneuerungscredentials benötigen sicheren Speicher. Bei Implementierungen mit mehreren Ausstellersystemen sind getrennte Registrierungen sowie ein eigenständiger Token-Zustand erforderlich. Metadaten, Redirect-URI, Scopes sowie kanonische Ressourcenidentifikatoren müssen stets konsistent bleiben.

8. Eine echte Deprecierungsrichtlinie

Funktionen haben derzeit drei Zustände: Aktiv, Depreciert und Entfernt. Eine Kernfunktion bleibt in der Regel mindestens zwölf Monate lang Depreciert, bevor sie entfernt werden kann. Für die Deprecierung ist ein dokumentierter Migrationsweg sowie ein Eintrag im zentralen Register erforderlich. Die tatsächliche Entfernung kann später stattfinden als das früheste Datum. Für akute Sicherheitsrisiken gibt es einen beschleunigten Weg, doch auch dieser benötigt in der Regel mindestens 90 Tage.

HTTP+SSE, das ältere Transportprotokoll, verfügt über eigene Übergangsregeln und könnte früher deaktiviert werden als die anderen kürzlich deprecierten Funktionen. Jeder, der es noch verwendet, sollte zunächst den Umstieg auf Streamable HTTP planen. Beachten Sie außerdem, dass die zwölfmonatige Frist nur für Protokollfunktionen gilt; SDK-APIs haben eigene Support-Richtlinien und Zeitpläne, die sich unterscheiden können.

Wie es in echten Anwendungen aussieht

Unternehmensinterne Tools

Stellen Sie sich ein Unternehmen vor, das interne Kenntnisse, Jira, Confluence, Servicekataloge sowie Anleitungen über MCP veröffentlicht. Mit dem alten Modell könnte eine entfernte Bereitstellung von Session-Affinität abhängen, sodass ein Mitarbeiter stets auf dieselbe Instanz zugreift. Ab 2026-07-28 kann die MCP-Ebene aus einer Reihe stateloser Container hinter einem normalen Kubernetes Service und Load Balancer bestehen:

MCP host
  ↓
API gateway / authorization
  ↓
Stateless MCP Deployment
  ├─ Knowledge connector
  ├─ Jira connector
  ├─ Confluence connector
  └─ Service catalog connector
  ↓
OpenTelemetry backend

Die tägliche Autorisierung kann dem grundlegenden OAuth folgen, wobei die Erweiterung „Enterprise-Managed Authorization“ zum Einsatz kommt, wenn eine zentrale IdP-Politik erforderlich ist. Die Anzahl der Clients, die diese Erweiterung tatsächlich unterstützen, stellt die Hauptbeschränkung dar.

Multi-tenant SaaS

Angenommen, ein Anbieter von Entwicklerwerkzeugen verkauft MCP als kostenpflichtige API an Hunderte oder Tausende von Nutzern. Der Zustandslosigkeitsansatz ermöglicht einfaches Mehr-Zonen-Routing, und das Gateway kann nach Mcp-Method sowie Mcp-Name messen, wobei der Nutzer aus einer validierten Autorisierung abgerufen wird und nicht aus den Namen oder Headern, die der Client sendet. Eine solide Implementierung würde die Handles und Tasks nach Nutzern trennen, nutzerbezogene Kataloge mit cacheScope: „private“ kennzeichnen, jeden Header mit dem Inhalt vergleichen, teure Tools innerhalb ihrer eigenen Grenzen begrenzen, Abfragen nach Tasks zwischen Nutzern blockieren und Autorisierungsentscheidungen außerhalb des lokalen Prozessspeichers vornehmen. Ein sessionsbasiertes Routing gibt es nicht mehr; die Trennung der Nutzer bleibt weiterhin Ihre Aufgabe.

KI-basierte Programmierassistenten

Ein Coding-Server kann run_tests, build_project, generate_patch oder deploy_preview als Aufgaben bereitstellen. Er gibt sofort eine Aufgaben-ID zurück, stellt die Arbeit in die Warteschlange und ermöglicht es dem Agenten, weiterhin Code zu lesen oder ein anderes Problem zu prüfen. Der Client fragt zu dem vom Server vorgeschlagenen Intervall nach, und wenn ein zerstörerischer Schritt Genehmigung benötigt, wechselt die Aufgabe in den Zustand input_required, woraufhin der Client mit tasks/update antwortet. Der Vorteil ist die Widerstandsfähigkeit gegenüber Neustarts des Editors und Netzwerkunterbrechungen. Der Preis ist ein echtes Aufgabensystem: eine zuverlässige Warteschlange, Arbeitsplatzmietmodelle, gespeicherte Ergebnisse, Möglichkeit zur Stornierung, isolierte Arbeitsräume sowie eine Speicherrichtlinie.

Gesundheitswesen und Finanzdienstleistungen

Ressourcenindikatoren und Überprüfungen der Zielgruppe verringern die Wahrscheinlichkeit, dass ein für einen MCP-Server ausgestellter Token an einem anderen Server erneut verwendet wird, und die Validierung des Ausstellers senkt das Risiko von OAuth-Fehlkonfigurationsangriffen. W3C Trace Context ermöglicht es, eine Anfrage entlang des MCP-Pfads sowie der dahinterliegenden Dienste nachzuvollziehen. Gemeinsam bieten sie den Teams für Sicherheit und Konformität ein klareres Kontrollinstrumentarium – allerdings nicht eine vollständige Lösung für die Konformitätsanforderungen. Im Inneren der Anwendung sind weiterhin Autorisierungen, unveränderliche Prüfungsereignisse, Regeln für die Aufbewahrung und Löschung von Daten, Datenklassifizierung, Handhabung von Einwilligungen, Schlüsselverwaltung, Protokolle zu administrativen Zugriffen, ein Vorgehen bei Vorfällen sowie minimale Verfolgungsdaten erforderlich. Die Verfolgung unterstützt die Diagnose; sie sollte jedoch nicht das einzige Prüfungsprotokoll sein.

Eine auf KI ausgerichtete Startup-Firma

Betrachten wir ein kleines Team, das einen Infrastruktur-Assistenten entwickelt. Über MCP Apps könnte es ein Deployment-Plan-Formular, ein Kostenkalkulations-Dashboard, ein Genehmigungsdialogfeld, einen Rollout-Überwachungsmechanismus sowie eine Rollback-Kontrollfunktion bereitstellen. Der Host liefert den konversationellen Kontext, der Server stellt Tools und UI-Ressourcen zur Verfügung, und die App ruft diese Tools über eine vom Host gesteuerte Brücke auf. Ein separates Dashboard-Produkt mag anfangs überflüssig sein, doch API-Design, Autorisierung, UI-Testing, Barrierefreiheit, CSP-Regeln sowie KompatibilitätsFallbacks bleiben weiterhin erforderlich.

Wo die neue Spezifikation Komplexität hinzufügt

Der Zustand wurde verschoben, er ist nicht verschwunden. Der Verbindungsstatus wird zu einem expliziten Domänenzustand – eine architektonische Verbesserung, die eine bewusste Gestaltung von Handhabungsmethoden, Speicherung, Ablaufzeiten, Eigentumsverhältnissen und Idempotenz erfordert.

Die Aktualisierung des SDK sowie die Einführung des Protokolls sind zwei getrennte Projekte. Während die Release-Kandidatur verfügbar war, rieten die SDK-Betreuer den Teams davon ab, die Erhöhung der Hauptversion des SDK mit dem Einsatz des neuen Übertragungsprotokolls zu verknüpfen – dieser Rat gilt weiterhin. Nehmen wir das TypeScript v2 SDK: Es teilt das ursprüngliche Paket in separate Server- und Client-Pakete auf, wird ausschließlich als ESM bereitgestellt, läuft unter Node.js 20+, Bun und Deno, wird durch standardkonforme Schema-Bibliotheken überprüft und enthält einen Codemod für typische Änderungen von v1. Auch Python v2 erfordert eine umfassende Überarbeitung, unter anderem durch die Umbenennung von FastMCP in MCPServer. TypeScript v1 erhält mindestens sechs Monate lang Fehlerbehebungen und Sicherheitsupdates, sobald v2 verfügbar ist, und Python v1 wird weiterhin kritische Fehlerbehebungen sowie Sicherheitspatches erhalten. Eine vorsichtige Arbeitsabfolge:

1. Erweitern Sie das SDK, wobei das bisherige Protokollverhalten dort beibehalten wird, wo es unterstützt wird.
2. Beseitigen Sie Änderungen an der API auf Anwendungsseite.
3. Fügen Sie Unterstützung für Protokolle beider Epochen hinzu.
4. Überprüfen Sie die Funktionalität mit echten Clients und Datenverkehr.
5. Führen Sie schrittweise ein modernes, zustandsloses Verhalten ein.
6. Entfernen Sie die Unterstützung für veraltete Versionen erst nach Beobachtung der Client-Akkzeptanz.

Erweiterungen fragmentieren die Funktionalitäten. Ein Tool kann nicht davon ausgehen, dass Tasks oder MCP Apps überall vorhanden sind, weshalb Produktteams Kompatibilitätsmatrizen sowie Ersatz-UX-Lösungen benötigen.

Wiederholte Versuche stellen ein Korrektheitsproblem dar. Wiederholte Versuche entstehen nun durch MRTR, Verhandlungen über die Protokollversion, abgebrochene HTTP-Antwortströme, Aufstieg der Autorisierungsebene, Polling von Tasks sowie Wiederherstellung von Abonnements. Jede Operation mit Nebeneffekten benötigt daher einen bewussten Plan zur Idempotenz.

OAuth ist besser interoperabel, bleibt aber anspruchsvoll. Die Spezifikation bezieht sich auf OAuth 2.1 sowie Client ID Metadata Documents als Entwürfe, weshalb Implementierer sowohl die MCP-Änderungen als auch die zugrunde liegenden Standards befolgen müssen.

Caching wirft Privatsphärenfragen auf. Die Markierung einer autorisierungsabhängigen Antwort als öffentlich könnte das Katalog eines Benutzers oder Mieters einem anderen zugänglich machen. Konservative Standards sind geeignet: Verwenden Sie einen privaten Scope, es sei denn, das Ergebnis ist für jeden Aufrufer tatsächlich identisch.

Gesamtbewertung

MCP 2026-07-28 bringt das Protokoll der Funktionsweise des modernen Webs näher: eigenständige Anfragen, explizite Versionen, herkömmliches HTTP-Routing, echte Cache-Semantik, verteiltes Tracing, standardisierte Autorisierung sowie optionale Funktionen, die getrennt weiterentwickelt werden. Der eigentliche Vorteil liegt nicht im Fehlen eines Zustands, sondern im Fehlen versteckter Protokollzustände.

Das Skalieren, das Routing über verschiedene Zonen, das Wiederherstellen nach Ausfällen, die Einstellung der Gateway-Politik sowie die Überwachung des Systems werden alle erheblich einfacher. Im Gegenzug treten die Arbeitssession-States zutage, die bisher verdeckt blieben: Anwendungshandle, Idempotenz, dauerhafte Aufgaben, Fallback-Möglichkeiten für Erweiterungen, Autorisierungsmetadaten, die Privatsphäre von Caches sowie das Verhalten bei Wiederholungsversuchen.

Falls Sie bereits einen Produktivserver betreiben, führen Sie die Migration schrittweise durch und unterstützen Sie beide Versionen. Behandeln Sie den SDK-Upgrade sowie das Wire-Protokoll als getrennte Schritte, entfernen Sie Annahmen bezüglich der Verbindungen, speichern Sie langfristig laufende Aufgaben in expliziten Strukturen, testen Sie Autorisierungsmechanismen sowie Wiederholungsversuche, und deaktivieren Sie veraltete Funktionalitäten erst, nachdem eine tatsächliche Adoptionsrate bei den Clients gemessen wurde. Bei einem völlig neuen Server ist es einfacher: Beginnen Sie mit statelessen Anfragenverarbeitern und explizitem Zustandsmanagement, verwenden Sie Streamable HTTP sowie aktuelle Autorisierungsverfahren, fügen Sie OpenTelemetry hinzu, gestalten Sie das Caching deterministisch und planen Sie bereits ab dem ersten Tag die Erweiterungsmöglichkeiten.

Das Protokoll ist nun leichter in Betrieb zu nehmen – allerdings nur für Teams, die bereit sind, ihren Anwendungsstatus, Sicherheitsgrenzen sowie Fehlerverhalten detailliert zu definieren.

Verwandte Literatur

• Praktische Hinweise: MCP 2026 – Wie das Protokoll weiterentwickelt wurde: Was bedeutet das für die Produktion von KI-Systemen – Detaillierte Anleitung zu den Praktischen Hinweisen: MCP 2026 – Wie das Protokoll weiterentwickelt wurde: Was bedeutet das für die Produktion von KI-Systemen, einschließlich Verträgen, Überprüfungen sowie Code-Blöcken, die Teams nutzen können, die dieses Muster einsetzen.
• Zehn MCP-Server, die Entwicklern in Prioritätsreihenfolge zuerst installiert werden sollten – Eine nach Priorität geordnete Liste von MCP-Servern für KI-Code-Assistenten, von Context7 und GitHub über Postgres bis hin zu Speichersystemen, inklusive Installationskonfigurationen und Hinweisen zu Berechtigungen.

Messung der Portfolio-Abweichung mit Claude und dem FMP MCP Server — Ein hypothetisches Portfolio eines Family Offices im Wert von 1 Mio. Dollar wird anhand der FMP-Preise neu aufgebaut, um absolute, relative sowie sektorspezifische Abweichungen zu messen und Positionen zur Überprüfung durch Analysten zu kennzeichnen.

[Praktische Hinweise: MCP Server – Vom KI-Chat zu produktionsreifen Aktionen Artikel — Detaillierte Anleitung zu den Praktischen Hinweisen: MCP Server – Vom KI-Chat zu produktionsreifen Aktionen [Artikel: Verträge, Überprüfungen sowie Code-Blöcke für Teams, die dieses Muster einsetzen.]