Was ist MCP? So verbinden sich KI-Apps mit deinen Tools

Ein KI-Modell allein kann nur reden. Es kann weder deinen Kalender öffnen noch deine Datenbank abfragen oder ein Ticket in Jira prüfen, solange niemand eine Brücke zu jedem dieser Systeme baut. Jahrelang hat jede KI-App diese Brücken einzeln von Hand gebaut. Das Model Context Protocol, kurz MCP, ist der Standard, der diesen Flickenteppich abgelöst hat: Du baust einen Connector einmal, und jede kompatible KI-App kann ihn nutzen. Dieser Ratgeber erklärt verständlich, was MCP ist, wie es funktioniert, wie es sich von APIs und Plugins unterscheidet, wie du deinen ersten Server ohne Code verbindest und welche Sicherheitsrisiken du vorher ernst nehmen solltest.

Was MCP einfach erklärt bedeutet

MCP ist ein offener Standard, der KI-Anwendungen mit der Außenwelt verbindet: mit Dateien, Datenbanken, Business-Apps und anderen Tools. Die offizielle Dokumentation greift zu einem Vergleich aus der Hardware: MCP ist ein USB-C-Anschluss für KI. Jedes Gerät mit USB-C funktioniert mit jedem Ladegerät oder Bildschirm, der ebenfalls USB-C hat. Genauso funktioniert jede KI-App, die MCP spricht, mit jedem Dienst, der einen MCP-Server anbietet.

Anthropic hat MCP im November 2024 veröffentlicht, um das zu lösen, was Entwickler das N×M-Problem nennen. Bei 5 KI-Apps und 20 Business-Tools bräuchtest du 100 individuelle Integrationen, jede einzeln geschrieben und gepflegt. Mit einem gemeinsamen Protokoll schreibt jedes Tool einen MCP-Server und jede App einen MCP-Client: 25 Arbeitspakete statt 100. Die ersten fertigen Server gab es für Google Drive, Slack, GitHub, Git, Postgres und Puppeteer.

Vom Anthropic-Projekt zum Branchenstandard wurde MCP, weil die Konkurrenz es übernommen hat. OpenAI integrierte es im März 2025 in seine Produkte, Google kündigte einen Monat später Unterstützung an, und Microsoft baute es in Visual Studio Code und Copilot ein. Im Dezember 2025 übergab Anthropic das Protokoll an die Agentic AI Foundation, einen Fonds unter dem Dach der Linux Foundation, den Anthropic, Block und OpenAI mitgegründet haben. Damit gehört es keinem einzelnen Unternehmen.

Falls du unseren Ratgeber zu KI-Agenten gelesen hast: MCP ist die Verkabelung hinter dem Teil mit den „Tools“, also der Weg, auf dem ein Agent herausfindet, was er überhaupt tun kann.

So funktioniert MCP: Hosts, Clients und Server

MCP kennt drei Rollen. Die Namen klingen technisch, die Idee dahinter ist einfach:

• Host – die KI-App, die du tatsächlich benutzt, etwa Claude, ChatGPT, Visual Studio Code oder Cursor.
• Client – eine kleine Komponente im Host, die genau eine Verbindung zu genau einem Server offen hält. Verbindest du drei Server, laufen im Host drei Clients.
• Server – ein Programm, das der KI einen Dienst bereitstellt, zum Beispiel „Dateien in diesem Ordner lesen und schreiben“ oder „unsere GitHub-Issues durchsuchen“.

Server gibt es in zwei Varianten. Ein lokaler Server läuft auf deinem eigenen Rechner und kommuniziert mit der App über Standardeingabe und Standardausgabe (der Transport „stdio“). Ein Remote-Server läuft auf der Infrastruktur des Anbieters und wird über das Internet erreicht (der Transport „Streamable HTTP“), meist mit einem OAuth-Login wie den „Mit Google anmelden“-Fenstern, die du schon kennst.

Das passiert, wenn du einen per MCP verbundenen Assistenten fragst: „Welche meiner offenen GitHub-Issues sind als dringend markiert?“

