Was ist MCP? Das Model Context Protocol für KI-Systeme

Was ist MCP?

Das Model Context Protocol (MCP) ist ein offenes Protokoll, das standardisiert, wie KI-Anwendungen mit externen Daten, Werkzeugen und weiteren Fähigkeiten verbunden werden. Statt jede Anbindung individuell zu bauen, definiert MCP eine gemeinsame Sprache aus Client-Server-Nachrichten: Eine KI-Anwendung kann darüber Werkzeuge entdecken und aufrufen, Daten lesen oder wiederverwendbare Prompt-Vorlagen nutzen.

Die offizielle Dokumentation vergleicht MCP mit einem USB-C-Anschluss für KI-Anwendungen: eine standardisierte Verbindung statt vieler Speziallösungen. Diese Analogie erklärt aber nur die Standardisierung – sie garantiert weder, dass jeder MCP-Server in jedem Client funktioniert, noch dass eine Verbindung automatisch sicher ist.

Welches Problem MCP löst

Ohne einen Standard muss jede KI-Anwendung für jedes Werkzeug eine eigene Integration bauen – das ergibt viele Einzelverbindungen (das klassische „M mal N"-Problem: M Anwendungen mal N Werkzeuge). MCP verschiebt das zu „M plus N": Ein Werkzeug wird einmal als MCP-Server bereitgestellt und kann dann von verschiedenen MCP-fähigen Anwendungen genutzt werden. Das entkoppelt die KI-Anwendung von der konkreten Werkzeuganbindung und erleichtert Wiederverwendung und Wartung.

MCP ist ein Protokoll – kein Agent und kein Modell

Die häufigste Verwechslung betrifft die Begriffsebene. MCP ist primär ein Protokoll bzw. offener Standard – nicht ein Modell, kein Agent, kein Framework, keine API und kein Tool:

Auch der Name führt in die Irre: „Context" meint hier nicht das Kontextfenster oder den Chatverlauf, sondern den Zugang zu Daten, Tools, Ressourcen und Prompt-Vorlagen, den ein MCP-Server bereitstellen kann.

MCP vs. API

Eine API beschreibt, wie ein konkreter Dienst angesprochen wird. MCP stellt eine standardisierte Protokollschicht bereit, über die KI-Anwendungen unterschiedliche Server und deren Fähigkeiten entdecken und nutzen können. Beides schließt sich nicht aus: Ein CRM hat bereits eine REST-API; ein MCP-Server kann ausgewählte CRM-Funktionen als MCP-Tools anbieten und liegt dann als KI-orientierte Integrationsschicht davor.

Host, Client und Server

MCP unterscheidet drei Rollen. Wichtig: Die Begriffe „Client" und „Server" meinen hier MCP-Komponenten, nicht klassische Web-Clients/-Server.

Ein MCP-Server kann lokal (als Prozess auf dem eigenen Rechner) oder remote (über das Netzwerk) laufen. „Server" heißt also nicht automatisch „Cloud".

Data Layer, Transport Layer und JSON-RPC

Die MCP-Architektur trennt zwei Ebenen. Der Data Layer definiert die eigentlichen Nachrichten und Abläufe: Discovery, Tools, Resources, Prompts, Elicitation, Notifications und Fortschritt. Der Transport Layer legt fest, wie diese Nachrichten zwischen Client und Server übertragen werden (siehe stdio & Streamable HTTP).

Als Nachrichtenformat nutzt MCP JSON-RPC 2.0: Der Client sendet eine strukturierte Anfrage, der Server antwortet strukturiert. Man muss JSON-RPC nicht im Detail kennen, um MCP zu verstehen – wichtig ist nur, dass die Kommunikation klar definiert und maschinenlesbar ist.

Was hat sich mit MCP 2026-07-28 geändert?

Statelessness und Discovery

„Stateless" bedeutet nicht, dass MCP-Anwendungen keinen Zustand haben dürfen. Es bedeutet, dass das Kernprotokoll so definiert ist, dass einzelne Requests die nötigen Protokollinformationen selbst mitführen und der Server nicht auf eine alte Protokollsession angewiesen ist. Anwendungszustand kann weiterhin existieren – etwa über server-vergebene Handles, Tool-Argumente, Anwendungsspeicher oder Extensions.

Über Discovery (server/discover) kann ein Client unterstützte Protokollversionen, Fähigkeiten und die Serveridentität ermitteln. Wichtig ist die Capability Negotiation: Nicht jeder Client oder Server unterstützt automatisch alles (Tools, Resources, Prompts, Elicitation, Extensions).

Tools, Resources und Prompts

Die drei zentralen Server-Bausteine unterscheiden sich vor allem darin, wer sie typischerweise auslöst:

Tools

Tools ermöglichen Aktionen: eine Datenbank abfragen, eine API aufrufen, eine Rechnung berechnen, eine Datei erstellen, einen Termin anlegen. Eine Tooldefinition enthält u. a. ein strukturiertes Schema für Ein- und Ausgaben. Ein Tool kann Seiteneffekte haben – get_customer ist etwas anderes als delete_customer.

Ein MCP-Server kann mehrere Tools bereitstellen; ein Tool ist also nicht dasselbe wie ein Server. Wichtig für Qualität und Sicherheit: Das Modell wählt Tools auch anhand ihrer Beschreibung und ihres Schemas aus. Schlechte Beschreibungen führen zu falscher Auswahl, falschen Parametern oder unnötigen Aufrufen. Und laut Spezifikation sind Tool-Beschreibungen und Annotationen nicht automatisch vertrauenswürdig – sie können manipuliert sein.

Resources

Resources stellen Daten bzw. Kontext bereit – eine Datei, ein Dokument, ein Datenbankschema, eine Anwendungsinformation. Ein Client kann eine Resource lesen und in den Kontext einbringen. Das allein ist aber noch kein RAG: RAG umfasst zusätzlich eine Retrievalstrategie, die entscheidet, welche Information relevant ist (Chunking, Embeddings, Ranking). Eine Resource zu lesen ist nur ein Baustein davon.

Prompts

Prompts sind wiederverwendbare Vorlagen, die ein Server bereitstellt und die laut Spezifikation auf nutzergesteuerte Interaktion ausgelegt sind. Ein Prompt ist keine Toolfunktion – und auch nicht automatisch die unveränderliche Systemanweisung einer Anwendung. Host bzw. Client entscheiden, wie ein bereitgestellter Prompt integriert und dargestellt wird.

Elicitation

Elicitation ist ein Client-Feature: Ein Server kann darüber über den Client zusätzliche Nutzereingaben anfordern, wenn während eines Ablaufs noch Informationen fehlen (z. B. ein Datum, ein Zielordner, eine Auswahl). Wichtig ist die Sicherheitsregel: Sensible Credentials gehören nicht in eine normale Elicitation-Abfrage. Ein Passwort oder API-Schlüssel wird nicht einfach über ein Formularfeld oder einen Agentenprompt eingesammelt, sondern über sichere Authorization-Mechanismen.

Extensions, Tasks und MCP Apps

Neben dem Kernprotokoll gibt es ein offizielles Extensions-Konzept: optionale Erweiterungen außerhalb des Cores, die von den beteiligten Implementierungen unterstützt werden müssen. Nicht jede Extension ist in jedem Client verfügbar.

Tasks dienen lang laufenden Operationen: Statt zu blockieren, gibt der Server ein dauerhaftes Task-Handle zurück; der Client fragt den Status ab, liefert bei Bedarf Eingaben nach oder bricht ab. Nicht jeder Tool-Call ist ein Task. MCP Apps können interaktive Oberflächen in unterstützten Clients ermöglichen – aber nur dort, wo der Client diese Extension unterstützt. Skills over MCP ist aktuell eine Working Group mit Entwurf, keine fertige offizielle Extension; entsprechend vorsichtig einordnen.

stdio und Streamable HTTP

Aktuell definiert MCP zwei Standard-Transporte:

Der frühere HTTP+SSE-Transport gilt als deprecated und sollte nicht als aktueller Haupttransport gelernt werden. Neuere Implementierungen nutzen Streamable HTTP. Wichtig auch hier: Lokal heißt nicht automatisch sicher (siehe Sicherheit).

Ältere und deprecated Funktionen

Viele Tutorials beschreiben Konzepte, die mit 2026-07-28 überholt sind. Wer MCP heute lernt, sollte diese nicht als aktuelle Architektur übernehmen:

MCP vs. Function Calling

Function Calling (Tool Calling) beschreibt die Fähigkeit eines Modells bzw. einer Modell-API, strukturierte Werkzeugaufrufe zu erzeugen. MCP standardisiert die Kommunikation zwischen KI-Anwendung und externen MCP-Servern. Beides ergänzt sich in einem typischen Ablauf:

MCP im Vergleich zu RAG, Agent und Workflow

Daraus folgen mehrere Klarstellungen: MCP kann RAG-Funktionen zugänglich machen (z. B. ein Tool search_knowledge_base), bestimmt aber nicht Chunking, Embeddings oder Retrievalstrategie. Ein MCP-Server kann Memory-/State-Funktionen anbieten, aber MCP gibt einem Modell nicht automatisch ein Langzeitgedächtnis. Ein Workflow kann MCP-Tools nutzen, doch MCP definiert nicht die komplette Ablaufsteuerung.

Sicherheit

MCP standardisiert Kommunikation – es ist keine Sicherheitsgarantie. Die Spezifikation betont ausdrücklich, dass Implementierer Schutzmaßnahmen umsetzen müssen; das Protokoll allein kann sie nicht erzwingen.

User Consent & Control: Nutzer sollten verstehen, welche Daten geteilt werden, welches Tool aufgerufen wird und welche Aktion erfolgt – besonders bei Aktionen mit Seiteneffekten. Tool Safety: Zu unterscheiden sind lesende (read-only), verändernde (write) und destruktive Aktionen (löschen, Zahlung, Deployment); Berechtigungen und Freigaben entsprechend gestalten. Und: Tool-Beschreibungen sind nicht automatisch vertrauenswürdig.

Weil ein MCP-Tool Inhalte von Webseiten, Mails, Dokumenten oder Datenbanken zurückgeben kann, ist Prompt Injection ein Kernrisiko: eingeschleuste Anweisungen können das Verhalten beeinflussen. MCP ist keine Schutzgrenze dagegen. Die offizielle Security-Dokumentation behandelt zusätzlich mehrere konkrete Angriffsmuster:

Authorization ist transportabhängig: Bei HTTP-basierten Verbindungen gibt es ein standardisiertes, auf OAuth aufbauendes Framework (u. a. mit dem Grundsatz, dass ein Server keine Tokens akzeptiert, die nicht für ihn ausgestellt wurden). Bei stdio werden Credentials anders gehandhabt – der Satz „MCP verwendet immer OAuth" ist also falsch. Ergänzend gelten Least Privilege (nur nötige Rechte), Scope Minimization (nur nötige Berechtigungsbereiche anfordern) und die Regel: keine Credentials in Prompts. Wichtig ist auch die Trennung von Authentifizierung (wer greift zu?) und Autorisierung (was ist erlaubt?) sowie zwischen Tool Discovery (ein Tool sehen) und Tool Authorization (es aufrufen dürfen). Wer welche Aktion freigibt, entscheidet die Host-/Agentenarchitektur, nicht MCP allein.

Datenschutz und Datenfluss

Bei MCP durchlaufen Daten mehrere Stationen mit jeweils eigenen Vertrauensgrenzen:

Ein Remote-Server verarbeitet Daten außerhalb des eigenen Systems – zu prüfen sind Betreiber, Datenschutz, Logging, Datenregion, Aufbewahrung und Drittanbieter. Ein lokaler Server ist keine automatische Datenschutzgarantie: Auch lokal können Daten in Logs landen oder über Tools an externe APIs gehen. Und ein lokaler MCP-Server ist ausführbare Software: Quelle, Repository und Paket prüfen, Version pinnen, Updates kontrollieren, Rechte minimieren – dieselbe Sorgfalt wie bei anderen Abhängigkeiten (Supply-Chain-Risiken wie manipulierte Pakete oder Typosquatting gelten auch hier).

Weiterführend: Datenschutz, Datenlecks und Risikomanagement.

Versionierung und Kompatibilität

MCP entwickelt sich schnell, deshalb ist die Spezifikationsversion wichtig. Aussagen auf dieser Seite beziehen sich auf die Revision 2026-07-28. Ein alter Client und ein neuer Server sind nicht automatisch vollständig kompatibel – Implementierungen brauchen ggf. Kompatibilitätslogik. Auch Konfiguration ist client-spezifisch: „MCP wird immer in einer bestimmten mcp.json konfiguriert" stimmt nicht; das hängt vom jeweiligen Client ab.

Entstehung und Governance

MCP wurde von Anthropic im November 2024 vorgestellt und als offener Standard veröffentlicht. Am 9. Dezember 2025 wurde das Projekt an die Agentic AI Foundation (AAIF) unter der Linux Foundation übergeben. MCP ist damit heute kein proprietäres Anthropic-Protokoll mehr; die Weiterentwicklung läuft offen über einen Community-Prozess (SEPs), an dem Anthropic weiterhin beteiligt ist. Die historische Herkunft bleibt korrekt zu nennen, die aktuelle Trägerschaft ist aber die Stiftung.

Wann MCP sinnvoll ist – und wann nicht

Sinnvoll, wenn mehrere KI-Anwendungen dieselben Fähigkeiten brauchen, Tools wiederverwendbar bereitgestellt werden sollen, Client und Toolanbieter entkoppelt werden sollen, standardisierte Discovery hilft, lokales und entferntes Tooling ähnlich angebunden werden soll oder eine wachsende Agenten-/Tool-Infrastruktur existiert.

Nicht nötig, wenn genau eine Anwendung genau eine einfache API nutzt, keine Wiederverwendung gebraucht wird, ein fester Workflow reicht, eine normale Library genügt oder ein zusätzlicher Serverprozess keinen Mehrwert bringt.

Häufige Missverständnisse

Praxis-Checkliste: MCP-Einsatz prüfen

• Brauche ich überhaupt eine standardisierte Integration – oder reicht eine direkte API?
• Wird die Fähigkeit von mehreren Clients genutzt?
• Welche Tools, Resources und Prompts bietet der Server?
• Welche Aktionen haben Seiteneffekte (write/destructive)?
• Welche Berechtigungen sind wirklich nötig (Least Privilege, Scope Minimization)?
• Lokal oder remote – und wohin fließen die Daten?
• Wie erfolgt die Authorization (Transport beachten)?
• Welche MCP-Version unterstützen Client und Server?
• Werden Extensions benötigt (z. B. Tasks, Apps)?
• Ist Human Approval vor kritischen Aktionen nötig?
• Werden Tool-Aufrufe protokolliert (ohne unnötige sensible Daten)?
• Wie vertrauenswürdig ist der Server, und wie werden Updates kontrolliert?

Weiterführend: KI-Agenten, RAG, Tokens & Kontextfenster, Prompt Injection und Was ist KI?

• KI-Agenten
• RAG
• Prompt Injection
• Tokens & Kontextfenster
• Automatisierung
• Was ist KI?