Die MCP Roadmap ist der offizielle Fahrplan der Kernentwickler des Model Context Protocol. Sie legt fest, welche Themen in die nächsten Versionen der Spezifikation einfließen und welche Vorschläge aus der Community bevorzugt geprüft werden.

Die aktuelle Fassung wurde von den Lead Maintainern David Soria Parra und Den Delimarsky veröffentlicht. Sie bündelt die Arbeit in fünf Prioritätsbereiche: agentische Messaging Primitives, Vereinheitlichung des HTTP nativen Transports, Agent Identity mit Enterprise Security, verbesserte Primitives und bessere SDKs.

Für Teams mit eigenen MCP Servern ist das kein Randthema. Wer heute einen Server betreibt, sollte wissen, welche Bausteine stabil bleiben und wo in den kommenden Spezifikationen Anpassungsbedarf entsteht.

Never Code Alone betreibt eigene MCP Server in Production. Unser Sulu CMS spricht MCP, unsere n8n Automatisierung ebenso. Wir kennen die Stolperstellen aus dem Alltag: Transport Wechsel, Token Verbrauch, Rechteverwaltung, Tool Kataloge die zu groß werden. Genau dort setzt die neue Roadmap an. Wir lesen sie deshalb nicht als Ankündigung, sondern als Planungsgrundlage.

Teams begleiten wir bei der MCP Middleware für Unternehmensdaten, beim Aufbau eigener Server nach dem Muster von Web MCP und beim Anbinden bestehender Systeme wie GitHub MCP Server oder Symfony AI Mate. Wer bereits Server betreibt, findet in MCP Responses optimieren die passende Vorarbeit für das Roadmap Thema Progressive Discovery.

Die Roadmap ordnet die Protokollarbeit in fünf Bereiche. Jeder Bereich hat feste Ansprechpartner unter den Core Maintainern und eine oder mehrere Working Groups. Das ist der wichtigste organisatorische Punkt: Wer einen Vorschlag einbringen will, weiß jetzt, an wen er sich wendet.

Agentic Messaging Primitives: Bausteine für lange laufende Agenten Läufe. Server initiierte Events, Tasks, Subscriptions und Progress Notifications sollen sauber zusammenspielen.

HTTP nativer Transport: Ein Transport für alle Betriebsarten, auch lokal.

Agent Identity und Enterprise Security: Agenten als eigenständige Identitäten statt eingefügter API Keys.

Improved Primitives: Klarer Vertrag für Tool Ergebnisse und Progressive Discovery gegen aufgeblähte Tool Kataloge.

SDK Developer Experience: Ergonomie, Konformitätstests und Dokumentation, weil Agenten die SDKs inzwischen selbst lesen.

Mehrere dieser Themen standen in der vorherigen Roadmap noch unter Ausblick. Server initiierte Events, bessere Result Types und Agent Identity sind inzwischen reif genug für eigene Prioritäten.

Ein klassischer Tool Call ist kurz. Frage rein, Antwort raus. Agentische Arbeitslasten sehen anders aus. Ein Lauf dauert Minuten oder Stunden, der Server liefert Zwischenergebnisse, und manchmal muss ein Mensch mitten im Lauf eingreifen.

MCP hat darauf bereits reagiert. Tasks als Extension, ein Listen Mechanismus für Subscriptions und Progress Notifications existieren. Die Roadmap zieht daraus die logische Konsequenz: Diese Bausteine sollen nicht nur einzeln funktionieren, sondern miteinander. Dafür arbeiten die Working Groups Agents, Transports sowie Triggers und Events an einer gemeinsamen Komposition.

Der praktisch wichtigste Punkt sind server initiierte Events per Webhook oder Channel. Heute pollen Clients auf Ergebnisse. Das kostet Tokens, Latenz und Nerven. Die Tasks Extension soll außerdem so weit reifen, dass sie aus dem Extension Status in die eigentliche Spezifikation wandert.

Wer heute einen Agenten baut, der lange Läufe orchestriert, sollte diesen Bereich beobachten. Das A2A Protokoll löst eine verwandte Frage auf einer anderen Ebene: Kommunikation zwischen Agenten statt zwischen Agent und Werkzeug.

