Dein MCP ist deine neue Homepage. Wir haben unsere gerade live geschaltet.

Wir haben unserem Produkt in zwei Wochen beigebracht, sich von einer KI steuern zu lassen. Ein neuer Nutzer, der seine erste Linie aufsetzt, kann jetzt Prüfzellen konfigurieren, Kameras registrieren, Toleranzen setzen und einen Operator onboarden, ohne unsere App jemals zu öffnen. Er richtet seinen Agenten auf unser MCP, und die Arbeit passiert im Chat.

Das ist kein Nebenfeature, sondern der Anfang einer grundlegenden Verschiebung in der Art, wie Software genutzt wird. Innerhalb von achtzehn Monaten wird die klassische Oberfläche eher der Ausnahmepfad sein als der Standardweg.

Hier liest Du, was wir getan haben, warum es zwei Wochen statt zwei Monate gedauert hat, und wo es uns überrascht hat.

Warum Navigationsmenüs eine sterbende Gattung sind

Seit dreißig Jahren sieht jedes B2B-SaaS-Produkt grob gleich aus: eine Sidebar, eine Top-Bar, ein Workspace, ein Einstellungsrad. Onboarding für einen neuen Nutzer heißt Doku lesen, herumklicken, ein Video schauen und sich langsam ein mentales Modell bauen, wo welche Funktion liegt. Das Produkt ist ein Ort, den man besucht und navigieren lernt.

Diese Annahme bricht gerade weg. Der Grund ist einfach: wenn ein Agent deine Doku lesen und deine APIs aufrufen kann, braucht der Nutzer die Navigation nicht mehr. Er sagt einfach, was er will, und der Agent findet heraus, wo das im Produkt liegt. Navigation wird zu Klempnerei, die der Nutzer nie sieht, ähnlich wie Paket-Routing in TCP.

Wir haben das am eigenen Onboarding besonders deutlich gesehen. Neue Kunden landeten früher auf einem Dashboard, fühlten sich erschlagen und pingten uns in Slack mit denselben fünf Fragen. Eine Inspektion einzurichten hieß, eine Kamera zu verbinden, ein Teil zu wählen, eine Region of Interest zu definieren, ein Modell zu trainieren und Toleranzen zu setzen, mit mindestens vier verschiedenen Screens dazwischen. Das Produkt funktionierte, und die Leute blieben dabei, aber die erste Stunde war eine Effort-Wand.

Unser Customer-Success-Team hat diese Wand auf den Schultern getragen. Wir haben deshalb eine andere Frage gestellt: was wäre, wenn ein neuer Nutzer nie einen Screen finden müsste?

Was MCP eigentlich ist, in einem Absatz

Model Context Protocol ist ein offener Standard von Anthropic, der jedem Agenten erlaubt, mit jeder Anwendung über einen einheitlichen Vertrag zu sprechen. Du legst eine Reihe von Tools offen, jedes davon eine typisierte Funktion mit klarer Beschreibung und klarem Schema, und der Agent entscheidet, welches Tool wann aufgerufen wird. Stell Dir das wie einen API-Vertrag vor, der für einen LLM-Konsumenten entworfen ist statt für einen menschlichen Entwickler. Der Agent liest deine Tool-Beschreibungen wie ein Junior-Engineer deine Doku lesen würde, und die Tool-Beschreibungen werden zur neuen Produktoberfläche.

Der Grund, warum das wichtig ist: jeder Agent in jedem Chat-Client weiß sofort, wie dein Produkt zu nutzen ist. Du brauchst keine Zapier-Integration, kein Custom-GPT, kein Partnerprogramm und kein Vendor-spezifisches SDK. Du lieferst das MCP aus und bist auf einen Schlag mit dem gesamten Agenten-Ökosystem verbunden.

Salesforce hat dieselbe Idee gerade produktisiert

