Seit Anfang 2025 stellen sich viele Backend- und API-Teams eine neue Frage. Wie lassen sich bestehende APIs so bereitstellen, dass KI-Agenten wie Claude, Cursor oder ChatGPT sie sinnvoll nutzen können? Eine der wichtigsten Antworten darauf ist MCP, das Model Context Protocol. Es ist ein offener Standard, der im November 2024 von Anthropic veröffentlicht wurde und sich innerhalb weniger Monate als De-facto-Standard für die Anbindung von Tools und Datenquellen an KI-Agenten etabliert hat.
Wer 2026 klären muss, wie KI-Agenten in eine bestehende API-Landschaft integriert werden, kommt an MCP kaum noch vorbei. Für viele Enterprise-Teams geht es deshalb weniger um die Frage, ob MCP relevant ist, sondern eher darum, welche APIs dafür geeignet sind, wie tief die Integration gehen soll und welche Governance-Regeln notwendig sind.
MCP, das Model Context Protocol, ist ein offener Standard von Anthropic und seit November 2024 verfügbar. Es definiert, wie KI-Agenten Tools, Resources und Prompts von externen Servern abrufen und verwenden können. Claude, ChatGPT, Cursor und weitere Agenten unterstützen das Protokoll. Für Enterprise-APIs entsteht damit eine zweite Spec-Schicht, über die ausgewählte API-Funktionen für KI-Agenten zugänglich werden, ohne bestehende REST-Endpoints verändern zu müssen.
Was MCP ist und warum es entstand
Das Model Context Protocol ist ein Kommunikationsstandard zwischen KI-Agenten und externen Tools, Datenquellen oder APIs. Anthropic veröffentlichte MCP im November 2024 als Open-Source-Spezifikation und adressierte damit ein Problem, das zuvor meist proprietär gelöst wurde. Jeder Anbieter eines KI-Agenten brachte seine eigene Schnittstelle für Tool-Integrationen mit, was die Portierbarkeit erschwerte.
Vor MCP dominierten vor allem zwei Ansätze. Function Calling, wie es OpenAI 2023 eingeführt hatte, ermöglichte Tool-Aufrufe innerhalb einer einzelnen API-Konversation. Das war pragmatisch und für viele Use Cases ausreichend, blieb aber eng an den jeweiligen Anbieter gebunden. Plugins, wie sie ChatGPT zeitweise anbot, verfolgten eine ähnliche Idee, waren jedoch ebenfalls proprietär.
MCP verändert diese Logik. Statt für jeden Agenten-Anbieter eine eigene Tool-Schnittstelle zu bauen, definiert MCP einen offenen Standard, gegen den sowohl Agenten als auch Tool-Anbieter implementieren können. Ein Tool, das für MCP gebaut wurde, kann dadurch mit Claude, ChatGPT, Cursor und jedem anderen Agenten genutzt werden, der das Protokoll unterstützt.
Die Verbreitung verlief ungewöhnlich schnell. Innerhalb weniger Monate nach Veröffentlichung hatten viele große Anbieter MCP integriert oder zumindest angekündigt. Microsoft, Google, Cursor und OpenAI gehörten zu den frühen Adoptierern. Dadurch wurde MCP bereits zum De-facto-Standard, bevor formale Standardisierungsgremien eine Rolle spielten.
Ein Grund für diese schnelle Adoption ist die Nähe zu bekannten Konzepten. In MCP kommen keine völlig neuen Modellierungs-Patterns vor. Tools sind im Kern Funktionen mit Input- und Output-Schemas, Resources sind benannte Datenpunkte, und die JSON-RPC-basierte Kommunikation ist seit Jahren etabliert. Wer OpenAPI verstanden hat, findet sich deshalb meist schnell in MCP zurecht. Viele Modellierungsprinzipien bleiben gleich, nur Konsument und Aufrufmechanismus ändern sich.
Die MCP-Architektur in vier Konzepten
MCP lässt sich über vier Kernkonzepte gut verstehen. Sie beschreiben, wie Agenten und Server miteinander interagieren und welche Arten von Informationen ein MCP-Server bereitstellen kann.
| Konzept | Was es konkret bedeutet |
|---|---|
| Server | Eine Komponente, die Tools, Resources und Prompts bereitstellt. Ein MCP-Server kann als eigenständiger Prozess laufen, als Sidecar neben einem bestehenden Backend eingesetzt werden oder Teil einer Plattform-Funktion sein. |
| Tools | Aufrufbare Funktionen mit Input-Schema und Output-Schema. Ein Tool ist die MCP-Entsprechung zu einem API-Endpoint und beschreibt, welche Aktion ein Agent ausführen kann. |
| Resources | Lesbare Datenquellen, die ein Agent abrufen kann. Resources sind passiv, anders als Tools. Eine Resource kann zum Beispiel ein Dokument, ein Datensatz oder ein zwischengespeicherter API-Response sein. |
| Prompts | Vorbereitete Konversations-Templates, die ein Server einem Agenten anbietet. Prompts strukturieren komplexere Workflows, in denen ein Agent mehrere Tools koordiniert nutzen soll. |
Die Kommunikation zwischen Agent und Server erfolgt über JSON-RPC. Häufig wird dafür ein lokaler Stdio-Transport genutzt. Bei entfernten Servern kommen HTTP/SSE oder vergleichbare Transportwege zum Einsatz. Die Authentifizierung war in frühen MCP-Versionen noch nicht vollständig ausdefiniert, ist inzwischen aber über ein OAuth-2.0-basiertes Profil deutlich klarer gefasst.
{
"name": "get_customer_orders",
"description": "Liefert die letzten Bestellungen eines Kunden",
"inputSchema": {
"type": "object",
"properties": {
"customerId": { "type": "string", "format": "uuid" },
"limit": { "type": "integer", "default": 10 }
},
"required": ["customerId"]
}
}Das Tool-Schema wirkt bewusst wie ein Ausschnitt aus einer OpenAPI-Spec. Konzeptionell ist es das auch. Es beschreibt Eingaben, erwartete Parameter und die aufrufbare Funktion. Der wesentliche Unterschied liegt nicht in der Modellierung, sondern darin, wer die Beschreibung konsumiert und wie der Aufruf erfolgt. Bei OpenAPI sind es meist Entwickler oder HTTP-Clients, bei MCP sind es KI-Agenten.
Auch der Verbindungsaufbau folgt einem klaren Ablauf. Im Initialize-Schritt tauschen Client und Server ihre Capabilities aus. Der Agent erfährt dabei, ob der Server Tools, Resources oder Prompts bereitstellt und welche Funktionen verfügbar sind. Danach bleibt eine Sitzung geöffnet, in der der Client Tools aufrufen, Resources abrufen oder Prompts laden kann. Über Notifications kann der Server den Client informieren, wenn sich Tool-Listen ändern oder neue Resources verfügbar werden.
MCP und OpenAPI im Verhältnis
MCP und OpenAPI lösen nicht dasselbe Problem, berühren sich aber an einer wichtigen Stelle. Beide beschreiben Funktionen, die ein Konsument aufrufen kann. OpenAPI richtet sich dabei vor allem an menschliche Entwickler, API-Konsumenten und HTTP-Clients. MCP beschreibt ähnliche Fähigkeiten für KI-Agenten.
In der Praxis ergänzen sich die beiden Standards. Eine API, die bereits sauber über OpenAPI beschrieben ist, lässt sich häufig ohne grundlegende Umbauten auch über MCP bereitstellen. Endpoints, Schemas und Auth-Mechanismen können weiterverwendet werden. Neu ist vor allem die zusätzliche Spec-Schicht, die beschreibt, wie ein KI-Agent diese Funktionen finden und sinnvoll aufrufen kann.
Wer eine Konvertierung von OpenAPI zu MCP plant, findet die technischen Details im kommenden Artikel zur OpenAPI-zu-MCP-Migration. Die zentrale Idee bleibt dabei einfach. Eine gut gepflegte OpenAPI-Spec ist der beste Ausgangspunkt für eine MCP-Exposition, weil Schemas, Authentifizierung und Operations bereits maschinenlesbar dokumentiert sind.
Der wichtigste Unterschied zeigt sich dort, wo OpenAPI bewusst endet. MCP-Tools benötigen häufig zusätzliche Informationen, die speziell für Agenten relevant sind. Wann soll ein Tool verwendet werden? Welche Reihenfolge ist sinnvoll? Welche Daten sollte der Agent vor einem Aufruf bereits kennen? Diese Meta-Informationen machen MCP-Tools für KI-Agenten nutzbar, gehen aber über das hinaus, was OpenAPI als Format typischerweise beschreibt.
Wer MCP heute unterstützt
Die Adoption von MCP hat sich in den ersten Monaten des Jahres 2025 stark beschleunigt. In der Praxis lassen sich heute vier Gruppen von Adoptierern unterscheiden.
KI-Agenten als Konsumenten. Claude unterstützt MCP seit Dezember 2024 nativ. ChatGPT folgte im Frühjahr 2025 mit einer eigenen Implementierung. Auch Cursor, Continue und weitere AI-Coding-Assistenten setzen MCP als Standardmechanismus ein, um externe Tools und Datenquellen anzubinden.
IDEs und Entwickler-Tools. JetBrains, VS Code und spezialisierte Editoren integrieren MCP als Schnittstelle zwischen Agent und Entwicklungsumgebung. Dadurch können Agenten auf Code-Repositories, lokale Dateien oder Build-Systeme zugreifen. MCP wird damit zur Brücke zwischen Coding-Workflow und KI-Agent.
Plattform-Anbieter. Microsoft integriert MCP-Server-Komponenten in Azure-Services. Google Cloud bietet MCP-fähige Endpoints für ausgewählte Services an. Anthropic pflegt zudem eine Reference-Implementierung, an der sich andere Anbieter orientieren können.
Open-Source-Community. Parallel wächst die Zahl verfügbarer MCP-Server für Standard-Tools wie GitHub, Slack, Notion oder lokale Datenbanken. Für Enterprise-Teams ist das relevant, weil viele Integrationsaufgaben nicht bei null beginnen müssen, sondern auf bestehenden Servern und Patterns aufsetzen können.
Auch cloud-native Anbieter ziehen nach. AWS hat im Frühjahr 2025 erste MCP-Endpoints für Bedrock-Services freigeschaltet, Snowflake bietet einen MCP-Server für Datenbankzugriffe an, und API-Plattformen wie api-portal.io integrieren die MCP-Server-Generierung aus OpenAPI-Specs direkt in ihre Produktfunktionen. Damit verschiebt sich MCP vom Sonderprojekt einzelner Teams hin zu einem festen Bestandteil moderner API-Plattformen.
Was MCP für Enterprise-APIs konkret bedeutet
Für Enterprise-API-Teams bedeutet MCP vor allem eines. Es entsteht eine zweite Spec-Schicht über bestehenden APIs. Nicht jede API-Funktion muss automatisch für Agenten verfügbar sein. Entscheidend ist vielmehr, welche Funktionen bewusst freigegeben werden, unter welchen Bedingungen sie nutzbar sind und wie Berechtigungen, Audit-Logging und Quotas umgesetzt werden.
In Enterprise-Kontexten zeigen sich besonders häufig drei Use Cases.
Internal Developer Productivity. Backend-Teams stellen ausgewählte Read-Endpoints über MCP bereit, damit Entwickler direkt in ihrem AI-Coding-Assistant auf API-Daten zugreifen können. Statt zwischen Editor, Postman und curl zu wechseln, können sie den Agenten im bestehenden Arbeitskontext fragen.
Customer Support Automation. Support-APIs werden über MCP für Agent-Anbindungen verfügbar gemacht. Diese Agenten können Tickets klassifizieren, Routing-Entscheidungen vorbereiten oder Vorgangsdaten zusammenfassen. Die Entscheidung bleibt beim Menschen, die strukturierte Datenarbeit übernimmt der Agent.
Internal Knowledge Workflows. Dokumenten-APIs, Wiki-APIs und Datenbank-Abfragen lassen sich über MCP an interne Agenten anbinden. Mitarbeitende erhalten dadurch Antworten auf Wissensfragen, ohne selbst mehrere Systeme durchsuchen zu müssen. Wichtig ist dabei, dass die Berechtigungslogik weiterhin in der zugrunde liegenden API bleibt und nicht in den MCP-Layer verlagert wird.
Für die erste MCP-Integration eignet sich ein klar abgegrenzter Read-Only-Use-Case. So kann das Team Erfahrungen mit Tool-Aufrufen, Berechtigungen und Audit-Logging sammeln, ohne direkt schreibende Zugriffe zu öffnen. Schreibende Tools folgen erst, wenn das Verhalten der Agent-Aufrufe im eigenen Setup nachvollziehbar und belastbar überwacht werden kann.
In einem Pilotprojekt haben wir einen MCP-Server vor eine bestehende interne Reporting-API gestellt. Der initiale Aufwand für Server-Setup und Tool-Definitionen lag bei rund zwei Personentagen. Der Nutzen wurde sichtbar, sobald Analysten direkt aus ihrem Coding-Assistant heraus Ad-hoc-Reports anfragen konnten. Was vorher mehrere Tool-Wechsel erforderte, lief anschließend im selben Editor-Fenster.
Wo Vorsicht geboten ist
MCP ist noch jung. Gerade deshalb gehören einige Punkte sorgfältig geprüft, bevor ein produktives Setup entsteht.
Das erste Thema ist Sicherheit. Ein MCP-Server stellt Tools bereit, die Agenten eigenständig ausführen können. Wenn ein Tool-Aufruf nicht ausdrücklich auf Read-Only beschränkt ist, erhält der Agent faktisch Schreibrechte auf das zugrunde liegende System. Deshalb braucht jedes produktive MCP-Setup ein sauberes Audit-Modell, lückenloses Logging aller Tool-Invocations und klar definierte Quotas.
Das zweite Thema ist Authentifizierung. Frühe MCP-Versionen ließen bei Authentifizierung und Autorisierung noch Interpretationsspielraum. Spätere Spezifikationen haben diese Lücken deutlich reduziert. Wer einen MCP-Server vor eine produktive API stellt, unterstützt daher das aktuelle OAuth-2.0-Profil und baut nicht auf älteren Implementierungen auf.
MCP-Server ohne Authentifizierungs-Layer sind ein direktes Risiko für das Backend. Mehrere öffentlich gewordene Vorfälle im Jahr 2025 folgten genau diesem Muster. Ein erreichbarer MCP-Server stellte Funktionen bereit, ohne Zugriffe ausreichend abzusichern. Das OAuth-2.0-Profil der aktuellen Spec ist deshalb kein optionales Add-on, sondern eine Grundvoraussetzung für jede produktive Exposition.
Das dritte Thema ist Tool-Design. Ein Tool, das einem Agenten bereitgestellt wird, muss eindeutig beschrieben sein. Vage Beschreibungen, zu viele optionale Parameter oder rein technische Bezeichnungen erhöhen das Risiko, dass der Agent ein Tool falsch auswählt oder mit ungeeigneten Parametern aufruft. Die Sorgfalt, die für gute API-Spezifikationen ohnehin notwendig ist, wird bei MCP noch wichtiger.
Eine einfache Praxisregel hilft besonders am Anfang. Die description eines MCP-Tools wird aus Sicht des Agenten geschrieben, nicht aus Sicht des Backends. „Liefert die letzten Bestellungen eines Kunden für Support-Anfragen" ist für einen Agenten deutlich hilfreicher als „GET /customers/{id}/orders". Das klingt banal, ist aber einer der häufigsten Fallstricke in den ersten MCP-Setups, weil Backend-Teams gewohnt sind, Endpoints vor allem technisch zu beschreiben.
Wie api-portal.io MCP unterstützt
In api-portal.io lassen sich MCP-Server direkt aus bestehenden OpenAPI-Specs erzeugen. Tools, Resources und Auth-Profile werden aus der Spec abgeleitet, können aber gezielt für den Agent-Use-Case angepasst werden. So bleibt die bestehende API-Beschreibung der Ausgangspunkt, während die MCP-Schicht zusätzliche Informationen für KI-Agenten ergänzt.
Die Plattform übernimmt dabei Audit-Logging, Quota-Management und das Berechtigungs-Mapping zwischen MCP-Aufrufen und der zugrunde liegenden API. Der MCP-Server macht bestehende APIs damit für MCP-Szenarien nutzbar, ohne dass Teams ihre REST-Endpoints neu bauen oder parallel pflegen müssen.
Damit wird MCP nicht zu einem Ersatz für OpenAPI, sondern zu einer ergänzenden Schicht für KI-Agenten. Bestehende APIs bleiben erhalten und werden gezielt für agentische Nutzung erschlossen.
Der MCP Server macht APIs für MCP-Szenarien nutzbar.