WISSEN > IT ARCHITEKTUR > APIS UND MCP
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
MCP ersetzt keine APIs – es standardisiert den Zugriff
Wie APIs, Tool Calling und MCP KI-Anwendungen mit produktiven Systemen verbinden
Das sollten Sie mitnehmen:
- RAG und MCP lösen unterschiedliche Probleme.
RAG beschafft Informationen für den Modellkontext, MCP standardisiert die Anbindung von Kontext und Funktionen.
- MCP ersetzt vorhandene APIs nicht.
Ein MCP Server kapselt APIs und stellt ausgewählte Funktionen als Tools, Daten als Resources bereit.
- Tool Calling heißt nicht, dass das LLM die Funktion ausführt.
Die Operation erfolgt außerhalb des Modells in der angebundenen Anwendung.
- Lesen und Handeln haben unterschiedliche Risikoprofile.
Eine Statusabfrage und eine zustandsverändernde oder destruktive Operation verlangen unterschiedliche Kontrollen.
- MCP löst das Berechtigungsproblem nicht.
Authentication, Authorization, Least Privilege und die Identität des Backend-Zugriffs bleiben Architekturentscheidungen.
MCP ersetzt keine APIs – es standardisiert den Zugriff
Inhaltsverzeichnis
- Eine API liefert nicht nur Daten, sondern kann Zustände verändern
- Das Modell wählt das Tool aus, ausführen muss es die Anwendung
- MCP standardisiert die Grenze, nicht die dahinterliegenden Systeme
- MCP und APIs liegen auf verschiedenen Ebenen, nicht in Konkurrenz
- RAG beschafft Wissen, Tools beschaffen Zustand
- Sobald die KI handelt, endet die Sicherheitsgrenze nicht am Modell
- Die Identitätsfrage entscheidet über die tatsächliche Berechtigungswirkung
- Least Privilege und Wirkungsklassen begrenzen die Fehlerfläche
- Ein standardisiertes Protokoll ist noch keine Sicherheitsarchitektur
- MCP entwickelt sich weiter, aber nicht mehr unvorhersehbar
- Die Auswahl beginnt bei der Anforderung, nicht beim Protokoll
- Fazit
- Quellen
Ein Large Language Model kann eine Frage beantworten, aber es kennt nicht automatisch den aktuellen Zustand eines ERP-Systems, den freien Speicherplatz eines Storage-Systems oder den Status eines laufenden Geschäftsprozesses. Ebenso kann ein Modell allein keine Datei verschieben, ein Ticket erstellen oder einen Workflow starten. Für solche Aufgaben muss die KI-Anwendung mit externen Systemen kommunizieren, und dafür existieren unterschiedliche Mechanismen: APIs stellen Daten und Funktionen eines Systems bereit, Tool Calling ermöglicht einem Sprachmodell die Auswahl solcher Funktionen, und das Model Context Protocol (MCP) standardisiert die Bereitstellung von Datenquellen und Tools gegenüber KI-Anwendungen.
Damit entsteht eine andere Form der Datenintegration als bei Retrieval-Augmented Generation. Vereinfacht gesagt holt RAG relevantes Wissen in den Kontext eines Modells, während APIs und Tools den Zugriff auf aktuelle Systemzustände und Funktionen ermöglichen und MCP die Schnittstelle zwischen KI-Anwendungen und solchen externen Fähigkeiten vereinheitlicht. In realen KI-Architekturen werden diese Verfahren nicht gegeneinander abgewogen, sondern miteinander kombiniert.
[Querverweis-Marker: Grundlagenartikel zu Retrieval-Augmented Generation – Einordnung des Retrieval-Pfades, auf den dieser Artikel durchgehend Bezug nimmt]
Eine API liefert nicht nur Daten, sondern kann Zustände verändern
Eine Application Programming Interface definiert, wie Softwarekomponenten miteinander kommunizieren können. Eine Anwendung stellt dabei definierte Operationen bereit, die eine andere Anwendung aufrufen kann. Ein vereinfachtes Beispiel ist eine Storage-Management-API, die eine Operation zur Abfrage der verfügbaren Kapazität eines Systems anbietet: Die aufrufende Anwendung sendet einen Request, das Storage-System antwortet mit strukturierten Daten, aus denen sich der aktuelle Kapazitätswert ermitteln lässt.
APIs können jedoch nicht nur Informationen liefern. Abhängig von der jeweiligen Schnittstelle und den erteilten Berechtigungen lösen sie auch Zustandsänderungen aus. Damit lassen sich zwei Klassen von Zugriff unterscheiden, die für die weitere Argumentation dieses Artikels entscheidend sind. Lesende Operationen fragen Informationen ab, etwa Kapazitätswerte, Monitoring-Daten, Objekt-Metadaten oder den Status eines Geschäftsprozesses. Schreibende beziehungsweise auslösende Operationen verändern dagegen ein externes System oder starten eine Funktion, beispielsweise das Erstellen eines Tickets, das Anstoßen eines Workflows oder eine administrative Operation.
Gerade dieser Unterschied ist für KI-Anwendungen sicherheitsrelevant, denn eine falsche Antwort eines Modells und eine falsch ausgelöste Aktion haben grundlegend verschiedene technische Konsequenzen. Die erste lässt sich korrigieren, indem der Benutzer nachfragt; die zweite hat den produktiven Zustand bereits verändert.
Das Modell wählt das Tool aus, ausführen muss es die Anwendung
Ein Sprachmodell führt eine externe Funktion normalerweise nicht selbst aus. Stattdessen beschreibt die umgebende KI-Anwendung dem Modell eine Menge verfügbarer Tools einschließlich ihrer Parameter. Das Modell kann anschließend auf Basis der Anfrage entscheiden, dass zur Beantwortung ein bestimmtes Tool benötigt wird, und einen entsprechenden Aufruf erzeugen. Die Anwendung führt diesen Aufruf aus und stellt das Ergebnis dem Modell für die weitere Verarbeitung zur Verfügung.
Fragt ein Benutzer etwa nach der freien Kapazität eines bestimmten Storage-Systems, muss diese Information nicht Bestandteil des Modellwissens sein. Die Anwendung kann dem Modell stattdessen ein Tool zur Kapazitätsabfrage bereitstellen und den Wert zum Zeitpunkt der Anfrage aus dem Zielsystem beziehen.
Wichtig ist dabei die Trennung der Zuständigkeiten: Das Modell entscheidet beziehungsweise schlägt vor, welches Tool mit welchen Parametern aufgerufen werden soll, während die tatsächliche Ausführung durch die Anwendung oder die angebundene Infrastruktur erfolgt. Damit bleibt die Kontrolle über Authentifizierung, Autorisierung, Validierung und Ausführung außerhalb des Sprachmodells. Wir kommen auf die sicherheitstechnische Bedeutung dieser Trennung weiter unten zurück, weil sie in der Praxis regelmäßig übersehen wird.
[BILD: Ablauf eines Tool Calls – Benutzeranfrage, Tool-Auswahl im Modell, Ausführung in der Anwendung, Rückgabe des Ergebnisses an das Modell; Ausführungsgrenze zwischen Modell und Anwendung hervorgehoben]
MCP standardisiert die Grenze, nicht die dahinterliegenden Systeme
Das Model Context Protocol definiert ein Protokoll für die Kommunikation zwischen KI-Anwendungen und Systemen, die ihnen Kontext oder Funktionen bereitstellen. Es ersetzt dabei nicht automatisch die APIs der angebundenen Systeme. Ein MCP Server kann auf eine bereits vorhandene REST-API, eine Datenquelle oder einen anderen Dienst zugreifen und ausgewählte Funktionen über eine standardisierte Schnittstelle veröffentlichen. Er bildet damit eine Integrationsschicht zwischen der KI-Anwendung und den dahinterliegenden Diensten, ohne diese abzulösen.
Nach der aktuellen MCP-Spezifikation können Server unter anderem Tools, Resources und Prompts bereitstellen. Die maßgebliche Revision trägt die Versionsbezeichnung 2026-07-28. Sie ist die erste Fassung seit der Revision 2025-11-25 und zugleich die erste, die unter der Trägerschaft der Agentic AI Foundation innerhalb der Linux Foundation entstanden ist. Ihre auffälligste Änderung betrifft den Protokollkern: Der frühere Initialisierungsaustausch aus initialize und initialized sowie der Header Mcp-Session-Id wurden entfernt, womit auch protokollseitige Sessions als Konzept entfallen. Jeder Request trägt seither die für seine Verarbeitung erforderlichen Angaben selbst, nämlich Protokollversion, Client-Identität und Client-Capabilities im Feld _meta.
Diese Änderung ist keine formale Umstellung, sondern hat unmittelbare betriebliche Folgen. Ein entfernter MCP Server, der zuvor Sticky Sessions, einen gemeinsamen Session-Store und eine Inspektion des Request Body am Gateway benötigte, lässt sich nun hinter einem gewöhnlichen Round-Robin-Load-Balancer betreiben. Das Routing kann anhand des Headers Mcp-Method erfolgen, ohne dass die Nutzlast ausgewertet werden muss, und Listenergebnisse wie tools/list tragen mit ttlMs und cacheScope eine ausdrückliche Gültigkeitsdauer, sodass Clients sie für die vom Server erlaubte Dauer zwischenspeichern können. Aus Betriebssicht ist ein MCP Server damit ein HTTP-Workload wie andere auch — eine Eigenschaft, die für die Skalierbarkeit von Enterprise-Deployments erheblich mehr bedeutet als die meisten funktionalen Neuerungen der Revision.
Tools sind ausführbare Funktionen mit sehr unterschiedlicher Wirkung
Tools sind Funktionen, die ein MCP Server zur Ausführung anbietet. Ein Storage-bezogenes Tool könnte konzeptionell get_capacity(system) heißen, ein anderes create_snapshot(volume). Die Auswirkungen dieser beiden Aufrufe unterscheiden sich erheblich: Die erste Funktion liest lediglich einen Zustand, die zweite verändert ihn, sofern das angebundene System diese Operation unterstützt. Welche Tools ein MCP Server tatsächlich bereitstellt, ist deshalb keine Frage der technischen Verfügbarkeit, sondern eine Architektur- und Sicherheitsentscheidung.
Resources stellen Kontext bereit, ohne etwas auszulösen
Resources liefern Daten beziehungsweise Kontext, den eine Anwendung verwenden kann. Die Spezifikation sieht dafür unter anderem Operationen zum Auflisten und Lesen verfügbarer Resources vor, und welche davon ein Client sehen kann, hängt von dessen Autorisierung ab. Konzeptionell sind Resources damit klar von Tools zu unterscheiden: Eine Resource stellt Information bereit, ein Tool ruft eine Funktion auf.
Prompts veröffentlichen wiederverwendbare Interaktionsvorlagen
MCP Server können außerdem Prompt-Vorlagen bereitstellen und damit neben Daten und Funktionen auch strukturierte Interaktionsmuster gegenüber Clients veröffentlichen. Tools, Resources und Prompts bilden zusammen eine standardisierte Oberfläche, über die unterschiedliche KI-Anwendungen mit angebundenen Diensten interagieren.
MCP und APIs liegen auf verschiedenen Ebenen, nicht in Konkurrenz
Ein häufiger konzeptioneller Fehler besteht darin, MCP und APIs als konkurrierende Technologien zu betrachten. Eine API beschreibt typischerweise die Schnittstelle zu einer Anwendung oder einem Dienst. MCP beschreibt dagegen eine standardisierte Schnittstelle, über die KI-Anwendungen angebotene Fähigkeiten und Kontext entdecken und verwenden können. Ein Storage-System stellt eine REST-API bereit; ein MCP Server greift auf diese API zu; und aus Sicht der KI-Anwendung entsteht eine Kette vom AI Client über den MCP Server und die REST-API bis zum Storage-System. Der MCP Server kann dabei die Besonderheiten der darunterliegenden API kapseln und nur diejenigen Funktionen bereitstellen, die für die KI-Anwendung vorgesehen sind. Die vorhandene API bleibt trotzdem Bestandteil des eigentlichen Daten- beziehungsweise Kontrollpfades.
[BILD: Schichtung AI Client → MCP Server → REST API → Zielsystem, mit Kennzeichnung der Protokollgrenze und der gekapselten API-Funktionen]
Eine KI-Anwendung kann APIs selbstverständlich auch direkt integrieren, und bei wenigen Integrationen kann das ausreichen. Mit zunehmender Zahl von Anwendungen und Datenquellen entsteht jedoch Integrationsaufwand, weil die KI-Anwendung für jede Schnittstelle wissen muss, wie diese angesprochen wird und wie ihre Funktionen zu beschreiben sind. MCP verschiebt einen Teil dieser Integrationslogik hinter eine standardisierte Protokollgrenze, sodass mehrere Zielsysteme über gleichartig aufgebaute Server erreichbar werden.
Das bedeutet allerdings nicht, dass die eigentliche Komplexität verschwindet. Authentifizierung, Autorisierung, Datenmodelle, Fehlerbehandlung und die Semantik der jeweiligen Backend-Systeme müssen weiterhin korrekt implementiert werden. MCP standardisiert die Kommunikation an einer bestimmten Integrationsgrenze; es vereinheitlicht nicht automatisch die Eigenschaften der dahinterliegenden Anwendungen.
RAG beschafft Wissen, Tools beschaffen Zustand
MCP und RAG lösen unterschiedliche Probleme. Bei RAG besteht das Ziel darin, für eine Benutzeranfrage relevante Informationen aus einem externen Wissensbestand zu ermitteln und dem Modell als zusätzlichen Kontext bereitzustellen; typische Quellen sind Dokumente, Dateien oder andere indexierbare Bestände. MCP definiert dagegen eine Schnittstelle, über die eine KI-Anwendung Resources lesen oder Tools aufrufen kann, um ein aktuelles Ergebnis aus einem Zielsystem zu beziehen.
Der wesentliche Unterschied liegt deshalb nicht bei statischen gegenüber dynamischen Daten, sondern in der Funktion innerhalb der Architektur. RAG ist ein Verfahren zur kontextbezogenen Informationsbeschaffung, MCP ein Protokoll zur standardisierten Anbindung von Kontext und Funktionen. Beide Konzepte schließen einander nicht aus: MCP kann Zugriff auf Daten ermöglichen, die anschließend als Modellkontext dienen, und ein über MCP angebotenes Tool kann seinerseits einen Retrieval-Prozess auslösen.
Ein Beispiel zeigt die Abgrenzung deutlicher als jede Definition. Die Frage, welche Anforderungen die interne Storage-Richtlinie für Snapshots definiert, betrifft vorhandenes Unternehmenswissen; ein Retrieval-System kann die relevanten Dokumentpassagen suchen und bereitstellen. Die Frage, wann auf einem bestimmten System zuletzt ein Snapshot erstellt wurde, betrifft dagegen einen aktuellen Systemzustand und lässt sich sinnvollerweise direkt aus dessen Managementschnittstelle beziehen. Die Aufforderung, jetzt einen Snapshot zu erstellen, ist noch einmal grundlegend anders, weil hier ein Zustand verändert werden soll. Damit ergeben sich drei unterschiedliche Vorgänge — Wissen recherchieren, aktuellen Zustand abfragen und Zustand verändern —, die jeweils einen anderen Mechanismus und eine andere Autorisierungstiefe verlangen.
Enterprise-KI-Anwendungen stehen deshalb selten vor der Entscheidung zwischen RAG und MCP. Fragt ein Administrator, ob die aktuelle Snapshot-Konfiguration der internen Richtlinie entspricht, werden beide Informationsquellen zugleich benötigt: Über Retrieval wird die Richtlinie gefunden, über einen Systemzugriff die Ist-Konfiguration abgefragt, und erst die Zusammenführung beider Informationen erlaubt dem Modell den Vergleich. Das Beispiel verdeutlicht einen wesentlichen Architekturpunkt, den wir in Projekten regelmäßig als Ausgangsfrage setzen: Unternehmenswissen und aktueller Systemzustand sind unterschiedliche Datenquellen und müssen nicht über denselben Integrationsmechanismus bereitgestellt werden.
[BILD: Kombinierter Pfad – Dokumentbestand über Retrieval und Zielsystem über MCP Tool laufen parallel zum Modell zusammen; Kennzeichnung der beiden getrennten Quellen]
[Querverweis-Marker: Artikel zur Aufbereitung von Unternehmensdaten für KI-Anwendungen – Anschlussstelle für den Retrieval-Pfad und die Frage, welche Bestände überhaupt indexierbar sind]
Sobald die KI handelt, endet die Sicherheitsgrenze nicht am Modell
Besonders relevant wird Tool Integration, sobald eine KI-Anwendung nicht nur Informationen verarbeitet, sondern Aktionen auslöst. Dann führt ein Pfad von der Benutzeranfrage über das Modell und den Tool Call bis zum MCP Server, zur API und schließlich zum produktiven System. Damit erreicht eine Entscheidung innerhalb eines AI Workflows die operative Infrastruktur, und die Sicherheitsgrenze darf folglich nicht am Modell enden. Ein MCP Server oder eine dahinterliegende API muss selbst prüfen, ob ein Request autorisiert ist; die Tatsache, dass ein Modell ein Tool ausgewählt hat, ist keine Autorisierung für dessen Ausführung.
Für solche Architekturen muss zwischen zwei Fragen unterschieden werden: Authentication klärt, wer die Anfrage stellt, Authorization dagegen, was diese Identität tun darf. OAuth ermöglicht Clients begrenzten Zugriff auf geschützte Ressourcen, wobei Access Tokens eine erteilte Autorisierung mit Eigenschaften wie Scope und Gültigkeitsdauer repräsentieren. Bei Bearer Tokens besitzt grundsätzlich derjenige die damit verbundenen Zugriffsmöglichkeiten, der über das Token verfügt; RFC 6750 fordert deshalb insbesondere Schutz vor Offenlegung bei Speicherung und Übertragung.
Für eine KI-Architektur reicht es folglich nicht aus festzustellen, dass der MCP Client authentifiziert ist. Zusätzlich muss geklärt werden, welche Resources er lesen und welche Tools er sehen beziehungsweise aufrufen darf, für welche Zielressourcen diese Berechtigung gilt, unter welcher Benutzer- oder Service-Identität die Backend-Operation ausgeführt wird und welche Parameter und Operationen dabei zulässig sind. Diese Fragen beantwortet kein Protokoll für den Betreiber.
Die Revision 2026-07-28 hat den Autorisierungsteil der Spezifikation gegenüber früheren Fassungen an mehreren konkreten Stellen verschärft. Clients müssen den Issuer-Bezeichner iss in Authorization Responses nach RFC 9207 validieren; die Spezifikation begründet dies als Gegenmaßnahme gegen eine Klasse von Mix-up-Angriffen, die im für MCP typischen Muster eines Clients gegenüber vielen Servern besonders tragfähig ist. Registrierte Credentials werden zudem an den Issuer des ausstellenden Authorization Servers gebunden, sodass ein Client sich neu registrieren muss, wenn eine Ressource zu einem anderen Authorization Server wechselt. Als bevorzugter Registrierungsweg treten OAuth Client ID Metadata Documents an die Stelle der Dynamic Client Registration nach RFC 7591, die nur noch zur Abwärtskompatibilität mit Authorization Servern erhalten bleibt, die das neue Verfahren nicht unterstützen.
Nicht neu in dieser Revision, aber häufig fälschlich ihr zugeschrieben, ist eine ältere Anforderung: Die Pflicht für MCP Server, OAuth 2.0 Protected Resource Metadata nach RFC 9728 zu veröffentlichen, besteht bereits seit der Revision 2025-06-18. Wer den eigenen Bestand bewertet, sollte diese Datierung kennen, weil sie darüber entscheidet, ob ein festgestellter Rückstand seit Wochen oder seit über einem Jahr besteht.
[Querverweis-Marker: Artikel zu Data Intelligence und Governance – Anschlussstelle für Berechtigungsmodelle und Nachvollziehbarkeit auf Datenebene]
Die Identitätsfrage entscheidet über die tatsächliche Berechtigungswirkung
Aus dem Vorstehenden ergibt sich eine zentrale Architekturfrage für Enterprise-KI: Handelt die KI mit den Rechten des Benutzers oder mit einer eigenen technischen Identität? Die beiden Varianten haben unterschiedliche Konsequenzen. Verwendet der Zugriff eine gemeinsame Service Identity, sieht das Backend zunächst nur diese technische Identität, und die Anwendung muss selbst sicherstellen, dass Benutzer nicht über die KI Funktionen erhalten, die ihnen beim direkten Zugriff auf das Zielsystem nicht zur Verfügung stehen sollten. Wird dagegen die Benutzeridentität beziehungsweise eine entsprechend delegierte Autorisierung bis zum Zielsystem weitergegeben, lassen sich vorhandene Berechtigungsmodelle stärker in die Entscheidung einbeziehen.
Welche Variante richtig ist, hängt von der Anwendung und den unterstützten Authentifizierungs- und Autorisierungsmechanismen ab. MCP beseitigt diese Entscheidung nicht. Für Umgebungen, in denen eine Organisation die Autorisierung zentral steuern will statt sie jedem Server einzeln zu überlassen, existiert inzwischen allerdings ein benannter Mechanismus: Enterprise-Managed Authorization wird als Extension geführt und gilt seit der Revision 2026-07-28 als stabil. Damit verschiebt sich die Frage von der grundsätzlichen Abbildbarkeit hin zu der Frage, ob die eingesetzten Clients und Server diese Extension unterstützen.
Least Privilege und Wirkungsklassen begrenzen die Fehlerfläche
Ein MCP Server sollte nicht allein deshalb sämtliche Funktionen einer Backend-API als Tools veröffentlichen, weil diese technisch verfügbar sind. Die sinnvollere Grenze ergibt sich aus der Frage, welche Funktionen die konkrete KI-Anwendung tatsächlich benötigt. Ein Monitoring-Assistent kommt möglicherweise ausschließlich mit lesenden Operationen aus, und dann besteht kein technischer Grund, demselben Integrationspfad auch administrative Schreiboperationen zur Verfügung zu stellen. Das Prinzip des Least Privilege reduziert damit nicht nur klassische Benutzerrechte, sondern auch die Angriffs- und Fehlerfläche eines AI Tool Layers.
Zwischen einem Aufruf wie get_snapshot_status() und einem Aufruf wie delete_snapshot() besteht aus Sicherheitssicht ein fundamentaler Unterschied: Der erste liefert Informationen, der zweite verändert produktive Daten beziehungsweise deren Schutzmechanismen. Je größer die Auswirkungen eines Tools sind, desto wichtiger werden zusätzliche Kontrollmechanismen wie eingeschränkte Berechtigungen, Parameterprüfung, nachvollziehbare Protokollierung und, abhängig vom Risiko, eine explizite Freigabe vor der Ausführung.
Eine AI-Architektur sollte Tools deshalb nicht nur nach ihrer fachlichen Funktion klassifizieren, sondern auch nach ihrer möglichen Wirkung. Eine praktikable Einteilung unterscheidet rein lesende, zustandsverändernde und destruktive Operationen; die konkrete Sicherheitsbehandlung leitet sich anschließend aus dem Risiko und dem jeweiligen Zielsystem ab. Diese Klassifikation lässt sich unabhängig vom eingesetzten Protokoll anwenden und überlebt damit auch künftige Spezifikationsänderungen.
[BILD: Wirkungsklassen von Tools – lesend, zustandsverändernd, destruktiv – mit den jeweils zugeordneten Kontrollmechanismen von Berechtigung über Protokollierung bis zur expliziten Freigabe]
Ein standardisiertes Protokoll ist noch keine Sicherheitsarchitektur
Die Verwendung eines standardisierten Protokolls macht eine Integration nicht automatisch sicher. MCP definiert Kommunikationsmechanismen und Autorisierungsverfahren, ersetzt jedoch nicht die Sicherheitsarchitektur der beteiligten Systeme. Weiterhin relevant bleiben Identitätsmanagement und Autorisierung, das Credential Management, Transport Security sowie die Prüfung von Eingaben und Parametern. Hinzu kommen Audit Logging, die Berechtigungen im Backend selbst, Netzwerksegmentierung, Rate Limits und ein definierter Umgang mit fehlerhaften oder unerwarteten Tool-Aufrufen. Keiner dieser Punkte wird durch die Wahl des Protokolls beantwortet.
Die Sicherheitsfrage lautet deshalb nicht, ob eine Anwendung MCP unterstützt, sondern welche Systeme, Daten und Aktionen über den MCP Server erreichbar werden und welche Kontrollinstanz bei jedem einzelnen Zugriff über dessen Zulässigkeit entscheidet.
MCP entwickelt sich weiter, aber nicht mehr unvorhersehbar
MCP ist ein vergleichsweise junges Protokoll und befindet sich weiterhin in aktiver Entwicklung, was für Architekturentscheidungen unmittelbar relevant ist. Die Revision 2026-07-28 hat gegenüber vorherigen Versionen grundlegende Änderungen eingeführt, darunter den beschriebenen zustandslosen Protokollkern, das header-basierte Routing, cachebare Listenergebnisse, ein Muster für mehrstufige Anfragen sowie die genannten Verschärfungen im Autorisierungsteil.
Ebenso relevant für eine Bestandsbewertung ist, was in dieser Revision auf eine Auslaufbahn gesetzt wurde. Die Funktionen Roots, Sampling und Logging gelten als deprecated; sie funktionieren weiterhin, sollen von neuen Implementierungen aber nicht mehr übernommen werden. Für Sampling verweist die Spezifikation als Ersatz auf die direkte Anbindung an die APIs der jeweiligen LLM-Anbieter, für Logging auf stderr bei stdio-Transporten beziehungsweise auf etablierte Observability-Verfahren. Auch der ältere HTTP+SSE-Transport gilt offiziell als deprecated, ebenso die bereits erwähnte Dynamic Client Registration.
Wer daraus schließt, MCP sei ein bewegliches Ziel ohne Planungshorizont, greift allerdings zu kurz. Dieselbe Revision hat erstmals eine formale Feature-Lifecycle-Policy eingeführt: Jedes Feature durchläuft die Zustände Active, Deprecated und Removed, und zwischen der Deprecation und dem frühestmöglichen Entfernen liegen mindestens zwölf Monate. Ergänzend erlaubt ein formalisiertes Extensions-Framework, neue Fähigkeiten zunächst als optionale Erweiterung zu veröffentlichen und dort reifen zu lassen, bevor sie — falls überhaupt — in die Spezifikation selbst übernommen werden. Für die Bestandsplanung bedeutet das, dass die genannten Deprecations ein Thema für die reguläre Roadmap sind und nicht für den Notfallkalender.
Eine Einschränkung bleibt dennoch. Die Umstellung auf den zustandslosen Kern ist ein Bruch, kein sanfter Übergang: Ein Client, der ausschließlich die neue Revision spricht, kann nicht mit einem Server kommunizieren, der nur die Vorgängerrevision beherrscht, und umgekehrt. Die offiziellen SDKs fangen dies ab, indem sie mehrere Protokollgenerationen aus derselben Serverimplementierung bedienen; die eingesetzten Bibliotheken müssen dafür allerdings hinreichend aktuell sein. MCP sollte deshalb nicht als unveränderliche Schnittstelle betrachtet werden. Bei Produkt- und Architekturentscheidungen ist zu prüfen, welche Protokollversion ein Client beziehungsweise Server unterstützt und welche Funktionen oder Erweiterungen in dieser Version tatsächlich spezifiziert sind.
Die Auswahl beginnt bei der Anforderung, nicht beim Protokoll
Die behandelten Technologien beantworten unterschiedliche Architekturfragen, und die Zuordnung lässt sich knapp zusammenfassen.
Anforderung
Typischer Mechanismus
Relevante Inhalte aus Dokumenten finden
RAG / Retrieval
Aktuellen Zustand eines Systems abfragen
API / Tool
Eine Funktion eines Systems ausführen
API / Tool
Externe Tools standardisiert gegenüber AI Clients anbieten
MCP
Daten oder Kontext standardisiert über MCP bereitstellen
MCP Resources
Unternehmenswissen und Live-Zustand kombinieren
RAG mit Tool/API beziehungsweise MCP
Aktion auf Basis von Wissen und Live-Daten ausführen
Kombination mit kontrolliertem Tool-Zugriff
Die Auswahl sollte daher nicht bei einem Protokoll beginnen, sondern bei der Frage, welche Information oder Funktion die KI benötigt und aus welchem System diese zum Zeitpunkt der Anfrage bezogen werden muss. Erst daraus ergibt sich der geeignete Integrationspfad.
[Querverweis-Marker: Ankerartikel zur KI-Architektur – übergeordnete Einordnung der hier behandelten Integrationsschicht]
Fazit
KI-Anwendungen benötigen für viele Enterprise-Szenarien mehr als den Zugriff auf Dokumentwissen. Sie müssen aktuelle Zustände aus Anwendungen und Infrastruktur beziehen und können, sofern vorgesehen und autorisiert, Funktionen dieser Systeme aufrufen. APIs stellen diese Daten und Funktionen bereits heute bereit, Tool Calling verbindet sie mit der Entscheidungslogik einer KI-Anwendung, und MCP schafft darüber eine standardisierte Integrationsschicht, über die AI Clients Tools, Resources und weitere Fähigkeiten unterschiedlicher Systeme verwenden können.
MCP und RAG stehen deshalb nicht in Konkurrenz. RAG beantwortet primär die Frage, welche vorhandenen Informationen für eine Anfrage relevant sind; Tool- und Systemintegration beantwortet, welcher aktuelle Zustand abzufragen oder welche Funktion auszuführen ist. In einer umfassenden Enterprise-KI-Architektur laufen beide Pfade zusammen. Entscheidend ist dann nicht allein, ob die KI technisch auf ein System zugreifen kann, sondern unter welcher Identität, mit welchen Berechtigungen und mit welchen kontrollierten Auswirkungen dieser Zugriff erfolgt.
Quellen
Model Context Protocol Project (Agentic AI Foundation / Linux Foundation), Specification, Version 2026-07-28. Normative Fassung; herangezogen für Tools, Resources und Prompts, den zustandslosen Protokollkern, Discovery und Routing, cachebare Listenergebnisse sowie den Autorisierungsteil. Abgerufen am 02.09.2026 unter modelcontextprotocol.io/specification/2026-07-28.
David Soria Parra / Den Delimarsky (Lead Maintainers), The 2026-07-28 Specification, Model Context Protocol Blog, 28.07.2026. Erläuternde Quelle zur Einordnung der Revision, zum Extensions-Framework, zur Deprecation von Roots, Sampling und Logging (SEP-2577) sowie zur Ablösung der Dynamic Client Registration durch Client ID Metadata Documents. Abgerufen am 02.09.2026.
David Soria Parra / Den Delimarsky (Lead Maintainers), The 2026-07-28 MCP Specification Release Candidate, Model Context Protocol Blog, 21.05.2026. Herangezogen für die Feature-Lifecycle-Policy mit zwölfmonatiger Mindestfrist, die Anforderung zur iss-Validierung (SEP-2468) sowie die Bindung registrierter Credentials an den Issuer (SEP-2352). Abgerufen am 02.09.2026.
Model Context Protocol Project, The New MCP Roadmap, Model Context Protocol Blog, 2026. Herangezogen für die Entfernung von protokollseitigen Sessions und Initialisierungshandshake (SEP-2575, SEP-2567) sowie für den Stabilitätsstatus der Extension Enterprise-Managed Authorization. Abgerufen am 02.09.2026.
Model Context Protocol TypeScript SDK, v2, Model Context Protocol Project, 2026. Herangezogen als Beleg dafür, dass die Umstellung eine Major-Revision der offiziellen SDKs erforderte; die stabile v2-Linie erschien zeitgleich mit der Spezifikation, v1.x erhält für mindestens sechs Monate weiterhin Fehler- und Sicherheitskorrekturen. Abgerufen am 02.09.2026.
IETF, D. Hardt (Ed.), RFC 6749 – The OAuth 2.0 Authorization Framework, Oktober 2012; aktualisiert unter anderem durch RFC 9700.
IETF, M. Jones / D. Hardt, RFC 6750 – The OAuth 2.0 Authorization Framework: Bearer Token Usage, Oktober 2012; aktualisiert unter anderem durch RFC 9700.
IETF, T. Lodderstedt / J. Bradley / A. Labunets / D. Fett, RFC 9700 – Best Current Practice for OAuth 2.0 Security, BCP 240, Januar 2025. Aktualisiert und erweitert das Bedrohungsmodell und die Sicherheitsempfehlungen der RFCs 6749, 6750 und 6819.
IETF, K. Meyer zu Selhausen / D. Fett, RFC 9207 – OAuth 2.0 Authorization Server Issuer Identification, März 2022. Definiert den Parameter iss als Gegenmaßnahme gegen Mix-up-Angriffe; Grundlage der in MCP 2026-07-28 geforderten Validierung.
IETF, M. B. Jones / P. Hunt / A. Parecki, RFC 9728 – OAuth 2.0 Protected Resource Metadata, April 2025. In MCP bereits seit der Revision 2025-06-18 gefordert, nicht erst seit 2026-07-28.
Welche Entscheidung steht bei Ihnen an?
Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.
Spezialist für moderne Dateninfrastruktur
