MCP-Protokoll und API: Wann sich welche Schnittstelle lohnt

Das MCP-Protokoll ersetzt keine API. Es bietet KI-Clients einen einheitlichen Weg, die auf einem Dienst aufbauenden Tools zu finden und aufzurufen. Bedient ein Produkt sowohl Anwendungen als auch Assistenten, bedeutet MCP vs API häufig: 2 Schnittstellen, die dieselben Geschäftsregeln nutzen. Für Anwendungsintegrationen bleibt die API bestehen. MCP kommt hinzu, wenn der Zugriff aus vorhandenen KI-Clients einen konkreten Kundenworkflow ermöglicht.

MCP-Protokoll und API: Was wird hier eigentlich verglichen?

Hier steht eine allgemeine Softwareschnittstelle einem speziellen Protokoll für KI-Integrationen gegenüber. Eine Programmierschnittstelle – auf Englisch Application Programming Interface, kurz API – legt fest, wie Software Daten oder Aktionen anfordert. Representational State Transfer (REST) ist ein Architekturstil, der häufig für HTTP-APIs verwendet wird. Das Model Context Protocol (MCP) vereinheitlicht den Zugriff kompatibler KI-Anwendungen auf externe Funktionen.

Ein Produkt lässt sich mit einer Werkstatt vergleichen. Die API ist der Serviceeingang mit dokumentierten Abläufen. Ein MCP-Server ergänzt einen Empfang, der die verfügbaren Arbeiten in einem Format beschreibt, das KI-Clients bereits verstehen. Die Menschen und Regeln, nach denen die Arbeit hinter dem Empfang erledigt wird, bleiben entscheidend.

Für die Entwicklung bedeutet das: ein Adapter für bestehende Funktionen. Für die Produktverantwortlichen entsteht ein weiterer Ort, an dem Kunden das Produkt nutzen können. Im Betrieb kommt eine Schnittstelle hinzu, für deren Zugriffe und Ausfälle jemand verantwortlich sein muss.

MCP kann auch lokale Funktionen bereitstellen, ohne eine HTTP-API aufzurufen. Eine API mit einem Adapter zu versehen, ist ein nützliches Muster, aber keine Pflicht. Die Dokumentation zur MCP-Architektur unterscheidet zwischen der KI-Anwendung und den Servern, die Funktionen bereitstellen. Eine umfassendere Einführung bietet der Artikel Was ist MCP?.

MCP vs REST API: Die Unterschiede im Überblick

REST eignet sich für die direkte Integration von Anwendungen. MCP ergänzt eine gemeinsame Toolschnittstelle, die kompatible KI-Clients nutzen können. Bei beiden Varianten bleibt das Produktteam für Berechtigungen und die korrekte Umsetzung der Geschäftslogik verantwortlich.

Diese Unterschiede ergeben sich aus den Empfehlungen zum REST-API-Design, den MCP-Transportmechanismen und der MCP-Autorisierungsspezifikation. Die gemeinsame Nutzung der Geschäftsregeln ist eine Architekturempfehlung.

Auch eine API kann bereits ein maschinenlesbares Schema besitzen. Die OpenAPI Specification beschreibt HTTP-Schnittstellen für Menschen und Computer. Das Besondere an MCP ist der gemeinsame Schnittstellenvertrag zur Laufzeit für KI-Integrationen. Die Fähigkeit, Parameter zu beschreiben, ist kein Alleinstellungsmerkmal.

Was ergänzt eine MCP-Schnittstelle an einer bestehenden API?

Mit MCP lässt sich die Toolschnittstelle über mehrere kompatible Hosts hinweg wiederverwenden. Der Host ist die KI-Anwendung, die das Modell und dessen Verbindungen koordiniert. Das Produktteam implementiert die Funktionen des Servers; der Host stellt seinen MCP-Client bereit.

Konkret kommt Folgendes hinzu:

