Übersicht
Seit Jahrzehnten gelten Anwendungsprogrammierschnittstellen (APIs) als der Goldstandard für die Kommunikation zwischen Softwareprogrammen.
Jede Online-Zahlung, die Sie jemals getätigt haben. Jedes Mal, wenn du dir die Wettervorhersage angesehen hast. Jedes Mal, wenn Sie sich bei einer Unternehmensanwendung angemeldet haben.
All diese Dinge und noch viele weitere werden durch APIs ermöglicht. Diese Tools dienen zum Senden und Empfangen von Informationen aus anderen Anwendungen.
API ist die Art und Weise, wie Software mit Software kommuniziert. Ein Entwickler programmiert die Integration, kennt die Endpunkte und wartet den Code. Es ist seit Jahrzehnten der Standard.
Das Model Context Protocol (MCP) ist die Art und Weise, wie KI mit Software kommuniziert. Der KI-Agent erkennt verfügbare Tools zur Laufzeit und nutzt diese über ein standardisiertes Protokoll, ohne dass für jede Integration eigener Code erforderlich ist. MCP wurde 2024 von Anthropic eingeführt und baut auf bestehenden APIs auf, ohne diese zu ersetzen, sondern sie für KI zugänglich zu machen.
APIs sind für Entwickler konzipiert. MCP wurde speziell für KI-Agenten entwickelt.
Im Gesundheitswesen beispielsweise ist es nicht ungewöhnlich, dass mehr als 30 APIs die technologische Infrastruktur eines Unternehmens unterstützen. Als dann KI-Agenten aufkamen, brachte dies eine interessante Herausforderung mit sich.
"Each of these tools had different ways to call them, different parameters, different arguments, different protocols," explains Don Woodlock , Präsident von InterSystems, in seiner Reihe „Code to Care“. "Which made the task of building an agentic system complicated."
Das Model Context Protocol wurde entwickelt, um diese Komplexität zu bewältigen. Es ersetzt nicht die Schnittstellen, die Ihre Systeme bereits verwenden. Es baut eine standardisierte Ebene darüber auf, sodass KI-Agenten Tools erkennen und nutzen können, ohne für jedes einzelne einen eigenen Code schreiben zu müssen.
Ganz gleich, ob Sie gerade Ihren ersten KI-Workflow erstellen oder verstehen möchten, warum im Bereich der Gesundheits-IT derzeit alle über MCP sprechen – hier finden Sie eine praxisnahe Übersicht: Was ist MCP, wie unterscheidet es sich von herkömmlichen APIs und wann kommt welche Variante zum Einsatz?
Was ist eine API?
Eine API (Application Programming Interface) ist eine Reihe von Regeln, die festlegt, wie eine Software mit einer anderen kommuniziert. APIs bilden die Grundlage der Kommunikation zwischen Softwareprogrammen: Ein System sendet eine strukturierte Anfrage, ein anderes gibt eine strukturierte Antwort zurück.
POST https://hospital.example.com/api/appointments
// Headers
Authorization: Bearer eyJhbGciOi ...
Content-Type: application/json
{
"patient_id": "MRN-00482916",
"provider": "Dr. Ramirez",
"department": "Cardiology",
"date": "2026-04-15T10:30:00Z"
} Response:
200 OK
{
"appointment_id": "APT-78291",
"status": "confirmed",
"patient": "MRN-00482916",
"provider": "Dr. Ramirez",
"location": "Building C, Room 204"
} Im Gesundheitswesen sind APIs die treibende Kraft hinter allen Prozessen – von der Überprüfung des Versicherungsanspruchs bis hin zum Austausch von Laborergebnissen. Eine Terminplanungsanwendung ruft die REST-API eines Krankenhaussystems auf, um einen Termin zu vereinbaren. Die API definiert den Endpunkt, die erforderlichen Parameter, die Authentifizierungsmethode und das Antwortformat. Der Aufrufer muss all dies im Voraus wissen.
Diese Anforderung (die Funktionsweise der API zu kennen, bevor man sie nutzen kann) ist zugleich ihre Stärke und ihre Einschränkung. APIs sind vorhersehbar, schnell und eignen sich gut für stabile Integrationen, bei denen die Kommunikation zwischen Softwarekomponenten einem festen Muster folgt.
Sie setzen jedoch voraus, dass der Aufrufer ein Entwickler ist, der die Dokumentation gelesen, den Integrationscode geschrieben und eine Fehlerbehandlung für jeden Sonderfall implementiert hat.
Was ist MCP (Model Context Protocol)?
Das Model Context Protocol ist ein Standard, der Ende 2024 von Anthropic eingeführt wurde und festlegt, wie große Sprachmodelle und KI-Agenten mit externen Tools, Datenquellen und externen Diensten interagieren.
Während APIs für die Kommunikation zwischen Softwarekomponenten konzipiert sind, ist das MCP KI-nativ und von Grund auf für KI-Systeme und KI-Anwendungen entwickelt worden, die Tools dynamisch erkennen und nutzen müssen.
Eine API setzt voraus, dass der Aufrufer Geheimnisse speichern, Netzwerkanfragen stellen und Fehler behandeln kann. Ein KI-Modell kann keine dieser Aufgaben sicher ausführen. Es analysiert Text und sagt das nächste Token voraus.
Ihm direkten Zugriff auf API-Endpunkte mit API-Schlüsseln und Authentifizierungstoken zu gewähren, wäre sowohl gefährlich als auch ineffizient.
MCP schafft eine kontrollierte Ebene zwischen dem KI-Agenten und der Außenwelt. Die KI hat zu keinem Zeitpunkt Zugriff auf sensible URLs oder Anmeldedaten. Es ruft Tools über eine standardisierte Schnittstelle auf, und der MCP-Server kümmert sich um alles, was dahinter läuft.
tools/list
// No URL, no auth token, no docs required[
{
"name": "schedule_appointment",
"description": "Book a patient appointment",
"inputs": { "patient_id", "provider", "department", "date" }
},
{
"name": "get_lab_results",
"description": "Retrieve lab results for a patient",
"inputs": { "patient_id", "test_type" }
},
{
"name": "check_insurance_eligibility",
"description": "Verify patient insurance coverage",
"inputs": { "patient_id", "procedure_code" }
}
]tools/call "schedule_appointment"
{
"patient_id": "MRN-00482916",
"provider": "Dr. Ramirez",
"department": "Cardiology",
"date": "2026-04-15T10:30:00Z"
}{
"appointment_id": "APT-78291",
"status": "confirmed",
"location": "Building C, Room 204"
}Die USB-C-Analogie
MCP verhält sich zu KI-Tools wie USB-C zu Peripheriegeräten. Vor der Einführung von USB-C benötigte jedes Gerät ein eigenes Ladegerät, ein eigenes Kabel und einen eigenen Anschluss. USB-C hat die Schnittstelle standardisiert, sodass jedes Peripheriegerät über denselben Anschluss an jeden Laptop angeschlossen werden kann.
MCP leistet dasselbe für die KI-Integration. Der MCP-Host ist das KI-System, das die Verbindungen verwaltet. Der MCP-Client übernimmt die Abwicklung des Protokolls. Der MCP-Server ist der externe Dienst: eine Datenbank, ein Terminplanungswerkzeug, ein klinisches System, eine Internetressource. Ein Protokoll, jedes beliebige Tool.
Zwei zentrale Methoden
Ein MCP-Server ist einfacher, als die meisten Leute erwarten. Es implementiert zwei Hauptmethoden:
- Werkzeuge auflisten – Der KI-Agent fragt: „Welche Werkzeuge stehen dir zur Verfügung?“
- Aufruf des Tools – Der KI-Agent sagt: „Rufe dieses Tool mit diesen Argumenten auf.“
„Der LLM kann fragen: ‚Welche Werkzeuge stehen dir zur Verfügung?‘“ Don erklärt es. „Und dann kann es später sagen: ‚Rufe dieses Tool mit diesen Argumenten auf.‘“ „Und das war’s im Grunde auch schon.“
Die Kommunikation erfolgt über JSON-RPC mit persistenten, bidirektionalen Verbindungen, was eine Abkehr vom zustandslosen Request-Response-Muster von REST-APIs darstellt.
Der MCP-Server antwortet mit maschinenlesbaren Beschreibungen der einzelnen Tools: deren Name, ihre Funktion, die akzeptierten Eingaben und die zurückgegebenen Ausgaben. Der KI-Agent kann sich an neue Funktionen anpassen, ohne dass jemand speziellen Integrationscode schreiben muss.
Die Tools, die hinter einem MCP-Server stehen, können in jeder beliebigen Sprache entwickelt werden. "The tool may be a Node app or an IRIS app or a Java app, and the client might be something else entirely," Don notes. Dank dieses technologieunabhängigen Designs werden die heute gebauten MCP-Server auch dann noch funktionieren, wenn sich die zugrunde liegende Technologie weiterentwickelt.
MCP vs. API – Die wichtigsten Unterschiede
Auf den ersten Blick sehen MCP und APIs ähnlich aus. Beide übertragen Daten zwischen Systemen. Beide verwenden strukturierte Anfragen und Antworten. Die Unterschiede werden deutlich, wenn man sich ansieht, welche Annahmen jeweils über den Anrufer getroffen werden.
Funktion | Herkömmliche APIs | MCP |
Architektur und Kommunikation
REST-APIs folgen einem zustandslosen Muster. Jede API-Anfrage ist unabhängig. Der Server merkt sich nicht, was beim vorherigen Aufruf passiert ist. Der Kontext muss bei jeder Anfrage manuell übergeben werden.
Das Model Context Protocol bewahrt den Status über mehrere Interaktionen hinweg, einschließlich des Konversationsverlaufs und früherer Tool-Ergebnisse. Ein KI-Agent, der einen klinischen Arbeitsablauf überprüft, kann eine Patientenakte abfragen, Laborergebnisse prüfen und Terminkonflikte überprüfen, ohne dabei den Zusammenhang zwischen den einzelnen Schritten aus den Augen zu verlieren.
Dynamische Erkennung vs. statische Endpunkte
Das ist der entscheidende Unterschied. Bei herkömmlichen APIs muss der Aufrufer jeden Endpunkt im Voraus kennen. Jemand liest die Dokumentation, schreibt den Code und programmiert die Integration fest ein. Wenn sich die API ändert, funktioniert der Code nicht mehr, bis ihn jemand aktualisiert.
MCP-Server beschreiben sich zur Laufzeit selbst. Der KI-Agent sendet eine Abfrage und erhält eine strukturierte Liste aller verfügbaren Tools: Namen, Beschreibungen, Eingabeschemata, Ausgabeformate. Es sind keine Vorkenntnisse erforderlich. Kein benutzerdefinierter Code pro Tool.
Don stellt dies als langfristigen Vorteil dar:
"For your very first project, it's not going to make that much sense. Du erstellst gerade deine erste agentische Schleife. Du fügst drei Werkzeuge hinzu und schließt sie an. Und das wird dein Leben tatsächlich erschweren. Aber stellen Sie sich das einmal in ein paar Jahren vor: – – dann haben Sie vielleicht 25, 75 oder 100 verschiedene Tools. „Und wenn Sie einen neuen agentenbasierten Workflow erstellen müssen, können Sie auf all diese Tools zurückgreifen, da sie alle auf dieselbe Weise geschrieben sind.“
Die dynamische Erkennung ist es, die diese Skalierbarkeit ermöglicht. Das 50. Werkzeug ist für die KI genauso einfach zu bedienen wie das 5.
Für wen sie gedacht sind
APIs sind für Entwickler und Softwaresysteme konzipiert, die sicher Netzwerkaufrufe tätigen, vertrauliche Daten speichern und Fehler behandeln können. Der Aufrufer hat die volle Kontrolle darüber, was geschieht.
MCP wurde speziell für KI-Modelle und große Sprachmodelle entwickelt. Es handelt sich hierbei um intelligente, aber nicht vertrauenswürdige Systeme, die mit natürlicher Sprache arbeiten, jedoch keine API-Schlüssel speichern, keinen beliebigen Code ausführen und keine eigenständigen Netzwerkanfragen stellen können. Das Model Context Protocol bietet diesen Modellen eine strukturierte und geregelte Möglichkeit, auf die Welt einzuwirken.
Sicherheit und Unternehmensführung
Bei APIs wird die Sicherheit auf Endpunkt-Ebene durch Authentifizierungstoken, API-Schlüssel, OAuth-Abläufe und Ratenbegrenzungen gewährleistet. Jede Integration verwaltet ihre eigenen Anmeldedaten.
MCP fügt eine Governance-Ebene über den einzelnen APIs hinzu. Der MCP-Server steuert, welche Funktionen für KI-Systeme verfügbar sind, welche Eingaben zulässig sind und welche Protokollierung erfolgt. Der KI-Agent hat niemals Zugriff auf die ursprünglichen Anmeldedaten.
In regulierten Umgebungen ist diese Trennung von großem Wert. Es reduziert die Zunahme von Anmeldedaten, vereinfacht die Überprüfung und sorgt dafür, dass KI-Systeme innerhalb klar definierter Betriebsgrenzen bleiben.
Die FHIR-Analogie – Warum Teams im Gesundheitswesen MCP sofort verstehen
IT-Teams im Gesundheitswesen haben einen solchen Standardisierungswandel bereits durchlebt.
Don zieht direkt eine Parallele: "In our industry, you might think of this a little bit like a FHIR server. Ein FHIR-Server ist im Grunde nichts anderes als ein REST-Server, allerdings gibt es eine bestimmte Vorgehensweise, wie man Patienteninformationen abfragen und aktualisieren kann. Die Rückmeldungen haben ein bestimmtes Format, mit dem du gut umgehen kannst. Es handelt sich also um eine standardisierte Methode, mit der über Gesundheitsdaten gesprochen werden kann. „Und MCP funktioniert ähnlich: Es handelt sich um eine standardisierte Methode, mit der auf Werkzeuge verwiesen wird und die zu Ergebnissen führt.“
Die Parallele ist eindeutig:
- FHIR hat die Gesundheitssysteme Systeme klinische Daten austauschen. Vor der Einführung von FHIR hatte jede elektronische Patientenakte ihr eigenes proprietäres Datenformat, ihre eigenen API-Konventionen und ihre eigenen Integrationsanforderungen. FHIR hat REST um eine standardisierte Ebene erweitert, sodass jedes System Patientendaten in einem einheitlichen Format austauschen kann.
MCP standardisiert die Art und Weise, wie KI-Agenten Werkzeuge finden und nutzen. Vor der Einführung von MCP war für jede KI-Integration individueller Code für jeden externen Dienst erforderlich. MCP fügt eine standardisierte Ebene über die bestehenden APIs hinzu, sodass jeder KI-Agent über ein einheitliches Protokoll mit jedem Tool interagieren kann.
Sowohl FHIR als auch MCP bauen auf der bestehenden Infrastruktur auf. Keines von beiden ersetzt das, was vorher war. Beide sorgen dafür, dass die zugrunde liegenden Systeme auf eine Weise miteinander kompatibel sind, deren Vorteile sich im Laufe der Zeit vervielfachen.
Für Organisationen, die bereits FHIR-basierte Interoperabilität über Plattformen wie InterSystems HealthShare nutzen, wird das MCP-Muster vertraut sein. Für beides gilt derselbe architektonische Grundsatz: Die Schnittstelle soll standardisiert werden, während die Implementierungen im Hintergrund variieren dürfen.
Ersetzt MCP die APIs?
Nein. Die meisten MCP-Server sind Wrapper für bereits vorhandene APIs.
Ein MCP-Server, der das Tool „schedule_appointment“ bereitstellt, könnte im Hintergrund die REST-API eines Krankenhauses aufrufen. Ein MCP-Server zur Problemverfolgung könnte Tool-Aufrufe in Jira-API-Anfragen umsetzen. Ein MCP-Server für klinische Daten könnte im Hintergrund einen FHIR-Endpunkt abfragen. Die APIs von „
“ bilden weiterhin die Ausführungsebene, also den eigentlichen Mechanismus, der den Vorgang ausführt. MCP wird zur Schnittstellenschicht für KI: die standardisierte Methode, mit der ein Agent diese Operationen erkennt und aufruft.
Don beschreibt die Tools hinter den MCP-Servern als „einfach APIs wie ‚einen Termin vereinbaren‘“. Es könnte sich um Datenbanken handeln, auf die Sie zugreifen und in die Sie Daten schreiben müssen. Das können Internetquellen oder Websites sein. „Möglicherweise erhalten Sie einige Informationen aus internen Dokumenten, einer PDF-Datei oder ähnlichen Quellen.“
MCP und APIs sind sich ergänzende Schichten im KI-Stack und keine konkurrierenden Technologien.
Wann sollte man MCP verwenden und wann eine API?
Die Wahl hängt davon ab, wer (oder was) den Aufruf ausführt und wie dynamisch der Arbeitsablauf sein muss.
Verwenden Sie APIs direkt, wenn:
- Der Arbeitsablauf ist vordefiniert, stabil und wird sich voraussichtlich nicht ändern.
- Die Leistung ist entscheidend (jede zusätzliche Ebene verursacht eine gewisse Latenz)
- Es sind keine KI-Agenten beteiligt, es handelt sich um eine Kommunikation von System zu System.
- Sie rufen Daten aus einer vorab gespeicherten Quelle wie einem Data Warehouse ab
Verwenden Sie MCP, wenn:
- KI-Agenten und KI-Anwendungen müssen Aktionen über mehrere externe Dienste hinweg koordinieren
- Arbeitsabläufe ändern sich häufig aufgrund von Vorschriften, internen Prozessen oder technologischen Neuerungen
- Sie benötigen eine dynamische Erkennung, d. h., die KI sollte sich an neue Tools anpassen können, ohne dass dafür eigener Code geschrieben werden muss.
- Rapid Prototyping ist wichtig. Mit MCP können Teams KI-Agenten schnell mit neuen Datenquellen und Tools verbinden, ohne für jede einzelne davon eigene Integrationen entwickeln zu müssen.
- Sicherheits-Governance ist wichtig. Sie möchten steuern, auf welche Daten die KI zugreifen kann, ohne die API-Endpunkte in ihrer Rohform offenzulegen
Verwenden Sie beide zusammen (die gängigste Vorgehensweise):
Die meisten ausgereiften Architekturen kombinieren direkte APIs für stabile Backend-Integrationen und MCP-Server für KI-orientierte Arbeitsabläufe. Die APIs übernehmen die Arbeit. Die MCP-Server machen diese Daten für KI-Agenten auf kontrollierte und standardisierte Weise zugänglich.
Bei diesem mehrschichtigen Ansatz zeigen Interoperabilitätsplattformen im Gesundheitswesen, was sie können. Die gleiche Infrastruktur, die Daten aus unterschiedlichen Systemen miteinander abstimmt, kann auch die MCP-Server betreiben, auf die sich KI-Agenten stützen. Dadurch werden bestehende Integrationen zu KI-fähigen Funktionen, ohne dass sie von Grund auf neu entwickelt werden müssen.
Warum MCP für das Gesundheitswesen im Unternehmensbereich wichtig ist
Der Nutzen von MCP wird beim ersten Projekt noch nicht sofort deutlich. In großem Maßstab lässt sich das nicht mehr leugnen.
Das langfristige Ziel – Von 3 Tools auf 100
Ein erster agentischer Arbeitsablauf könnte drei Tools miteinander verbinden: eine EHR-Abfrage, eine Terminprüfung und ein Benachrichtigungssystem. Das Schreiben von benutzerdefiniertem Integrationscode für drei Tools ist unkompliziert.
Doch in Einrichtungen des Gesundheitswesens wird sich die Anzahl der Tools schnell erhöhen. Fügen Sie Abrechnungsprüfung, Versicherungsberechtigung, Apothekensysteme, Laboraufträge, klinische Entscheidungsunterstützung, Bildgebung, Patientenkommunikation und Revenue-Cycle-Management hinzu.
Jedes neue Tool, das dem MCP-Standard entspricht, lässt sich genauso einfach integrieren wie das vorherige, da alle das gleiche Protokoll verwenden.
„Sie können auf all diese Tools zurückgreifen, da sie alle auf die gleiche Weise programmiert sind.“ „Die reden alle auf dieselbe Art und Weise“, erklärt Don.
Dynamik im Anbieter-Ökosystem
Die Einführung von MCP schreitet über die Early Adopters hinaus immer schneller voran. " Wenn Sie Salesforce als CRM nutzen oder Jira als Issue-Tracking-System nutzen, sind diese auf den MCP-Servern bereits vorinstalliert," Don notes. "Your vendor-supplied system that you use will start to be shipped with MCP servers, allowing you to take those systems and plug them into your agentic workflows."
Anbieter im Gesundheitswesen werden denselben Weg einschlagen. EHR-Plattformen, Systeme für die Bevölkerungsgesundheit, Tools für den Umsatzzyklus und klinische Analysedienste werden MCP-Server bereitstellen. Dadurch lassen sie sich problemlos in agentenbasierte Workflows integrieren, ohne dass für jeden einzelnen ein eigener Integrationscode geschrieben werden muss.
InterSystems IRIS kann beispielsweise als Backend für MCP-Server dienen, die klinische Workflows, Patientenabfragen oder Analysen in der vom Entwicklungsteam bevorzugten Sprache bereitstellen. Da zwischen dem MCP-Client und der zugrunde liegenden Technologie eine unabhängige Beziehung besteht, werden die heute entwickelten Tools auch bei einer Weiterentwicklung des Stacks weiterhin funktionieren.
Dieses Muster lässt sich über interne Systeme hinaus anwenden. Don verweist auf Context7, einen MCP-Server, der LLM-freundliche Dokumentationen zu verschiedenen Technologien bereitstellt und somit ein Beispiel für MCP-Ressourcen im Internet-Maßstab darstellt.
Das Pendant im Gesundheitswesen könnten Datenbanken zu Arzneimittelwechselwirkungen, klinische Leitlinien oder Daten aus Arzneimittellisten sein, die als MCP-kompatible Tools bereitgestellt werden und von jedem KI-Agenten gefunden und genutzt werden können. Das Protokoll ermöglicht die schnelle Entwicklung von KI-basierten Workflows, die große Sprachmodelle mit realen klinischen Datenquellen verbinden, ohne dass für jede Integration eigener Code geschrieben werden muss.
Häufig gestellte Fragen
Fazit
APIs bilden die Ausführungsebene. MCP ist die KI-native Schnittstellenschicht. Sie arbeiten zusammen.
Für Teams im Gesundheitswesen ist die beste Parallele der Übergang von proprietären Datenformaten zu FHIR. Organisationen, die FHIR frühzeitig eingeführt haben, haben damit nicht nur ein Interoperabilitätsproblem gelöst. Sie schufen eine Grundlage, deren Wert sich mit der Inbetriebnahme weiterer Systeme vervielfachte. MCP ist dasselbe Muster, nur auf die KI-Integration angewendet.
Der Mehrwert liegt nicht in Ihrem ersten agentischen Projekt mit drei Tools. Es geht darum, was passiert, wenn man hundert Geräte hat, die alle dasselbe Protokoll verwenden. Unternehmen, die bereits jetzt Standards für die Interaktion ihrer KI-Agenten mit externen Systemen festlegen, werden einen strukturellen Vorteil haben, der mit jedem hinzugefügten Tool weiter zunimmt.
