Model Context Protocol (MCP): wie ein offener Standard KI-Anwendungen mit Unternehmenssystemen verbindet

Was MCP ist und was es nicht ist

Das Model Context Protocol, kurz MCP, ist ein offenes Protokoll, das beschreibt, wie ein KI-Modell oder eine Anwendung auf externe Werkzeuge, Datenquellen und Wissen zugreift. Statt jeden Anbindungsweg pro Modell und pro System neu zu bauen, definiert MCP eine gemeinsame Sprache zwischen Client (der KI-Anwendung) und Server (dem angebundenen System).

MCP ist kein Modell, kein Agentenframework und kein neues KI-Produkt. Es ist eine Schnittstellenbeschreibung. Genauso wie HTTP nicht festlegt, was eine Webseite zeigt, sondern wie Browser und Server miteinander reden, legt MCP fest, wie ein KI-Client und ein angebundenes System Werkzeuge, Ressourcen und Prompts austauschen.

Diese Trennung ist für Unternehmensarchitekturen wichtig. MCP definiert die Verbindungsschicht. Welches Modell darüber arbeitet, in welcher Anwendung der Client läuft und welche Logik im Server steckt, bleibt eine eigenständige Entscheidung — und kann sich ändern, ohne dass die Verbindungsschicht jedes Mal neu gebaut wird.

Welches Problem MCP im Unternehmen tatsächlich löst

Wer in den letzten Jahren KI-Assistenten oder Agenten gebaut hat, kennt das Muster: Für jedes Modell und jede Plattform wird eine eigene Toolschicht entwickelt. Function Calling für ein Modell, Plugin-APIs für eine Plattform, Connector-Frameworks für ein anderes Produkt. Wechselt das Modell oder die Plattform, beginnt die Anbindung an die internen Systeme oft von vorn.

Genau diese Doppel- und Dreifacharbeit greift MCP an. Ein einmal gebauter MCP-Server für das CRM, das Wiki oder das ERP kann von verschiedenen KI-Clients genutzt werden, ohne dass die Anbindung dafür jeweils neu geschrieben werden muss. Das senkt nicht nur den Initialaufwand, sondern verringert auch den Lock-in an einen einzelnen Modell-Anbieter — eine Architekturfrage, die wir im Beitrag zur LLM-Auswahl im Unternehmen schon einmal in einem anderen Zuschnitt diskutiert haben.

MCP löst dabei nicht das Problem, dass eine KI-Anwendung gut werden muss. Es löst das Problem, dass die Schnittstelle zwischen KI und Systemen nicht in jedem Projekt neu erfunden werden sollte. Die inhaltliche Qualität von Antworten, Tool-Auswahl und Verhalten entsteht weiterhin in der Anwendung selbst.

MCP, Tool-Use und klassisches Function Calling

MCP ist eng verwandt mit dem, was viele Teams heute unter Tool-Use und Function Calling kennen. Ein Modell entscheidet, welches Werkzeug aufgerufen wird, mit welchen Argumenten, und verarbeitet das Ergebnis weiter. Der entscheidende Unterschied liegt nicht in der Idee, sondern in der Standardisierung.

Klassisches Function Calling ist anbietergebunden. Jeder Modell-Anbieter beschreibt Tools auf seine Weise, mit eigenen Schemata, eigenen Aufrufkonventionen und teilweise eigener Fehlerbehandlung. MCP bringt eine gemeinsame Beschreibung dieser Schicht. Tools werden einmal definiert und sind über jeden MCP-fähigen Client nutzbar — vom Desktop-Assistenten über interne Anwendungen bis zu agentischen Pipelines.

Für Architekturentscheidungen heißt das: MCP ersetzt Tool-Use nicht, sondern verlagert es auf eine andere Ebene. Die Frage „was darf das System tun?" bleibt. Die Frage „wie wird das pro Modell konkret beschrieben?" wird mit MCP einheitlicher beantwortet.

