MCP 2026: Der Umbau zum produktionsreifen Agenten-Protokoll

📷 "Technical Session # 5 Learning" by brewbooks is licensed under CC BY-SA 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by-sa/2.0/.

Vor knapp zwei Jahren hat Anthropic das Model Context Protocol (MCP) vorgestellt, um KI-Modelle standardisiert mit externen Tools und Datenquellen zu verbinden. Aus dem Experiment ist längst die Integrationsschicht der Agentic-KI geworden: Die Tier-1-SDKs verzeichnen inzwischen rund eine halbe Milliarde Downloads pro Monat, die TypeScript- und Python-SDKs haben jeweils die Milliarden-Marke überschritten. Im Mai 2026 warnte die NSA erstmals formal vor Sicherheitslücken des Protokolls, im Juli 2026 folgte die bislang tiefgreifendste Revision der Spezifikation. MCP wird erwachsen — und genau das verändert, wie Teams Agenten bauen und betreiben.

Abschied vom Session-Zwang: der stateless Core

Das Herzstück der Revision 2026-07-28 ist ein stateless Protokollkern. Der initialize/initialized-Handshake und der Mcp-Session-Id-Header sind ersatzlos entfallen. Jede Anfrage trägt ihre Protokollversion, Client-Identität und Capabilities selbst in _meta mit; wer die Fähigkeiten eines Servers vorab kennen will, nutzt optional den neuen server/discover-Aufruf. Die Folge ist praktisch bedeutsam: Eine Anfrage kann auf jede beliebige Instanz hinter einem einfachen Round-Robin-Load-Balancer landen, ohne dass die Instanzen gemeinsamen State halten müssen. Horizontale Skalierung, wie man sie von normalen HTTP-Diensten kennt, wird damit erstmals ohne Workarounds möglich.

The New Stack weist in seiner Einordnung auf einen wichtigen Punkt hin: „The protocol stopped managing state, which is not the same as the state going away." Wer als Server Anwendungszustand braucht, verwaltet ihn jetzt explizit — etwa über Handles, die das Modell als Argument zwischen Tool-Aufrufen weitergibt. Das macht den Zustand für das Modell sichtbar und für die Infrastruktur skalierbar.

Agentische Muster: MRTR und Tasks

Mit dem Wegfall bidirektionaler Streams mussten auch die Server-initiierten Anfragen neu gedacht werden. Dafür führt die Revision Multi Round-Trip Requests (MRTR) ein: Braucht ein Tool mitten im Aufruf eine Rückfrage, etwa eine Bestätigung oder einen fehlenden Parameter, antwortet der Server mit resultType: "input_required" und der Liste offener Fragen; der Client wiederholt den Aufruf mit den Antworten. Gleichzeitig sind die Tasks aus dem experimentellen Kern in die offizielle Extension io.modelcontextprotocol/tasks gewandert und bekamen mit tasks/update einen neuen Lebenszyklus.

Auch für den Betrieb gibt es Neuerungen: Methoden- und Tool-Namen reisen jetzt in den HTTP-Headern Mcp-Method und Mcp-Name, sodass Gateways, Rate-Limiter und WAFs direkt auf Headern routen können, statt JSON-Bodies zu parsen. Listenantworten (tools/list, resources/list) tragen Cache-Hinweise (ttlMs, cacheScope) und eine deterministische Reihenfolge — Client-Caches und Prompt-Caches bleiben so über Reconnects hinweg stabil.

Die NSA-Warnung als Weckruf

Im Mai 2026 veröffentlichte das NSA AI Security Center mit dem Cybersecurity Information Sheet U/OO/6030316-26 seine erste formale Sicherheitsanalyse zu MCP. Der Befund ist deutlich: Die Verbreitung des Protokolls sei der Reife seines Sicherheitsmodells davongelaufen. Die NSA identifiziert acht strukturelle Schwachstellenklassen, die auf Protokollebene liegen und nicht durch das Patchen einzelner Server zu beheben sind — darunter fehlende obligatorische Zugriffskontrolle, unsichere Serialisierung (CWE-77/78/94/95), Tool-Poisoning über manipulierte Tool-Beschreibungen sowie fehlende Audit-Log-Standards.