Mit der Spezifikation vom 28. Juli 2026 ist ein Remote MCP Server technisch nichts Besonderes mehr. Er verhält sich wie jede andere HTTP Anwendung. Das heißt: Load Balancer, API Gateway, CDN, bestehende Monitoring Ketten, alles greift ohne Sonderbehandlung.

Die Roadmap will dieses Modell auf die restlichen Betriebsarten ausdehnen. Auch lokale Server sollen Streamable HTTP sprechen, transportiert über stdio. Ein Transport für alles bedeutet weniger Codepfade in Servern und Clients, weniger Konfigurationsvarianten und weniger Fehlerquellen beim Wechsel zwischen Entwicklung und Betrieb.

Für Teams ist das die wahrscheinlich angenehmste Änderung der Roadmap. Wer bisher stdio lokal und Streamable HTTP remote gefahren hat, pflegt zwei Wege. Die Vereinheitlichung räumt das auf. Der praktische Nutzen zeigt sich vor allem beim Testen: Ein Server, der lokal und remote identisch spricht, lässt sich mit denselben Tests absichern.

Die heutige MCP Autorisierung geht davon aus, dass ein Mensch im Browser sitzt und einen Zugriff bestätigt. Für interaktive Clients passt das. Für Agenten, die als Cloud Workload laufen, passt es nicht. Sie handeln im Auftrag eines Menschen, der gerade nicht anwesend ist, und geben Teile ihrer Rechte an Sub Agenten weiter.

Die Roadmap setzt hier bewusst auf bestehende Standards statt auf eine MCP Eigenlösung. Genannt werden Demonstrating Proof of Possession nach RFC 9449, Workload Identity Federation, der ID JAG Grant hinter Enterprise Managed Authorization und der klassische Token Exchange. Dazu kommt die Mitarbeit in den IETF Arbeitsgruppen OAuth und WIMSE.

Kritisch gesehen ist das der Bereich mit dem längsten Zeithorizont. Identitätsstandards entstehen nicht in einem Quartal, und die Abhängigkeit von externen Gremien macht Termine schwer planbar. Gleichzeitig ist es der Bereich mit dem größten Nutzen für Unternehmen, weil er das Ende von langlebigen API Keys in Konfigurationsdateien bedeutet.

Unsere Einschätzung für Teams: Wer heute Server baut, sollte Zugriffsrechte bereits jetzt eng schneiden und nicht auf einen zukünftigen Standard warten. Ein Server, der nur lesen darf, ist auch ohne Agent Identity deutlich sicherer als einer mit vollem Schreibzugriff.

Tool Calling ist der Teil von MCP, den Entwickler zuerst anfassen. Er hat sich bewährt. Schwächen zeigen sich beim Rückgabewert: Eine Antwort kann dieselbe Information in mehreren Formen tragen, und der Server Entwickler weiß nicht, welche Form ein bestimmter Client dem Modell tatsächlich vorlegt. Die Roadmap will das auf einen klaren Vertrag reduzieren.

Das zweite Thema ist für uns das praktisch relevanteste der ganzen Roadmap. Ein Server mit hundert Tools kostet Kontext, bevor der Nutzer die erste Frage gestellt hat. Und je länger die Liste, desto schlechter wählt das Modell aus. Progressive Discovery soll dem Server erlauben, mit einem kleinen Einstiegspunkt zu starten und den Katalog erst zu öffnen, wenn das Gespräch enger wird.

Wer heute schon Tool Kataloge im Griff behalten will, muss nicht warten. Kleine Server statt eines Monolithen, sprechende Tool Namen und knappe Antworten wirken sofort. Wie viel dabei herausspringt, zeigt unsere Praxisanalyse zu MCP Responses und Token Verbrauch. Welche Modelle mit vielen Tools überhaupt zuverlässig umgehen, klärt der Vergleich zu Modellen für MCP und Tool Handling.

Der fünfte Bereich klingt unspektakulär und ist es nicht. Die SDKs sind für die meisten Entwickler der erste Kontakt mit MCP. Die Roadmap investiert in Ergonomie, in Konformitätstests gegen die Spezifikation und in Dokumentation über alle unterstützten Sprachen hinweg.