• Toolerkennung: tools/list teilt einem verbundenen Client mit, welche Operationen verfügbar sind.
• Eine einheitliche Tooldefinition: Name, Beschreibung und ein JSON Schema für die Eingaben. JSON Schema beschreibt die erwarteten Felder und deren Typen. Ein Tool kann außerdem ein Ausgabeschema deklarieren.
• Ein gemeinsames Aufrufverfahren: tools/call übermittelt Toolname und Argumente; die Ergebnisse werden im Nachrichtenformat von MCP zurückgegeben.

Die Toolspezifikation definiert diese Operationen. Ein Ticketdienst kann beispielsweise create_ticket anbieten und dabei erklären, wann das Tool einzusetzen ist und welche Felder es benötigt. Der Client kann diese Definition nutzen, ohne dass im Host selbst ein eigenes Plugin für den Ticketdienst programmiert werden muss.

Der Nutzen hängt von der Zielgruppe ab. Wenn ausschließlich das eigene Backend den Dienst aufruft, kontrolliert das Team womöglich ohnehin beide Seiten der Integration. Wollen Kunden dieselbe Aufgabe in verschiedenen unterstützten KI-Anwendungen erledigen, gewinnt ein gemeinsames Protokoll an Wert.

MCP Server vs API: Die Bereitstellung ist eine eigene Entscheidung

MCP erfordert nicht zwangsläufig einen zusätzlichen Dienst. Ein MCP-Handler kann neben der API laufen, ein separat bereitgestellter Adapter kann die API aufrufen, oder die vorhandene Serviceschicht wird direkt angebunden. Ausschlaggebend sind die Anforderungen an Isolation, Zuständigkeit und Releases.

Bei stdio startet der Client einen Prozess und tauscht Nachrichten über dessen Standardein- und -ausgabe aus. Bei Streamable HTTP kontaktiert er einen MCP-Endpunkt über HTTP. Das sind die standardisierten Transportanbindungen. Bei einer Netzwerkverbindung muss der Endpunkt vom tatsächlich verwendeten Client aus erreichbar sein.

Das Diagramm zeigt die Variante mit einem Adapter vor der API. Ebenso kann ein gemeinsamer interner Dienst aufgerufen werden, sofern der MCP-Zugriff dieselbe Autorisierung und Validierung beibehält.

API vs MCP: Dasselbe Ticket über beide Schnittstellen anlegen

Das angelegte Ticket muss identisch sein, unabhängig von der aufrufenden Schnittstelle. Als Beispiel dient ein fiktives Ticketsystem: Ein Kunde möchte im Projekt EXAMPLE ein Ticket mit dem Titel „Login button fails“ anlegen. Die folgenden Namen und Felder illustrieren mögliche Schnittstellenverträge einer Anwendung; sie gehören zu keiner API eines Drittanbieters.

Der Weg über die REST API

Die Anwendung sendet eine authentifizierte Anfrage an POST /tickets mit diesem JSON-Inhalt: {"project_key":"EXAMPLE","title":"Login button fails","request_key":"demo-ticket"}.

Die API ermittelt die Identität des Aufrufers, prüft den Projektzugriff, validiert den Titel und ruft den Dienst zum Anlegen des Tickets auf. Dieser gibt die Kennung und den Status des neuen Tickets zurück.

In diesem Beispiel ist request_key ein von der Anwendung festgelegter Idempotenzschlüssel: Wird dieselbe logische Anfrage mit demselben Schlüssel wiederholt, sollte das ursprüngliche Ergebnis zurückkommen, statt ein weiteres Ticket anzulegen. Das ist eine Designentscheidung für dieses Beispiel, keine automatisch von REST bereitgestellte Funktion.

Der Weg über den MCP-Server

Der Server bietet ein Tool namens create_ticket an, etwa mit der Beschreibung „Erstellt ein Ticket in einem Projekt, auf das der aktuelle Nutzer zugreifen darf.“ Sein inputSchema verlangt die Zeichenkettenfelder project_key, title und request_key.

