Microsoft hat Version 2.0 des offiziellen MCP-Software Development Kits für C# veröffentlicht, zeitgleich mit der Umsetzung der Spezifikation vom 28.07.2026. Die Version ändert die Art und Weise, wie MCP-Server über HTTP betrieben werden, indem sie standardmäßig zustandslos arbeiten, fügt standardisierte HTTP-Header hinzu und unterstützt Multi-Round-Trip-Anfragen, durch die Tools Eingaben vom Benutzer oder vom Sprachmodell anfordern können, ohne auf eine dauerhafte Sitzung angewiesen zu sein.
Die Version richtet sich an Entwickler, die MCP-Server und -Clients auf .NET erstellen, wobei stabile APIs der Version 1.x weiterhin funktionieren. Unterstützt werden die Frameworks net8.0, net9.0 und net10.0 sowie netstandard2.0 zur Verwendung mit .NET Framework.
Standardmäßig zustandslose Server
In früheren Versionen erforderte die Verwendung von Streamable HTTP den Abschluss eines Initialize- und Initialized-Handshakes sowie das Senden eines Mcp-Session-Id-Headers mit jeder nachfolgenden Anfrage. Dadurch wurden Anfragen an die Serverinstanz gebunden, die die ID ausgestellt hatte, was beim Betrieb mehrerer Instanzen statisches Routing oder die Übertragung von Sitzungen erforderte.
Die Spezifikation vom 28.07.2026 schafft den Initialize- und Initialized-Handshake sowie den Mcp-Session-Id-Header ab und übermittelt die Protokollversion und die Fähigkeiten in jeder Anfrage. Dadurch kann jede Serverinstanz jede Anfrage verarbeiten, ohne dass statische Sitzungen oder gemeinsam genutzte Sitzungsspeicher auf Protokollebene erforderlich sind. Damit kommt die Bereitstellung von MCP-Servern in serverlosen Umgebungen, Umgebungen mit mehreren Instanzen oder Edge-Umgebungen dem Betrieb einer gewöhnlichen ASP.NET-Core-Anwendung hinter einem Load Balancer näher.
Die Option HttpServerTransportOptions.Stateless ist in Version 2.0 standardmäßig auf true gesetzt. Bei Bedarf kann der zustandsbehaftete Modus aktiviert werden, wenn nicht angeforderte Nachrichten vom Server an den Client oder ein sitzungsgebundener Transportzustand erforderlich sind. Sitzungen bleiben verfügbar, sind jedoch nicht mehr die Standardeinstellung.
HTTP-Header für Routing und Überwachung
Das zustandslose Modell verwandelt eine MCP-Anfrage in eine eigenständige HTTP-POST-Anfrage, sodass die übliche Infrastruktur sie wie jeden anderen HTTP-Datenverkehr behandeln kann. Die Spezifikation ermöglicht Header wie Mcp-Method und Mcp-Name sowie die Möglichkeit, bestimmte Tool-Parameter in Header des Typs Mcp-Param-* hochzustufen.
Load Balancer, Proxys, Gateways oder Web Application Firewalls können diese Header für Routing und Überwachung verwenden, ohne den JSON-RPC-Anfragerumpf analysieren zu müssen. Der Anfragerumpf bleibt die maßgebliche Quelle. Weicht der Wert des Headers vom Wert im Rumpf ab, lehnt der Server die Anfrage mit dem Fehler HeaderMismatch ab. Das Design unterstützt außerdem die Kodierung von Werten, die in Headern nicht unterstützt werden, etwa Nicht-ASCII-Werten, mithilfe eines Base64-Indikators.
Multi-Round-Trip-Anfragen für interaktive Tools
Die Funktion Multi Round-Trip Requests, kurz MRTR, bietet eine Möglichkeit, mit Tools umzugehen, die ihre Aufgabe nicht innerhalb eines einzigen Aufrufs abschließen können. Statt dass der Server während der Verarbeitung der Anfrage über eine aktive Sitzung mit dem Client kommuniziert, gibt er ein Ergebnis des Typs InputRequiredResult zurück, das Eingabeanforderungen und einen opaken Zustand namens requestState enthält.
Der Client führt die erforderliche Aktion aus, etwa eine Bestätigungsanfrage an den Benutzer, den Aufruf eines Sprachmodells oder die Anzeige von Arbeitsbereichs-Stammverzeichnissen, und sendet anschließend denselben Tool-Aufruf erneut, ergänzt um inputResponses und requestState. Der Vorgang kann über mehrere Runden wiederholt werden. Die Informationen zur Fortsetzung werden in der Nutzlast übertragen, sodass der Vorgang keine Sitzung benötigt.
Der übergeordnete McpClient verarbeitet MRTR automatisch, nachdem die entsprechenden Handler registriert wurden. Die Version kann außerdem eine Kompatibilitätsbrücke zu älteren Clients verwenden, wenn eine zustandsbehaftete Sitzung vorhanden ist. Ein älterer Client, der ohne Sitzung arbeitet, kann keine Interaktion über mehrere Runden ausführen. Daher muss das Tool einen alternativen Pfad anbieten, etwa die direkte Übergabe des erforderlichen Werts als Aufrufparameter.
Kompatibilität und verfügbare Pakete
Stabile, nicht veraltete APIs der Version 1.x lassen sich weiterhin unter 2.0 kompilieren und ausführen, während veraltete Änderungen als Warnungen und nicht als Löschungen erscheinen. Ein 2.0-Client kann beim Verbinden mit einem älteren Server den alten Initialize-Handshake verwenden. Ebenso akzeptiert ein 2.0-Server diesen Handshake von einem älteren Client.
Die einzige Ausnahme bei der Protokollkompatibilität ist die Tasks-Erweiterung. Ihr in 2.0 überarbeitetes Design ersetzt die experimentelle Tasks-Funktion aus der Spezifikation 2025-11-25 und ist auf Schnittstellen- oder Protokollebene nicht mit ihr kompatibel. Tasks ist nun im separaten Paket ModelContextProtocol.Extensions.Tasks verfügbar, während die experimentellen MCP Apps im Paket ModelContextProtocol.Extensions.Apps enthalten sind.
Zu den Kernpaketen gehören ModelContextProtocol.Core für den Client und Low-Level-Komponenten, ModelContextProtocol für die meisten Server sowie ModelContextProtocol.AspNetCore für Streamable-HTTP-Server. Der Beitrag weist darauf hin, dass der nächste Schwerpunkt der 2.x-Reihe auf einer umfassenden Authentifizierung und Autorisierung liegen wird, basierend auf einer engeren Abstimmung mit OAuth und OpenID Connect.