MCP-first réorganise l’ordre de priorités classique. Ce n’est pas l’interface qui est au centre, mais une couche centrale d’actions, de ressources et de workflows, utilisée de manière égale par toutes les interfaces.
La nouvelle priorité
Auparavant, la webapp était créée en premier, puis venaient l’API et l’automatisation. MCP-first inverse cela : d’abord le domaine, les actions et les politiques, les interfaces sont les 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
Architecture cible
L’architecture se compose de six couches. Les interfaces humaines et agentiques se trouvent en haut, la couche de capacités forme le cœur, en dessous viennent la sécurité, le domaine et les données.
Règle fondamentale
La logique métier ne doit pas se trouver dans la webapp. La logique métier ne doit pas se trouver dans le serveur MCP.
Pourquoi cela impose une meilleure architecture
Qui construit MCP-first doit automatiquement modéliser plus proprement :
- des domain-actions claires avec une intention utilisateur non ambiguë
- des schémas d’entrée et de sortie typés
- des droits, cas d’erreur et effets secondaires clairs
- des audit events et niveaux de protection clairement définis
Ce n’est pas seulement bon pour l’IA. C’est une bonne architecture logicielle.
Moteur de politique central
Toutes les interfaces utilisent la même fonction de décision :
can(user, action, resource, context)Il n’y a ainsi pas de seconde logique de droits divergente dans le serveur MCP ou dans la webapp, seulement une source de vérité.