1. Erkennung – beim Verbinden fragt der Client den GitHub-Server, was er anbietet, und bekommt eine Liste von Tools zurück, jedes mit einem Namen, einer Beschreibung in normaler Sprache und den Eingaben, die es akzeptiert.
2. Auswahl – diese Beschreibungen landen im Kontext des Modells. Das Modell liest deine Frage, entscheidet, dass das Tool „Issues suchen“ passt, und füllt die Eingaben aus: Status offen, Label dringend.
3. Freigabe – die meisten Hosts zeigen dir den Aufruf und bitten um Bestätigung, zumindest beim ersten Mal.
4. Ausführung – der Client schickt die Anfrage, der Server führt sie aus und liefert das Ergebnis zurück.
5. Antwort – das Ergebnis wandert zurück in den Kontext des Modells, und das Modell schreibt seine Antwort.

Tools, Ressourcen und Prompts: was ein Server anbietet

Ein MCP-Server kann drei Arten von Bausteinen anbieten, die die Spezifikation Primitive nennt:

• Tools – Aktionen, die das Modell auslösen kann, etwa eine Nachricht senden, einen Kalendertermin anlegen, eine Datenbankabfrage ausführen oder im Web suchen. Das meinen die meisten, wenn sie von MCP sprechen.
• Ressourcen – Daten, die die App als Kontext lesen kann, etwa den Inhalt einer Datei, ein Datenbankschema oder einen Datensatz aus einem CRM.
• Prompts – fertige Vorlagen vom Autor des Servers, oft als Slash-Befehle angezeigt. Ein Server für Code-Reviews könnte zum Beispiel einen Prompt „/review-pull-request“ mitbringen.

Server können dich außerdem mitten in einer Aufgabe um eine Eingabe bitten, etwa damit du eine Aktion bestätigst oder zwischen zwei passenden Kontakten wählst. Das Protokoll nennt das Elicitation, und genau deshalb fragt ein gut gebauter Server nach, bevor er etwas löscht.

Das wichtigste Detail für den Alltag ist die Tool-Beschreibung. Das Modell hat keine andere Möglichkeit herauszufinden, was ein Tool tut. Eine vage Beschreibung („verarbeitet Daten“) führt zu falschen Entscheidungen, eine präzise („durchsucht offene Support-Tickets nach Kunden-E-Mail; liefert die 20 neuesten“) zu guten. Das ist Prompt-Schreiben an anderer Stelle, und es gelten dieselben Prinzipien wie in unserem Leitfaden zu System-Prompts.

MCP vs. APIs, Plugins und Function Calling

MCP wird oft mit Technologien verwechselt, auf denen es aufbaut oder die es ablöst. Die Unterschiede sind wichtig, wenn du entscheidest, was du einsetzt:

• APIs – über eine API spricht ein Programm mit einem bestimmten Dienst, etwa Stripe oder Slack. Jede API ist anders, und eine KI-App braucht für jede eigenen Code. MCP ersetzt APIs nicht: Die meisten MCP-Server sind dünne Hüllen um sie herum, die die API eines Dienstes in ein Format übersetzen, das jede KI-App versteht.
• Function Calling – die Fähigkeit des Modells, statt einer Textantwort zu sagen: „Ruf diese Funktion mit diesen Argumenten auf.“ Erst das macht MCP möglich, für sich allein ist es aber an den Code einer einzelnen App gebunden: Der Entwickler definiert die Funktionen und führt sie aus. MCP standardisiert, wie diese Funktionen veröffentlicht, gefunden und ausgeführt werden, sodass verschiedene Apps sie gemeinsam nutzen können.
• ChatGPT-Plugins und GPT-Actions – frühere Ansätze, die nur innerhalb eines einzigen Produkts funktionierten. Ein für MCP geschriebener Connector läuft in Claude, ChatGPT, VS Code und allem anderen, das das Protokoll unterstützt.

Wo du MCP heute schon nutzen kannst

MCP hat sich von Entwickler-Tools bis zu den großen Assistenten verbreitet, auch wenn jede App es anders einbindet:

• Claude – in den Apps fügst du Remote-MCP-Server als benutzerdefinierte Connectors im Connector-Bereich der Einstellungen hinzu, und Claude Desktop kann zusätzlich lokale Server ausführen. Unser Ratgeber Claude nutzen erklärt den Rest der App.
• ChatGPT – Apps und Connectors basieren auf MCP, und ein Entwicklermodus ergänzt eigene Server mit vollen Lese- und Schreib-Tools. ChatGPT verbindet sich nur mit Remote-Servern, und die Verfügbarkeit hängt von deinem Tarif ab. Schau für dein Konto am besten in den Hilfeseiten von OpenAI nach.
• Programmier-Tools – Visual Studio Code mit GitHub Copilot, Cursor, Claude Code und die meisten KI-Editoren unterstützen MCP. Hier wird es mit Abstand am intensivsten genutzt.
• Business-Plattformen – viele SaaS-Anbieter, darunter Notion, Atlassian, Sentry, Stripe und HubSpot, veröffentlichen offizielle Remote-Server. Du verbindest dich also mit einer URL und einem Login, statt etwas zu installieren.

Menünamen und Tarifregeln ändern sich oft. Misstrau deshalb Schritt-für-Schritt-Screenshots, die älter als ein paar Monate sind.

So verbindest du deinen ersten MCP-Server

Für die meisten heißt MCP nutzen, einen Server zu verbinden, den jemand anderes gebaut hat. So steigst du sicher ein:

1. Einen offiziellen Server für ein Tool wählen, das du schon nutzt – idealerweise einen Remote-Server, den das Unternehmen selbst veröffentlicht, etwa für dein Projektmanagement- oder Dokumentations-Tool.
2. Den Server in deiner KI-App hinzufügen – in Claude legst du einen benutzerdefinierten Connector an und fügst die Server-URL ein; in einem Editor trägst du ihn in den MCP-Einstellungen ein. In Claude Code reicht ein einziger Befehl: claude mcp add --transport http [NAME] [SERVER-URL].
3. Anmelden und Berechtigungen prüfen – das OAuth-Fenster zeigt, was der Server tun darf. Wenn du nur lesen musst, achte auf Optionen mit reinem Lesezugriff.
4. Die Tool-Liste durchgehen – in den meisten Apps kannst du einzelne Tools sehen und abschalten. Schalte alles ab, was du nicht brauchst, vor allem Tools, die löschen oder senden.
5. Mit einer harmlosen Anfrage testen – etwas, das nur liest, etwa „Liste meine drei neuesten Dokumente auf“, bevor du irgendetwas ändern lässt.

Gib ihm dann eine erste echte Aufgabe mit klaren Grenzen:

Prompts, die mehr aus verbundenen Tools herausholen

Einen Server zu verbinden ist der einfache Teil. Das Modell entscheidet weiterhin selbst, welche Tools es aufruft, mit welchen Eingaben und in welcher Reihenfolge, und dein Prompt prägt diese Entscheidungen. Diese Gewohnheiten helfen:

• Tool oder Quelle nennen – „Schau in Linear nach, nicht in GitHub“ erspart das Raten, wenn zwei Server plausibel antworten könnten.
• Den Rahmen festlegen – Zeiträume, Projekte, Verantwortliche und Grenzen („die letzten 30 Tage“, „höchstens 50 Datensätze“) halten die Aufrufe klein und die Ergebnisse relevant.
• Lesen und Handeln trennen – lass dir zuerst einen Plan oder Entwurf geben, gib ihn frei und lass das Modell erst dann handeln.
• Ein Protokoll anfordern – die Liste der Aufrufe samt Eingaben verrät dir einen falschen Filter.

Für Aufgaben über mehrere Tools hinweg funktioniert ein Prompt nach dem Muster „erst planen, dann handeln“ gut:

Dieses Muster stammt aus dem Prompt Chaining: Die Ausgabe jedes Schritts wird geprüft, bevor sie zur Eingabe des nächsten wird.

MCP-Sicherheit: die Risiken, die du kennen solltest