Nachdem der Client das Tool ermittelt hat, sendet er eine tools/call-Anfrage mit den Parametern {"name":"create_ticket","arguments":{"project_key":"EXAMPLE","title":"Login button fails","request_key":"demo-ticket"}}. Gezeigt sind die Aufrufparameter, keine vollständige Protokollnachricht.

Der Adapter übergibt die Argumente an denselben Ticketdienst oder ruft den bestehenden Endpunkt POST /tickets auf. Kennung und Status des Tickets liefert er im Toolergebnis zurück. MCP vereinheitlicht das Auffinden und Aufrufen des Tools; was das Anlegen eines Tickets bedeutet, legt die Anwendung fest.

Die Berechtigungsprüfung muss für beide Wege gelten

Der Adapter darf keinen Weg an den Projektberechtigungen vorbei eröffnen. Identität und Organisation des Aufrufers müssen aus einem vertrauenswürdigen Authentifizierungskontext stammen. Anschließend wird der Projektzugriff geprüft. Eine Organisationskennung ist nicht allein deshalb vertrauenswürdig, weil ein Modell sie geliefert hat.

Bei der Wiederholung derselben beabsichtigten Aktion muss der Idempotenzschlüssel unverändert bleiben. Wiederholte Modellanfragen mit unterschiedlichen Schlüsseln gelten nicht automatisch als Duplikate. Die Anwendung muss deshalb festlegen, wie sie wiederholte Schreibvorgänge erkennt und prüft.

Für welche KI-Clients ist MCP-Unterstützung dokumentiert?

Claude, ChatGPT, Cursor und GitHub Copilot dokumentieren alle MCP-Unterstützung. Die Anbindungswege unterscheiden sich jedoch. Die folgenden Angaben wurden am 17. Oktober 2026 anhand der jeweiligen aktuellen Herstellerdokumentation geprüft. Sie belegen die dokumentierte Unterstützung; sie ersetzen keinen praktischen Interoperabilitätstest sämtlicher Server, Features oder Protokollrevisionen.

Claude

Claude, der KI-Assistent von Anthropic, unterstützt benutzerdefinierte Remote-MCP-Konnektoren. Laut Konnektor-Dokumentation gehen diese Verbindungen von der Cloud-Infrastruktur von Anthropic aus. Ein Endpunkt, der nur vom eigenen Laptop aus erreichbar ist, reicht für diesen Anbindungsweg daher nicht aus. Auch Organisationseinstellungen beeinflussen, wer einen Konnektor hinzufügen darf.

Bei einem gehosteten Produkt sollten Erreichbarkeit und Authentifizierungsablauf auf Kundenseite geprüft werden, bevor eine funktionierende Integration zugesagt wird. Die Einrichtung lokaler Server in der Desktop-Anwendung ist ein gesonderter Mechanismus.

ChatGPT

ChatGPT, die KI-Anwendung von OpenAI, dokumentiert die Anbindung eines eigenen MCP-Servers über Plugins. Die Schnellstartanleitung von OpenAI führt durch das Hinzufügen einer HTTPS-MCP-URL, die Einrichtung der Authentifizierung, das Erstellen und Installieren des Plugins und den anschließenden Aufruf im Chat. Eine eigene grafische Oberfläche ist optional.

Für diesen dokumentierten Weg muss der Server von ChatGPT aus erreichbar sein; die Entwicklungsanleitung macht ihn über das öffentliche Internet zugänglich. Ein lokaler Startbefehl aus der Konfiguration eines anderen Clients lässt sich dafür nicht einfach übernehmen.

Cursor

Cursor, der KI-Codeeditor, dokumentiert Verbindungen über stdio, Server-Sent Events (SSE) und Streamable HTTP. Die MCP-Dokumentation beschreibt die Toolunterstützung, die Konfiguration über mcp.json und OAuth für Server, die es voraussetzen. SSE ist ein Verfahren, mit dem ein Server fortlaufend Ereignisse übermittelt.