Wo MCP in Unternehmensarchitekturen Sinn ergibt

MCP entfaltet seinen Nutzen dort, wo Anbindungen wiederkehren oder wo eine KI-Architektur über mehrere Anwendungen hinweg dieselben internen Systeme nutzt. Drei Konstellationen tauchen besonders häufig auf.

Erstens als zentraler Zugang zu Wissensquellen. Eine MCP-Anbindung an Wiki, Ablage oder ein internes Dokumentenarchiv kann sowohl von einem produktiven RAG-System als auch von einem persönlichen Assistenten am Arbeitsplatz genutzt werden — mit denselben Berechtigungen, derselben Aufbereitung und derselben Quellenausweisung.

Zweitens als gemeinsame Aktionsschicht für Agenten. Wenn ein KI-Agent Vorgänge in CRM, Ticket-System oder Backoffice-Tools auslösen darf, profitieren alle späteren Agenten und Assistenten von einer einmal gebauten, gut abgesicherten Anbindung. Der spezifische Agent legt fest, wofür er die Aktionen nutzt, nicht, wie er sie ansteuert. Besonders stark wirkt dieses Muster in Multi-Agent-Systemen, in denen mehrere Agenten sich eine zentrale Werkzeugschicht teilen — mit pro Agent durchgesetzten Berechtigungen.

Drittens als Brücke zwischen verschiedenen KI-Clients. Ein internes Mitarbeitenden-Werkzeug, ein Vertriebsassistent und ein Backoffice-Agent greifen oft auf dieselben Datenquellen zu. Mit MCP entsteht hier nicht eine Punkt-zu-Punkt- Verbindung pro Anwendung, sondern eine wiederverwendbare Anbindungsschicht — die sauber im Bereich AI Engineering verantwortet werden kann.

Sicherheit, Berechtigungen und Audit-Anforderungen

Eine offene Verbindungsschicht macht KI-Anwendungen leistungsfähiger und gleichzeitig anspruchsvoller im Betrieb. Wer einem Client erlaubt, Werkzeuge auf produktiven Systemen aufzurufen, schafft eine neue, breite Angriffs- und Fehlerfläche.

Drei Punkte gehören in jede ernsthafte MCP-Einführung im Unternehmen. Erstens eine saubere Authentifizierung: Welcher Client darf welchen Server überhaupt erreichen? Zweitens fein granulare Berechtigungen pro Werkzeug: Welche Aktionen darf der Client tatsächlich ausführen, welche Datensätze sehen und welche Felder verändern? Drittens ein lückenloses Audit-Log auf der Server-Seite: Welcher Aufruf ist wann mit welchen Argumenten erfolgt, und welches Ergebnis hat der Client zurückbekommen?

Wir behandeln diese Schicht in unseren Projekten wie eine produktive API, nicht wie ein Experiment. Mit Validierung der Eingaben, klaren Fehlerpfaden, Rate-Limits und einem Verhalten, das zwischen „abgelehnt" und „nicht verfügbar" sauber unterscheidet. Das ist kein MCP-spezifisches Wissen, aber MCP zwingt dazu, es konsistent in einer eigenen Schicht zu lösen.

Qualität, Tests und Beobachtbarkeit

Eine MCP-Anbindung verändert auch, wo Qualität entsteht und wo sie gemessen werden muss. Solange Tools modellintern beschrieben waren, ließ sich Verhalten überwiegend in der Anwendung beobachten. Mit einer eigenen Server-Schicht entsteht ein zweiter Ort mit eigenem Lebenszyklus, eigener Versionierung und eigenen Fehlerquellen.

Praktisch heißt das: Tool-Beschreibungen werden zu versionierten Artefakten, Antwortformate brauchen Tests, und das Zusammenspiel zwischen Client und Server sollte in Regressionstests abgesichert sein. Sobald Modelle ausgetauscht oder aktualisiert werden, muss man wissen, welche Tools sich anders verhalten und welche Antworten plötzlich anders interpretiert werden. Diese Fragestellung gehört in unser Verständnis von LLM-Qualitätssicherung und sollte nicht erst beim ersten Vorfall in Produktion entdeckt werden.

