Klassische Softwareentwicklung denkt zuerst in Oberflächen: Kundenliste, Projektseite, Upload-Button, Rechnungsformular, Kalenderansicht. Für Menschen ist das sinnvoll. Für AI Agents, Automationen und externe Systeme ist es das falsche Abstraktionsmodell.
Ein Agent sollte nicht wissen müssen, auf welcher Seite ein Button liegt.
Was ein Agent wirklich braucht
Ein Agent navigiert keine Oberflächen. Er ruft Fähigkeiten auf. Die relevanten Fragen lauten:
- Welche Aktionen gibt es?
- Welche Inputs erwartet eine Aktion, welche Outputs liefert sie?
- Welche Rechte sind nötig?
- Welche Aktion ist riskant oder irreversibel?
- Wann braucht es eine Rückfrage an den Benutzer?
- Was wird auditiert?
UI-first-Software beantwortet keine dieser Fragen. MCP-first-Software beantwortet sie alle.
Klassisch
- Webapp
- Mobile App
- Admin UI
- API
- Automation
- AI-Integration
MCP-first
- Domain Model
- Action Layer
- Permission Layer
- MCP Tools
- MCP Resources
- MCP Workflows
- Audit Layer
- Webapp · Mobile · Admin · API · Automation
These 1: AI Agents benutzen Software nicht wie Menschen
Menschen klicken, scrollen, lesen und interpretieren. Agents brauchen strukturierte Fähigkeiten, die direkt und sicher aufgerufen werden können.
Der zweite Weg ist deterministisch, typisiert, berechtigungsgeprüft und auditierbar. Der erste erzeugt fragile Browser-Automation, die bei jedem UI-Update bricht.
-
schedule_follow_up(contactId, projectId, datetime, note) -
contacts.search(query, tenantId) -
reminders.create(contactId, datetime, note, assignedTo) -
calendar.find_free_slot(participantIds, duration, after)
These 2: Die Benutzeroberfläche wird zu einem von vielen Clients
In der Vergangenheit war die UI der Hauptzugang zur Software. Künftig gibt es mehrere gleichwertige Zugänge, die alle auf denselben Capability Layer zugreifen:
- Mensch über Webapp
- Mensch über Mobile App
- AI Agent über MCP
- Automation über Worker
- Drittanbieter über API
- Interne Systeme über Events
- CLI über Action Layer
Wer die Webapp zuerst baut und den Rest nachzieht, baut denselben Action Layer mehrfach, jedes Mal leicht anders, jedes Mal mit eigener Rechtelogik.
These 3: Software ohne Agentenfähigkeit wird schwer integrierbar
Wenn Software nur über Oberflächen funktioniert, entstehen zwangsläufig fragile Workarounds:
- Browser-Automation und Screen Scraping
- CSV-Importe und manuelle Copy-Paste-Prozesse
- Halbautomatische Workflows
- Sonderlösungen pro Kunde oder Integrationsprojekt
Diese Workarounds brechen bei UI-Änderungen, skalieren nicht und lassen sich nicht auditieren. MCP-first beseitigt den Grund für ihre Existenz, indem das System von Anfang an strukturiert steuerbar ist.
These 4: Die beste Oberfläche für viele Aufgaben ist keine Oberfläche
Viele Aufgaben sind dialogisch, kontextuell und workflowbasiert, sie brauchen keine Seite mehr:
„Erstelle eine Zusammenfassung aller offenen Deals.” „Welche Kunden sollte ich heute kontaktieren?” „Prüfe, ob bei diesem Mitarbeiter Dokumente fehlen.” „Erstelle einen Report über alle Projekte mit Risiko.” „Vergleiche die letzten beiden Payroll-Läufe.”
Für diese Aufgaben ist ein konversationeller Agent mit Zugriff auf einen Capability Layer effizienter als jede Seite mit Filtern und Tabellen. Die Voraussetzung: Die Fähigkeiten sind sauber modelliert, typisiert und mit Risikostufen versehen.
Low Zusammenfassung generieren, Medium Dokument erstellen, Critical Payroll-Export, diese Unterschiede muss das System kennen.
These 5: MCP-first reduziert doppelte Entwicklung
Wenn ein Feature zuerst als Action gebaut wird, kann jeder Client dieselbe Action nutzen, ohne Doppelimplementierung:
create_project(name, templateId, ownerId, tenantId)Diese eine Action ist nutzbar von:
- Webapp
- Mobile App
- Admin UI
- MCP Agent
- CLI
- Worker
- Import-Prozess
- Integration
- Test-Suite
Das reduziert nicht nur Aufwand, es beseitigt Inkonsistenzen zwischen den Clients, die sich sonst über Zeit aufschichten.
These 6: MCP-first erzwingt bessere Architektur
Wer MCP-first baut, muss automatisch sauberer modellieren. Jede Capability braucht:
- klare Domain Actions mit eindeutigem Benutzer-Intent
- typisierte Input- und Output-Schemas
- klare Rechte und Fehlerbehandlung
- definierte Side Effects
- Audit Events und Schutzstufen
Das zwingt dazu, fachliche Verantwortung klar zuzuordnen, bevor eine Zeile UI-Code geschrieben wird.
-
Input Schema, typisiert, validiert -
Output Schema, deterministisch -
Permission Scopes, welche Rolle darf aufrufen -
Risk Level, low / medium / high / critical / forbidden -
Side Effects, externe Wirkung, ja oder nein -
Audit Event, was wird geloggt -
Confirmation Policy, autonom oder menschliche Freigabe
API-first war für Entwickler. MCP-first ist für Agents.
Software, die zuerst als vollständig beschriebenes, berechtigungsgeprüftes und auditiertes Capability-System gebaut wird, ist zugleich besser für Menschen, besser für Agents und besser für alles dazwischen.