Ein lokales Entwicklertool und ein gehosteter Dienst können daher unterschiedliche Anbindungswege nutzen. Die Bereitstellung muss zum unterstützten Transport und zur Authentifizierungskonfiguration passen. „Funktioniert in Cursor“ ist noch keine vollständige Kompatibilitätsbeschreibung.

GitHub Copilot

GitHub Copilot, der KI-Programmierassistent von GitHub, dokumentiert MCP für mehrere Produktumgebungen. Die Dokumentation zur Verfügbarkeit behandelt integrierte Entwicklungsumgebungen (IDEs), die Kommandozeilenschnittstelle, die Copilot-App sowie die Repository-Konfiguration für den Cloud-Agenten und Code-Reviews. Die CLI unterstützt lokale und entfernte Server. Die Unterstützung in den einzelnen Editoren variiert, und Organisationsrichtlinien können den Zugriff regeln.

Die unterstützte Umgebung sollte konkret benannt werden, etwa Copilot in einem bestimmten Editor. Eine erfolgreiche CLI-Verbindung belegt nicht, dass die Repository-Konfiguration oder die Organisationsrichtlinien des Kunden denselben Server auch an anderer Stelle zulassen.

Beispiele bereits verfügbarer Integrationen bietet der Leitfaden zu den besten MCP-Servern. Hier geht es um die Entscheidung, ob das eigene Produkt einen solchen Server bereitstellen sollte.

MCP vs API: Wann lohnt sich welche Schnittstelle?

MCP lohnt sich, wenn ein klar definierter Workflow dadurch im bereits genutzten KI-Client des Kunden verfügbar wird. Begeisterung für das Protokoll allein rechtfertigt keine weitere Schnittstelle, die dauerhaft unterstützt werden muss.

MCP bereitstellen, wenn:

• Kunden Datensätze des Produkts durchsuchen oder eine klar begrenzte Aktion aus einer vorhandenen MCP-kompatiblen KI-Anwendung heraus ausführen möchten.
• Dieselben nützlichen Funktionen mehreren kompatiblen Hosts zur Verfügung stehen sollen.
• Die Aufgabe davon profitiert, dass ein Assistent anhand des Gesprächskontexts zwischen gut beschriebenen Operationen auswählt.
• Transport, Authentifizierung und Installationsweg des Zielclients unterstützt werden können und die Zuständigkeit für Fehler und Änderungen geklärt ist.

Bei der API bleiben, wenn:

• Anwendungen, geplante Jobs oder Partnerintegrationen mit einem bereits festgelegten Workflow die Schnittstelle aufrufen.
• Das eigene Team die KI-Anwendung und ihren API-Adapter kontrolliert und keine Kompatibilität mit externen Hosts benötigt.
• Sich keine konkrete Kundenaufgabe benennen lässt, die durch die Bereitstellung von Tools für einen weiteren Client besser gelöst wird.
• Berechtigungen oder Dienstverhalten noch nicht stabil sind. Diese Grundlagen sollten gefestigt werden, bevor ein weiterer Schnittstellenvertrag hinzukommt.

Beides bereitstellen, wenn: herkömmliche Integrationen wichtig bleiben und Kunden zusätzlich einen dialogbasierten Zugriff wünschen. Ein Ticketprodukt könnte seine API für die Webanwendung und Automatisierungen beibehalten und ausgewählte MCP-Tools anbieten, mit denen ein Assistent Tickets suchen und anlegen kann.

Für die Entwicklung heißt das: die Serviceschicht wiederverwenden. Die Produktverantwortlichen legen die unterstützten Aufgaben und Clients fest. Der Betrieb muss nachvollziehen können, welcher Nutzer eine Aktion ausgeführt hat und wie sich der Zugriff entziehen lässt. Diese Verantwortlichkeiten bleiben unterschiedlich, auch wenn dieselbe Person sie alle übernimmt.

MCP vs API vs CLI: Welche Schnittstelle passt zum Aufrufer?