Salesforce hat am 17. April seine Headless-360-Plattform angekündigt und damit den gesamten Stack über APIs und MCP zugänglich gemacht. Marc Benioff fasst die These in fünf Worten zusammen: "The API is the UI." Jason Lemkins Reaktion bei SaaStr war, dass das kein Produkt-Launch sei, sondern eine Beschreibung dessen, wie sein Unternehmen seit sechs Monaten läuft. SaaStr operiert heute auf einem Headless-Salesforce, mit drei Menschen, rund zwanzig Production-Agents und zwei AI-Agents auf Executive-Niveau (einem AI VP of Marketing und einem AI VP of Customer Success), die das CRM kontinuierlich lesen und schreiben, während an einem typischen Tag niemand im Team das Salesforce-UI öffnet. SaaStr gibt mittlerweile etwa fünfzehn Mal mehr für Agents aus als für Salesforce-Lizenzen, und das ist die nützlichere Zahl, weil sie zeigt, wohin sich der Wert im Stack verschiebt.

Das ist genau die Form der Verschiebung, die wir hier beschreiben, nur ein Stockwerk höher. Salesforce-als-Datenschicht für SaaStr ist das, was Enao-Vision-als-Datenschicht für unsere Kunden gerade wird. Das System of Record bleibt, wo es ist, die Agents lesen und schreiben über das Protokoll, und die Menschen sehen die Antworten in dem Chat-Client, den sie bevorzugen. Das klassische UI ist ein Pfad, den Nutzer gehen können, wenn sie wollen, nicht der Pfad, den sie gehen müssen.

Wie wir unseres in zwei Wochen ausgeliefert haben

Wir haben das Produkt nicht umgebaut, kein neues "MCP-Team" gegründet. Ein Engineer, zwei Wochen, auf dem bestehenden Code.

Grob, wie die Tage fielen:

Tag 1: die Tools definieren. Wir haben uns mit dem Customer-Success-Team hingesetzt und die Operationen aufgelistet, die ein neuer Nutzer in seiner ersten Stunde tatsächlich macht: ein Gerät registrieren, eine Inspektion anlegen, eine Region definieren, Referenzbilder hochladen, Gut- und Schlechtteile labeln, das Training starten, Toleranzen setzen, Ergebnisse anschauen. Das ergab rund fünfzehn Tools. Wir haben jedes als typisierte Signatur mit einer einzeiligen Beschreibung geschrieben und diese Beschreibungen wie Produkttexte behandelt, nicht wie Dev-Kommentare. Schlechte Beschreibungen sind schlechtes UX in der Agenten-Ära.

Tag 2 bis 7: die /mcp-Schicht bauen. Wir haben einen schmalen Adapter über unsere bestehenden Domain-Services gelegt und jedes MCP-Tool auf einen oder mehrere interne Aufrufe gemappt. Der Adapter ist das Einzige, was der Agent jemals sieht. Er übernimmt Authentifizierung, Parameter-Validierung, Fehler-Normalisierung und Rate-Limiting und reicht dann weiter. Wir haben den Agenten bewusst nicht direkt an die Domain-Schicht gelassen, weil wir einen sauberen Blast-Radius wollten, falls sich eine Tool-Beschreibung ändert.

Tag 8 und 9: Frontend. Wir haben ein einzelnes Panel in der App ergänzt, das den MCP-Verbindungsstatus, die verfügbaren Tools und einen Copy-Paste-Konfig-Block für Claude Desktop, Cursor, ChatGPT Desktop und einen generischen stdio-Client zeigt. Nichts Spektakuläres, aber es nimmt das letzte Stück "wo stecke ich das ein"-Friktion raus.

Tag 10 bis 12: Politur und Edge Cases. Lange Uploads, partielle Fehler, Idempotenz bei wiederholten Tool-Calls, sprechende Fehler-Strings, an denen der Agent ansetzen kann, und eine ordentliche Rate-Limit-Story. Wir haben außerdem strukturierte Progress-Messages ergänzt, damit der Agent dem Nutzer während langsamer Operationen wie einem Trainingsdurchlauf erzählen kann, was gerade passiert.

