MCP-Update 2026: Was Schweizer KMU jetzt prüfen sollten

Wer bei Hedinger-Digital oder einer anderen Agentur in den letzten Monaten eine Claude-Integration ans CRM oder ERP anbinden liess, hat vermutlich schon vom Model Context Protocol (MCP) gehört – dem offenen Standard, über den KI-Agenten mit internen Systemen sprechen. Am 28. Juli 2026 ist die grösste Überarbeitung dieses Standards seit seiner Einführung erschienen. Für IT-Verantwortliche stellt sich damit eine naheliegende Frage: Bricht die bestehende Integration? Muss jetzt gehandelt werden?

Die kurze Antwort: Nichts bricht sofort, aber wer eine KI-Agenten-Anbindung betreibt oder plant, sollte die Änderungen kennen – weil sie Hosting-Kosten senken, eine bekannte Sicherheitslücke schliessen und die Verwaltung von Zugriffsrechten für Mitarbeitende erheblich vereinfachen können. Dieser Beitrag ordnet ein, was sich technisch ändert, was Bestandsintegrationen betrifft und welche drei Fragen sich lohnen, bevor mit der eigenen Agentur oder IT-Abteilung gesprochen wird.

Was sich technisch ändert: vom Dauergespräch zum zustandslosen Request

Bisher funktionierte MCP wie ein Telefongespräch: Ein Client baute über einen Handshake (initialize/initialized) eine Verbindung zu einem bestimmten Server auf, bekam eine Sitzungs-ID (Mcp-Session-Id) zugewiesen und musste für die Dauer der Konversation bei genau diesem Server-Prozess bleiben. Für Betreiber eines MCP-Servers – etwa der Komponente, die Claude an das eigene CRM anbindet – bedeutete das: eine Sitzung musste über die gesamte Konversation hinweg demselben Server zugeordnet bleiben, was gemeinsamen Sitzungsspeicher oder eine feste Zuordnung erforderte.

Mit MCP 2026-07-28 fällt dieser Handshake weg. Jede einzelne Anfrage trägt jetzt ihre eigene Protokollversion, Client-Identität und Fähigkeiten in einem _meta-Feld mit sich. Jede verfügbare Serverinstanz kann jede Anfrage beantworten – wie ein gewöhnlicher zustandsloser Webdienst. Praktisch heisst das für den Betrieb eines eigenen MCP-Servers: Er lässt sich hinter einem einfachen Round-Robin-Load-Balancer horizontal skalieren, auf Serverless- oder Edge-Infrastruktur betreiben und braucht keinen geteilten Sitzungsspeicher mehr. Wer die laufenden Kosten der eigenen KI-Integration im Blick behält, sieht hier eine der konkretesten Auswirkungen des Updates: schlankere, günstigere Infrastruktur für dieselbe Funktion.

Bricht meine bestehende Integration? Die Migrationsfrist im Detail

Die MCP-Arbeitsgruppe hat gleichzeitig mit dem grössten Umbau des Protokolls eine formelle Deprecation-Policy eingeführt: Jedes veraltete Merkmal bleibt mindestens zwölf Monate funktionsfähig, bevor es entfernt werden darf. Konkret heisst das für Bestandsintegrationen:

• Die bisherige Dynamic Client Registration (DCR) funktioniert weiter, auch wenn Client ID Metadata Documents (CIMD) als neuer bevorzugter Mechanismus eingeführt werden.
• Die ältere HTTP+SSE-Übertragung erhält eine einjährige Übergangsfrist.
• Die älteren Funktionen Roots, Sampling und Logging gelten als veraltet, bleiben aber nutzbar.

Wer bereits eine funktionierende Claude- oder MCP-Anbindung betreibt, muss also nicht in Panik verfallen. Alle vier Tier-1-SDKs – TypeScript, Python, Go und C# – sowie das Rust-SDK in Beta unterstützen die neue Spezifikation bereits seit dem Erscheinungstag. Eine Migration ist damit technisch schon heute möglich, aber nicht erzwungen. Anthropic hat mit "Bringing MCP 2026-07-28 to Claude" bestätigt, dass die Unterstützung schrittweise über die Claude-Produkte ausgerollt wird.

Mehr Sicherheit: was sich bei OAuth und Autorisierung ändert

Der zweite grosse Block des Updates betrifft die Authentifizierung – und hier lohnt sich genaueres Hinsehen, weil er direkt die Sicherheit betrifft, mit der Mitarbeitende auf interne Systeme über KI-Agenten zugreifen. Die neue Spezifikation gleicht den OAuth-Ablauf enger an reale OAuth-2.0- und OIDC-Praxis in Unternehmen an.

Zwei Änderungen sind besonders relevant:

Erstens müssen Autorisierungsserver künftig einen Issuer-Parameter gemäss RFC 9207 zurückgeben. Der Client muss diesen Wert vor dem Einlösen eines Autorisierungscodes prüfen. Das schliesst sogenannte Mix-up-Angriffe, bei denen ein Angreifer einen Client dazu bringt, einen Code beim falschen Autorisierungsserver einzureichen – eine reale, dokumentierte Schwachstelle in OAuth-Implementierungen mit mehreren Autorisierungsservern.

Zweitens sind Client-Credentials jetzt fest an den Server gebunden, der sie ausgestellt hat. Eine Wiederverwendung derselben Credentials bei einem anderen Autorisierungsserver ist damit ausgeschlossen. Spricht der eigene MCP-Server künftig mit mehreren Diensten oder Identitätsanbietern, verringert das die Angriffsfläche strukturell – ohne dass am eigenen Nutzungsverhalten etwas geändert werden müsste.

