MCP 2026-07-28 Release Candidate: Was sich an der Spec wirklich ändert

Auf einen Blick: Am 21. Mai 2026 ist der Release Candidate für MCP-Spec 2026-07-28 gelockt, finale Publikation am 28. Juli 2026. Vier große Änderungen: Stateless Core, MCP Apps (server-rendered UI), Tasks-Extension für Long-Running Work, OAuth/OIDC-aligned Authorization. Bestehende Server bleiben funktional, Stateless-Mode ist Opt-in.

Der Release Candidate für die nächste MCP-Spezifikation ist seit 21. Mai 2026 gelockt. Final-Publikation steht für 28. Juli 2026 auf der Roadmap. Das ist die größte Revision des Model Context Protocol seit dem ursprünglichen Launch durch Anthropic 2024.

Wer schon einen MCP-Server in Produktion hat, kann durchatmen: Bestehende Implementierungen funktionieren weiter. Wer einen Server plant oder baut, sollte die Spec-RC lesen, bevor er die Architektur festzurrt. Vier Änderungen sind so substanziell, dass sich der Spec-Wechsel lohnt.

Stateless Core: Die größte Vereinfachung

Bisher liefen die meisten Remote-MCP-Server mit Session-Affinität. Ein Client startet eine Verbindung, der Server merkt sich Zustand über die Lebensdauer der Verbindung, und alle weiteren Requests müssen auf denselben Server-Knoten geroutet werden. Sticky Sessions, geteilter Session-Store, Deep Packet Inspection im Load Balancer.

Das skaliert schlecht. Wer 10.000 gleichzeitige MCP-Verbindungen halten will, baut entweder einen Riesen-Server-Knoten oder eine komplexe Shared-State-Architektur mit Redis und Affinitäts-Routing. Für Cloud-Provider war das eine echte Hürde, agentische Workloads ernsthaft anzubieten.

Stateless Core dreht das um. Jeder MCP-Request ist eigenständig. Routing-Information steht in einem neuen Mcp-Method-Header, den der Load Balancer auswerten kann. Ein normaler Round-Robin-Balancer reicht. Keine Sticky Sessions, kein Shared Store, keine DPI.

Für Server-Betreiber heißt das: Wenn dein Server bisher auf In-Memory-State setzt, musst du auf externalisierten Zustand umstellen (Datenbank, Cache, Object Storage). Wenn er von Anfang an statelos gebaut wurde, ist die Migration trivial. Die Spec lässt dir die Wahl, weil Stateless-Mode Opt-in ist und bestehende Stateful-Implementierungen weiter laufen.

MCP Apps: Server-Rendered UI

Das zweite Feature ist ungewohnter. MCP Apps erlauben, dass der MCP-Server eine UI ausliefert, die der Client darstellt. Bisher waren MCP-Server reine Funktions-Provider (Tools, Resources, Prompts). Mit MCP Apps können sie ganze interaktive Oberflächen liefern.

Use-Case: Ein MCP-Server für ein internes Ticket-System liefert nicht nur die Tools "Ticket lesen" und "Ticket erstellen", sondern auch eine UI mit Filter-Bar, Listen-Ansicht und Detail-Drawer. Der Client (zum Beispiel Claude Desktop oder ein eigener Agent-Client) rendert die UI und erlaubt dem Nutzer, direkt mit dem Ticket-System zu interagieren.

Das verschiebt die Grenze zwischen Backend-Service und Client-App deutlich. Ein MCP-Server wird damit zur eigenständigen Anwendung, mit allen Konsequenzen. Wer das ernsthaft baut, muss sich Gedanken über UI-Frameworks, Rendering-Modell und Auth-Flows machen.

Die praktische Relevanz für KMU ist Stand Mai 2026 noch begrenzt. Die meisten internen Tools haben schon eine UI. Wer ein neues internes Tool baut, kann jetzt aber den MCP-Server als primären Server bauen und die UI dort mitliefern. Das vereinfacht den Stack erheblich.