Das deckt sich mit einer nüchternen Beobachtung aus der Praxis: Die Spezifikation erzwingt Sicherheit auf Protokollebene bewusst nicht — Authentifizierung, Autorisierung und Governance sind Sache der Implementierung. Ein MCP-Server ist damit kein harmloses Browser-Plugin, sondern eher ein Service-Account mit Zugriff auf Live-Systeme. Empfehlungen aus der Praxis gehen deshalb dahin, das Hinzufügen eines MCP-Servers wie eine Beschaffungsentscheidung zu behandeln: Wer darf Server hinzufügen, wer reviewt sie, sind Versionen gepinnt?

Enterprise-Auth: Was die Revision nachschärft

Die Revision 2026-07-28 hat genau dort nachgelegt, wo die NSA die größten Lücken sieht. Authorization-Server müssen den iss-Parameter nach RFC 9207 ausliefern, und Clients müssen ihn vor dem Einlösen eines Codes validieren — das schließt die Verwechslung von Authorization-Servern. Client-Credentials sind jetzt an den ausstellenden Issuer gebunden, und die Dynamic Client Registration wird offiziell zugunsten von Client ID Metadata Documents (CIMD) abgelöst. Dazu kommt mit Enterprise-Managed Authorization eine stabile Extension für zentral verwaltete Zugriffsrechte.

Die im August veröffentlichte Roadmap treibt das Thema weiter: Agent Identity über Demonstrating Proof of Possession (DPoP, RFC 9449), Workload Identity Federation für Agenten, die im Auftrag abwesender Nutzer handeln, sowie die Zusammenarbeit mit den OAuth-Standardisierungsgremien IETF und WIMSE sind dort explizit als Priorität genannt.

Roadmap 2026: Fünf Prioritäten und neue Governance

Die neue Roadmap organisiert die Arbeit nicht mehr nach Release-Terminen, sondern nach Prioritätsbereichen mit eigenen Working Groups: agentische Messaging-Primitive, HTTP-native Transport-Unifikation, Agent-Identität und Enterprise-Security, verbesserte Primitiven (etwa progressive Discovery großer Tool-Kataloge) sowie SDK-Erlebnis. Neu ist auch die Governance: Ein formaler Contributor Ladder, Working Groups, die SEPs in ihrem Bereich selbst triagieren, und eine Deprecation-Policy mit zwölf Monaten Mindestübergang. Für Plattform-Teams ist gerade diese schriftliche Deprecation-Garantie ein starkes Argument, wie The New Stack anmerkt: Man kann Integrationen planen, statt auf Breaking Changes zu reagieren.

Der Enterprise-Bereich bleibt dabei bewusst der am wenigsten definierte — die Maintainer wollen, dass Teams mit Produktionserfahrung die Anforderungen (Audit-Trails, SSO, Gateway-Verhalten) selbst einbringen.

Fazit

MCP hat 2026 den Sprung vom Tool-Protokoll zur Infrastruktur geschafft: Der stateless Kern macht Server wie normale HTTP-Workloads skalierbar, MRTR und Tasks decken agentische Muster ab, und die Auth-Härtung adressiert zentrale NSA-Kritikpunkte. Zugleich ist die Botschaft eindeutig: Sicherheit ist und bleibt Aufgabe der Betriebsteams. Wer MCP einführt, sollte Server wie Dienste behandeln — mit Review, Version-Pinning, Least Privilege und Audit. Teams, die auf Session-basierten Servern aufbauen, sollten die Migration über die dokumentierten Übergangspfade (etwa server/discover mit Fallback auf initialize) planen. Die Grundlage dafür ist jetzt besser als je zuvor.