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 (, , ) variieren nicht mehr pro Verbindung – derselbe Request liefert dieselbe Antwort, egal welches Replica ihn bearbeitet.