Model Context Protocol ist kein Pflichtbaustein für jede KI-Integration. In vielen Unternehmen wird es gerade trotzdem so behandelt, weil Einkaufsprozesse sichtbare Assistenten bevorzugen und die Zugriffsschicht erst später auffällt. Genau dort entsteht der teure Fehler: Wer mehrere KI-Anwendungen plant, aber Werkzeuge, Rechte und Protokollierung pro Bot einzeln baut, produziert keinen Vorsprung, sondern künftige Integrationsschuld. Für einen einzelnen, engen Use Case ist MCP oft zu viel. Ab dem zweiten oder dritten Assistenten kippt die Rechnung schnell.
Im Markt wird die Rolle von MCP vor allem an einer Stelle falsch gelesen: als Abkürzung zu einer fertigen KI-Plattform. Das ist bequem für Demos und noch bequemer für Beschaffung, weil ein neues Protokoll nach strategischer Zukunftssicherheit klingt. Im Betrieb bleibt davon wenig übrig. MCP standardisiert, wie ein KI-Client Werkzeuge und Ressourcen entdeckt und aufruft. Es ersetzt weder Fachsysteme noch IAM, Audit, Freigaben oder eine saubere API-Architektur. Wer das verwechselt, kauft Architekturversprechen ein, die später im Projektteam landen.
Die eigentliche Entscheidung ist deutlich prosaischer: Braucht das Unternehmen einen wiederverwendbaren Tool-Layer für KI oder nur eine schnelle Einzelanbindung? Diese Frage ist wichtiger als fast jede Debatte über Protokolltrends.
Was Model Context Protocol standardisiert und was nicht
Model Context Protocol definiert die Schnittstelle zwischen einem KI-Client und einem Server, der Fähigkeiten bereitstellt. Diese Fähigkeiten können Werkzeuge, Ressourcen oder strukturierter Kontext sein. Ein Client erkennt verfügbare Funktionen, übergibt Parameter und erhält Ergebnisse in einem einheitlichen Muster zurück.
Technisch wirkt das zunächst unspektakulär. Operativ ist es relevant, sobald mehrere Assistenten auf ERP, CRM, DMS, Helpdesk oder interne Wissensquellen zugreifen. Dann taucht immer dieselbe Frage auf: Wie werden diese Zugriffe beschrieben, abgesichert, versioniert und für verschiedene Modelle nutzbar gemacht? Genau dort setzt MCP an.
Die Rollen sind klar:
- MCP-Client ist die Anwendung oder Laufzeit, die Werkzeuge aufrufen kann.
- MCP-Server stellt diese Werkzeuge oder Ressourcen standardisiert bereit.
- Werkzeuge sind definierte Aktionen wie „Bestellung abrufen“ oder „Dokument nach ID laden“.
- APIs der Zielsysteme bleiben im Hintergrund bestehen und werden gekapselt.
Die Grenze ist entscheidend. Ein ERP behält seine eigene API, seine Rechte und seine Datenlogik. Ein Ticketsystem bleibt ein Ticketsystem. MCP legt sich darüber als Zugriffsschicht für KI. Wer erwartet, dass das Protokoll Governance automatisch mitliefert, startet mit der falschen Annahme.
Die Spezifikation von Anthropic beschreibt den Austausch zwischen Host, Client und Server präzise genug, um daraus belastbare Integrationsmuster abzuleiten. Für die Praxis zählt zusätzlich, dass strukturierte Werkzeugaufrufe längst kein exotisches Konzept mehr sind. OpenAI dokumentiert mit Function Calling denselben Grundgedanken aus einer anderen Richtung: Modelle arbeiten robuster, wenn Aktionen nicht als freier Text, sondern als definierte Aufrufe beschrieben werden. Das beweist nicht, dass MCP zwangsläufig der Marktstandard wird. Es zeigt aber, warum standardisierte Tool-Aufrufe in produktiven KI-Setups an Gewicht gewinnen.
Ein Punkt wird in frühen Diskussionen fast immer unterschätzt: MCP macht Zugriffe strukturierter, aber nicht automatisch sicher oder sauber. Ein zu breites Werkzeug bleibt riskant. Ein Service-Konto mit zu vielen Rechten bleibt riskant. Fehlende Protokollierung bleibt fehlende Protokollierung. Das Protokoll ordnet den Zugriff. Es repariert keine schlechte Betriebsarchitektur.
Wann sich MCP lohnt und wann API oder iPaaS die bessere Wahl ist
Die beste Entscheidungshilfe ist keine Technologiedebatte, sondern eine Wiederverwendungsfrage. Wenn ein Team nur einen Assistenten mit zwei oder drei klaren Leseabfragen baut, ist direkte API-Anbindung meist die bessere Wahl. Weniger Schichten, weniger Betrieb, schneller live.
Die Rechnung kippt, sobald dieselben Funktionen in mehreren KI-Anwendungen auftauchen. Dann wird aus jeder schnellen Einzelintegration ein späteres Migrationsproblem. Ein MCP-Layer spart selten die erste Anbindung. Er spart die dritte, vierte und fünfte, weil Werkzeuge nicht jedes Mal neu modelliert, dokumentiert und abgesichert werden müssen.
| Ansatz | Passt gut, wenn | Stärke | Grenze |
|---|---|---|---|
| Direkte API-Anbindung | ein enger Use Case, wenige Systeme, kaum Wiederverwendung | schneller Start, wenig Zusatzschichten | enge Kopplung an Bot-Logik und Modellumgebung |
| MCP-Layer | mehrere KI-Anwendungen, wiederkehrende Werkzeuge, möglicher Modellwechsel | einheitlicher Tool-Zugriff, bessere Wiederverwendung | zusätzlicher Aufwand für Betrieb, Versionierung und Sicherheit |
| iPaaS oder bestehende Integrationsplattform | reife Middleware, viele bestehende Flüsse, klare Governance | Policies, Konnektoren und Monitoring oft schon vorhanden | Werkzeugsemantik für KI muss zusätzlich definiert werden |
Ein häufiger Fehlkauf im aktuellen Markt: Unternehmen kaufen zuerst einen sichtbaren Copiloten und verschieben die Zugriffsschicht auf später. Das sieht in Demos gut aus und wirkt im Einkauf kleiner. Im Betrieb wird es oft teurer, weil dieselben Rechte-, Logging- und Ownership-Fragen in jedem neuen Assistenten wieder auftauchen. Mein strittiger Punkt dazu: Wer heute einen Copiloten ohne saubere Zugriffsschicht einkauft, kauft in vielen Fällen nur eine teure Demo mit aufgeschobener Integrationsrechnung.
Bestehende Middleware bleibt dabei wertvoll. Wer bereits eine saubere iPaaS- oder API-Landschaft hat, sollte sie nicht wegen MCP neu erfinden. In vielen Fällen sitzt MCP davor: als KI-taugliche Zugriffsschicht, während Fachlogik, Policies und Konnektoren in der vorhandenen Integrationsarchitektur bleiben. Für diese Grundlage ist Integrationen und APIs oft wichtiger als jede Protokolldiskussion.
Die technische Debatte wird trotzdem oft an der falschen Stelle geführt. Teams sprechen zuerst über Protokolle und erst danach über Rechte, Logs, Timeouts, Fehlertypen, Versionierung und Ownership. Das ist verkehrt herum. Wenn diese Punkte ungeklärt sind, verpackt MCP nur bestehende Unordnung in ein neues Format.
Latenz gehört ebenfalls in die Entscheidung. Jeder zusätzliche Layer kostet Zeit. Für interne Recherche ist das meist akzeptabel. Für interaktive Prozesse mit vielen Tool-Aufrufen pro Antwort kann es spürbar werden. Dann entscheiden Werkzeugzuschnitt, Caching und Parallelisierung darüber, ob die Lösung produktiv wirkt oder zäh bleibt.
Drei Einsatzfälle, in denen MCP operativ Sinn ergibt oder eben nicht
1. Wissensassistent für Richtlinien, Dokumente und verteilte Quellen
Das ist oft der sauberste Einstieg. Mitarbeitende suchen Informationen in Wissensplattformen, Dateifreigaben, Richtlinienordnern und Produktdokumentation. Das Modell soll hier nicht handeln, sondern aktuelle und freigegebene Quellen zuverlässig finden, laden und referenzieren.
MCP passt gut, wenn dieselben Lesezugriffe mehrfach gebraucht werden: Dokumentensuche, Laden eines Dokuments nach ID, Abruf einer Richtlinie nach Thema, Rückgabe einer Quelle mit Berechtigungsprüfung. Der Nutzen liegt nicht in einem großen Universalwerkzeug, sondern in einem kleinen, kontrollierbaren Katalog.
Der Hauptnutzen ist Klarheit im Zugriff. Ein Assistent kann dieselben Werkzeuge nutzen wie ein zweiter Assistent für Onboarding- oder Compliance-Fragen, ohne dass jedes Team seine eigene Dokumentensuche neu baut. Das spart Entwicklungszeit und reduziert widersprüchliche Tool-Definitionen.
Die Hauptgrenze liegt fast nie im Protokoll. Sie liegt in der Wissensbasis. Wenn dieselbe Richtlinie auf Deutsch, Polnisch und Englisch in mehreren Versionen kursiert und niemand festlegt, welche Fassung Vorrang hat, produziert auch ein sauber gebauter MCP-Server widersprüchliche Antworten. Für Unternehmen in Polen und im EU-Binnenmarkt ist Mehrsprachigkeit kein Komfortmerkmal, sondern ein Architekturthema. Werkzeuge müssen Quellen priorisieren, Sprachvarianten verknüpfen und lokale von konzernweiten Dokumenten trennen.
Ein konkreter Ablauf aus der Praxis: Eine Mitarbeiterin fragt nach der gültigen Reisekostenregel für eine polnische Tochtergesellschaft. Der Assistent darf nicht einfach das erstbeste PDF aus einer globalen SharePoint-Struktur ziehen. Er muss zuerst den Mandantenkontext erkennen, dann die lokale Richtlinie priorisieren, die passende Sprachversion laden und im Zweifel die zentrale Konzernregel nur ergänzend heranziehen. Genau für solche eng definierten Zugriffe ist ein kleiner MCP-Werkzeugkatalog nützlich. Nicht als Magie, sondern als Disziplin.
