MCP erklärt: So funktioniert das Model Context Protocol

LLMs können schon seit einiger Zeit Tools aufrufen, aber Model Context Protocol (MCP) bietet dafür einen strukturierten, standardisierten Weg.

Trotzdem ist noch immer unklar, was MCP eigentlich ist.

Viele gehen davon aus, dass MCP eine App, eine API oder ein Tool ist, aber es ist nichts davon. Es ist ein Protokoll, und das bedeutet etwas sehr Konkretes.

Schauen wir es uns genauer an.

Wenn du nur sehen möchtest, was MCP in der Praxis ermöglicht, sieh dir dieses kurze Video an:

Was ist ein Protokoll?

Ein Protokoll ist einfach ein Regelwerk, das definiert, wie zwei oder mehr Systeme miteinander kommunizieren.

Für sich allein tut es nichts. Es definiert nur die Struktur und Erwartungen einer Unterhaltung zwischen zwei Entitäten. Stell es dir als eine gemeinsame Sprache mit strengen Grammatikregeln vor, an die sich Computer halten, um Informationen auszutauschen.

Postsysteme funktionieren ähnlich. Alle Postämter in einem bestimmten Land folgen einem standardisierten Adressformat, um Briefe zuzustellen.

Oder stell es dir wie USB-C für AI-Tools vor. Vor zwanzig Jahren war der Markt voll mit unterschiedlichen Arten von Lade- und Datenkabeln. Ähnlich gab es in AI-Ökosystemen mehrere Wege, Tools an Sprachmodelle zu übergeben. Frameworks wie LangChain, Haystack und Pydantic AI haben alle ihre eigenen Formate für die Integration von Tools definiert. Wenn ein Entwickler also ein Toolset für Google Maps schreiben wollte, musste er das für jede spezifische Technologie tun.

Um das konkreter zu machen, schauen wir uns das bekannteste Protokoll an, HTTP (Hypertext Transfer Protocol), das Websites antreibt. HTTP definiert unter anderem, wie ein Browser (Client) eine Webseite von einem Webserver anfordert und wie der Server antworten soll.

Hier ist ein Beispiel für einen HTTP-Request-Response-Zyklus:

1. Browser stellt eine HTTP-Anfrage

Wenn du https://example.com in deinen Browser eingibst, sendet der Browser eine strukturierte HTTP-Anfrage an den Webserver:

Hier sind die HTTP-Parameter und -Werte, die in unserem Beispiel verwendet werden:

"GET" – Das ist die Aktion (Anforderung einer Webseite).
"/index.html" – Die konkret angeforderte Webseite.
"HTTP/1.1" – Die verwendete Version des Protokolls.
"Host: example.com" – Der Domainname der Website.
"User-Agent: Mozilla/5.0" – Informationen über den Browser, der die Anfrage stellt.

Der Webserver weiß, wie er diese Anfrage interpretieren muss, weil HTTP dieses Format standardisiert. Er versteht diese „Sprache“.

2. Server antwortet mit dem HTTP-Protokoll

Der Server verarbeitet die Anfrage und sendet eine strukturierte HTTP-Antwort zurück:

"HTTP/1.1 200 OK" – Der Antwortcode (200 bedeutet Erfolg).
"Content-Type: text/html" – Der Typ des zurückgesendeten Inhalts.
"Content-Length: 512" – Die Größe der Antwort.
HTML-Inhalt – Der eigentliche Webseiteninhalt (es gibt nur eine Überschrift „Welcome to Example.com“)

Wichtig: HTTP selbst speichert keine Webseiten und zeigt sie auch nicht an. Es definiert nur die Regeln, nach denen Webbrowser und Webserver kommunizieren dürfen. Jedes System, das diese Regeln befolgt, kann über das durch HTTP definierte Internet kommunizieren.

Wie MCP als Protokoll funktioniert

Wenden wir dieselbe Denkweise nun auf MCP (Model Context Protocol) an.

