KI-Modelle, insbesondere Sprachmodelle wie GPT von OpenAI oder Claude von Anthropic, werden immer besser. Sie verstehen zunehmend genauer, was wir von ihnen wollen, und liefern auch immer bessere Antworten. Sie sind damit extrem leistungsfähig. Anzeige the next big thing – Golo Roden Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss. Trotzdem gibt es eine Sache, die sie nicht beherrschen, nicht einmal im Ansatz: Sie können von sich aus keine Aktionen ausführen und sind nicht eigenständig lebensfähig. Das bedeutet, dass ein Sprachmodell nicht in der Lage ist, von sich aus auf externe Tools, Datenbanken, Server, APIs oder Ähnliches zuzugreifen. Genau dafür gibt es nun eine offene und standardisierte Lösung: das Model Context Protocol, kurz MCP. Im heutigen Beitrag erkläre ich, was dieses Protokoll genau ist, was es leistet und für wen es interessant sein könnte. Was ein KI-Modell wirklich ist Zum besseren Verständnis müssen wir uns zunächst einen Überblick über die Ausgangslage verschaffen. Wichtig ist zu verstehen, was ein KI-Modell von seiner Natur her ist. Viele Menschen glauben, dass beispielsweise ChatGPT selbst ein KI-Modell sei. Das ist jedoch nicht korrekt. ChatGPT ist vielmehr eine Anwendung, die um ein KI-Modell herum entwickelt wurde. Das eigentliche Modell, auf dem das Ganze basiert, gibt es in verschiedenen Ausprägungen, etwa GPT-4o, GPT-4.5, o3 oder o4-mini. Diese Modelle sind der eigentliche Kern von ChatGPT. Was diese Modelle tatsächlich sind, ist nichts anderes als eine mathematische Funktion – allerdings eine extrem komplexe. Die Sprachverarbeitung funktioniert ausschließlich, weil Sprache in Zahlen codiert wird, mit diesen Zahlen auf geschickte Weise gerechnet wird, und das Ergebnis anschließend wieder in Sprache zurückübersetzt werden kann. Im Kern handelt es sich also einfach um eine hochkomplexe mathematische Funktion, die zufällig besonders gut geeignet ist, Vorhersagen auf Sprache zu berechnen. Trotzdem bleibt es eine Funktion, ohne Verständnis für die Inhalte. Warum KI-Modelle Unterstützung brauchen Anzeige Daraus ergibt sich auch, warum KI-Modelle nicht eigenständig auf Datenbanken, Server oder APIs zugreifen können. Mathematische Funktionen sind dazu nicht in der Lage, unabhängig von ihrer Komplexität. Genauso wenig wie eine einfache Funktion f(x) = x² eine API ansteuern könnte, können es auch KI-Modelle wie GPT-4o nicht. Es braucht jemanden, der die Nutzung dieser Funktion ermöglicht. Bei GPT-4o ist das die Anwendung ChatGPT. Man könnte also sagen: Das eigentliche KI-Modell ist das Gehirn, dem der restliche Körper fehlt. Empfohlener redaktioneller Inhalt Mit Ihrer Zustimmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen. YouTube-Video immer laden YouTube-Video jetzt laden Mächtigere KI mit dem Model Context Protocol (MCP) // deutsch Man könnte meinen, dass diese Darstellung nicht stimmen könne, da ChatGPT sehr wohl in der Lage sei, auf externe Dienste und das Internet zuzugreifen. Das ist korrekt, erfolgt jedoch nicht durch das Modell selbst, sondern über eine Funktionalität der Anwendung, die davor geschaltet ist. Bei OpenAI heißt dieses Feature "Function Calling". Es funktioniert, sehr vereinfacht gesagt, so, dass der Prompt um den Hinweis erweitert wird: "Wenn Du zur Beantwortung noch zusätzliche Informationen brauchst, kannst Du Bescheid sagen." Daraufhin könnte das Modell anmerken, es benötige eine Internetrecherche, und OpenAI übernimmt diese Suche außerhalb des Modells. Die Ergebnisse werden anschließend erneut als Eingabe in das Modell gegeben. Der eigentliche Zugriff erfolgt also durch die Anwendung, nicht durch das Modell selbst. Die Einschränkung proprietärer Lösungen Der Haken an Function Calling ist, dass es rein proprietär funktioniert. Es ist ausschließlich innerhalb der OpenAI-Umgebung nutzbar und kann nicht auf andere Plattformen oder Modelle übertragen werden. Damit bleibt diese Möglichkeit an einen Anbieter gebunden. Hier setzt das Model Context Protocol (MCP) an. Es bietet einen einheitlichen Weg, externe Tools und Dienste an KI-Modelle anzubinden. Es handelt sich im Prinzip um das Gleiche wie Function Calling, nur als offene und standardisierte Variante, die von jedem Anbieter implementiert werden kann. Entwickelt wurde MCP von Anthropic, dem Unternehmen hinter Claude. Offene Standards sind grundsätzlich positiv zu bewerten, und insofern ist MCP eine sehr begrüßenswerte Entwicklung. Die drei Rollen im MCP Beschäftigt man sich näher mit MCP, fallen sofort drei zentrale Rollen auf: das Modell, der MCP-Server und der Host. Persönlich finde ich die Begriffe etwas unglücklich gewählt, da insbesondere die Abgrenzung zwischen Host und MCP-Server anfangs verwirrend sein kann. Deshalb möchte ich diese drei Rollen zunächst klar erläutern. Das Modell ist die einfachste Rolle: Es handelt sich um ein KI- beziehungsweise Sprachmodell wie GPT-4o, GPT-4.5, o3, o4-mini, Claude, LLaMa oder DeepSeek R1, also ein neuronales Netz, das Vorhersagen berechnen kann. Demgegenüber steht der MCP-Server. Er ist ein Dienst, der Funktionen oder Daten zur Verfügung stellt – etwa E-Mails versenden, Datenbanken abfragen, eine Webcam steuern oder im Internet suchen. Kurz: jede Art von Funktionalität oder Datenbereitstellung. Die entscheidende Frage ist, wie man Modell und MCP-Server miteinander verbindet, da die Modelle nicht selbstständig auf solche Dienste zugreifen können. Hier kommt der Host ins Spiel. Der Host integriert das Modell und führt es aus. Gleichzeitig fungiert er als Client gegenüber den externen MCP-Servern. Im Sprachgebrauch von MCP wird der Host daher auch als MCP-Client bezeichnet, was die Begriffswahl zusätzlich erschwert. Wichtig ist: Der Host bleibt in Bezug auf die Integration des Modells unverändert. Wer bisher eine Anwendung hatte, die ein Sprachmodell gehostet hat, hat diesen Teil von MCP bereits erledigt. Spannend wird es erst in Bezug auf die Kommunikation zwischen Host und externen MCP-Servern. Damit eine solche Kommunikation stattfinden kann, muss ein MCP-Server dem Host zunächst bekannt gemacht werden. Dies erfolgt durch die Anwenderin oder den Anwender. Beispielsweise könnte ein Texteditor oder eine IDE, die ein Sprachmodell betreibt, eine Funktion anbieten, um einen neuen MCP-Server zu registrieren. Dabei wird die URL des Servers angegeben. Manifest und Serverregistrierung Der Texteditor oder die IDE lädt daraufhin vom MCP-Server die Datei manifest.json herunter. Diese Datei beschreibt auf standardisierte Weise, welche Fähigkeiten und Daten der MCP-Server anbietet, wie man sie aufruft, welche Rückgabewerte es gibt, wie die Parameter aussehen und so weiter. Oft enthält sie auch Vorlagen für Prompts, die der Host intern verwenden kann. Damit weiß der Host, welche Möglichkeiten der Server bietet. Wenn der Host nun eine Anfrage an das Modell stellt, erweitert er den Prompt um Informationen über die verfügbaren Tools der registrierten MCP-Server. Das Modell selbst muss dafür nicht speziell vorbereitet werden. Es erhält einfach zusätzliche Kontextinformationen. Damit kann das Modell, falls es dies für sinnvoll hält, eine Rückfrage an den Host senden, mit der Bitte, auf einen externen Dienst zuzugreifen. Der Host führt diese Aktion aus, erhält die Antwort vom MCP-Server und gibt sie wiederum an das Modell zurück. Dieser Dialog kann mehrmals hin und her gehen, bis schließlich die finale Antwort vorliegt. MCP als universelle Lösung Das Model Context Protocol definiert im Wesentlichen den offenen und standardisierten Austausch zwischen Host und MCP-Server, nicht zwischen Host und Modell. Dadurch entsteht eine Art Plug-in-Ansatz für KI-Modelle. Diese Plug-ins können beliebige Funktionen oder Daten bereitstellen. Damit werden KI-Modelle erheblich flexibler und leistungsfähiger, da sie nicht mehr nur auf ihr antrainiertes Wissen beschränkt sind, sondern auf externe Ressourcen zugreifen können – vorausgesetzt, diese unterstützen MCP. Ich gehe davon aus, dass viele Serverprodukte künftig MCP als weiteres unterstütztes Protokoll anbieten werden. Das ist eine spannende Perspektive. Vergleicht man MCP mit OpenAI Function Calling oder Claude Tools von Anthropic, zeigt sich: MCP bietet dieselbe Funktionalität, jedoch offen und herstellerunabhängig. Es funktioniert nicht nur für GPT-Modelle oder Claude, sondern theoretisch für alle KI-Modelle und alle Dienste, die MCP unterstützen. Ein offener Blick in die Zukunft Für Anbieterinnen und Anbieter bedeutet das, dass Integrationen künftig erheblich einfacher werden. Es reicht, MCP einmal zu implementieren, statt individuelle Anbindungen für jede Plattform zu entwickeln. Das beschleunigt das Wachstum des gesamten KI-Ökosystems und könnte der Startpunkt für eine universelle, modulare KI-Arbeitsumgebung sein. (rme)