MCP in der Praxis: Wie Unternehmen interne Tools sicher an KI-Assistenten anbinden

Das eigentliche Problem: KI ohne Kontext ist halbgar

Die meisten KI-Projekte in Unternehmen scheitern nicht daran, dass das Modell zu dumm ist. Sie scheitern daran, dass das Modell nichts weiß. Nichts über den Kunden, der gerade anruft. Nichts über den Auftragsstatus, der seit drei Tagen offen ist. Nichts über die interne Richtlinie, die letzte Woche aktualisiert wurde.

Das Ergebnis: Mitarbeiter fragen den KI-Assistenten etwas, bekommen eine generische Antwort, und wechseln dann manuell ins CRM, ins ERP, ins Ticketsystem. Genau das, was die KI eigentlich ersetzen sollte.

Das Problem hat einen Namen: fehlende Kontextanbindung. Und es hat seit einiger Zeit eine Lösung: das Model Context Protocol, kurz MCP.

Was MCP eigentlich ist — und was es nicht ist

MCP ist ein offener Standard, der festlegt, wie ein KI-Assistent mit externen Tools und Datenquellen kommuniziert. Nicht mehr, nicht weniger.

Stell dir vor, du hast einen neuen Mitarbeiter. Der ist klug, redet gut — aber er hat keinen Zugang zu euren Systemen. Er kann keine Kundendaten abrufen, keine Tickets öffnen, keine Bestellungen nachschlagen. Nützlich? Begrenzt.

MCP ist die Schnittstelle, die diesem Mitarbeiter kontrollierten Zugang gibt. Du entscheidest: Welche Systeme darf er sehen? Was darf er lesen, was darf er schreiben? Und jede Aktion wird protokolliert.

Technisch gesehen sitzt zwischen dem KI-Modell und deinen internen Systemen ein sogenannter MCP-Server. Dieser Server stellt dem Modell eine Liste von Funktionen bereit — zum Beispiel „Kundendaten abrufen", „Ticket erstellen" oder „Lagerbestand prüfen". Das Modell wählt autonom, welche Funktion es für eine Anfrage braucht, ruft sie auf und verarbeitet das Ergebnis.

Das Entscheidende: Das Modell sieht nie direkt deine Datenbank. Es kommuniziert ausschließlich über den MCP-Server — und der ist dein Kontrollpunkt.

Warum das für Unternehmen ein Paradigmenwechsel ist

Vor MCP gab es zwei Wege, KI an interne Systeme anzubinden. Entweder du hast für jedes Tool eine individuelle Integration gebaut — teuer, fragil, wartungsintensiv. Oder du hast alles in den Prompt gepackt — unsicher, unstrukturiert, nicht skalierbar.

MCP standardisiert diesen Prozess. Ein KI-Assistent, der MCP versteht, kann theoretisch mit jedem MCP-kompatiblen Tool sprechen — ohne dass du jedes Mal eine neue Integration baust. Das ist der gleiche Gedanke wie bei USB: ein Standard, viele Geräte.

Konkret bedeutet das: Wenn du heute einen MCP-Server für dein CRM baust, kannst du morgen dasselbe Modell auch für deinen Support-Assistenten nutzen — ohne die CRM-Anbindung neu zu entwickeln.

Ein konkretes Szenario: Kundentermin-Vorbereitung

Nehmen wir ein Beispiel aus der Praxis. Ein Vertriebsmitarbeiter hat in 20 Minuten einen Kundentermin. Er fragt den internen KI-Assistenten: „Bereite mich auf das Gespräch mit Müller GmbH vor."

Was passiert im Hintergrund? Der Assistent ruft über den MCP-Server mehrere Funktionen auf — parallel oder nacheinander:

• Letzte Bestellungen und offene Angebote aus dem ERP
• Kommunikationsverlauf der letzten 90 Tage aus dem CRM
• Offene Support-Tickets aus dem Ticketsystem
• Relevante interne Notizen aus der Wissensdatenbank

Das Ergebnis: Eine strukturierte Zusammenfassung, die der Mitarbeiter in zwei Minuten lesen kann. Kein manuelles Zusammensuchen aus vier Systemen. Kein Vergessen des letzten Beschwerdetickets.

Das klingt simpel. Ist es aber nicht — ohne MCP wäre jede dieser Datenquellen eine separate Baustelle.

Sicherheit: Der Haken, den viele unterschätzen

Mal ehrlich: Wenn ein KI-Modell auf deine internen Systeme zugreifen kann, ist das auch ein Risiko. Ein schlecht konfigurierter MCP-Server kann mehr Schaden anrichten als ein schlecht konfigurierter Mitarbeiter.

Die häufigsten Probleme in der Praxis:

• Zu breite Zugriffsrechte. Der MCP-Server darf alles lesen und schreiben — obwohl der Assistent nur Lesezugriff braucht. Minimalprinzip gilt auch hier.
• Kein Audit-Log. Wer hat wann was abgerufen? Ohne Protokollierung gibt es keine Nachvollziehbarkeit — und im Zweifel auch keine DSGVO-Compliance.
• Prompt Injection. Ein Angreifer schleust über einen manipulierten Datensatz Anweisungen ins Modell ein — und bringt es dazu, unerwünschte Aktionen auszuführen. Das ist kein theoretisches Risiko. Es wurde bereits in produktiven MCP-Umgebungen nachgewiesen.
• Unkontrollierte Schreibzugriffe. Ein Assistent, der Tickets erstellen, E-Mails versenden und Datensätze ändern kann — ohne Bestätigungsschritt — ist ein Risiko.

Die Lösung ist nicht, auf MCP zu verzichten. Die Lösung ist, es mit der gleichen Sorgfalt aufzusetzen wie jede andere kritische Systemintegration.

Wie ein sicheres MCP-Setup in der Praxis aussieht

Ein paar Prinzipien, die ich in Projekten konsequent umsetze:

Least Privilege — immer. Jeder MCP-Server bekommt nur die Rechte, die er für seine Aufgabe braucht. Ein Assistent für die Terminvorbereitung braucht Lesezugriff auf CRM und ERP — aber keinen Schreibzugriff und keinen Zugang zur Buchhaltung.

Read vs. Write trennen. Lesende Aktionen laufen automatisch. Schreibende Aktionen — Ticket erstellen, E-Mail senden, Datensatz ändern — brauchen eine explizite Bestätigung durch den Nutzer. Das ist kein Komfortverlust, das ist Kontrolle.

Jede Aktion protokollieren. Welche Funktion wurde aufgerufen, mit welchen Parametern, zu welchem Zeitpunkt, von welchem Nutzer ausgelöst? Dieses Log ist dein Sicherheitsnetz — und dein Audit-Trail für Compliance.

MCP-Server intern hosten. Für sensible Unternehmensdaten gehört der MCP-Server in deine eigene Infrastruktur, nicht in eine externe Cloud. Das ist bei DSGVO-relevanten Daten kein Nice-to-have, sondern Pflicht.

Funktionen granular definieren. Statt einer Funktion „Alle Kundendaten abrufen" lieber mehrere spezifische Funktionen: „Letzte drei Bestellungen abrufen", „Offene Angebote abrufen", „Kontaktperson abrufen". Je enger der Scope, desto kleiner die Angriffsfläche.

Welche Tools sich für den Einstieg eignen

Für Unternehmen, die ohne großes Entwicklerteam starten wollen, ist n8n ein sinnvoller Ausgangspunkt. Damit lassen sich MCP-Server visuell aufbauen und mit bestehenden Systemen verbinden — ohne dass jede Integration von Grund auf neu programmiert werden muss. Wer bereits auf Make setzt, findet dort ähnliche Möglichkeiten.

Für komplexere Setups mit eigener Datenhaltung — etwa wenn Kontext aus vergangenen Gesprächen gespeichert und abgerufen werden soll — kommt Supabase als Backend ins Spiel. Einfach zu integrieren, DSGVO-konform hostbar, und gut dokumentiert.

Das Wichtigste dabei: Fang klein an. Ein MCP-Server, eine Datenquelle, ein klar definierter Anwendungsfall. Nicht sofort alles anbinden. Verstehen, wie sich das Modell verhält, wenn es Zugang zu echten Daten hat — und dann schrittweise erweitern.

Was sich im Arbeitsalltag wirklich verändert

Wenn MCP richtig aufgesetzt ist, verändert sich nicht nur die Effizienz — es verändert sich die Art, wie Mitarbeiter mit Informationen arbeiten.

Der Vertriebsmitarbeiter fragt nicht mehr fünf Systeme ab, bevor er zum Kunden fährt. Der Support-Mitarbeiter sieht sofort den vollständigen Kontext eines Tickets, ohne selbst recherchieren zu müssen. Die Geschäftsführerin fragt morgens nach dem aktuellen Auftragseingang — und bekommt eine Antwort, die direkt aus dem ERP kommt, nicht aus einer gestern Abend manuell erstellten Tabelle.

Das ist keine Zukunftsvision. Das läuft heute in Unternehmen, die MCP ernsthaft einsetzen.

Der Unterschied zwischen einem KI-Assistenten, der nur im Chat lebt, und einem, der wirklich in deine Prozesse integriert ist — das ist MCP. Aber nur, wenn Sicherheit und Kontrolle von Anfang an mitgedacht werden. Nicht als Nachbau, sondern als Fundament.

Wenn du wissen willst, wie ein solches Setup für dein Unternehmen konkret aussehen könnte — welche Systeme sich eignen, wie der MCP-Server sicher konfiguriert wird und was realistisch in drei Monaten umsetzbar ist — melde dich bei mir.