Das war es. Keine neue Infrastruktur, keine neue Datenbank, kein neues Auth-Modell, dazu rund vierhundert Zeilen Glue plus die Tool-Beschreibungen und eine Tests-Datei.

Was uns überrascht hat

Wir dachten, der harte Teil wäre das Protokoll oder die Agenten-Integration. War er nicht. Der harte Teil war Schema Drift.

Unsere Domain-Logik ist über zwei Jahre gewachsen. Sie hat die feinen Inkonsistenzen, die jede echte Codebase ansammelt: ein "Device"-Objekt, das in zwei Kontexten leicht Unterschiedliches bedeutet, eine "Inspection" mit fünf Feldern, die sich fast überlappen, ein Settings-Objekt, dessen Struktur zu zwei Dritteln historischer Zufall ist.

Ein menschlicher Nutzer navigiert um diesen Drift herum, ohne es zu merken, weil er immer nur einen Screen auf einmal sieht und das UI die Nähte glättet. Ein Agent sieht alles auf einmal, in den Tool-Beschreibungen, und wird verwirrt. Wir mussten einen kleinen, nüchternen Durchgang durch unsere Domain-Typen machen, damit sie sich sauber beschreiben ließen.

Dieser Durchgang war aus anderen Gründen wertvoll. Er hat zwei echte Bugs im bestehenden UI aufgedeckt, einen Onboarding-Flow vereinfacht, den wir seit Monaten aufräumen wollten, und unsere internen API-Docs um etwa dreißig Prozent verkürzt. Ein MCP zu bauen ist eine Forcing Function fürs Aufräumen deines Domain-Modells, in derselben Art, wie früher das Hinzufügen einer öffentlichen API.

Wenn Du eines startest und deine Codebase zickt, ist das das Signal, dass nicht das MCP das eigentliche Problem ist; es ist der Drift darunter.

Was sich für das Geschäft ändert

Drei Zahlen, die uns interessieren, drei Wochen nach Launch:

Time to first inspection running ist von typischerweise zwei Stunden in der ersten Session auf unter zwanzig Minuten gefallen, sofern der Nutzer einen Agenten hat. Er beschreibt die Linie, das Teil und den Defekt, der ihm wichtig ist, der Agent ruft die richtigen Tools auf, wir machen das Schwergewicht im Backend, und am Ende des Gesprächs steht eine konfigurierte Inspektion.

Support-Tickets zur Erstwoche-Einrichtung sind spürbar runtergegangen. Nicht null, aber die einfachen ("wo finde ich das, wie mache ich jenes") werden jetzt vom Agenten beantwortet, der unsere Tool-Beschreibungen liest. Customer Success kann die Zeit wieder in die harten Probleme stecken, was sie ohnehin lieber tun.

Sales-Motion hat sich verändert, ohne dass wir sie umgebaut hätten. Ein technischer Evaluator beim Prospect will keine Demo mehr, er will uns in Claude oder Cursor stecken und einen echten Workflow eine Stunde lang selbst fahren. Wir schicken die MCP-Konfig, er sagt bis Freitag Ja oder Nein. Die Buying-Loop ist auf dieser Persona von zwei Wochen auf etwa drei Tage zusammengeschrumpft.

Keine dieser Zahlen ist für sich allein riesig. Zusammen heißen sie, dass wir pro Umsatz-Euro weniger Customer Success einstellen, schneller abschließen und mehr vom Team ins Produkt stecken können.

Wer wahrscheinlich noch kein MCP ausliefern sollte

Drei ehrliche Ausnahmen, weil der Post sonst unredlich wäre.

Wenn Du noch keinerlei API- oder Service-Schicht unter deinem UI hast, ist ein MCP nicht dein nächster Schritt. Bau zuerst die API, idealerweise als schmale interne, und leg dann das MCP darüber. Wir konnten das in zwei Wochen machen, weil unser Produkt unter der Haube schon API-first war, auch wenn die meisten Nutzer nur das UI sahen.

