Das neue MCP-Protokoll entlastet Server, belastet aber die Clients

Paradigmenwechsel in der MCP-Kommunikation

Das Model Context Protocol (MCP) steht vor einer grundlegenden technischen Neuausrichtung. Mit der neuesten Version vollzieht LF Projects den Schritt hin zu einer vollständig zustandslosen (stateless) Kommunikation. Dieser Wandel markiert einen signifikanten Einschnitt in der Architektur, da das bisherige Modell, das auf Sitzungen und initialen Handshakes basierte, zugunsten einer HTTP-ähnlichen Struktur aufgegeben wird.

Entlastung der Serverseite

Der Kern der Änderung liegt in der Beseitigung der Sitzungsverwaltung auf dem Server. Bisher mussten Serverinstanzen Informationen über aktive Sessions vorhalten und verwalten. Durch den Wegfall des `initialize`-Handshakes und der damit verbundenen Session-IDs entfällt dieser Overhead.

Für Betreiber von MCP-Servern ergeben sich daraus handfeste Vorteile:

* **Vereinfachte Skalierbarkeit:** Da Anfragen nicht mehr an eine spezifische Serverinstanz gebunden sind, lässt sich die Last problemlos über Round-Robin-Verfahren auf mehrere Instanzen verteilen.

* **Kein Session-Management:** Server müssen keine Zustände mehr über die Dauer einer Verbindung hinweg speichern.

* **Flexiblere Updates:** Da keine persistenten Sitzungen mehr existieren, können Server-Updates durchgeführt werden, ohne bestehende Verbindungen manuell bereinigen zu müssen.

Die neue Last bei den Clients

Wo Licht ist, ist auch Schatten: Die Komplexität, die auf der Serverseite abgebaut wurde, wandert nun in die Clients. Da der Server keine Informationen mehr über den Kontext speichert, müssen Clients die notwendigen Metadaten – wie Protokollversionen oder Client-Fähigkeiten – bei jeder einzelnen Anfrage im neuen `_meta`-Feld mitsenden.

Zudem sind Clients nun dafür verantwortlich, unterbrochene Sitzungen eigenständig neu zu initiieren. Die Methode `server/discover` dient dabei als neues Werkzeug für Clients, um die Fähigkeiten des Servers bei Bedarf abzufragen. Diese Umstellung erfordert von Entwicklern eine Anpassung der bestehenden Client-Architekturen, da die Zustandsverwaltung nun vollständig in deren Verantwortungsbereich liegt.

Breaking Changes und technologische Anpassungen

Die Umstellung ist mit sogenannten „Breaking Changes“ verbunden, die eine Anpassung der Software erfordern. Das Projektteam betont jedoch, dass dies keine dauerhafte Praxis werden soll. Zu den weiteren technischen Neuerungen gehören:

* **Standardisierung:** Für die Definition von Input- und Output-Schemata wird nun der Standard JSON Schema 2020-12 genutzt, was komplexere Bedingungen wie `oneOf`, `anyOf` oder `allOf` ermöglicht.

* **Veraltete Funktionen:** Die bisherigen Mechanismen für Roots, Sampling und Logging werden als veraltet eingestuft und sollen in einem Jahr vollständig aus dem Protokoll entfernt werden.

* **Logging-Änderungen:** Das Logging muss künftig über Mechanismen wie `stderr` oder OpenTelemetry abgewickelt werden.

* **Fehlerbehandlung:** Der Fehlercode für nicht auffindbare Ressourcen wurde auf -32602 (JSON-RPC) angepasst.

* **Sandbox-Integration:** Neu eingeführte HTML-Schnittstellen erlauben es dem Host, Schnittstellen innerhalb einer Sandbox auszuführen, wobei der Host diese vorab prüfen kann.

Implikationen für das Ökosystem

Durch den Wegfall des Samplings verlagert sich die Kontrolle stärker in Richtung der LLM-Anbieter. Diese fungieren nun direkter als API-Schnittstelle, was ihnen unter anderem ermöglicht, die Nutzung dieser Schnittstellen gezielter zu bepreisen. Die Einführung eines Namespace-Identifiers (`io.modelcontextprotocol`) für Extensions unterstreicht zudem den Wunsch nach einer saubereren Strukturierung im wachsenden MCP-Ökosystem. Entwickler sollten die kommenden Monate nutzen, um ihre Implementierungen auf die neuen Standards zu migrieren, da die Unterstützung für die als veraltet markierten Funktionen zeitlich begrenzt ist.