MCP-Protokoll im Mittelstand KI-Agenten an eigene Systeme anbinden.

KI-Assistenten werden erst dann richtig nützlich, wenn sie nicht nur reden, sondern handeln können — eine Rechnung im ERP nachschlagen, einen Kundenstatus im CRM prüfen, einen Datensatz aus der Datenbank ziehen. Bis vor Kurzem bedeutete jede solche Anbindung einen eigenen, fragilen Connector: viel Eigenbau, viel Wartung, und bei jedem neuen Tool fing man wieder von vorne an. Das Model Context Protocol (MCP) ist ein offener Standard, der genau dieses Problem adressiert. Es definiert eine einheitliche Sprache, in der KI-Anwendungen mit externen Werkzeugen und Datenquellen sprechen — ähnlich wie USB einst die Wildwuchs-Stecker vereinheitlichte. Für den Mittelstand ist das relevant, weil es die Integration von KI-Agenten in die eigene Systemlandschaft planbarer und sicherer macht. Dieser Beitrag erklärt, wie MCP funktioniert, welche Connectoren es bereits gibt, was die Anbindung an ERP, CRM und Datenbanken realistisch kostet — und wo die Grenzen liegen, gerade bei Sicherheit und Reife, die man kennen muss, bevor man einen Agenten an produktive Systeme lässt.

Das Problem vor MCP: jeder Connector ein Einzelfall.

Wer einen KI-Assistenten an ein Unternehmenssystem koppeln wollte, stand bisher vor demselben Muster: Für jede Kombination aus KI-Anwendung und Zielsystem brauchte es eine maßgeschneiderte Brücke. ERP-Anbindung, CRM-Anbindung, Datenbankzugriff — jeweils eigene Logik, eigene Authentifizierung, eigene Fehlerbehandlung. Bei wenigen Tools ging das. Bei einem Dutzend wurde es zum Wartungsalbtraum, weil jede API-Änderung eine eigene Reparatur verlangte.

Dieses Problem skaliert quadratisch: M KI-Anwendungen mal N Werkzeuge ergeben im Extremfall M×N Integrationen. Das ist genau die Art von Komplexität, die im Mittelstand Projekte zum Stillstand bringt — nicht weil die Idee schlecht ist, sondern weil der Klebstoff zwischen den Systemen mehr Aufwand frisst als der eigentliche Nutzen.

MCP bricht dieses Muster auf, indem es eine standardisierte Schnittstelle dazwischenschaltet. Statt M×N individuellen Brücken gibt es einen gemeinsamen Standard: Jede KI-Anwendung spricht MCP, jedes Werkzeug stellt einen MCP-Server bereit. Aus dem Produkt wird eine Summe — M plus N statt M mal N.

Wie MCP grundsätzlich funktioniert.

MCP folgt einer einfachen Client-Server-Architektur. Die KI-Anwendung — etwa ein Assistent oder Agent — ist der Client. Jedes anzubindende System wird über einen MCP-Server verfügbar gemacht, der drei Arten von Bausteinen anbietet:

• Tools: ausführbare Aktionen, die das Modell aufrufen kann — „Rechnung suchen“, „Bestellung anlegen“, „Datensatz aktualisieren“.
• Resources: lesbare Datenquellen, auf die das Modell zugreifen kann — Dokumente, Datenbankinhalte, Dateien.
• Prompts: vordefinierte Vorlagen, die wiederkehrende Abläufe standardisieren.

Der Clou: Der MCP-Server beschreibt seine Fähigkeiten selbst — welche Tools es gibt, welche Parameter sie erwarten, was sie tun. Das Modell entdeckt diese Beschreibung zur Laufzeit und kann die Werkzeuge nutzen, ohne dass jemand sie fest in den Client einprogrammiert hat. Genau das macht den Ansatz so flexibel: Ein neuer MCP-Server ist sofort für jeden MCP-fähigen Client verwendbar, ohne Anpassung auf der Client-Seite.

Technisch läuft die Kommunikation über ein definiertes Nachrichtenformat, lokal oder über Netzwerk. Für das Verständnis im Management reicht das Bild: ein einheitlicher Adapter, an den sich beide Seiten halten.

Welche Connectoren es schon gibt.

MCP ist jung, aber das Ökosystem wächst schnell. Es gibt bereits eine wachsende Zahl fertiger MCP-Server — teils von Herstellern, teils aus der Open-Source-Community. Typische Kategorien:

Für Standardsysteme stehen die Chancen gut, dass ein brauchbarer Server existiert oder mit überschaubarem Aufwand gebaut werden kann. Bei spezialisierten oder älteren ERP-Systemen ist die Lage uneinheitlicher — hier kann ein Eigenbau-Server nötig werden, der die vorhandene API des Systems hinter der MCP-Schnittstelle kapselt. Die gute Nachricht: Dieser Server ist dann für jeden MCP-fähigen Assistenten nutzbar, der Aufwand fällt nur einmal an.

Anbindung an ERP, CRM und Datenbanken in der Praxis.

Im Mittelstand sind drei Anbindungen besonders gefragt — und jede hat ihr eigenes Profil. Eine Datenbank-Anbindung ist meist am einfachsten: Existiert ein generischer SQL-MCP-Server, ist der Leseteil oft in Tagen produktiv. Hier liegt der schnellste Mehrwert, etwa für natürlichsprachige Auswertungen.

Die CRM-Anbindung ist mittlerer Aufwand. Existiert ein fertiger Server für das eingesetzte CRM, ist die Anbindung primär Konfiguration und Rechtevergabe. Fehlt er, kapselt man die ohnehin vorhandene CRM-API in einen schlanken eigenen Server.

