MCP 2026-07-28: Stateless, Production-Ready – und nicht von Skills ersetzt

Das Model Context Protocol hat gerade seine größte Überarbeitung seit dem Start veröffentlicht. Die Spezifikation 2026-07-28 streicht genau die zwei Dinge, um die herum jede MCP-Implementierung gebaut wurde: Sessions und den initialize-Handshake.

Das klingt brutal. Es ist aber genau die Änderung, die MCP endlich zu langweiliger Infrastruktur macht – der Sorte, die man hinter einen Load Balancer stellt, ohne nachzudenken. Hier die Kurzfassung: was passiert ist, was bricht, und warum die Debatte "Skills vs. MCP" von einer falschen Annahme ausgeht.

Die Schlagzeile: Stateless MCP

Bisher war die Kommunikation mit einem entfernten MCP-Server über HTTP ein Ritual: Client und Server tauschten Capabilities aus, der Server erzeugte eine Mcp-Session-Id, und jeder weitere Aufruf musste beim selben Prozess landen. In Produktion bedeutet das Sticky Sessions, einen geteilten Redis für den Session-State und Gateways, die Pakete tief inspizieren, um korrekt zu routen. Nett in der Demo. Schmerzhaft im Betrieb.

Spezifikation 2026-07-28 entfernt Sessions auf Protokollebene vollständig. Es gibt keinen Mcp-Session-Id-Header mehr und keinen Handshake. Jeder Request bringt alles Nötige in _meta mit:

• io.modelcontextprotocol/protocolVersion – welche Version dieser Request spricht
• io.modelcontextprotocol/clientCapabilities – was der Client unterstützt
• io.modelcontextprotocol/clientInfo – wer da anfragt

Server antworten mit ihrer eigenen Identität im _meta jedes Ergebnisses. Eine Versionsabweichung liefert einen UnsupportedProtocolVersionError, statt irgendwo tief im Aufruf zu scheitern. Die List-Endpunkte (tools/list, resources/list, prompts/list) variieren nicht mehr pro Verbindung – derselbe Request liefert dieselbe Antwort, egal welches Replica ihn bearbeitet.

Braucht ein Server wirklich Zustand über mehrere Aufrufe hinweg, erzeugt er ein explizites Handle, das der Client als ganz normales Tool-Argument zurückgibt. Zustand wird zu Anwendungsdaten statt zu Protokollmagie.

Das praktische Ergebnis: Ein MCP-Server ist jetzt einfach ein HTTP-Endpunkt. Serverless Functions, autoskalierende Pods, CDN-gecachte List-Antworten – alles funktioniert ohne Spezialrouting.

Was sich konkret geändert hat

MRTR ist konzeptionell das Spannendste. Im alten Modell riefen Server zurück in den Client – für Sampling, Roots oder Nutzereingaben. Das funktioniert nur mit einer zustandsbehafteten, bidirektionalen Verbindung. Das neue Modell macht daraus einen ganz normalen, wiederholbaren Request/Response-Zyklus. Elicitation, Freigaben, fehlende Parameter: alles wird zu "das brauche ich noch, frag mich nochmal".

Die Deprecation-Liste

MCP hat außerdem eine formale Feature-Lifecycle-Policy eingeführt: Active → Deprecated → Removed, mit einem Mindestfenster von zwölf Monaten und einem öffentlichen Register. Nichts verschwindet über Nacht, aber neue Implementierungen sollten Folgendes nicht mehr übernehmen:

Dass Roots, Sampling und Logging deprecated werden, ist eine Absichtserklärung: MCP verengt sich auf das, was nur ein Protokoll leisten kann – Transport, Discovery, Autorisierung, Tool- und Resource-Semantik. Alles andere gehört in die Host-Anwendung oder in dedizierte Infrastruktur.

Leise, aber wichtig: Auth, Caching, Tracing

In den kleinen Änderungen steckt der "Production Ready"-Teil:

• Härtere Autorisierung. Authorization Server sollen den iss-Parameter zurückgeben (RFC 9207), und Clients MÜSSEN ihn prüfen, bevor sie den Code einlösen. Client-Credentials sind an den ausstellenden Authorization Server gebunden – keine Wiederverwendung über Issuer hinweg, Neuregistrierung bei Wechsel. Dynamic Client Registration weicht Client ID Metadata Documents.
• Cachebare Ergebnisse. tools/list, prompts/list, resources/list, resources/read und Templates liefern jetzt ttlMs und cacheScope (public/private). Clients cachen statt zu pollen; Intermediaries wissen, was sie halten dürfen.
• Deterministische Tool-Reihenfolge. Server sollen Tools in stabiler Reihenfolge liefern – kleine Änderung, echter Effekt auf die Prompt-Cache-Trefferquote.
• OpenTelemetry. Dokumentierte Konventionen für traceparent, tracestate und baggage in _meta. Agenten-Aufrufe werden über Servicegrenzen hinweg nachvollziehbar.
• Standard-Header. Mcp-Method und bei Streamable-HTTP-POSTs, damit Gateways routen und rate-limiten können, ohne den JSON-RPC-Body zu parsen.