MCP ist ein Protokoll, mit dem AI Agents mit externen Tools und Datenquellen kommunizieren. Wie HTTP speichert es keine Daten und führt selbst keine Aufgaben aus. Es definiert lediglich einen standardisierten Weg, über den KI Informationen von Tools anfordern und abrufen kann.

Was sind diese „Tools“?

Im Kontext von LLMs sind Tools externe Systeme, APIs oder Dienste, mit denen KI interagieren kann, um ihre Fähigkeiten über reine Textgenerierung hinaus zu erweitern. Sie ermöglichen AI Agents, Echtzeitdaten abzurufen, Termine zu buchen oder deinen Freunden Nachrichten zu schreiben, wodurch sie für reale Anforderungen deutlich nützlicher werden.

Angenommen, du fragst einen AI Agent:

„Wie spät ist es gerade in London?“

Da die KI selbst die richtige Antwort nicht kennt, weil AI-Modelle ein Knowledge-Cutoff-Datum haben (Oktober 2023 für die Modelle von OpenAI), muss sie Live-Daten von einem Zeitdienst abrufen. Statt HTTP zu verwenden, um eine Webseite anzufordern, nutzt die KI MCP, um Zeitdaten anzufordern.

Das passiert dabei:

1. AI Agent stellt eine MCP-Anfrage an den Zeitdienst (Beispiel)

"method": "tools.call" → Die KI ruft ein externes Tool auf.
"tool": "get_time" → Der Name des Tools, das sie verwenden möchte.
"args": { "location": "London" } → Die konkreten Eingabeparameter.

Wie bei HTTP folgt diese Anfrage einem strengen Format, sodass jedes MCP-kompatible Tool genau weiß, wie es sie interpretieren muss.

2. MCP-Zeitserver antwortet

Das externe Tool (Zeitserver) folgt den Antwortregeln von MCP und sendet zurück:

"status": "success" → Bestätigt, dass die Anfrage korrekt verarbeitet wurde.
"result" → Enthält die eigentlichen Zeitdaten.

Jetzt kann der AI Agent diese Daten nehmen und daraus eine tatsächliche Antwort an den Nutzer formulieren:

„Die aktuelle Uhrzeit in London ist 12:20 PM (GMT).“

Zusammengefasst, um Missverständnisse auszuräumen:

„MCP ist eine App.“ → Nein, MCP ist ein Regelwerk. Du brauchst AI-Software und Tools, die MCP implementieren, um es tatsächlich zu verwenden, genau wie die Instagram-App aktive Instagram-Server braucht, die auf HTTP-Anfragen antworten und Daten liefern.

„MCP ist eine Datenbank.“ → Nein, MCP speichert keine Daten. Es hilft AI Agents, mit Datenbanken oder APIs zu kommunizieren.

„MCP ist wie eine API.“ → Nicht genau. Eine API ist ein konkreter Weg, mit einem System zu interagieren, während ein Protokoll (wie MCP oder HTTP) einen universellen Weg definiert, über den viele verschiedene Systeme kommunizieren können. MCP ist eine Sprache, die ein AI-System verwenden kann, um mit vielen tatsächlichen APIs zu interagieren (Zeit, Datenbanken, Stripe, Slack usw.).

Warum MCP interessant ist

Nachdem wir nun wissen, dass MCP ein standardisierter Weg ist, über den AI-Software mit externen Tools und Apps interagiert, und dass MCP keine API ist, sehen wir uns an, warum die Community der AI-Entwickler (uns eingeschlossen) davon begeistert war.

Da MCP keine API ist, sondern AI-Apps ermöglicht, mit tatsächlichen APIs im großen Maßstab zu interagieren, hilft es Projekten, die viele externe Systeme anbinden müssen, schneller zu starten. Tools geben einem Modell außerdem Reichweite, und was beim OpenAI-Hugging-Face-Vorfall passiert ist, zeigt, wie diese Reichweite aussieht, wenn sie über die Aufgabe hinausgeht. Dafür mussten Entwickler manchmal einen vollständigen Entwicklungszyklus für API-Integrationen durchlaufen. Heute verwenden sie jedoch meist vorhandene Bibliotheken oder Open-Source-Projekte (zum Beispiel auf GitHub), die die benötigte Funktionalität bereitstellen.