Die ERP-Anbindung ist am anspruchsvollsten — wegen Komplexität, Datensensibilität und oft eigenwilliger Schnittstellen. Realistisch beginnt man hier lesend und auf wenige, klar abgegrenzte Vorgänge beschränkt, bevor man überhaupt an schreibende Aktionen denkt.

Als grobe Größenordnung für einen ersten produktiven Anwendungsfall im Mittelstand sind je nach Systemlage einige Tage bis wenige Wochen Integrationsarbeit realistisch, wenn ein Server existiert — und deutlich mehr, wenn ein Eigenbau-Server samt Tests und Absicherung nötig ist. Wichtiger als die exakte Zahl ist das Vorgehen: klein anfangen, lesend, mit eng begrenzten Rechten.

Sicherheit: der entscheidende Punkt.

Ein KI-Agent, der im ERP schreiben oder im CRM Datensätze ändern darf, ist ein mächtiges und potenziell gefährliches Werkzeug. MCP standardisiert die Anbindung, löst aber nicht automatisch die Sicherheitsfrage — die bleibt Ihre Verantwortung. Vier Prinzipien sind nicht verhandelbar.

• Least Privilege: Der Agent bekommt nur die minimal nötigen Rechte. Ein Assistent, der Rechnungen nachschlagen soll, braucht keinen Schreibzugriff auf Stammdaten.
• Lesen vor Schreiben: Beginnen Sie mit reinen Leseaktionen. Schreibende Aktionen folgen erst, wenn das Lesen sich bewährt hat — und dann am besten mit menschlicher Freigabe bei folgenreichen Vorgängen.
• Prompt-Injection ernst nehmen: Wenn der Agent fremde Inhalte verarbeitet (E-Mails, Dokumente), können darin versteckte Anweisungen stehen, die ihn zu unerwünschten Aktionen verleiten. Schreibende Tools brauchen daher Grenzen, die das Modell nicht selbst aufheben kann.
• Protokollierung: Jede Aktion des Agenten wird nachvollziehbar geloggt — wer, was, wann, mit welchem Ergebnis.

Diese Punkte sind kein Grund, MCP zu meiden — aber ein Grund, es erwachsen einzuführen. Wer einem Agenten ungebremsten Schreibzugriff auf produktive Systeme gibt, handelt fahrlässig, egal wie elegant das Protokoll ist.

Wo MCP heute an Grenzen stößt.

Bei aller Eleganz: MCP ist ein junger Standard, und das hat Konsequenzen. Erstens die Reife des Ökosystems: Die Qualität verfügbarer Server schwankt stark. Manche sind solide gepflegt, andere sind Wochenend-Projekte ohne Sicherheitsfokus. Ein Server aus unklarer Quelle gehört nicht ungeprüft an Produktivsysteme.

Zweitens die Zuverlässigkeit agentischer Abläufe: Dass ein Modell Tools aufrufen kann, heißt nicht, dass es immer das Richtige tut. Mehrschrittige Aufgaben können entgleisen — falsches Tool, falsche Parameter, Schleifen. Je folgenreicher die Aktion, desto mehr braucht es Leitplanken und menschliche Kontrolle.

Drittens Standard-Dynamik: Das Protokoll entwickelt sich weiter, Details ändern sich. Wer heute baut, sollte mit gewisser Anpassungsarbeit über die Zeit rechnen.

Viertens Eignung: Nicht jeder Anwendungsfall braucht einen Agenten. Für einen festen, immer gleichen Ablauf ist eine klassische Automatisierung oft robuster und billiger als ein KI-Agent mit MCP. Der Mehrwert von MCP entfaltet sich dort, wo Flexibilität und natürlichsprachige Bedienung echten Nutzen bringen — nicht als Selbstzweck.

Ein realistischer Einstieg.

Ein vernünftiger Weg in MCP beginnt nicht beim ERP-Schreibzugriff, sondern bei einem kleinen, risikoarmen Lesefall mit klarem Nutzen. Bewährt hat sich folgende Reihenfolge:

• Use-Case wählen: ein konkreter, lesender Anwendungsfall mit erkennbarem Wert — etwa „Mitarbeiter fragen den Lagerbestand oder den Auftragsstatus in natürlicher Sprache ab“.
• Server klären: Prüfen, ob ein vertrauenswürdiger MCP-Server für das Zielsystem existiert oder ein schlanker Eigenbau nötig ist.
• Rechte minimal setzen: nur Lesen, nur die nötigen Datenbereiche, eigener Technik-Account mit klarer Berechtigung.
• Pilot mit echten Nutzern: in einer abgegrenzten Gruppe testen, Logs auswerten, Fehlverhalten beobachten.
• Erst dann erweitern: weitere Systeme, später schreibende Aktionen mit Freigabe-Schritt.

So ein Pilot ist im Mittelstand oft in einigen Wochen machbar und liefert eine ehrliche Antwort auf die eigentliche Frage: Bringt ein angebundener KI-Agent in unserem Kontext genug Nutzen, um den Integrations- und Sicherheitsaufwand zu rechtfertigen? Diese Frage lässt sich an einem kleinen, sicheren Fall viel verlässlicher beantworten als an einer Folie — und genau dafür ist MCP gemacht.

Sie wollen prüfen, ob sich ein MCP-gestützter KI-Agent sinnvoll an Ihr ERP, CRM oder Ihre Datenbanken anbinden lässt? Unverbindlich anfragen — wir bewerten Ihre Systemlandschaft, wählen einen risikoarmen Einstiegs-Use-Case und legen Architektur, Rechte und Absicherung sauber fest.