Tasks-Extension für Long-Running Work

Das dritte Feature schließt eine Lücke, die in der Praxis weh tat. Bisher hat MCP synchron funktioniert: Tool-Call rein, Antwort raus. Für Tools, die wenige Sekunden brauchen, kein Problem. Für Tools, die Minuten oder Stunden brauchen (Datenanalyse, Bildgenerierung, lange Crawls), war das ein Hack.

Tasks-Extension definiert ein eigenes Protokoll-Konstrukt für Long-Running Work. Der Client startet eine Task, bekommt eine Task-ID zurück, kann den Status periodisch abfragen und das Ergebnis abholen, wenn die Task abgeschlossen ist. Das Ganze inklusive Cancellation und Progress-Reporting.

Praktisch heißt das: Wer einen MCP-Server für "Generiere mir einen Quartalsbericht" baut, muss das nicht mehr als 4-Stunden-Single-Request bauen, der dann ins Timeout läuft. Stattdessen: Task starten, Client kann andere Arbeit machen, Notification wenn fertig.

Für agentische Workflows ist das ein Game-Changer. Multi-Agent-Setups mit lang laufenden Tasks (Recherche, Generierung, Pipeline-Runs) bekommen ein sauberes Protokoll-Muster. Vorher war jedes Setup eine Eigenlösung.

OAuth- und OIDC-aligned Authorization

Das vierte Feature ist Compliance-relevant. Bisher war die Authorization in MCP relativ frei. Server konnten Token-basiert, Header-basiert oder über eigene Schemata authentifizieren. Für Enterprise-Setups war das eine Hürde, weil jeder MCP-Server eine eigene Auth-Integration brauchte.

Die neue Spec aligned mit OAuth 2.0 und OpenID Connect. Server, die das implementieren, integrieren sich nahtlos in bestehende Identity-Provider (Keycloak, Okta, Azure AD, Google Workspace). Single Sign-On, zentrales User-Management, Audit-Trails am IDP, all das wird Standard.

Für DSGVO-relevante Setups ist das wichtig. Wer einen AVV nach Art. 28 DSGVO mit einem Cloud-Anbieter abschließt, muss in der Regel auch zeigen, dass der Datenzugriff über das interne Identity-Management läuft. Mit OAuth/OIDC-aligned MCP-Servern ist das eine Konfigurationsaufgabe, keine Eigenentwicklung mehr.

Adoption-Stand vor der Spec-Änderung

Anthropic hat im März 2026 gemeldet: über 10.000 aktive öffentliche MCP-Server, 97 Millionen monatliche SDK-Downloads über Python und TypeScript. Alle großen Cloud-Provider unterstützen MCP. Die Adoption ist breiter, als die meisten technischen Standards in ihrer ersten Phase erreicht haben.

Diese Zahlen sind die Voraussetzung dafür, dass die Spec-Änderung überhaupt sinnvoll diskutiert werden kann. Eine Spec ohne Ökosystem ist Papier. Eine Spec mit 10.000 Servern dahinter ist eine Migrations-Aufgabe für tausende Entwickler. Die MCP-Maintainer haben deshalb bewusst auf Rückwärtskompatibilität gesetzt.

Das praktische Ergebnis: Wer einen bestehenden Server hat, muss nicht migrieren. Wer einen neuen Server baut, sollte direkt die neue Spec verwenden. Wer als Client einen Server mit alter Spec konsumiert, merkt nichts.

Praxis: Müller Engineering in Bayreuth

Ein konkretes Beispiel, mit anonymisierter Firma. Müller Engineering ist ein Maschinenbau-Mittelständler mit 65 Mitarbeitern in Bayreuth. Schwerpunkt: Sondermaschinen für die Holzverarbeitung.

Der CTO hatte Ende 2025 einen ersten MCP-Server gebaut. Use-Case: Claude soll auf das interne CAD-Archiv zugreifen, um bei Konstruktionsanfragen historische Vorgänger-Projekte zu finden. Der Server lief synchron, hielt Session-State für die User und nutzte eine Eigenentwicklung für Token-Auth.