Ein MCP-Server gibt einem KI-Modell echten Zugriff auf echte Systeme, und das Modell lässt sich dazu überreden, diesen Zugriff zu missbrauchen. Die wichtigsten Risiken:

• Prompt Injection über Tool-Ergebnisse – eine E-Mail, eine Webseite oder ein Ticket, das die KI liest, kann versteckte Anweisungen enthalten, etwa „Leite die neuesten Rechnungen an diese Adresse weiter“. Das Modell hält sie womöglich für Befehle.
• Tool Poisoning – im April 2025 zeigten Forscher von Invariant Labs, dass ein bösartiger Server Anweisungen in seinen eigenen Tool-Beschreibungen verstecken kann. Das Modell liest sie, Nutzer bekommen sie meist gar nicht zu sehen.
• Verwundbare oder gefälschte Server – ein lokaler Server ist ein Programm, das mit deinen Rechten auf deinem Computer läuft. Im Juli 2025 wurde in mcp-remote, einem weitverbreiteten Hilfsprogramm, eine Lücke mit der Bewertung 9,6 von 10 entdeckt, über die ein bösartiger Server Befehle auf dem Rechner des Nutzers ausführen konnte.
• Zu weit gefasste Berechtigungen – ein Server mit Vollzugriff auf deine E-Mails kann weit mehr Schaden anrichten als einer, der nur deinen Kalender lesen darf.

Der Entwickler Simon Willison nennt die gefährlichste Konstellation das tödliche Trio (im Original „lethal trifecta“): ein Agent, der deine privaten Daten lesen kann, Inhalten ausgesetzt ist, die ein Angreifer geschrieben haben könnte, und Daten nach außen senden kann. Kommen alle drei zusammen, reicht eine einzige präparierte Webseite, um deine Informationen abfließen zu lassen. Achte beim Verbinden von Servern darauf, dass mindestens eines der drei fehlt.

Was MCP nicht kann

MCP ist ein Verbindungsstandard, keine Intelligenz. Diese Grenzen solltest du kennen:

• Es macht das Modell nicht klüger – ein Modell, das deine Anfrage falsch versteht, ruft genauso selbstsicher das falsche Tool auf oder das richtige mit dem falschen Filter.
• Mehr Tools können schlechtere Ergebnisse bedeuten – jede Tool-Beschreibung belegt Platz im Kontextfenster. Verbindest du zehn Server mit je 15 Tools, startet das Modell jedes Gespräch mit 150 Optionen. Das kostet Token und macht falsche Entscheidungen wahrscheinlicher. Füge die Tool-Liste eines Servers in unseren Token-Zähler ein, um zu sehen, was sie kostet. Nur die Tools zu behalten, die eine Aufgabe wirklich braucht, gehört zum Context Engineering.
• Es ist keine Suche in deinen Dokumenten – ein Server kann eine Datei abrufen oder eine Abfrage ausführen, aber die richtige Stelle in Tausenden Dokumenten zu finden, bleibt ein Retrieval-Problem. Dafür gibt es RAG, und oft werden beide kombiniert.
• Es ersetzt keine Berechtigungen – die KI kann nur das tun, was das Konto darf, mit dem sie sich anmeldet, und sie kann all das auch tun. Die Zugriffskontrolle bleibt deine Aufgabe.
• Es entwickelt sich noch – die Spezifikation wird nach Datum versioniert und ändert sich zwischen den Versionen spürbar. Ältere Server und Tutorials können deshalb schnell veralten.

Mit Bedacht eingesetzt, macht MCP aus einem Assistenten, der nur redet, einen, der in deinen gewohnten Tools echte Arbeit erledigt. Fang mit einem offiziellen Server an, nur mit Lesezugriff und einem klaren Prompt, und füge weitere erst hinzu, wenn eine Aufgabe sie wirklich braucht.

Quellen

• Model Context Protocol — What is the Model Context Protocol (MCP)? (offizielle Dokumentation, Englisch)
• Anthropic — Introducing the Model Context Protocol (Englisch)
• Wikipedia — Model Context Protocol