Enterprise-Managed Authorization: Single Sign-on für KI-Agenten

Eng mit der Autorisierungshärtung verknüpft ist eine zweite Neuerung, die für Firmen mit mehreren Mitarbeitenden besonders relevant sein dürfte: Enterprise-Managed Authorization (EMA), seit dem 18. Juni 2026 offiziell stabil.

Bisher musste sich jede Mitarbeiterin und jeder Mitarbeiter bei jedem einzelnen MCP-Server separat per OAuth anmelden und den Zugriff bestätigen – bei fünf angebundenen Tools also fünf einzelne Anmeldevorgänge samt Zustimmungsdialog. EMA macht stattdessen den unternehmenseigenen Identitätsanbieter zur zentralen Autorität: Wer sich einmal per Single Sign-on anmeldet, erhält automatisch Zugriff auf alle MCP-Server, für die seine Rolle freigegeben ist – ohne weitere Bestätigungsdialoge.

Unterstützt wird das aktuell über Okta als Identitätsanbieter; die Unterstützung für Microsoft Entra ID unterscheidet sich je nach verwendetem Client. Als Clients unterstützen bereits Claude, Claude Code und Cowork sowie Visual Studio Code die Erweiterung. Auf der Server-Seite sind unter anderem Asana, Atlassian, Canva, Figma, Granola, Linear und Supabase mit dabei, weitere Dienste wie Slack folgen. Ist bereits Okta oder eine vergleichbare Identitätslösung vorhanden, reduziert EMA den administrativen Aufwand einer KI-Agenten-Einführung spürbar – Zugriffsrechte lassen sich zentral über Rollen statt einzeln pro Tool verwalten.

Für die revDSG-Perspektive ist das mehr als ein Komfortgewinn. Zentral über Rollen gesteuerte Zugriffe lassen sich leichter dokumentieren und begründen als eine gewachsene Sammlung einzelner Tool-Freigaben, die niemand mehr vollständig überblickt – ein Punkt, den auch der EDÖB in seinen Empfehlungen zu KI-Einsatz in Unternehmen regelmässig betont: Nachvollziehbarkeit der Zugriffe ist Teil einer sauberen Datenbearbeitung, nicht nur eine IT-Frage. Wer ohnehin eine Datenschutz-Folgenabschätzung für die eigene KI-Integration führt, kann eine EMA-Einführung als Gelegenheit nutzen, das Berechtigungskonzept gleich mit zu bereinigen.

MCP Apps und Tasks: aus dem Experiment in den festen Rahmen

Neben Architektur und Sicherheit bringt die neue Spezifikation eine strukturelle Aufwertung von Erweiterungen. Zwei Funktionen, die bisher als experimentell galten, wandern in ein formelles, versioniertes Erweiterungsframework: Tasks für länger laufende Vorgänge und MCP Apps, mit denen sich interaktive Oberflächen direkt in einer Chat-Konversation anzeigen lassen – etwa ein Formular oder eine Tabelle, statt reinem Text.

Der praktische Effekt: Diese Funktionen können sich künftig unabhängig von den grossen Kern-Spezifikations-Releases weiterentwickeln, was für Entwicklerteams und Agenturen eine planbarere Roadmap bedeutet. Für ein KMU ist das vor allem mittelbar relevant – es erhöht die Wahrscheinlichkeit, dass künftige KI-Agenten-Oberflächen über einfache Chat-Antworten hinausgehen, etwa mit eingebetteten Formularen für Bestellungen oder Freigaben.

Checkliste: Was Sie jetzt mit Ihrer Agentur klären sollten

Für die meisten Unternehmen besteht kein akuter Handlungsdruck – die zwölfmonatige Übergangsfrist verschafft Zeit. Drei Fragen lohnen sich trotzdem im nächsten Gespräch mit der IT-Abteilung oder der zuständigen Agentur:

1. SDK-Stand prüfen: Läuft der eingesetzte MCP-Server bereits auf einem SDK, das 2026-07-28 unterstützt? Alle Tier-1-SDKs tun das seit dem Release-Tag.
2. Client-Registrierung klären: Wird aktuell Dynamic Client Registration genutzt, und ist ein Wechsel zu Client ID Metadata Documents sinnvoll oder notwendig?
3. EMA-Nutzen abwägen: Lohnt sich Enterprise-Managed Authorization angesichts der eigenen Mitarbeiterzahl und des vorhandenen Identitätsanbieters – oder reicht die bestehende Pro-Tool-Anmeldung für die aktuelle Grösse der Organisation aus?

Diese drei Antworten genügen, um realistisch einzuschätzen, ob und wann eine Migration sinnvoll ist – unabhängig davon, ob die bestehende Integration selbst betrieben oder extern begleitet wird.

Wer eine bestehende Claude- oder MCP-Integration betreibt oder eine erste KI-Agenten-Anbindung an CRM, ERP oder interne Systeme plant, profitiert davon, diese Fragen frühzeitig zu klären statt erst beim nächsten Vorfall. Hedinger-Digital begleitet Schweizer KMU bei genau dieser Einordnung – von der ersten Architekturfrage bis zur laufenden Betreuung. Mehr zu den Möglichkeiten gibt es unter KI-Integration für KMU, oder direkt im unverbindlichen Gespräch.