Wenn dein Produkt ein regulierter Workflow ist, in dem jede Aktion menschlich attestiert werden muss (denk an Aerospace-Qualitätsdaten, GxP-Pharma-Prozesse oder Finanztransaktionen oberhalb einer Schwelle), hilft Dir der Agenten-Pfad nicht weiter, und das MCP würde vor allem Attestierungs-Probleme schaffen. Warte ab, beobachte, wie sich Regulatoren zu Agenten-Aktionen positionieren, und bleib am Spielfeldrand.

Wenn Du ein Legacy-Monolith bist, in dem Business-Logik und UI-Logik nicht sauber getrennt sind, wird ein MCP-Projekt auf halbem Weg zum Domain-Refactor. Dieser Refactor ist vielleicht das Richtige, aber er ist ein Sechs-Monats-Projekt, kein Zwei-Wochen-Projekt, und Du solltest ihn intern auch so einpreisen.

Für alle anderen: der Fall fürs Ausliefern ist stärker als der fürs Warten.

Was wir als Nächstes bauen

Die erste Version unseres MCP ist strikt Request-Response: der Agent ruft ein Tool auf, wir machen die Arbeit, wir geben ein Ergebnis zurück. Das passt sauber auf Onboarding- und Konfigurations-Aufgaben, und genau dort haben wir angefangen.

Die nächste Schicht sind langlaufende, agentische Aufgaben, die nicht in einen einzelnen Round-Trip passen. Ein neues Defekt-Modell zu trainieren dauert Minuten, einen Qualitätstrend über eine Produktionswoche zu auditieren dauert länger, und eine Linie auf ungewöhnliche Signale zu beobachten ist per Definition offen. Diese Workflows wollen eine andere Form: der Agent stößt einen Job an, der Job läuft gegen unser Backend, der Agent wird benachrichtigt, wenn etwas Interessantes passiert, und der Nutzer sieht die Konversation weiterlaufen, ohne irgendetwas zu refreshen.

Wir testen dieses Pattern noch in diesem Quartal. Wenn es trägt, ändert sich der Tagesrhythmus mit Enao Vision von "Nutzer loggt sich ein und schaut aufs Dashboard" zu "der Agent meldet, was zählt, der Nutzer reagiert im Chat, das System korrigiert sich selbst." Das ist ein anderes Produkt als das, das wir vor zwei Jahren ausgeliefert haben, und es ist das, auf das wir die nächsten zwei Jahre wetten.

Warum das für die Reihe wichtig ist

Das ist der dritte Post in Building Enao Vision, in dem wir die Engineering- und Produkt-Entscheidungen hinter dem Unternehmen teilen. Der rote Faden in der Reihe ist derselbe wie der in der Software-Welt insgesamt: die Schicht, die früher Menschen brauchte, nimmt jetzt Agenten, und die Produkte, die sich am schnellsten anpassen, gewinnen.

In Post zwei haben wir unser CMS in drei Stunden migriert, indem wir die Arbeit über Sanitys MCP an einen Agenten gegeben haben. In diesem Post haben wir aus unserem eigenen Produkt etwas gemacht, das ein Agent end-to-end fahren kann. Der Bogen ist kein Zufall. Es ist dieselbe Verschiebung, von beiden Seiten des Vertrags gesehen.

Wenn Du 2026 Software baust und dein Produkt immer noch ein UI ist, dem Du Menschen das Navigieren beibringen musst, werden die nächsten achtzehn Monate unbequem. Wenn Du es als etwas baust, das ein Agent verstehen, konfigurieren und im Auftrag eines Nutzers bedienen kann, werden dieselben achtzehn Monate eine Menge Spaß machen.

Wir wissen, auf welcher Seite dieser Wette wir stehen.