Diese Schnittstellen können unterschiedliche Aufrufer mit demselben Dienst verbinden. Eine Kommandozeilenschnittstelle (CLI) stellt Menschen und Skripten ausführbare Befehle zur Verfügung. Eine API bietet Anwendungscode einen programmatischen Schnittstellenvertrag. MCP gibt kompatiblen KI-Hosts eine gemeinsame Toolschnittstelle.

Wenn ein Bereitstellungsskript bereits eine zuverlässige CLI oder API nutzt, muss MCP daran nichts verbessern. Möchte ein Kunde die Ticketfunktion dagegen in seinem Assistenten nutzen, kann MCP eine eigens entwickelte Hostintegration ersparen. Entscheidend ist die passende Schnittstelle für den jeweiligen Aufrufer. Funktionierende Automatisierung sollte nicht allein wegen eines einheitlichen Kürzels migriert werden.

Eine zusätzliche Schnittstelle absichern und pflegen

Der wesentliche Mehraufwand liegt in einer weiteren Schnittstelle, für die das Team einstehen muss – auch wenn MCP und API gemeinsam bereitgestellt werden. Toolbeschreibungen, Schemas, Abhängigkeiten, die Anbindung der Authentifizierung und die Clientkompatibilität müssen gepflegt werden.

Zugangsdaten und Berechtigungen getrennt betrachten

Die Autorisierungsspezifikation von MCP beschreibt für HTTP-Implementierungen einen auf OAuth 2.1 basierenden Rahmen. OAuth dient dazu, einer Anwendung begrenzten Zugriff auf einen Dienst zu gewähren. Auf Protokollebene ist Autorisierung optional. Daraus folgt keine Empfehlung, private Produktdaten ungeschützt zu lassen. Bei stdio werden Zugangsdaten anders eingebunden als im HTTP-Verfahren.

Ein Adapter muss unter Umständen sowohl eingehende Zugangsdaten für den MCP-Server als auch ausgehende Zugangsdaten für den zugrunde liegenden Dienst verarbeiten. Zu prüfen ist die vorgesehene Zielressource, also der Dienst, für den ein Token ausgestellt wurde. Der zulässige Berechtigungsumfang des Nutzers muss dabei erhalten bleiben. Die Sicherheitsempfehlungen untersagen es, Tokens für eine andere Ressource ungeprüft zu akzeptieren und an nachgelagerte Dienste weiterzureichen.

Im Ticketbeispiel dürfen weitreichende Dienstzugangsdaten nicht unbemerkt jeden verbundenen Nutzer zum Projektadministrator machen. Die Zugriffsprüfung gehört in die gemeinsam genutzte Geschäftsoperation – unabhängig davon, wie der Adapter seine Zugangsdaten verwaltet.

Tools auf klar umrissene Aufgaben zuschneiden

Ein Tool sollte eine nützliche Aktion mit klaren Grenzen anbieten. Als Einstieg eignen sich create_ticket oder eine begrenzte Suche, nicht ein uneingeschränktes Tool, das beliebige URLs, Methoden und Anfrageinhalte annimmt.

Das ist eine Empfehlung für das Produktdesign, keine Einschränkung des Protokolls. Eine kleinere Schnittstelle lässt sich leichter erklären, mit Berechtigungen versehen und bei Fehlern untersuchen. Nicht jeder interne Endpunkt gehört in den Toolkatalog, nur weil ein Generator die Definitionen erzeugen kann.

Beschreibungen sollten Zweck und Nebenwirkungen einer Aktion benennen. Ergebnisse müssen genügend Informationen enthalten, um den Ausgang der Aktion zu erkennen; sachfremde sensible Felder gehören nicht hinein. Ein Schema legt die Form fest. Es belegt weder, dass die angeforderte Aktion erlaubt ist, noch, dass sie angemessen ist.

Fehler über beide Schnittstellen hinweg nachvollziehen

Der Toolaufruf muss bis zur zugrunde liegenden Operation nachvollziehbar sein. Dazu werden die autorisierte Identität, der Toolname, die relevante Anfragekennung und das Ergebnis erfasst, ohne Zugangsdaten oder unnötige sensible Daten zu protokollieren.

