cyberivy
Model Context ProtocolMCPAI AgentsDeveloper ToolsAI InfrastructureTool ServersAI SecurityOpen Standards

MCP wird zustandslos: Agenten-Infrastruktur rückt näher ans Web

29. Juli 2026

Ein Techniker sitzt mit einem Laptop vor einem geöffneten Serverrack in einem Rechenzentrum.

Die MCP-Spezifikation vom 28. Juli 2026 streicht Protokoll-Sessions und macht Tool-Aufrufe besser routbar. Für Entwickler ist das weniger Architekturballast, aber kein Freifahrtschein für Sicherheit.

Worum es geht

Model Context Protocol hat am 28. Juli 2026 eine neue Spezifikation veröffentlicht. Der wichtigste Bruch mit der bisherigen Architektur: MCP wird im Kern zustandslos. Statt einer versteckten Protokoll-Session trägt jede Anfrage ihre Version, Fähigkeiten und Identität selbst mit.

Das klingt trocken, ist aber für alle relevant, die Agenten nicht nur als Demo, sondern als produktive Infrastruktur betreiben wollen. Ein Tool-Server kann nun eher wie ein normaler HTTP-Dienst skaliert, geroutet und überwacht werden. Genau diese Reibung war bisher ein Grund, warum MCP-Server im Betrieb schnell komplizierter wurden als in der lokalen Entwicklungsumgebung.

Was MCP 2026-07-28 tatsächlich macht

Die neue Version entfernt die Protokoll-Session und den bisherigen Initialisierungs-Handshake. Anfragen enthalten Metadaten wie Protokollversion, Client-Fähigkeiten und optional Client-Informationen. Server können außerdem über server/discover mitteilen, welche Versionen und Fähigkeiten sie unterstützen.

Neu sind auch HTTP-Header für Methode und Tool-Name. Gateways können dadurch erkennen, ob eine Anfrage etwa tools/call für ein bestimmtes Tool ist, ohne zuerst den gesamten JSON-RPC-Body auszuwerten. Listen von Tools, Prompts und Ressourcen werden besser cachebar, während längere Abläufe über eine eigene Tasks-Erweiterung statt über versteckte Transportzustände laufen.

Warum das wichtig ist

Agenten werden erst dann wirklich nützlich, wenn sie mit echten Systemen sprechen: Tickets, Dateien, Datenbanken, Kalendern, Build-Systemen oder internen APIs. Dafür braucht es eine Integrationsschicht, die nicht nur auf dem Laptop funktioniert, sondern auch in Cloud-Umgebungen mit Load Balancern, Observability und klaren Berechtigungen.

Die MCP-Änderung macht genau diesen Schritt plausibler. Ein zustandsloser Server kann einfacher hinter mehrere Instanzen verteilt werden. Header-basiertes Routing hilft Plattformteams, Berechtigungen und Monitoring näher an die Infrastruktur zu legen. Gleichzeitig bleibt das Risiko: MCP verbindet Sprachmodelle mit Datenzugriff und potenzieller Codeausführung. Die Spezifikation selbst betont deshalb Zustimmung, Kontrolle, Datenschutz und Tool-Sicherheit als zentrale Prinzipien.

Einfach erklärt

Stell dir eine Hotelrezeption vor. Früher musste sich der Gast einmal anmelden, bekam eine unsichtbare Akte, und jede spätere Bitte hing davon ab, dass genau dieselbe Rezeption diese Akte wiederfindet. Jetzt bringt der Gast bei jeder Bitte die relevanten Angaben auf einem klaren Formular mit. Das macht den Betrieb mit mehreren Schaltern einfacher, ersetzt aber nicht die Pflicht zu prüfen, ob der Gast wirklich ins Zimmer darf.

Praktisches Beispiel

Ein Softwareteam betreibt 40 interne MCP-Tools für Code-Suche, Loganalyse und Deployment-Freigaben. Bisher mussten die Server-Sessions über bestimmte Instanzen gehalten werden. Nach einer Migration auf MCP 2026-07-28 können fünf identische Server hinter einem einfachen Load Balancer laufen. Wenn täglich 30.000 Tool-Aufrufe anfallen, kann das Team Lastspitzen abfangen, ohne Session-Speicher quer über alle Instanzen zu synchronisieren.

Die Sicherheitsarbeit bleibt konkret: Ein Deployment-Tool darf trotzdem nicht ohne menschliche Freigabe auslösen. Ein Loganalyse-Tool darf keine Kundendaten an fremde Endpunkte schicken. Und jedes Tool braucht saubere Protokolle, damit ein auffälliger Agentenlauf später nachvollziehbar ist.

Einordnung und Grenzen

Erstens ist die Spezifikation kein fertiges Sicherheitsprodukt. Wer gefährliche Tools anbietet, braucht weiterhin Rechtekonzepte, Audit-Logs und klare Nutzerzustimmung.

Zweitens verschwindet Zustand nicht vollständig. Anwendungen mit längeren Abläufen müssen explizite Handles oder Tasks nutzen. Das ist besser sichtbar, aber immer noch Architekturarbeit.

Drittens entstehen Migrationskosten. Clients und Server, die bisher auf Session-IDs, Initialisierung oder alte Streaming-Erwartungen gebaut haben, müssen angepasst und getestet werden.

SEO- und GEO-Schlüsselbegriffe

Model Context Protocol, MCP 2026-07-28, AI agents, Tool-Server, agent infrastructure, stateless HTTP, JSON-RPC, MCP Apps, Tasks extension, AI security, developer tools, Cloudflare Workers

💡 Im Klartext

MCP wird für Produktionssysteme einfacher betreibbar, weil Tool-Aufrufe weniger an versteckte Sessions gebunden sind. Das hilft beim Skalieren, ersetzt aber keine Berechtigungen, Prüfpfade oder menschliche Freigaben für riskante Aktionen.

Wichtigste Erkenntnisse

  • Die MCP-Spezifikation 2026-07-28 wurde am 28. Juli 2026 veröffentlicht.
  • Der Protokollkern ist nun zustandslos und entfernt Session-Handshake sowie Session-ID.
  • Header für Methode und Tool-Name erleichtern Routing, Autorisierung und Monitoring.
  • Längere Abläufe wandern in eine Tasks-Erweiterung statt in versteckten Transportzustand.
  • Sicherheit bleibt Aufgabe der Betreiber: Zustimmung, Rechte und Protokollierung sind weiterhin nötig.

Häufige Fragen

Was ist MCP?

MCP ist ein offenes Protokoll, mit dem KI-Anwendungen externe Datenquellen und Tools anbinden können.

Warum ist zustandslos wichtig?

Zustandslose Anfragen lassen sich einfacher über mehrere Server verteilen, überwachen und bei Fehlern wiederholen.

Wird MCP dadurch automatisch sicherer?

Nein. Die Änderung macht Infrastruktur klarer, aber Betreiber müssen Berechtigungen, Freigaben und Protokolle selbst sauber umsetzen.

Quellen & Kontext