Ein LLM weiss viel, aber nichts über die eigene Firma. Es kennt keine Kundendaten, keine Benutzerrechte, keine internen Prozesse. Wer AI-Agenten für echte Aufgaben einsetzen will, muss ihnen Zugang zu den Systemen geben, in denen diese Informationen liegen. Genau dafür gibt es das Model Context Protocol.
Vor MCP hat jedes Tool seine eigene Anbindung mitgebracht. Das funktionierte, aber es skalierte nicht.
Was bisher jeder selbst gebaut hat
Vor MCP sah die Integration von AI mit bestehenden Systemen so aus: Jedes Tool, jede Plattform und jeder Agent brachte seine eigene Anbindung mit. Wer einen Agenten an ein CRM, ein Ticketsystem oder eine interne API anbinden wollte, schrieb eine individuelle Integration. Das funktionierte, aber es skalierte nicht.
Das kennen wir aus einer anderen Welt. Bevor REST und OpenAPI sich als Standards etabliert haben, wurden die Schnittstellen für jede Applikation individuell definiert und gebaut. SOAP, XML-RPC, proprietäre Formate. Die darauf folgende Standardisierung hat damals nicht die Möglichkeiten verändert, sondern die Geschwindigkeit, mit der Systeme zusammengewachsen sind.
Was MCP ist
Das Model Context Protocol ist ein offener Standard. Er definiert, wie AI-Agenten auf externe Informationen zugreifen können. Anthropic hat ihn Ende 2024 veröffentlicht, inzwischen unterstützen es alle grossen AI-Plattformen.
Die Architektur ist bewusst einfach gehalten mit drei Rollen: einen Host, einen Client und einen Server. Der Host ist die AI-Anwendung, zum Beispiel Claude Code. Der Client ist die Schnittstelle innerhalb der Anwendung, die die Verbindung zu MCP-Servern verwaltet. In der Praxis sind Host und Client meist ein und dieselbe Applikation. Der Server stellt die eigentliche Funktionalität bereit und beschreibt seine Fähigkeiten in einem strukturierten Format. Der Agent sieht, welche Tools verfügbar sind, was sie tun und welche Parameter sie erwarten. Er entscheidet dann selbstständig, wann er welches Tool aufruft.
graph LR
subgraph "AI Anwendung (Host + Client)"
A["Agent / Claude Code"]
B["MCP Client"]
end
subgraph "Funktionalität (Server)"
C["MCP Server"]
D[("Tools und Ressourcen")]
end
C -- "1. Capabilities und Tool-Definitionen" --> B
B -- "2. Verfügbare Tools anzeigen" --> A
A -- "3. Entscheidung und Tool-Aufruf" --> B
B -- "4. Ausführung" --> C
C -- "5. Ergebnis" --> B
B -- "6. Kontext-Erweiterung" --> A
Ein MCP-Server für ein Benutzerverwaltungssystem könnte zum Beispiel drei Tools anbieten: Benutzer suchen, Rollenzuweisungen abfragen und Berechtigungen prüfen. Der Agent kennt diese Tools und weiss, wann er sie braucht. Fragt jemand “Wer hat Zugriff auf das Modul Finanzen?”, ruft der Agent die passenden Tools in der richtigen Reihenfolge auf, ohne dass jemand diese Logik vorher programmiert hat.
Warum das mehr ist als eine neue API
Auf den ersten Blick sieht MCP aus wie eine weitere API-Spezifikation. Der Unterschied liegt darin, wer die Integration steuert. Bei einer klassischen API programmiert ein Entwickler den Ablauf: Zuerst diesen Endpunkt aufrufen, dann die Daten transformieren, dann den nächsten Endpunkt. Bei MCP beschreibt der Server seine Fähigkeiten, und der Agent entscheidet selbst, wie er sie kombiniert.
Das verändert auch, wie Kontext entsteht. Vor MCP war der gängige Ansatz, möglichst viel Kontext vorab in den Prompt zu packen, etwa über RAG-Pipelines. Der Agent bekam alles auf einmal, ob er es brauchte oder nicht. Mit MCP holt sich der Agent gezielt die Informationen, die er für den aktuellen Schritt braucht. Context on Demand statt Kontext auf Vorrat.
Das verändert, was man mit wenig Aufwand bauen kann. Ein MCP-Server, der Zugriff auf Projektdaten gibt, funktioniert mit jedem AI-Client, der das Protokoll spricht. Claude Code kann ihn nutzen, eine eigene Chat-Applikation ebenfalls, ein automatisierter Agent genauso. Die Integration muss nur einmal gebaut werden.
Wie sich das in der Praxis anfühlt
An unserem letzten Code Camp hat ein Team einen MCP-Server für unser Uniport IAM Produkt gebaut. Über natürliche Sprache lässt sich abfragen, wer worauf Zugriff hat und welche Benutzer zu welcher Organisation gehören. Der MCP-Server selbst war an einem Tag fertig. Die eigentliche Herausforderung war eine andere: Der Agent sollte mit den echten Berechtigungen des angemeldeten Benutzers arbeiten. Ein Agent, der Berechtigungsdaten liefert, muss selbst Berechtigungen respektieren.
Seitdem setzen wir MCP-Server in weiteren Projekten ein. Der Server ist selten das Schwierige. Die Spezifikation ist schlank, die Implementierung in den meisten Sprachen unkompliziert. Die Arbeit steckt in den Fragen drumherum. Welche Daten darf der Agent sehen? Wie granular sollen die Tools sein? Was passiert, wenn der Agent ein Tool auf eine Weise nutzt, die wir nicht vorgesehen haben?
Wo die eigentliche Arbeit steckt
MCP definiert ein Transportprotokoll, keine Sicherheitsarchitektur. Authentifizierung und Autorisierung muss jeder Server selbst implementieren. Ein MCP-Server ohne Berechtigungsprüfung gibt einem Agenten Zugriff auf alles, was die darunterliegende API hergibt. Wer ein bestehendes System über MCP exponiert, muss dieselben Sicherheitsfragen beantworten wie bei jeder anderen Schnittstelle.
Auch die Granularität der Tools muss iterativ entwickelt werden. Zu wenige, grobe Tools geben dem Agenten wenig Spielraum. Zu viele, feine Tools überfordern ihn bei der Auswahl. In unseren Projekten hat sich gezeigt, dass man besser mit wenigen Tools startet und bei Bedarf verfeinert.
Dazu kommt: MCP ist jung. Die Spezifikation für Remote-Server mit OAuth-basierter Authentifizierung wurde erst 2025 finalisiert. Inzwischen gibt es Standard-Bibliotheken, die das OAuth-Handshaking weitgehend automatisch übernehmen. Der Einstieg ist dadurch einfacher geworden als noch vor einem Jahr. Aber wer heute darauf aufbaut, sollte trotzdem damit rechnen, dass sich Details noch ändern werden.
Ein Standard, der die Geschwindigkeit verändert
MCP löst ein konkretes Problem: Sie geben AI-Agenten eine standardisierte Möglichkeit, um auf Unternehmensdaten und -dienste zuzugreifen. Die Einstiegshürde ist niedrig, die Integration in bestehende Systeme mit überschaubarem Aufwand machbar. Die Frage ist nicht mehr, ob man AI-Agenten Zugriff auf Geschäftsdaten gibt, sondern wie man es sicher tut. Wer dies selber einsetzen möchte, dem zeigen wir gerne, wie der Einstieg aussieht.
