Was ist MCP (Model Context Protocol) — und wofür braucht man es wirklich?
Kurz gesagt
MCP ist ein offenes Protokoll, das die Verbindung zwischen KI-Anwendungen (Hosts) und externen Werkzeugen, Datenquellen und Prompt-Bausteinen (Servern) standardisiert. Es löst das Problem, dass sonst jeder Anbieter eigene, proprietäre Connectoren bauen müsste. MCP ersetzt dabei weder die zugrunde liegenden APIs noch Berechtigungsprüfung, Serverprüfung, Sandbox oder laufendes Lifecycle-Management — es standardisiert nur die Verbindung, nicht deren Vertrauenswürdigkeit.
Die Grundarchitektur in drei Rollen
MCP unterscheidet drei Rollen: Der Host ist die KI-Anwendung, mit der ein Mensch tatsächlich interagiert — er steuert Nutzerinteraktion, Richtlinien und Zustimmung. Der MCP-Client ist eine logisch getrennte Verbindung des Hosts zu genau einem Server. Der MCP-Server stellt die eigentlichen Fähigkeiten bereit: Werkzeuge, die etwas tun können, Ressourcen, aus denen gelesen werden kann, und Prompt-Bausteine, die wiederverwendbar sind. Diese Trennung erlaubt es, einen einmal gebauten Server von mehreren unterschiedlichen KI-Anwendungen aus zu nutzen.
Warum MCP überhaupt entstanden ist
Ohne einen gemeinsamen Standard braucht jede Kombination aus KI-Anwendung und externem System eine eigene, individuell gebaute Integration. Ein Praxisbeispiel: Ein Unternehmen möchte einem KI-Assistenten lesenden Zugriff auf das eigene CRM geben. Statt für jeden möglichen KI-Client eine eigene, proprietäre CRM-Anbindung zu entwickeln, wird ein einziger MCP-Server für das CRM gebaut, den anschließend jeder MCP-fähige Host nutzen kann. Das reduziert Doppelarbeit — verändert aber nichts an der Notwendigkeit, den Zugriff dieses Servers sauber zu begrenzen und zu prüfen.
Zwei Transportwege, unterschiedliche Risikoprofile
MCP kennt zwei Übertragungswege: stdio für die lokale Kopplung zweier Prozesse auf demselben Rechner, und Streamable HTTP für die Kommunikation mit einem entfernten Server über das Netzwerk. Wichtig dabei: Ein lokaler Transport ist nicht automatisch harmlos. Ein lokal laufender MCP-Server hat mit den Rechten des ausführenden Nutzers Zugriff auf Dateien, Prozesse und mitunter gespeicherte Zugangsdaten — dieselbe Vorsicht, die für jede lokal installierte Software gilt, muss auch hier angewendet werden.
Autorisierung läuft über bestehende Standards
Für die Zugriffssteuerung erfindet MCP kein eigenes Verfahren, sondern setzt auf bestehende OAuth-Mechanismen zur Ressourcen-Metadaten- und Discovery-Prüfung. Das ist grundsätzlich sinnvoll, weil bewährte Sicherheitsinfrastruktur wiederverwendet wird — es bedeutet aber auch, dass alle bekannten Risiken rund um OAuth-Token-Handling (etwa unkontrollierte Weitergabe von Zugriffstoken an nachgelagerte Systeme) genauso für MCP-Integrationen gelten.
Ein verbreiteter Irrtum: MCP als Datenbank oder Gedächtnis
Ein häufiges Missverständnis besagt, MCP sei eine Art neue Datenbank oder ein Memory-System für KI-Anwendungen. Das ist falsch: MCP standardisiert nur den Protokollzugriff auf Werkzeuge, Ressourcen und Prompts. Speicherung und Gedächtnisfunktion einer KI-Anwendung sind eigenständige, davon unabhängige Komponenten, die ein Unternehmen weiterhin selbst entwerfen und absichern muss.
Was MCP ausdrücklich nicht übernimmt
MCP standardisiert die Verbindung zwischen KI-Anwendung und externem System — es ersetzt dabei weder die zugrunde liegenden APIs noch Autorisierungsprüfung, Serverprüfung, Sandboxing, Audit-Protokollierung oder das laufende Lifecycle-Management eines Servers. Ein Unternehmen, das MCP einsetzt, trägt also weiterhin dieselbe Verantwortung für Zugriffskontrolle und Betrieb wie bei jeder anderen Systemintegration auch — MCP macht die Anbindung leichter wiederverwendbar, nicht automatisch sicherer.