Was am 28. Juli erschienen ist
Das Model Context Protocol hat am 28. Juli seine fünfte Spezifikation veröffentlicht, und es ist die größte Änderung seit dem Start des Protokolls. Der Kern arbeitet jetzt zustandslos. Der Handshake aus initialize und initialized entfällt, der Header Mcp-Session-Id wird abgeschafft, und jede Anfrage trägt stattdessen die Protokollversion, die Identität des Clients und dessen Fähigkeiten in einem _meta-Feld. Praktisch heißt das: Ein einfacher Round-Robin-Lastverteiler genügt, jede Instanz kann jede Anfrage bedienen, und es gibt keinen gemeinsamen Sitzungsspeicher mehr zu betreiben.
Mehrere weitere Bausteine folgen aus dieser Entscheidung. Multi Round-Trip Requests ersetzen die vom Server ausgehenden Aufrufe, die bisher einen offen gehaltenen Datenstrom brauchten: Statt eine Anfrage durch einen offenen Kanal zu schieben, gibt der Server den Ergebnistyp input_required zurück, und der Client wiederholt den ursprünglichen Aufruf mit den Antworten im Gepäck. Streamable-HTTP-Anfragen führen nun die Header Mcp-Method und Mcp-Name mit, damit ein Gateway oder eine Ratenbegrenzung routen und messen kann, ohne den JSON-Rumpf zu lesen. Listenergebnisse von Werkzeugen, Prompts und Ressourcen tragen eine Lebensdauer und einen Cache-Geltungsbereich. Tasks und MCP Apps wandern in einen förmlichen Erweiterungsrahmen, statt im Kern zu sitzen.
Die Verbreitungszahlen erklären, warum das über den Kreis der Serverentwickler hinaus zählt. Die Tier-1-SDKs für TypeScript, Python, Go und C sharp nähern sich zusammen 500 Millionen Downloads im Monat, und die Pakete für TypeScript und Python haben je die Milliardengrenze insgesamt überschritten. David Soria Parra, einer der leitenden Maintainer, nannte es die wichtigste Veröffentlichung seit dem Start von remote MCP vor über einem Jahr. Wenn Ihr Unternehmen in den vergangenen achtzehn Monaten ein Produkt gekauft hat, das einen Assistenten an Ihre Systeme anbindet, liegt diese Spezifikation darunter, ob Ihnen der Name genannt wurde oder nicht.
Der Wegfall von Sampling verschiebt eine Inferenzrechnung
Die Liste der veralteten Funktionen liest sich wie Hausputz: Roots, Sampling und Logging, alle mit zwölfmonatiger Übergangsfrist. Zwei davon sind wirklich nebensächlich. Roots wird zu Verzeichnis- und Dateipfaden, die als Werkzeugparameter übergeben oder in der Serverkonfiguration hinterlegt werden. Logging wandert auf die Standardfehlerausgabe oder zu OpenTelemetry, wohin es die meisten Betreiber ohnehin haben wollten. Sampling ist ein anderer Fall, und zwar einer, der ein Budget berührt und nicht eine Codebasis.
Sampling war der Mechanismus, mit dem ein MCP-Server den Client bitten konnte, eine Modellantwort für ihn zu erzeugen. Der Server brauchte die Ausgabe eines Sprachmodells, musste aber keine Modellzugangsdaten halten, denn der Client führte die Inferenz aus und der Client bezahlte sie. Das ist eine reale kommerzielle Aufteilung, ausgedrückt als Protokollfunktion. Die veröffentlichte Migrationsempfehlung für Server, die Sampling verlieren, lautet, serverseitig direkt an die Schnittstellen eines Modellanbieters anzubinden. Als Betreiber gelesen ist die Folge eindeutig: Wer den Server betreibt, braucht künftig ein eigenes Anbieterkonto, einen eigenen Schlüssel und eine eigene Position im Budget.
In welche Richtung sich das Geld bewegt, hängt davon ab, auf welchem Platz Sie sitzen. Betreiben Sie MCP-Server für die eigene Belegschaft gegen den Client eines Anbieters, landet Inferenz auf Ihrem Konto, die Sie bisher nicht bezahlt haben, und bei einer mittelgroßen Installation ist das eine neue vierstellige Monatsverpflichtung in Euro und kein Rundungsfehler. Nutzen Sie den MCP-Server eines Anbieters, rechnen Sie mit einer Neubepreisung, denn Kosten, die bisher auf Ihren Client abgewälzt wurden, trägt nun der Anbieter selbst. Nichts davon steht in den Release Notes. Beides steht binnen eines Jahres auf einer Rechnung.
Zustandslos hat den Zustand verschoben, nicht gelöscht
Die Kommentare der Anbieter zu dieser Veröffentlichung drehen sich einhellig um Skalierung, und sie kommen von den Unternehmen, die am meisten davon haben, wenn Server leicht zu betreiben sind: Cloud- und Edge-Anbieter, die das Protokoll als routingfähig, zwischenspeicherbar und global skalierbar beschreiben, und Plattformfirmen, die das Ende der Sitzungsverwaltung begrüßen. Das alles trifft zu. Der Verzicht auf die Sitzungsbindung an eine feste Instanz beseitigt eine Fehlerklasse, bei der ein unterbrochener Datenstrom das ganze Gespräch zerstörte, und er erlaubt den Betrieb auf Serverless-Infrastruktur, die eine Sitzung nie hätte offen halten können.
Was dabei niemand sagt: Der Zustand hat sich nicht in Luft aufgelöst. Alles, was wirklich über mehrere Aufrufe hinweg bestehen muss, ist jetzt ausdrücklich abzubilden. Der Server vergibt eine Kennung - eine Warenkorb-ID, ein Token, eine Vorgangsreferenz - und gibt sie im Ergebnis zurück, damit der Client sie wieder mitschickt. Das ist ein solider Entwurf, aber er verwandelt eine unsichtbare Protokollangelegenheit in einen sichtbaren Teil Ihrer Werkzeugverträge. Jemand muss entscheiden, was diese Kennungen bedeuten, wie lange sie gelten und was geschieht, wenn ein Client eine veraltete erneut sendet. Diese Arbeit ist mit dem Sitzungsheader nicht verschwunden. Sie ist in Ihre Schemata gewandert, wo Ihr Team sie richtig machen muss.
Der 28. Juli 2027 gehört in die Planung
Maßgeblich ist die Regel, dass alles als veraltet Markierte mindestens zwölf Monate funktionsfähig bleibt. Damit ist der 28. Juli 2027 der früheste Termin, an dem Roots, Sampling, Logging, die dynamische Client-Registrierung oder der alte Transport über HTTP und SSE tatsächlich entfernt werden können, und der einzige Termin dieser Veröffentlichung, der in einen Fahrplan gehört. In dieser Woche bricht nichts. Die Änderungen bei der Autorisierung sollten Sie dennoch zuerst lesen: Autorisierungsserver müssen nun einen Aussteller-Parameter zurückgeben, Clients müssen ihn prüfen, bevor sie einen Code einlösen, Client-Zugangsdaten sind an den ausstellenden Server gebunden, und die dynamische Client-Registrierung weicht den Client ID Metadata Documents.
Für einen europäischen Betrieb lohnt sich frühes Handeln vor allem bei Enterprise Managed Authorization. Sie kommt als Erweiterung und erlaubt es der Administration, Zugriff auf MCP-Server zentral über einen Identitätsanbieter zu vergeben. Bislang kam die Autorisierung in MCP-Installationen häufig zuletzt, und genau deshalb blieben so viele interne Agentenprojekte in der Sicherheitsprüfung stecken. Falls Ihres dazugehört: Der Grund für das Steckenbleiben ist nun in der Spezifikation adressiert, und der ehrliche nächste Schritt ist, Ihre Anbieter zu fragen, wann sie die Erweiterung unterstützen, statt darauf zu warten, dass man es Ihnen sagt.
Weiterlesen: Eine Nachricht erreichte die SSH-Schlüssel | Anthropic bat einen Speicherhersteller um eigene Chips