Validierungsfehler, verweigerte Berechtigungen, Ratenbegrenzungen und ein nicht erreichbarer vorgelagerter Dienst müssen unterscheidbar sein. Läuft eine Schreibanfrage nach dem Absenden in einen Timeout, bestimmen die Wiederholungsregeln der gemeinsamen Operation, wie vor einem erneuten Versuch geprüft wird, ob sie bereits abgeschlossen wurde. MCP liefert diese fachliche Garantie nicht mit.

Ein lokaler Server verursacht Aufwand für Abhängigkeiten und Ausführungsrechte, ein gehosteter Server für Bereitstellung und Verfügbarkeit. Wartung ist in beiden Fällen nötig.

Versionierung und Limits: Zwei Schnittstellenverträge kompatibel halten

Protokollkompatibilität und Toolkompatibilität sind getrennte Aufgaben. Bei der Prüfung am 17. Oktober 2026 führte die MCP-Dokumentation 2026-07-28 als aktuelle Protokollrevision. Die Dokumentation zur Versionierung beschreibt die Versionsangabe pro Anfrage und die Kompatibilität mit früheren Revisionen, die auf einem Handshake beruhten.

Damit ist nicht belegt, dass jeder oben genannte Client diese Revision implementiert. Es gilt, ein unterstütztes Software Development Kit (SDK) auszuwählen und die Revisionen und Features zu testen, die von den vorgesehenen Clients genutzt werden.

Davon getrennt zu betrachten ist der fachliche Vertrag eines Tools. Wenn create_ticket statt eines Projektschlüssels künftig eine andere Kennung verlangt, macht eine unveränderte MCP-Protokollrevision diese Änderung nicht kompatibel. Während der Migration sollte der bisherige Vertrag erhalten bleiben oder ein klar unterscheidbarer Ersatz eingeführt werden – mit Dokumentation und einer Regelung für die Ablösung.

Auch Limits müssen sich am tatsächlich unterstützten Dienst und Host orientieren: Ergebnisgröße, zulässiger Datenumfang, Anfragedauer und Ratenbegrenzungen vorgelagerter Dienste. Eine erfolgreiche Protokollverbindung belegt weder, dass eine riesige Antwort für das Modell nützlich ist, noch, dass sich ein lange laufender Schreibvorgang sicher wiederholen lässt.

Welche Versprechen rund um MCP gehen zu weit?

MCP verringert die Unterschiede zwischen Integrationen; es beseitigt nicht die Integrationsarbeit. Bei den folgenden Aussagen ist eine präzisere Einordnung nötig:

• „KI braucht MCP, um eine API aufzurufen.“ Eine KI-Anwendung kann eigene Tools implementieren. Die Dokumentation zum Function Calling von OpenAI beschreibt ausdrücklich, wie die Anwendung Code ausführt, nachdem ein Modell ein Tool angefordert hat. MCP ist dann nützlich, wenn eine gemeinsame Client-Server-Schnittstelle das Ziel ist.
• „Das Schema macht die Aktion sicher.“ Auch eine korrekt aufgebaute Anfrage kann auf ein gesperrtes Projekt zielen oder einen unerwünschten Schreibvorgang auslösen. Berechtigungen und Prüfung bleiben Aufgaben der Anwendung.
• „MCP ersetzt das Backend.“ Das Protokoll vermittelt Funktionen. Es liefert weder die Regeln des Ticketsystems noch eine Datenbank oder einen zuverlässigen Dienst.
• „MCP ist immer zustandsbehaftet.“ Dieser pauschale Gegensatz zu REST lässt außer Acht, dass die aktuelle Spezifikation auf einzelnen Anfragen aufbaut und frühere, an Verbindungen gebundene Sitzungen gesondert behandelt. Maßgeblich ist die tatsächlich implementierte Revision der Transportspezifikation.

