Bevor es MCP gab, musste jede KI-Anwendung jede Integration selbst bauen: eine eigene Anbindung an das CRM, eine an die Datenbank, eine an das Ticketsystem, jeweils mit eigenem Format. Das Model Context Protocol löst dieses Problem wie USB für Peripheriegeräte: Ein System stellt seine Funktionen einmal standardisiert bereit, und jede kompatible KI-Anwendung kann sie nutzen.
Die Architektur
MCP unterscheidet drei Rollen. Der Host ist die KI-Anwendung, mit der ein Mensch arbeitet, etwa ein Chat-Client oder eine Entwicklungsumgebung. Der Client im Host hält die Verbindung zu einem Server. Der Server stellt die Fähigkeiten eines Systems bereit. Server können lokal laufen oder als entfernter Dienst über HTTP erreichbar sein; für entfernte Server ist eine Authentifizierung über OAuth vorgesehen.
Was ein Server bereitstellt
Tools sind Funktionen, die das Modell aufrufen kann, etwa eine Suche oder das Anlegen eines Eintrags — technisch dasselbe Prinzip wie Tool-Calling. Resources sind Daten, die als Kontext gelesen werden können, etwa Dokumente oder Datensätze. Prompts sind vorbereitete Vorlagen für wiederkehrende Aufgaben. Ein gut gebauter Server bietet wenige, klar beschriebene Tools statt einer Eins-zu-eins-Abbildung jeder API-Route.
MCP für SaaS-Produkte
Für SaaS-Anbieter ist ein eigener MCP-Server eine neue Art von Schnittstelle: Kunden können das Produkt direkt aus ihren KI-Assistenten heraus nutzen, Daten abfragen und Aktionen auslösen. Wir betreiben MCP-Server auch für Produkte des eigenen Portfolios. Die Erfahrung zeigt: Der Aufwand liegt weniger im Protokoll als im Zuschnitt der Tools, in Berechtigungen pro Nutzer und Mandant und in sauberen Fehlermeldungen.
Sicherheitsfragen
MCP bringt die Risiken von Tool-Calling in die Breite. Ein Server mit weitreichenden Rechten ist ein attraktives Ziel; Prompt Injection über gelesene Inhalte kann Tool-Aufrufe auslösen; manipulierte Tool-Beschreibungen können ein Modell zu unerwünschten Handlungen verleiten. Gegenmassnahmen sind minimale Rechte pro Tool, serverseitige Prüfung von Mandant und Nutzer, Bestätigung folgenreicher Aktionen, Protokollierung und eine bewusste Auswahl, welche Server in einer Organisation zugelassen sind.
Einordnung
MCP ist kein Ersatz für eine gut gebaute API, sondern eine Schicht darüber, zugeschnitten auf Modelle. Wer bereits eine saubere API mit Authentifizierung und Mandantentrennung hat, kann einen MCP-Server schnell ergänzen. Wer eine solche API erst braucht, sollte dort beginnen; dabei hilft unser API-Integrations-Sprint.