MCP-first ordnet die klassische Prioritätenfolge neu. Nicht die Oberfläche steht im Zentrum, sondern eine zentrale Schicht aus Actions, Resources und Workflows, die von allen Interfaces gleichermaßen genutzt wird.
Die neue Priorität
Früher entstand zuerst die Webapp, danach kamen API und Automatisierung. MCP-first dreht das um: zuerst Domain, Actions und Policies, Interfaces sind die Clients.
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
Zielarchitektur
Die Architektur besteht aus sechs Schichten. Menschliche und agentische Interfaces liegen oben, der Capability Layer bildet das Herzstück, darunter folgen Sicherheit, Domäne und Daten.
Grundregel
Business Logic darf nicht in der Webapp liegen. Business Logic darf nicht im MCP-Server liegen.
Warum das bessere Architektur erzwingt
Wer MCP-first baut, muss automatisch sauberer modellieren:
- klare Domain Actions mit eindeutigem Benutzer-Intent
- typisierte Input- und Output-Schemas
- klare Rechte, Fehlerfälle und Side Effects
- klar definierte Audit Events und Schutzstufen
Das ist nicht nur für KI gut. Das ist gute Softwarearchitektur.
Zentrale Policy Engine
Alle Interfaces nutzen dieselbe Entscheidungsfunktion:
can(user, action, resource, context)
Dadurch gibt es keine zweite, abweichende Rechtelogik im MCP-Server oder in der Webapp, nur eine Quelle der Wahrheit.