Zusammengenommen: Transport ohne Sticky Sessions, audience-gebundenes OAuth, Cache-Hinweise und verteiltes Tracing. Genau die Checkliste, die einem jedes Enterprise-Plattformteam vorlegt, bevor irgendetwas in Produktion darf.

Skills vs. MCP: die falsche Frage

Parallel dazu wurden Agent Skills – schlichte Markdown-Dateien mit prozeduralen Anweisungen, die bei Bedarf in einen isolierten Kontext geladen werden – sehr populär, und das Internet erklärte MCP prompt für tot.

Ist es nicht. Was stirbt, ist eine konkrete Unart: das mechanische Verpacken einer REST-API in einen MCP-Server. MCP-Mitgründer David Soria Parra bezeichnet simple REST-zu-MCP-Wrapper als Anti-Pattern, und die Zahlen geben ihm recht. Wer 40 REST-Endpunkte als 40 Tools exponiert, injiziert 40 JSON-Schemas in jeden einzelnen Turn des System-Prompts. In Claude Code verbrauchten statische Tool-Definitionen routinemäßig über 56.000 Tokens, bevor der Nutzer überhaupt etwas eingegeben hatte. Jede Zwischenantwort fließt anschließend durch das Kontextfenster – ein Dokument zwischen zwei Systemen zu bewegen, schiebt denselben Text also zweimal durch das Modell.

Aufmerksamkeit ist endlich und quadratisch. Mehr Tokens heißt mehr Kosten, mehr Latenz und messbar schlechteres Erinnerungsvermögen – Context Rot.

Zwei Muster lösen das, und keines davon verlangt, MCP aufzugeben:

• Progressive Discovery (Tool Search). Keine Schemas vorab injizieren. Das Modell bekommt eine search_tools-Fähigkeit und lädt nur die Schemas, die der aktuelle Schritt braucht. In Anthropics eigenen Messungen sank der Basis-Overhead in Claude Code von ~56.000 auf ~9.000 Tokens – rund 84 % weniger Kontext, verbrannt bevor die Arbeit beginnt.
• Programmatic Tool Calling (Code Mode). Statt eines Inferenz-Turns pro Tool-Aufruf schreibt der Agent ein einziges Skript, das in einer Sandbox läuft, in der MCP-Server als normale Code-APIs verfügbar sind. Schleifen, Filterung und Fehlerbehandlung passieren lokal; nur das Endergebnis kehrt in den Kontext zurück. Berichteter Effekt bei komplexen Workflows: von 150.000 auf ~2.000 Tokens.

Der Stack 2026 ist also kein einzelner Mechanismus, sondern drei komplementäre Säulen:

• Agent Skills – prozedurales Wissen, lokale Workflows, kein Vorab-Kontextverbrauch.
• MCP – die governte Konnektivitätsschicht: Discovery, Autorisierung, Transport, Tool- und Resource-Semantik.
• Code-Ausführung – die effiziente Laufzeit, in der Daten tatsächlich bewegt werden.

Sie ergänzen sich. Ein Skill kann dem Agenten explizit sagen, welche MCP-Tools er wie aufrufen soll. Server können ihr Domänenwissen zusammen mit ihren Tools ausliefern, sodass Anleitungen mit dem Server reisen statt in jedem Client zu leben. Und höhere Ebenen wie MCP Apps (server-gerenderte UI) sitzen auf dem Protokoll-Kernel, nicht darin – der Core bleibt schlank, das Ökosystem wächst drumherum.

Was jetzt zu tun ist

1. Session-Annahmen entfernen. Hängt der Server an Mcp-Session-Id, ersetzt ihn durch explizite, serverseitig erzeugte Handles als Tool-Argumente.
2. server/discover implementieren. Es ist verpflichtend – und die Kompatibilitätsgeschichte für ältere Clients.
3. Callbacks auf MRTR umstellen. Alles, was Sampling-, Roots- oder Elicitation-Callbacks nutzte, wird zu einem input_required-Ergebnis plus Retry.
4. Deprecated Features migrieren, solange das Zwölf-Monats-Fenster offen ist – vor allem HTTP+SSE und Dynamic Client Registration.
5. Keine REST-Wrapper mehr ausliefern. Ein kleines Set agenten-nativer Tools entwerfen, ttlMs setzen, Tool-Reihenfolge stabil halten – den Rest erledigen Progressive Discovery oder Code-Ausführung.

Das Fazit

MCP wird nicht ersetzt – es wird zur Infrastruktur degradiert, und das ist das Beste, was einem Protokoll passieren kann. Die Revision 2026-07-28 tauscht clevere bidirektionale Zustandshaltung gegen etwas, das in Produktion deutlich mehr wert ist: ein zustandsloses, cachebares, nachvollziehbares und audience-gebundenes HTTP-Protokoll, das skaliert wie alles andere im Cluster.

Die Ära des naiven Tool-Wrappings ist vorbei. Die Ära der Konnektivitätsschicht beginnt gerade.