Wenn der Chatbot handelt: Tools, APIs und MCP für Unternehmensprozesse

Ein Chatbot, der nur redet, ist ein schlaueres Suchfeld. Er beantwortet die Frage, wie der Bestellprozess läuft — den Kundenanruf nimmt er Ihnen trotzdem nicht ab. Entscheidend wird es beim nächsten Schritt: Der Assistent führt die Aktion selbst aus. „Leg für Kunde Meier ein Ticket an und häng das Angebot dran“ — und im Ticketsystem liegt ein Ticket mit angehängtem Angebot. Dafür braucht der Bot zwei Dinge: einen Weg, Ihre Systeme anzurufen, und klare Regeln, wann er das darf.

„Tool-Calling“ klingt nach Hexerei, ist aber ein unspektakulärer Mechanismus. Man beschreibt dem Sprachmodell die verfügbaren Aktionen wie Einträge in einer Werkzeugliste: Es gibt die Funktion crm.kunde_suchen (braucht: Name oder Kundennummer, liefert: Kunde mit Adresse und zuständigem Betreuer) und die Funktion ticket.anlegen (braucht: Kunde, Betreff, Beschreibung, Priorität). Das Modell selbst tippt keine Tasten — es entscheidet, welches Werkzeug mit welchen Werten aufzurufen ist, und Ihr Backend führt den Aufruf über die ganz normale REST-API aus.

In der Praxis sieht das so aus: Jemand fragt „Wie ist der Status bei Meier und leg wegen der Reklamation ein Ticket an, bevor ich in den Urlaub gehe.“ Der Assistent sucht den Kunden im CRM, liest den offenen Vorgang, formuliert den Tickettext und legt das Ticket an — mit Quellenangabe, woher die Informationen stammen. Zwei Werkzeugaufrufe, beide über Schnittstellen, die es längst gibt. Die Magie liegt höchstens in der Formulierung; die Technik ist Integrationsarbeit.

Klassisch war bei der Systemanbindung jeder gegen jeden: Für jedes KI-Werkzeug musste jede Schnittstelle einzeln angebunden werden. Das Model Context Protocol (MCP) ist ein offener Standard, der diese Kombination entkoppelt: Ein System (CRM, Ticketsystem, Kalender) stellt seine Funktionen einmal als MCP-Server bereit, und jedes MCP-fähige Werkzeug kann sie nutzen. Statt N×M Adaptern baut man N — und kann die Werkzeuge später tauschen, ohne die Anbindung neu zu machen.

Die ehrliche Einordnung: MCP ist nützlich, aber keine Bedingung. Wenn der Assistent genau ein CRM und ein Ticketsystem anfasst, ist ein normaler REST-Adapter genauso richtig — und wartbarer. Der Standard lohnt sich, wenn mehrere KI-Werkzeuge auf dieselben Quellen zugreifen sollen oder wenn Sie offene MCP-Server für Ihre Systeme ohnehin anbieten. Ein Werkzeug um des Namens willen einzusetzen, ist auch hier der schlechtere Weg.

Ein Bot, der liest, kann höchstens falsche Antworten geben. Ein Bot, der schreibt, kann Bestellungen stornieren. Deshalb gilt für handelnde Assistenten eine andere Latte als für redende:

• Rechte geerbt, nicht erfunden: Der Assistent darf nur Aktionen ausführen, die der Fragende selbst ausführen dürfte. Ein Sachbearbeiter kann ein Ticket anlegen, aber keinen Auftrag löschen.
• Bestätigungsstufen vor schreibenden Aktionen: Lesende Aufrufe laufen direkt; bevor etwas angelegt, geändert oder gelöscht wird, zeigt der Bot, was er tun wird, und wartet auf ein ausdrückliches „Mach das“. Je kritischer das System, desto höher die Hürde — bis hin zur Freigabe durch eine zweite Person.
• Lückenlose Protokolle: Wer hat wann welches Werkzeug mit welchen Parametern aufgerufen und welches Ergebnis kam zurück? Das ist keine Misstrauenskultur, sondern die Voraussetzung, um im Fehlerfall nachvollziehen zu können, was passiert ist — und gegenüber Audit und Kunden sauber zu bleiben.
• Kleine Werkzeugliste: Nur anbieten, was gebraucht wird. Jedes Werkzeug ist eine Tür; eine Tür, die niemand benutzt, sollte erst gar nicht eingebaut werden.

Eine Aktion lohnt sich über den Chat, wenn drei Dinge zusammenkommen: Sie passiert häufig genug, dass sich das Tippen lohnt; sie ist formalisiert (definierte Felder, klare Regeln); und der Auslöser ist ohnehin ein Gespräch („Der Kunde ruft an, leg das Ticket an“). Ungeeignet sind Aktionen mit seltener, aber existenzieller Wirkung — monatliche Gehaltsläufe oder Vertragskündigungen gehören in einen Prozess mit vier-Augen-Prinzip, nicht in einen Chat.

Und noch eine ehrliche Einschränkung: Tool-Anbindung ist kein Projekt, das man über Nacht nebenbei macht. Sie setzt voraus, dass Ihre Systeme überhaupt brauchbare Schnittstellen haben und dass Rechte sauber gepflegt sind. Beides ist oft mehr Arbeit als der Chatbot selbst — und beides nützt Ihnen auch ohne ihn.

Der Unterschied zwischen Suchmaschine und Assistent ist die Möglichkeit zu handeln. Damit das tragfähig ist, braucht es geerbte Rechte, Bestätigungsstufen vor Schreibaktionen und Protokolle, die alles nachvollziehbar machen. Wie ein solcher Assistent — wahlweise über REST oder MCP an Ihre Systeme angebunden — konkret aussieht, zeigen wir auf unserer Seite zum KI-Assistenten mit Tool-Anbindung. Ob sich das für Ihre Prozesse rechnet, klären wir am besten direkt — hier geht's zum Erstgespräch.