Diese Bibliotheken beschleunigen den Entwicklungsstart, aber sie sauber in dein System zu integrieren (wenn es nicht mit der Implementierung kompatibel ist, die du auf GitHub gefunden hast), erfordert weiterhin Aufwand, damit das Tool mit der KI funktioniert.

Mit MCP kann das Hinzufügen einer neuen Integration (zum Beispiel Google Drive) nach Einrichtung des Frameworks darin bestehen, sich mit ein paar Codezeilen mit dem Google Drive MCP-Server zu verbinden. Du wirst keine Kompatibilitätsprobleme haben, weil beide Seiten dasselbe Protokoll verwenden: MCP.

Vergleichen wir beide Ansätze, um die Unterschiede klarer zu sehen.

Standardintegration vs. Nutzung des Model Context Protocol (MCP)

Um diesen Vergleich konkret zu machen, gehen wir durch, wie Google-Drive-Dateizugriff zu einem AI Agent hinzugefügt wird, zuerst manuell und dann mit einem MCP-kompatiblen Tool.

Standardintegration

1. Bibliothek finden und anpassen: Du suchst nach einem Google Drive API-Client oder Open-Source-Projekt. Google stellt Client-Bibliotheken bereit (z. B. Google Drive API for Python). Du bindest sie in dein Projekt ein. Du musst trotzdem sicherstellen, dass sie in der Umgebung deiner KI funktioniert.

2. Logik implementieren: Du schreibst Funktionen, zum Beispiel um Dateien zu suchen oder ein Dokument aus Drive abzurufen. Wenn die KI etwas benötigt, muss sie diese Funktionen aufrufen. Du formatierst die Anfrage der KI in Google-Drive-spezifische API-Aufrufe. Nachdem du eine Antwort von Google erhalten hast, extrahierst du den Inhalt, um ihn an den Kontext der KI zurückzugeben.

3. Fehler und Randfälle behandeln: Du fügst Code hinzu, um Fälle wie „Datei nicht gefunden“, Berechtigungsfehler oder API-Rate-Limits zu behandeln. Wenn die Google-API einen Fehler zurückgibt, fängst du ihn ab und antwortest vielleicht mit einer entschuldigenden Nachricht oder bittest die KI um eine Umformulierung. Außerdem musst du verhindern, dass deine KI zu viele Anfragen zu schnell sendet.

4. Warten: Wenn Google im Laufe der Zeit die API oder Bibliothek aktualisiert, musst du deinen Code aktualisieren. Wenn du einen Fehler in der Bibliothek findest, musst du sie möglicherweise patchen oder eine andere Quelle finden. Im Grunde wirst du zum Maintainer dieser Google-Drive-Integration innerhalb deiner AI-Anwendung.

Dieser Prozess gilt auch für andere Tools: Du möchtest Slack oder eine Datenbank zu deiner KI hinzufügen? Dann musst du den gesamten Prozess für jedes Tool wiederholen.

MCP-Integration

Sehen wir uns nun an, wie dieser Prozess mit MCP aussehen würde.

Zunächst definieren wir die wichtigsten Konzepte:

Client – eine AI-Anwendung (ChatGPT, Claude app, Quickchat AI), die eine Verbindung zu einem oder mehreren Servern herstellt und Informationen oder Aktionen anfordert, um von einem Nutzer angeforderte Aufgaben auszuführen.

Server – Jeder Server kann sich mit etwas wie einer Datenbank oder einer API (Google Drive) verbinden und eine Reihe von „Tools“ oder Daten definieren, die er bereitstellen kann. In diesem Fall ist der Server ein Programm, das diese Tools und Fähigkeiten dem Client (AI-App) zugänglich macht.

Entwickler können, je nachdem, was sie tun möchten, auf beiden Seiten arbeiten: einen Server bauen, um Daten bereitzustellen, oder einen AI-Client bauen, der mit beliebigen Servern kommunizieren kann. Die meisten wollen die zweite Option, aber beginnen wir trotzdem mit der Serverseite, um Schritt für Schritt zu verstehen, wie MCP funktioniert:

• Initialisieren eines MCP-Servers. Ein Entwickler oder Systemadministrator richtet einen MCP-Server für ein bestimmtes Tool oder eine bestimmte Datenquelle ein. Ein MCP-Server ist normalerweise nur ein kleines Programm, das die MCP-Spezifikation implementiert. Zum Beispiel gibt es einen vorgefertigten Google Drive MCP-Server, der Dokumente suchen und abrufen kann.

  Beim Initialisieren des Servers gibst du ihm Zugriff auf das Zielsystem (Google Drive). Der Server stellt dann eine Reihe von Tools bereit, die Aktionen oder Abfragen entsprechen, die er verarbeiten kann. Im Kern ist es ein API-Adapter, der auf der einen Seite MCP und auf der anderen Seite den nativen Dienst spricht.

  Sobald der Server läuft, wartet er auf Anfragen.

• Verbinden eines LLM (Client) mit einem MCP-Server. Als Nächstes muss die AI-Anwendung (die „Client“-Seite) eine Verbindung zu diesem Server herstellen. In der Praxis würdest du, wenn du eine AI-Plattform verwendest, die MCP unterstützt (wie Claude Desktop), sie mit der Adresse oder dem Befehl zum Starten des Servers konfigurieren. Sobald die Verbindung steht, baut der Client gemäß dem MCP-Handshake eine Sitzung mit dem Server auf. Wenn du die Oberfläche von Claude verwendest, würdest du sehen, dass Claude mit bestimmten MCP-Servern „verbunden“ ist (die UI zeigt möglicherweise verfügbare Connectors an).

So sieht es in der Claude UI aus

• Verfügbare Tools erkennen. Nachdem die Verbindung hergestellt wurde, besteht der erste Schritt darin, herauszufinden, was der Server anbietet (manchmal passiert das automatisch, nachdem du dich mit dem Server verbunden hast). Der MCP-Client sendet eine tools/list-Anfrage an den Server (das ist im Protokoll definiert). Der Server antwortet mit einer Liste seiner verfügbaren Tools, jeweils mit Details wie Name, Beschreibung und Eingabeschema.

  Zum Beispiel könnte ein Server antworten, dass die Tools create_file(path, content), read_file(path) und search_files(query) verfügbar sind. Der Client stellt diese Informationen dann dem LLM zur Verfügung. In vielen Implementierungen formatiert der Client diese Tool-Beschreibungen und nimmt sie in den Kontext des Modells auf (zum Beispiel durch Ergänzung des Systemprompts: „Du hast Zugriff auf die folgenden Tools… [Tool-Liste]“).

Hier ist ein AI-Systemprompt zusammen mit der Nachricht des Nutzers, in der die aktuelle Uhrzeit angefordert wird

Mit implementierten MCP-Tools ist ein Tool namens „get_current_time“ integriert, mit dem die KI auf eine externe Ressource zugreifen und die genaue Uhrzeit in London abrufen kann

Das bedeutet, dass du nicht alle potenziellen Aktionen, die deine AI-App möglicherweise benötigt, um eine Aufgabe abzuschließen, im Voraus durchdenken und einprogrammieren musst. Mit MCP kann die KI alle möglichen Aktionen zur Laufzeit entdecken, indem sie einen MCP-Server fragt, und das auswählen, was benötigt wird.

• Ein Tool über MCP verwenden. Wenn die KI eine Aktion ausführen oder Daten abrufen muss, ruft sie ein Tool über MCP auf. Aus Sicht der KI (insbesondere bei Modellen wie Claude, die Tool-Nutzung nativ unterstützen) entscheidet sie in ihrer Schlussfolgerung: „Ich sollte Tool X mit diesen Parametern aufrufen.“ Der MCP-Client erfasst diese Absicht und sendet eine tools/call-Anfrage im MCP-Format an den entsprechenden Server (Google Drive MCP-Server).