Hinzu kommt die Beobachtbarkeit über die Verbindung selbst. Latenzen, Fehlerquoten, Werkzeugaufrufe pro Nutzer oder Sitzung sind Metriken, die in klassischen API-Dashboards landen sollten — nicht in Modell-Logs. MCP belohnt Architekturen, die ihre KI-Anbindung wie produktive Infrastruktur behandeln, und straft solche, die sie als Nebenprojekt führen.

Wann sich der Einsatz heute schon lohnt

MCP ist kein Selbstzweck. Für eine einzelne, eng gefasste Anwendung mit einem festen Modell und einer einzigen Datenquelle bringt der Standard kaum Vorteile gegenüber einer direkten Anbindung. Sinnvoll wird MCP dort, wo Anbindungen mehrfach genutzt werden oder wo absehbar mehrere KI-Anwendungen auf dieselben Systeme zugreifen.

Drei Anzeichen sprechen besonders dafür, MCP von Anfang an einzuplanen. Erstens, wenn mehrere Teams parallel KI-Anwendungen bauen, die im Kern dieselben Quellen brauchen. Zweitens, wenn ein Wechsel zwischen Modell-Anbietern wahrscheinlich oder gewünscht ist und die Anbindung nicht jedes Mal neu gebaut werden soll. Drittens, wenn die Roadmap von einzelnen Assistenten in Richtung echter Agenten geht und eine stabile, gut beobachtbare Aktionsschicht ohnehin entstehen muss.

Wenn keines dieser Muster zutrifft, ist es legitim, MCP heute noch nicht aufzusetzen und stattdessen die Anwendung mit einer aufgeräumten direkten Anbindung zu bauen — mit dem Vorbehalt, dass eine Migration zu MCP später dann ein eigener Schritt wird.

Typische Fehler in den ersten MCP-Projekten

Der erste Fehler ist, MCP als reine Technologieübung zu verstehen. Ein gut gebauter Server, der nichts verantwortet, ist im Unternehmen wertlos. Wer Aktionen über MCP anbietet, braucht eine Klarheit darüber, wer für die fachliche Korrektheit dieser Aktionen geradesteht — der Server-Verantwortliche, das anschließende Team, die Plattform.

Der zweite Fehler ist, alles auf einmal anschließen zu wollen. MCP-Server sind dort am wertvollsten, wo sie eine klar umrissene Domäne abbilden, nicht eine ganze Systemlandschaft. Lieber zwei sauber geschnittene Server als ein riesiger „Unternehmens-MCP", der nirgends wirklich verantwortet wird.

Der dritte Fehler ist, Berechtigungen erst spät zu denken. Ein Server, der heute ungeprüft alles zurückgibt, ist morgen ein Compliance-Problem, sobald der erste echte Mitarbeitendenkontext darüberläuft. Berechtigungen gehören in den allerersten Entwurf jedes MCP-Servers, nicht in eine spätere Härtungsphase.

Wann externe Unterstützung sinnvoll ist

Ein experimenteller MCP-Server für ein internes Wiki ist heute in wenigen Tagen gebaut. Eine produktive MCP-Architektur, an der mehrere KI-Anwendungen, Teams und Systeme hängen, ist eine andere Größenordnung — sowohl in Sicherheit als auch in Betrieb. Spätestens dort lohnt sich ein Blick von außen auf Schnitt, Berechtigungen und Lebenszyklus dieser Schicht.

Wir arbeiten mit Unternehmen, die MCP nicht aus Trend-Gründen einführen wollen, sondern weil sie eine wachsende KI-Landschaft beherrschbar halten müssen. Wenn das zu Ihrer Situation passt, sprechen Sie uns an, am besten bevor der erste Server in Produktion geht.