GitHub stellt seinen MCP-Server bereits auf den nächsten, zustandsfreien Protokollkern um. Der praktische Punkt dahinter: Remote-Toolserver können ohne Session-Speicher im Request-Pfad laufen – und Logging sowie Secret Scanning erhalten klarere Anker.
Der neue MCP-Kern soll laut GitHub am 28. Juli 2026 offiziell erscheinen. GitHub hat seinen Server vorab mit dem offiziellen Go-SDK angepasst. Für Teams, die MCP über HTTP betreiben, ist das mehr als ein Protokoll-Refactoring: Es verschiebt State aus der kritischen Anfragekette.
Was sich im Remote-Betrieb ändert
Im neuen Kern entfallen sessions und initialize. Clients können den Handshake parallel erledigen; mehrstufige Interaktionen wie Elicitation werden als einzelne HTTP-Anfragen möglich. GitHub nennt als Folge ausdrücklich leichter skalierbare MCP-Deployments.
Am eigenen Server wird die Wirkung greifbar:
- Kein Redis im Hot Path: Die Datenbankschreibvorgänge beim Initialisieren und die Datenbanklesevorgänge bei jedem Call fallen weg.
- Weniger Payload-Inspektion: Für Logging und Secret Scanning kann GitHub garantierte HTTP-Header nutzen, statt jeden MCP-Request vor dem SDK zu untersuchen.
- Kompatibler Übergang: Der Go-SDK-Wrapper soll die alte und neue Elicitation-Mechanik parallel abdecken.
„Sessions and initialize are both removed, so you can connect to servers faster and easier.“ – GitHub Changelog, 23. Juli 2026
Die Architekturfrage: Wo liegt noch State?
„Stateless“ bedeutet nicht, dass Agenten oder Tools keinen Zustand mehr haben. Authentifizierung, Einwilligungen, Langläufer und Tool-seitige Geschäftslogik bleiben zustandsbehaftet. Der Unterschied: Dieser Zustand sollte nicht mehr als implizite MCP-Transport-Session zwischen Load Balancer und Server kleben.
| Vorher: sessiongebunden | Neuer Kern: zustandsfreier Transport |
|---|---|
| Session-Speicher muss zum Request passen | Requests können einfacher über Instanzen verteilt werden |
| Inspektion kann den MCP-Payload berühren | Definierte Header liefern Kontext für Logs und Scans |
| Mehrere Interaktionsschritte sind sessionnah modelliert | Mehrere HTTP-Round-Trips werden explizit unterstützt |
Was Teams jetzt konkret prüfen sollten
- Session-Abhängigkeiten inventarisieren: Redis, Sticky Sessions und Connection-affine Middleware in Remote-MCP-Deployments erfassen.
- Header-Pipeline absichern: Welche garantierten Header erreichen Logging, DLP und Secret Scanning tatsächlich – und welche dürfen Proxies verändern?
- Client-/SDK-Matrix testen: Vor allem Elicitation, parallele Handshakes und Retry-Verhalten mit den eingesetzten Clients prüfen.
- Conformance in CI aufnehmen: GitHub verweist auf offizielle Conformance-Tests. Für eigene Server ist das der sinnvollere Kompatibilitätscheck als erfolgreiche Demo-Calls.
Einordnung: GitHub meldet hier keine neue Modellfunktion. Es ist Infrastrukturarbeit – und gerade deshalb relevant: Ein zustandsfreier Transportkern reduziert Betriebsballast, ohne Authentifizierung oder Tool-Berechtigungen automatisch sicher zu machen. Wer MCP produktiv horizontal skaliert, sollte den Umstieg als Architekturtest behandeln, nicht als Versionswechsel im Hintergrund.
Quelle
GitHub, GitHub MCP Server supports the next MCP specification, veröffentlicht am 23. Juli 2026. GitHub nennt den 28. Juli 2026 als Termin für die offizielle Spezifikation.
Schreibe einen Kommentar