• Der MCP-Server fungiert als Brücke. Er empfängt eine strukturierte, MCP-konforme Anfrage vom AI Agent, ordnet sie dem richtigen Google Drive API-Endpunkt zu, schreibt die Anfrage in einen tatsächlichen Google Drive API-Aufruf um, führt die Anfrage aus, verarbeitet die Antwort und formatiert sie erneut in eine MCP-konforme Antwort, bevor er sie an den AI Agent zurücksendet.

  Erwähnenswert ist, dass MCP-Server einem strukturierten Ansatz zur Fehlerbehandlung folgen, sodass AI Agents Fehler effektiv interpretieren und darauf reagieren können.

  Angenommen, ein AI Agent verwendet ein MCP-Tool, um eine Datei in Google Drive zu finden. Wenn die Anfrage eine ungültige Datei-ID enthält (z. B. eine fünf Zeichen lange Zeichenkette statt des erwarteten Formats), gibt der MCP-Server eine Fehlermeldung zurück:

  Statt einfach fehlzuschlagen, kann der AI Agent diese strukturierte Antwort nehmen und sie in nutzerfreundliches Feedback umformulieren:

  „Es sieht so aus, als wäre die von dir angegebene Datei-ID zu kurz. Google-Drive-Datei-IDs sind normalerweise 28 Zeichen lang. Könntest du sie bitte noch einmal prüfen und es erneut versuchen?“

  Dieser Ansatz stellt sicher, dass Fehler nicht in Sackgassen führen, sondern zu Gelegenheiten werden, bei denen der AI Agent den Nutzer zu einer erfolgreichen Lösung führen kann.

• Die Frage oder Anfrage des Nutzers beantworten. Sobald der MCP-Server ein Ergebnis zurückgibt, übergibt der MCP-Client diese Daten zurück an die AI-App. Das Modell bezieht das Ergebnis dann in seine Schlussfolgerung ein oder direkt in die Ausgabe, die es für den Nutzer erzeugt.

  Wenn der Nutzer die Erstellung einer neuen Google Sheets-Datei anfordert, wird die Antwort des Servers (mit Datei-ID und generiertem Link) an das Modell übergeben. Das Modell antwortet dem Nutzer dann mit: „Gute Nachricht! Deine neue Google Sheets-Datei ist fertig. Du kannst sie hier öffnen: [link].“

Während dieses gesamten Prozesses behält die KI die Kontrolle über den Ablauf: Sie entscheidet, wann sie ein Tool aufruft und wie sie das Ergebnis für ihre Antwort verwendet. Gleichzeitig muss der Entwickler diese Schritte nicht manuell orchestrieren, das MCP-Framework und das AI-Modell übernehmen das. Das Endergebnis ist, dass der Nutzer der KI komplexe Fragen stellen oder Aufgaben geben kann, die externe Informationen oder Aktionen erfordern, und die KI diese über MCP autonom ausführen und ein Ergebnis zurückgeben kann.

Vorteile der Nutzung eines MCP

Beachte, wie dieser Ansatz viele Details abstrahiert: Der Client hat sich nicht um API-Schlüssel oder HTTP-Statuscodes gekümmert, diese werden vom MCP-Server behandelt.

Der zentrale Punkt ist die Einfachheit am Integrationspunkt: Wir „fragen“ nach Kunden und erhalten sie. Die Logik, wie sie abgerufen werden, ist an anderer Stelle gekapselt. Das bedeutet, dass ein Entwickler, der auf der AI-Seite arbeitet, keine neuen HTTP-Aufrufe für jede neue Aktion schreiben muss, er ruft Tools einfach per Namen auf. Die Hauptarbeit (Authentifizierung, Aufruf der Google-Drive-Endpunkte, Formatierung der Antwort) übernimmt der MCP-Server-Code, der wiederverwendbar und standardisiert ist.

Hier ist eine Zusammenfassung der wichtigsten Vorteile:

• Reduziert API-spezifischen Glue Code. Vor MCP erforderte es typischerweise viel „Glue“-Code, damit eine KI einen externen Dienst verwenden konnte: die API aufrufen, die Antwort in Text umwandeln, den das Modell verarbeiten kann, dann die Ausgabe des Modells parsen, um vielleicht eine weitere API aufzurufen usw. Mit MCP entfällt ein großer Teil dieses Glues. Der Client des Modells und der Server regeln den Datenaustausch strukturiert, sodass du andere Formate (wie JSON) nicht manuell in Text oder umgekehrt umwandeln musst, das Protokoll erledigt das. Du musst auch keine Logik schreiben, die entscheidet, wann was aufgerufen wird. Die KI (geführt durch die Tool-Beschreibungen und ihre eigene Schlussfolgerung oder den Prompt) übernimmt das.

• Wiederverwendbare, gemeinsame Connectors statt einmaliger API-Wrapper. Mit MCP schreibst du eine Integration einmal und kannst sie in vielen Projekten und AI-Systemen wiederverwenden. Du könntest zum Beispiel einen MCP-Server für das interne Wiki deines Unternehmens erstellen. Jede AI-App, die MCP unterstützt, kann sich mit diesem einen Server verbinden, um das Wiki abzufragen. Du musst „Wiki-Suche“ nicht für jeden neuen AI-Chatbot oder jeden anderen LLM-Anbieter neu implementieren. Diese Wiederverwendbarkeit ist ein Unterschied zur Vergangenheit, in der jedes Team möglicherweise eine eigene, leicht abweichende Integration für dieselbe API geschrieben hat. MCP fördert eine Bibliothek von Connectors, die gemeinsam genutzt und verbessert werden können.

• Plug-and-play-Integration mit unterschiedlichen LLMs. MCP ist modellunabhängig. Dem Protokoll ist egal, ob der Client Claude, GPT-4, DeepSeek oder ein zukünftiges Modell ist, solange der Client die MCP-Schnittstelle verarbeiten kann. Wenn du in Zukunft zu einem anderen Modell wechseln möchtest, kannst du das tun, ohne alle Integrationen neu zu schreiben.

• Einfachere Wartung. Da es ein offener Standard ist, wächst eine Community, die vorgefertigte Server (für Datenbanken, populäre APIs usw.) beiträgt, die du nutzen kannst, statt alles von Grund auf neu zu bauen. Wenn du weitere Systeme integrierst, hilft MCP, das „Spaghetti“-Problem vieler Punkt-zu-Punkt-Integrationen zu vermeiden. Außerdem musst du nicht alle API-Updates anderer Anbieter überwachen.

Werden API-Integrationen überflüssig?

Sowohl klassische API-Integrationen als auch MCP haben ihren Platz. Der beste Ansatz kann von der Art des Projekts, der Expertise des Teams und den langfristigen Zielen abhängen.

Wenn du nur ein oder zwei externe Dienste integrieren musst und die Interaktionen relativ einfach sind, ist eine direkte API-Integration oft die schnellste Lösung. Wenn deine Web-App beim Checkout nur ein Stripe-Zahlungstoken verifizieren muss, ist der direkte Aufruf der Stripe-API einfach und effektiv. MCP in diesem Szenario einzuführen, wäre möglicherweise überdimensioniert. Du kannst einen AI Agent mit jeder dokumentierten REST API verbinden, mit einer geprüften HTTP Action, oder eine One-Click-Integration wie Google Sheets zum Protokollieren von Leads und Demo-Anfragen verwenden, ohne einen MCP-Server zu betreiben.

In Fällen, in denen du sehr genaue Kontrolle über Request und Response benötigst (für Performance-Tuning, spezielle Datenverarbeitung oder proprietäre Protokolle), kann es besser sein, direkt gegen die API zu schreiben. Klassische Integrationen ermöglichen dir, alle erweiterten Funktionen einer API zu nutzen und die Aufrufe exakt anzupassen. Wenn eine API ungewöhnliche Anforderungen hat oder du jede Abstraktionsschicht vermeiden möchtest, um maximale Klarheit und Kontrolle zu behalten, ist der klassische Ansatz passend.

