Wann sich eigene Tools lohnen – und wann MCP der nächste Schritt ist
Eigene KI-Tools und MCP sind gerade das Begriffspaar, das auf keiner KI-Folie fehlen darf. MCP – Model Context Protocol – ist der Standard, über den KI-Modelle Werkzeuge ansprechen. Kaum stellt jemand ein eigenes Tool vor, kommt die Frage: „Läuft das schon über MCP?“
Die Frage ist verständlich – aber sie kommt zu früh. Bevor du dich fragst, wie ein Tool angebunden ist, solltest du zuerst beantworten: Lohnt sich ein eigenes Tool überhaupt? Die meiste Wirkung entsteht nicht durch das Protokoll, sondern durch die Entscheidung, einen Prozess sauber in ein Werkzeug zu gießen. Am Beispiel unserer Raumbuchung mit n8n zeigen wir, wann sich das lohnt, wann du ohne MCP auskommst und ab wann MCP der nächste Schritt ist.
Grundsatzfrage
Wann sich ein eigenes Tool lohnt
Nicht jeder Handgriff braucht ein eigenes Werkzeug. Für vieles gibt es fertige Produkte, die besser gepflegt sind, als du es je selbst leisten könntest. Ein eigenes Tool lohnt sich erst, wenn drei Dinge zusammenkommen: Der Prozess wiederholt sich oft genug, er folgt eigenen Regeln, die kein Standardprodukt kennt, und die Datenhoheit ist dir wichtig.
Der Wert steckt nicht in der schicken Chatoberfläche, sondern in den Regeln dahinter. Wer sie kennt und automatisiert, hat schon 80 Prozent des Nutzens – ganz ohne Protokoll-Diskussion.
Ein eigenes Tool lohnt sich dort, wo ein Prozess klare Regeln hat, die kein Standardprodukt kennt.
Praxisbeispiel
Unser Beispiel: die Raumbuchung
Bei uns läuft die Raum-, Sitzplatz- und Parkplatzbuchung über ein eigenes Tool – in einer abgesicherten, komplett lokalen Chatumgebung. Die Bausteine sind bewusst schlicht:
- Open WebUI als Chatoberfläche für Buchungen in natürlicher Sprache.
- Ein lokales Modell (z. B. Qwen), das die Anfrage versteht – lokal, damit keine Daten das Haus verlassen.
- n8n als Motor, der die Buchungslogik ausführt.
- Python als Bindeglied: damit haben wir in Open WebUI die Tools gebaut – die Brücke zum n8n-Webhook.
Die Intelligenz steckt nicht im Modell, sondern in den Regeln: maximal ein Sitzplatz pro Person und Tag, abteilungsgebundene Räume nur für Berechtigte, HR-Komplettbuchungen als eigene Aktion. Das Modell versteht die Anfrage – ob sie erlaubt ist, entscheidet die Logik in n8n.
Und der Punkt, um den es geht: Für dieses Setup brauchst du kein MCP. Ein Client, ein Backend, eine geschlossene Umgebung – das reicht. MCP würde hier eine Standardisierungsschicht einziehen, für die es (noch) keinen Grund gibt.
Architektur
Lokale Tools heute, MCP als Ausbaustufe
Nächste Stufe
Wann MCP der nächste Schritt ist
Interessant wird MCP, wenn die geschlossene Umgebung aufbricht. Zwei Auslöser gibt es typischerweise: Du willst dieselben Tools wiederverwenden – nicht für jeden Ort neu bauen. Oder du willst deine Tools für andere Clients öffnen – eine IDE, einen anderen Assistenten, die Anwendung eines Kollegen.
Der MCP-Server stellt Werkzeuge bereit und sagt nach außen: „Diese Funktionen kann ich, so rufst du sie auf.“ Der MCP-Client ist die Anwendung, in der das KI-Modell läuft und entscheidet, welches Tool es aufruft. Kurz: Der Server bietet an, der Client fragt nach.
Der Gewinn ist die Standardisierung dazwischen: Jeder MCP-fähige Client kann jeden MCP-Server ansprechen. Du baust dein Tool einmal als Server – und öffnest es für viele.
Sicherheit
Der Haken: ein MCP-Server ohne Authentifizierung ist ein offenes Scheunentor
Genau hier entsteht das Risiko, das gern übersehen wird. In der lokalen Umgebung war klar, wer am Tool sitzt. Sobald du daraus einen MCP-Server machst, fällt dieser Kontext weg: Jeder, der die Instanz erreicht, hat dieselben Rechte.
Für ein Buchungstool ist das fatal. Die ganze Governance – ein Sitzplatz pro Person, Räume nur für Berechtigte, HR-Sonderrechte – setzt voraus, dass das System weiß, wer bucht. Ein offener MCP-Server behandelt jeden Aufruf, als käme er von einem Nutzer mit vollen Rechten.
Ein eigener MCP-Server braucht deshalb zwingend eine Authentifizierung (wer ruft an?) und darauf aufbauend eine Autorisierung (was darf diese Person?). Erst beides zusammen macht aus einem offenen Endpunkt ein kontrolliertes Werkzeug.
Lösen lässt sich das über n8n als Türsteher: n8n prüft das Token, ordnet es Person und Rolle zu und wendet erst dann die Buchungsregeln an. Der MCP-Server stellt bereit, n8n entscheidet über den Umfang. Dieselbe Logik wird zur Sicherheitsschicht.
cimt-Mehrwert
Sicherheit ist kein Nachgedanke
Man sieht, wie schnell aus einer technischen Bequemlichkeit ein Governance-Thema wird: Wer darf was, wer weist es nach, wer haftet, wenn etwas schiefläuft? Diese Fragen nehmen wir bei cimt ernst – als Teil der Architektur. Unser Informationssicherheits-Management ist nach ISO 27001 zertifiziert: geprüfte Prozesse, systematisches Risikomanagement und der Anspruch, Sicherheit von Anfang an mitzudenken statt nachträglich aufzusetzen.
FAQ
Häufige Fragen: Eigene KI-Tools und MCP
Was heißt MCP – und wofür steht die Abkürzung?
MCP steht für Model Context Protocol – ein offener Standard, der festlegt, wie KI-Modelle externe Werkzeuge und Datenquellen ansprechen. Eine gemeinsame Sprache zwischen Modell und Tool, damit nicht jede Anwendung ihre eigene Anbindung braucht.
Wann lohnt sich ein eigenes KI-Tool – und wann nicht?
Wenn ein Prozess sich wiederholt, eigenen Regeln folgt und die Datenhoheit wichtig ist. Für Standardaufgaben mit gepflegten Fertigprodukten lohnt sich der Eigenbau selten – Betrieb und Pflege werden unterschätzt.
Brauche ich für eigene Tools zwingend MCP?
Nein. In einer geschlossenen Umgebung mit einem Client – etwa Open WebUI, das über ein Python-Tool den n8n-Webhook aufruft – geht es ohne MCP. MCP lohnt erst, wenn mehrere Clients dieselben Tools nutzen sollen.
Was ist der Unterschied zwischen MCP-Server und MCP-Client?
Der Server stellt Werkzeuge bereit, der Client nutzt sie – die Anwendung, in der das Modell läuft. Der Server bietet an, der Client fragt nach. Jeder MCP-fähige Client kann jeden MCP-Server ansprechen.
Warum braucht ein eigener MCP-Server eine Authentifizierung?
Weil sonst jeder mit Zugriff auf die Instanz dieselben Rechte hätte. Der Nutzerkontext aus der lokalen Umgebung fällt weg – ohne Authentifizierung lassen sich rollenbasierte Regeln nicht mehr durchsetzen.
Wie lässt sich die Authentifizierung mit n8n lösen?
n8n arbeitet als vorgelagerte Sicherheitsschicht: Es prüft das Token, ordnet es Person und Rolle zu und wendet erst dann die Logik an. So bleibt der MCP-Server schlank, während n8n Identität und Rechte kontrolliert.
Ist eine lokale Chatumgebung wirklich sicher genug?
Ein lokales Modell hat den Vorteil, dass keine Daten das Haus verlassen. „Lokal“ allein ist aber keine Freigabe – Zugriffsrechte, Nachvollziehbarkeit und ein Berechtigungskonzept gehören dazu, genau die Themen eines zertifizierten ISMS.
Fazit
Was jetzt sinnvoll ist
- Klär zuerst die Vorfrage: Lohnt sich für diesen Prozess überhaupt ein eigenes Tool?
- Fang klein und lokal an – ein Client, ein Backend. Das reicht überraschend weit.
- Steck die Regeln in eine Logikschicht wie n8n, nicht ins Modell.
- Zieh MCP erst ein, wenn du Tools wiederverwenden oder für andere Clients öffnen willst.
- Plane in dem Moment die Authentifizierung mit ein – nicht danach.
Die Werkzeugfrage ist selten die erste Frage. Die erste Frage ist, welchen Prozess du wirklich beherrschen willst.
KI, die produktiv wird – erlebe es live
Am 10. September zeigen wir im Hamburger Volksparkstadion, wie aus KI-Piloten produktive Enterprise-Lösungen werden – mit echten Projekten, Stadiontour und Networking. Teilnahme kostenfrei, Plätze begrenzt.