Das tragfähige Versprechen ist überschaubar und nützlich: Kunden können eine unterstützte Toolschnittstelle von kompatiblen Hosts aus wiederverwenden, während das Produktteam die Kontrolle über den zugrunde liegenden Dienst behält.

Der nächste Schritt zur Umsetzung

Bevor ein MCP-Katalog entsteht, müssen eine Kundenaufgabe und ein Zielclient feststehen. Wer auf Produktseite das Anlegen von Tickets bewertet, sollte als Nächstes mit den für die bestehende API zuständigen Entwicklern eine kurze Liste von Abnahmekriterien erarbeiten.

1. 1

   Die gemeinsame Aktion festlegen

   Eingaben, Ergebnis, Berechtigungsgrenzen und das Verhalten bei doppelten Anfragen definieren. Diese Regeln bleiben im vorhandenen Dienst.

2. 2

   Ein klar begrenztes Tool bereitstellen

   MCP-Definition und Handler ergänzen, den dokumentierten Anbindungsweg des Clients wählen und die vorhandene API für ihre bisherigen Aufrufer verfügbar halten.

3. 3

   Das entscheidende Verhalten prüfen

   Eine erlaubte Anfrage, verweigerten Projektzugriff, einen wiederholten Schreibvorgang und eine fehlgeschlagene Anfrage an den zugrunde liegenden Dienst prüfen. Sicherstellen, dass beide Schnittstellen dasselbe fachliche Ergebnis bewahren.

Details zur Implementierung bietet der Leitfaden für einen MCP-Server mit Python. Der Katalog sollte erst wachsen, wenn der erste Workflow seinen dauerhaften Unterstützungsaufwand rechtfertigt.

Häufig gestellte Fragen

Warum MCP statt einer API verwenden?

MCP ist sinnvoll, wenn Kunden den Dienst über eine einheitliche, automatisch auffindbare Toolschnittstelle aus kompatiblen KI-Anwendungen heraus nutzen können. Häufig liegt dahinter weiterhin eine API. Es geht also darum, diesen Zugangsweg zu ergänzen, statt den zugrunde liegenden Dienst zu ersetzen.

Sind API und Endpunkt dasselbe?

Nein. Die API ist der Schnittstellenvertrag; ein Endpunkt ist eine Adresse, über die ein Teil davon erreichbar ist. Im Ticketbeispiel umfasst die API Operationen und Datenregeln, während /tickets ein Ressourcenpfad ist, den eine Operation verwendet. Die API-Erklärung von IBM unterscheidet zwischen dem Vertrag und der Anfrageadresse.

Was sind typische Beispiele für API-Funktionen?

Das Anlegen eines Tickets, die Abfrage eines Bestellstatus und das Abrufen eines Kontodatensatzes sind Beispiele für API-Funktionen. Ein MCP-Server kann ausgewählte Funktionen als Tools bereitstellen, während ihre Implementierung in der zugrunde liegenden Anwendung bleibt.

Was unterscheidet eine API von einem Proxy?

Eine API legt fest, wie Software mit einem Dienst interagiert. Ein Proxy ist eine Zwischenstation, die Anfragen weiterleitet. Ein MCP-Adapter kann im Auftrag eines Clients eine API aufrufen, stellt aber zusätzlich den MCP-Toolvertrag bereit. Das bloße Weiterleiten von HTTP-Anfragen ermöglicht noch keine Toolerkennung.

Welche vier Arten von APIs gibt es?

Eine allgemeingültige Einteilung in vier API-Arten gibt es nicht. Öffentlich, privat und partnerbezogen beschreiben die Zielgruppen des Zugriffs; zusammengesetzt bezeichnet die Kombination zugrunde liegender Operationen. Die API-Übersicht von IBM behandelt dies als unterschiedliche Dimensionen. Daraus ergibt sich nicht, ob eine HTTP-API um MCP ergänzt werden sollte.

Praktische Entscheidungshilfen für die Entwicklung mit KI gibt es im Newsletter.