Ein konkretes Beispiel dafür, wie MCP-Tools einem produktiven AI Agent neben benutzerdefinierten API-Aktionen bereitgestellt werden, findest du bei den Quickchat AI Agents, die beide Ansätze kombinieren. Die ausführlichere Diskussion darüber, wann MCP, einzelne AI Actions oder „Generate from Text“ verwendet werden sollten, findest du in APIs für AI Agents: Von MCP zu benutzerdefinierten Endpunkten. Wenn du es selbst ausprobieren möchtest, folge der Schritt-für-Schritt-Anleitung, um deinen AI Agent mit einem Remote-MCP-Server zu verbinden, damit er mitten in einer Unterhaltung ein Live-Tool aufruft.

Liste verfügbarer MCP-Server

Wenn du mit MCP starten möchtest, sieh dir die folgenden MCP-Server-Verzeichnisse an:

• https://github.com/modelcontextprotocol/servers
• https://smithery.ai

Du kannst auch einen ausführen, ohne Code zu schreiben: Jeder Quickchat AI Agent kann in einen MCP-Server umgewandelt werden, mit einer gehosteten URL, die Claude, ChatGPT und Cursor als Tool aufrufen. Die Verbindung funktioniert auch in die andere Richtung: Ein Quickchat AI Agent kann den gehosteten MCP-Server eines Anbieters als seine Tools aufrufen. So prüft der AI-Terminplanungsassistent auf Basis des MCP-Servers von Calendly echte Verfügbarkeiten und bucht Meetings aus einem Chat heraus, und so antwortet ein Notion AI-Chatbot aus einem Live-Help-Center und protokolliert Supportanfragen zurück in einer Notion-Datenbank.

Quickchat AI betreibt außerdem einen Remote-MCP-Server für dein eigenes Konto. Verbinde ihn mit ChatGPT, Claude, Cursor oder Codex, und du kannst deine AI Agents von dort aus verwalten: Analysen, Gesprächsprotokolle, Knowledge-Base-Updates und die Erstellung neuer Agents, abgesichert durch eine einzige OAuth-Anmeldung. Die Einrichtungsanleitung für jeden Client findest du in Verwalte deinen AI Agent aus ChatGPT, Claude und Codex mit MCP.

FAQ

Funktioniert es nur mit Claude?

MCP ist modellunabhängig. Dem Protokoll ist egal, ob der Client Claude, GPT-4, ein lokales LLaMA-Derivat oder ein zukünftiges Modell ist, solange der Client die MCP-Schnittstelle verarbeiten kann. Das bedeutet, dass du beim Aufbau deiner Tool-Integrationen nicht an einen einzelnen AI-Anbieter gebunden bist.

Wie unterscheidet sich MCP davon, dem Modell alle benötigten Informationen direkt vorab zu geben? Warum den Prompt nicht einfach mit Daten füllen?

MCP unterscheidet sich grundlegend davon, den Prompt des Modells mit Daten zu füllen, weil es dem Modell ermöglicht, Informationen bei Bedarf dynamisch abzurufen, statt mit einem statischen, vorab geladenen Prompt zu arbeiten. Text in den Prompt zu stopfen stößt auf Grenzen, da AI-Modelle ein festes Kontextfenster haben. Zu viele Daten können also dazu führen, dass wichtige Details verloren gehen, Antworten langsamer werden und API-Kosten steigen (wegen der von LLM-Anbietern verwendeten Preismodelle pro Token). Außerdem liefert das nur Wissen zu einem einzigen Zeitpunkt, während MCP Echtzeitzugriff auf aktuelle externe Daten ermöglicht und die KI handeln lässt, statt nur Informationen zu lesen. Eine KI mit einem vollgepackten Prompt kennt vielleicht Kundendetails, kann aber keine Datensätze aktualisieren oder Transaktionen verarbeiten.

Was ist, wenn wir Dutzende Tools mit der KI verbinden? Überfordert das nicht das Modell oder führt dazu, dass es sie falsch verwendet?