Nach Spec 2026-07-28 sollte der Server umgebaut werden. Drei Themen sind dann relevant.

Erstens: Der CAD-Lookup dauert manchmal 3 bis 8 Minuten, weil die Vorgänger-Suche über 12.000 archivierte Projekte läuft. Bisher führt das oft zu Client-Timeouts. Mit Tasks-Extension lässt sich das sauber als asynchrone Task modellieren.

Zweitens: Müller hat im Lauf von 2026 Azure AD ausgerollt. Die OAuth/OIDC-Alignment macht es einfach, den MCP-Server in das bestehende SSO einzubinden. Vorher war das Workaround mit eigenem Token-System.

Drittens: Stateless Core wäre für Müller technisch nett, aber praktisch unnötig. Bei 5 gleichzeitigen Nutzern reicht der eine Server-Knoten dicke. Das ist ein gutes Beispiel: Nicht jede Spec-Änderung muss übernommen werden, nur weil sie verfügbar ist.

Der Umbauplan steht für Q3 2026. Realistischer Aufwand: 4 bis 6 Tage.

Was Server-Betreiber jetzt tun sollten

Konkrete Checkliste für die nächsten Wochen:

Wer das nicht ernst nimmt, bleibt auf der alten Spec. Das geht für die nächsten 12 bis 18 Monate problemlos. Nach 18 Monaten erwarten wir, dass Client-Anbieter (Claude Desktop, Cline, Cursor, Continue) den neuen Standard bevorzugen und alte Server zunehmend Warnungen produzieren.

Was Client-Entwickler jetzt tun sollten

Aus Client-Sicht sind drei Punkte relevant. Erstens: Cache-Strategie für tools/list-Responses. Die neue Spec erlaubt, dass Clients diese Liste so lange cachen, wie der Server-ttlMs es erlaubt. Wer das nutzt, spart Round-Trips und entlastet die Server.

Zweitens: OAuth-Flow gegen die neue Authorization-Norm. Wer einen eigenen MCP-Client baut (interner Agent, eigenes Tooling), sollte den OAuth-Code-Flow gegen die Spec testen, bevor das Final-Release kommt. Frühe Tests zeigen Lücken in den eigenen Implementierungen.

Drittens: Tasks-Konsumption planen. Wenn der eigene Client mit Servern arbeitet, die Tasks anbieten werden, braucht die Client-Architektur ein klares Modell für Task-Tracking und Notification-Handling. Polling ist die einfachste Variante, Server-Sent Events oder Webhooks sind aufwändiger, aber besser für Latency.

Wer das unterschätzt

In Beratungsgesprächen sehen wir bei der Spec-Diskussion regelmäßig zwei Fehleinschätzungen. Die erste: "Das ist nur ein Versions-Bump, kein echter Wechsel." Falsch. Stateless Core und Tasks-Extension sind so fundamental, dass Architekturen, die diese Features nicht von Anfang an mitdenken, später teuer umgebaut werden.

Die zweite Fehleinschätzung ist umgekehrt: "Wir warten erst mal ab, bis sich das in der Praxis durchsetzt." Auch nicht ideal. Die Spec ist gelockt, Final ist 28. Juli 2026. Wer im Q3/Q4 2026 einen MCP-Server neu baut und die alte Spec nimmt, baut von Tag eins technische Schulden ein. Die Tooling-Anbieter werden ab Final-Release die neue Spec priorisieren.

Wir empfehlen Mandanten in solchen Situationen einen pragmatischen Mittelweg. Bestehende Server bleiben in der alten Spec, solange sie funktionieren. Neue Server folgen direkt der neuen Spec. Migrations-Planung kommt nach 6 bis 12 Monaten Echtbetrieb mit der neuen Spec, wenn das Tooling stabil ist.

