Die meisten Betriebe haben kein Softwareproblem. Sie haben ein Verbindungsproblem. Die Webseite weiß nicht, was die Kasse weiß. Der Kalender weiß nicht, wer angerufen hat. Die Buchhaltung bekommt am Monatsende einen Stapel Papier, den vorher schon einmal jemand getippt hat. Jedes Werkzeug funktioniert für sich. Zusammen funktionieren sie nicht.
Genau darum geht es bei Schnittstellen. Und darum geht es, wenn im Moment alle über MCP reden.
Was eine API ist, ohne Fachsprache
Eine API ist eine Klappe in einem Programm, durch die ein anderes Programm hineinfassen darf. Nicht mehr und nicht weniger. Wer die Klappe öffnet, legt fest, was durchgeht: Termine lesen, einen Kunden anlegen, eine Rechnung holen. Alles andere bleibt zu.
Das Gute daran: Klappen sind verlässlich. Sie ändern ihre Form nicht, wenn jemand die Oberfläche neu gestaltet. Eine Webseite kann fünf Mal ihr Aussehen wechseln, die API dahinter bleibt dieselbe.
Das Mühsame daran: jede Klappe ist anders gebaut. Der Kalender will einen anderen Schlüssel als die Kasse. Die Buchhaltung will die Daten in einem anderen Format. Wer zehn Werkzeuge verbinden will, baut zehn Übersetzungen, pflegt zehn Zugänge und prüft zehn Stellen, wenn etwas nicht mehr geht. Das ist der Grund, weshalb Digitalisierung in kleinen Betrieben so oft nach der zweiten Verbindung stehen bleibt.
Was MCP daran ändert
MCP steht für Model Context Protocol. Man kann es sich als Norm für diese Klappen vorstellen, geschrieben für eine neue Art von Nutzer: nicht für einen Menschen, der klickt, und nicht für ein Programm, das starr abarbeitet, sondern für einen Assistenten, der versteht, was er tun soll.
Der Unterschied ist einfacher, als es klingt.
- Eine API sagt: hier ist eine Klappe, die Antwort kommt in dieser Form, den Rest musst du wissen.
- Ein MCP-Server sagt: hier sind meine Werkzeuge, so heißen sie, das können sie, so wird sie benutzt, und das darfst du damit.
Damit muss ein Assistent nicht mehr für jedes System eigens programmiert werden. Er liest die Werkzeugliste und arbeitet damit. Für Betriebe heißt das: die Verbindung zwischen Werkzeugen wird billiger, weil sie nicht mehr jedes Mal von Hand gebaut wird.
Eine API ist eine Tür. MCP ist eine Tür mit Beschriftung, Schlüsselordnung und Protokoll, wer wann hindurchgegangen ist.
Wo wir das selbst einsetzen
Wir schreiben hier nichts, was wir nicht selbst betreiben. Drei Beispiele aus unserem eigenen Haus.
Der Chatbot und das Kundenportal
Unsere KI-Assistenten laufen auf einem eigenen Dienst. Das Kundenportal, in dem unsere Kunden ihre Leistungen sehen, ist eine andere Anwendung. Beide sprechen über eine Schnittstelle miteinander, und zwar in einer Richtung: das Portal fragt, der Dienst antwortet. Jede Anfrage ist signiert und nur wenige Minuten gültig. Im Zugang steht, welche Assistenten der Anfragende sehen darf, und diese Grenze wird nicht im Portal, sondern im Dienst selbst durchgesetzt. Wer versucht, einen fremden Assistenten zu lesen, bekommt eine Absage, auch wenn er einen gültigen Zugang hat.
Das ist der Punkt, den man bei Schnittstellen am leichtesten falsch macht: Rechte prüft immer das System, das die Daten hat. Nicht das System, das sie anzeigt.
Die Pixel-Sammlung im Portal
Unser 1M-Pixel-Projekt ist eine eigene Plattform mit eigener Datenbank. Wer dort Pixel kauft, sieht seinen Bestand inzwischen auch im Kundenportal: Vorrat, Werke mit Zertifikat, Rechnungen. Kopiert wird dabei nichts. Das Portal liest bei jedem Aufruf frisch über eine Schnittstelle und schickt den Kunden für alles Weitere mit einem Einmal-Link hinüber. Es gibt keine zweite Anmeldung und keinen zweiten Datenbestand, der irgendwann von der Wahrheit abweicht.
Hosting, das ein Agent selbst bedienen kann
Das dritte Beispiel geht am weitesten. Für Kunden, die selbst entwickeln, betreiben wir Platz auf unserem Server: eigene Adresse, eigener Speicher, Ausrollen per Push. Dazu gibt es einen MCP-Zugang. Damit kann der Entwicklungsassistent des Kunden, etwa Claude Code auf seinem Rechner, unseren Bereich direkt bedienen: Zustand abfragen, ausrollen, Protokolle lesen, Umgebungsvariablen setzen, Domains verbinden, neu starten.
Vierzehn Werkzeuge, klar benannt, und jedes davon endet an der Grenze des eigenen Bereichs. Der Agent kommt nicht auf den Server, sieht keine anderen Kunden und kann nichts außerhalb des ihm zugewiesenen Platzes anfassen. Jeder Zugang ist einzeln widerrufbar. Der Kunde arbeitet in seinem Werkzeug weiter, ohne bei uns eine Oberfläche lernen zu müssen.
Was ein Betrieb davon hat, der nicht entwickelt
Die meisten unserer Kunden schreiben keinen Code. Für sie zählt nicht das Protokoll, sondern was dadurch möglich wird.
| Ohne Verbindung | Mit Verbindung |
|---|---|
| Anfrage kommt per Mail, wird abgetippt | Anfrage landet direkt als Termin im Kalender |
| Preise stehen an drei Stellen, zwei sind alt | Preise stehen an einer Stelle, alles zieht sie von dort |
| Monatsabschluss heißt sammeln und sortieren | Belege sind schon zugeordnet |
| Kunde fragt nach dem Stand, jemand schaut nach | Kunde sieht den Stand selbst |
Der Gewinn ist selten spektakulär. Er ist ruhig. Weniger Doppelarbeit, weniger Rückfragen, weniger Stellen, an denen ein Fehler entstehen kann.
Sicherheit ist der eigentliche Teil der Arbeit
Eine Schnittstelle zu bauen ist schnell erledigt. Sie so zu bauen, dass man nachts ruhig schläft, dauert länger. Woran wir uns halten:
- Getrennte Geheimnisse. Jede Verbindung hat ihren eigenen Schlüssel. Wird einer getauscht, stehen nicht alle anderen still.
- Kurze Gültigkeit. Ein Zugang, der fünf Minuten gilt, ist nach einem Abfluss wertlos.
- Grenzen im Datensystem. Wer was sehen darf, entscheidet die Seite mit den Daten.
- Nur lesen, wenn Lesen reicht. Die meisten Verbindungen brauchen keine Schreibrechte.
- Protokoll. Jeder Zugriff ist nachvollziehbar, mit Zeit, Herkunft und Umfang.
- Widerrufbar. Ein einzelner Zugang lässt sich abschalten, ohne dass der Betrieb stehen bleibt.
Wer einem Assistenten Zugriff auf betriebliche Systeme gibt, sollte genau diese sechs Punkte verlangen. Von uns und von jedem anderen.
Wann eine Schnittstelle die falsche Antwort ist
Nicht jedes Problem ist eines der Verbindung. Wenn ein Ablauf im Kopf des Inhabers unklar ist, wird er durch eine Schnittstelle nur schneller unklar. Zwei Systeme zu verbinden, die beide das Gleiche verwalten, verdoppelt den Pflegeaufwand statt ihn zu halbieren. Und eine Verbindung, die niemand versteht, wird beim ersten Ausfall zum Risiko.
Unsere Reihenfolge ist deshalb immer dieselbe: erst den Ablauf klären, dann entscheiden, wo die Wahrheit liegt, und erst danach verbinden.
Kurz gesagt
- Eine API ist eine definierte Klappe in ein Programm.
- MCP ist eine Norm für solche Klappen, geschrieben für Assistenten, die verstehen, was sie tun sollen.
- Wir nutzen beides intern: Portal und Chatbot, Portal und Pixel-Projekt, Hosting mit MCP-Zugang für die Agenten unserer Kunden.
- Der Nutzen für den Betrieb ist weniger Doppelarbeit, nicht mehr Technik.
- Die Arbeit steckt in der Absicherung, nicht in der Verbindung.
Wenn du wissen willst, ob sich das bei dir lohnt, reicht ein kurzes Gespräch über deine Abläufe. Wir sagen auch, wenn es sich nicht lohnt.