Der Grund dafür hat sich geändert. Viele Server und Clients entstehen heute nicht mehr Zeile für Zeile von Hand, sondern indem ein Agent auf die Bibliotheken gerichtet wird. Ob der erzeugte Code funktioniert, hängt dann direkt an der Klarheit der API und an der Aktualität der Doku. Schlechte Dokumentation produziert schlechten generierten Code.

Das deckt sich mit dem, was wir bei Kunden sehen. Ein Agent, der eine veraltete Signatur aus dem Training zieht, verursacht Fehler, die stundenlang wie Anwendungsprobleme aussehen. Deshalb gehören automatisierte Quality Gates für KI Code in jede Pipeline, in der Agenten schreiben.

Specification Enhancement Proposals sind der formale Weg, Änderungen am Protokoll vorzuschlagen. Die Roadmap ändert daran die Reihenfolge: Vorschläge innerhalb der fünf Prioritätsbereiche bekommen eine beschleunigte Prüfung und die besten Chancen auf Annahme.

Vorschläge außerhalb werden nicht automatisch abgelehnt. Die Maintainer sagen aber offen, dass ihre Review Zeit knapp ist und zuerst in die Roadmap fließt. Wer etwas einbringen will, ordnet seinen Vorschlag also zuerst einem Bereich zu und spricht mit der zuständigen Working Group.

Für Experimente gibt es einen zweiten Weg. Working und Interest Groups dürfen in eigenen Repositories mit dem Präfix für experimentelle Erweiterungen arbeiten, bevor daraus ein formaler Vorschlag wird. Das senkt die Hürde für Ideen, deren Nutzen sich erst im Betrieb zeigt.

Ehrliche Einordnung: Diese Priorisierung ist gut für die Fokussierung und unangenehm für Nischenbedürfnisse. Wer ein Sonderthema hat, das in keinen der fünf Bereiche passt, wartet voraussichtlich länger.

Eine Roadmap ist keine Deadline. Nichts an der aktuellen Spezifikation bricht morgen weg. Trotzdem lohnt es sich, die eigenen Server auf die Richtung auszurichten, statt später umzubauen.

Jetzt sinnvoll: Tool Kataloge klein halten, Antworten knapp gestalten, Rechte pro Server eng schneiden, Read Only als Standard für alles, was nicht schreiben muss. Diese Punkte zahlen sofort ein und passen später zu Progressive Discovery und Agent Identity.

Beobachten statt bauen: Eigene Lösungen für Agent Identity. Wer jetzt ein eigenes Delegationsmodell zimmert, baut es voraussichtlich zweimal. Hier auf die Standardisierung zu warten ist die günstigere Entscheidung.

Vorbereiten: Wer lange laufende Agenten betreibt und heute pollt, sollte die Stelle im Code so kapseln, dass ein Wechsel auf server initiierte Events später eine überschaubare Änderung bleibt.

Für die Datenschutzseite ändert die Roadmap nichts an unserer Regel: Coding Modelle, die nicht auf eigener Infrastruktur laufen, arbeiten gegen lokale Entwicklungsumgebungen mit Fake Daten, nie gegen echte Bestände. Ein MCP Server, der auf Produktionsdaten zeigt, gehört hinter enge Rechte und in eine dokumentierte Freigabe.

Wir arbeiten täglich über MCP. Unser Sulu CMS wird über einen eigenen Server bedient, unsere n8n Workflows ebenfalls. Was in Blogposts nach Magie klingt, ist im Alltag eine Frage von sauberen Tool Namen, kurzen Antworten und klaren Rechten. Genau diese Erfahrung fließt in unsere Beratung ein.

Vergleichbare Server aus dem Ökosystem ordnen wir in eigenen Beiträgen ein, etwa den Sylius MCP Server für den E Commerce Bereich. Wer Agenten in bestehende Projekte holen will, findet den passenden Rahmen in unseren Agentic AI Coding Guardrails. Für Teams, die den Einstieg planen, ist die Vibe Coding Beratung der richtige Startpunkt.

Die wichtigsten Fragen aus unserer Beratungspraxis zur neuen Roadmap und zu ihren Folgen für bestehende MCP Server.