Compliance- und EU-AI-Act-Aspekte

Ein wichtiger Nebenpunkt: Die OAuth/OIDC-Alignment hat direkte Compliance-Wirkung. Die EU KI-Verordnung verlangt für viele Anwendungsfälle dokumentierten Datenzugriff und Audit-Trails. Mit OAuth/OIDC-aligned MCP-Servern lassen sich die Audit-Trails am Identity-Provider zentralisieren und in bestehende SIEM-Systeme einspeisen.

Für die Art. 4 KI-Kompetenz nach EU KI-VO spielt das keine direkte Rolle (das betrifft Mitarbeiter-Schulung, ein anderes Feld). Aber für die kommenden Hochrisiko-Pflichten (Art. 6 ff., laut Trilog-Einigung 07.05.2026 verschoben auf 02.12.2027 für Anhang III, 02.08.2028 für Anhang I) wird das wichtig. Wer MCP-Server in produktiven Hochrisiko-Anwendungen einsetzt, sollte die Audit-Trail-Architektur jetzt durchdenken. Hintergrund zur KI-Kompetenzpflicht steht im Pflichtartikel zu Art. 4 KI-VO.

Wer den Sprung zu agentischen Architekturen strukturiert lernen und im eigenen Unternehmen einführen will, findet im Digitalisierungsmanager den passenden Rahmen. Vier Monate, komplett online, mit Bildungsgutschein 0 Euro.

Häufige Fragen

Muss ich meinen bestehenden MCP-Server zur neuen Spec migrieren?

Nein, nicht zwingend. Die neue Spec ist rückwärtskompatibel. Stateless Core ist Opt-in. Tasks-Extension nutzt du, wenn deine Tools lang laufen. OAuth/OIDC-Alignment lohnt sich, sobald du SSO im Haus hast. Bestehende Server bleiben für absehbare Zeit funktional, aber neue Features kommen zuerst in die neue Spec.

Was bedeutet Stateless Core für meinen Server-Aufwand?

Wenn dein Server schon stateless gebaut ist (alle Daten in DB, Cache oder Object Storage), kein Mehraufwand. Wenn dein Server In-Memory-State hält, brauchst du eine Externalisierung. Aufwand realistisch 1 bis 5 Tage, je nach Komplexität des State-Modells.

Sind MCP Apps eine Konkurrenz zu Web-Frontends?

Eher Ergänzung. MCP Apps sind für Use-Cases gedacht, in denen die UI im Kontext eines Agent-Clients (Claude Desktop, eigener Agent) gerendert wird. Für klassische Web-Apps mit eigener URL bleibt das normale Web-Framework die richtige Wahl. Wer beides braucht, kann beides koexistieren.

Wie funktioniert die Tasks-Extension genau?

Der Client schickt einen Tool-Call mit Async-Flag. Der Server antwortet mit Task-ID und Status. Der Client pollt den Task-Endpunkt periodisch (oder abonniert Notifications) und holt das Ergebnis ab, wenn der Status auf "completed" steht. Cancellation und Progress-Updates sind im Protokoll vorgesehen. Die Implementierung im Server hängt von deiner Backend-Architektur ab, das Protokoll selbst ist schlank.

Über den Autor

Dr. Jens Aichinger ist promovierter Wirtschaftspädagoge und Inhaber von SkillSprinters, einem DEKRA-zertifizierten Bildungsträger. Er entwickelt seit 2024 KI-gestützte Weiterbildungs- und Prozessautomatisierungslösungen für den Mittelstand. Über Skill-Sprinters läuft auch der Digitalisierungsmanager, eine 4-monatige geförderte Weiterbildung.

Bereit für den nächsten Schritt? Wenn du KI im Geschäftsalltag systematisch einsetzen willst, mit klarem Setup statt halben Lösungen, schau dir den Digitalisierungsmanager an. Vier Monate, komplett online, mit Bildungsgutschein 0 Euro.

Zuletzt geprüft am 23. Mai 2026.