Das hängt von der Implementierung ab, aber es stimmt, dass aktuelle LLMs Grenzen darin haben, viele Optionen zuverlässig zu unterscheiden und auszuwählen. Wenn du einem Modell zum Beispiel 50 mögliche Tools präsentierst, besteht das Risiko, dass es das falsche auswählt. Der MCP-Ansatz selbst zwingt dich nicht, alles auf einmal zu laden. Du solltest relevante Tools basierend auf dem Kontext verbinden. Eine bewährte Praxis ist, nur die Tools zu verbinden, die für die aktuelle Aufgabe oder Domain benötigt werden, und Multiagent Collaboration zu nutzen, also eine Art Tool-Routing oder einen Agent, der zuerst entscheidet, welche Teilmenge von Tools berücksichtigt werden soll.

MCP vs Function Calling

Klassisches Function Calling (wie in der API von OpenAI oder anderen LLMs) ermöglicht einem Entwickler, eine Reihe von Funktionen zu definieren, ihre Definitionen dem Modell zu geben und das Modell sie per Namen mit Argumenten „aufrufen“ zu lassen. Das war ein großer Schritt für AI-Integration, hat aber Einschränkungen. Ein wesentlicher Unterschied liegt darin, wann und wie Tools definiert werden. Beim klassischen Function Calling müssen alle möglichen Funktionen im Voraus (zur Designzeit) im Prompt oder über die API deklariert werden. Das Modell kann nur diese festen Funktionen aufrufen. In MCP sind Tools zur Laufzeit auffindbar, die KI kann abfragen, was verfügbar ist, und sogar mitten in einer Sitzung neue Tools erhalten.

MCP vs GPT Actions & Plugins

GPT Actions/Plugins bezieht sich auf das Ökosystem von OpenAI, in dem du Plugins (wie einen Webbrowser oder einen PDF-Reader) für ChatGPT aktivieren konntest, oder auf die „GPTs“ (benutzerdefinierte ChatGPT-Agents), die Tool-Nutzung haben können. Diese Ansätze waren interessant, erforderten aber individuelle Entwicklung für jedes Plugin und waren auf die Plattformen von OpenAI beschränkt. Wenn du ein ChatGPT-Plugin für eine Aufgabe wolltest, musstest du eine API und ein Manifest erstellen und die Freigabe von OpenAI durchlaufen oder es zumindest manuell aktivieren. Jedes Plugin war im Grunde ein Silo, ein Wetter-Plugin, ein Reise-Plugin usw., jeweils mit eigenen Endpunkten und eigener Logik. MCP verbessert dieses Konzept, indem es es vereinheitlicht und öffnet.

MCP vs RAG (Retrieval-Augmented Generation)

Retrieval-Augmented Generation (RAG) ist eine Technik, bei der ein LLM mit einer externen Wissensbasis ergänzt wird. Typischerweise umfasst RAG eine Vektordatenbank oder einen Suchindex: Die Anfrage des Nutzers wird verwendet, um relevante Dokumente oder Daten abzurufen (per semantischer Suche oder anderen Methoden), und diese Dokumente werden dem Modell als zusätzlicher Kontext zum „Lesen“ bereitgestellt, wenn es eine Antwort formuliert. Bei RAG geht es darum, dem Modell Wissen zu geben, das es ursprünglich nicht hatte. Das ist besonders hilfreich für faktische QA oder domänenspezifische Informationen. Allerdings ist RAG nur lesend, das Modell ruft Textpassagen ab, führt aber keine Aktionen über den Abruf hinaus aus.

MCP hingegen dient dazu, Aktionen auszuführen oder beliebige Operationen durchzuführen, nicht nur Informationskontext abzurufen. Mit MCP kann eine KI Dinge tun: in eine Datenbank schreiben, eine E-Mail senden, Code ausführen usw. Es ist nicht darauf beschränkt, Wissen abzurufen. Es kann Änderungen in externen Systemen auslösen. Daher erfüllen RAG und MCP in vielerlei Hinsicht unterschiedliche Zwecke.