Le schéma est toujours le même : d’abord décrire les capacités du système, puis construire les interfaces par-dessus. Le domaine change, la structure composée de ressources, d’outils et de classes de risque reste identique. Les exemples suivants montrent à quoi ressemble MCP-first concrètement dans différents secteurs.
Immobilier
Un logiciel immobilier classique pense en surfaces : liste de projets, gestion des contacts, page d’exposé, vue e-mail, modale de rappel. MCP-first inverse cela, les capacités sont créées en premier, puis la webapp est construite comme client sur les mêmes actions.
Classique
- Liste de projets
- Gestion des contacts
- Page d'exposé
- Vue e-mail
- Modale de rappel
MCP-first
- projects.list_active
- contacts.search_buyers
- exposes.generate_download_link
- emails.send_project_email
- deals.recommend_next_action
La webapp appelle les mêmes actions que l’agent. Il n’y a pas de logique d’agent séparée, la couche de capacités est le cœur commun aux deux.
-
projects.list_activeLow -
projects.get_contextLow -
contacts.search_buyersLow -
contacts.get_purchase_profileLow -
exposes.generate_download_linkMedium -
emails.create_project_draftMedium -
calendar.find_free_slotLow -
calendar.create_buyer_meetingMedium -
reminders.create_follow_upLow -
emails.send_project_emailCritical -
deals.recommend_next_actionLow
Paie & RH
Les systèmes de paie gèrent certaines des données les plus sensibles d’une entreprise. MCP-first sépare clairement ce qu’un agent peut lire, ce qu’il peut préparer, et ce qui ne s’exécute qu’après approbation explicite.
-
employees.listLow -
employees.getMedium -
payroll_runs.listMedium -
payroll_runs.getMedium -
documents.list_missingLow -
absences.listLow -
contracts.getMedium
-
employees.createMedium -
employees.updateMedium -
documents.request_missingLow -
payroll.validate_runMedium -
payroll.explain_differenceLow -
payroll.generate_reportMedium -
absences.approveMedium -
salary.readRestricted -
payroll.exportCritical -
salary.changeCritical
Aperçu de la gradation des risques :
- Low
employee.basic.read, données de base, sans risque pour l’agent - Restricted
salary.read, uniquement avec approbation supplémentaire, transmission restreinte - Critical
payroll.export, toujours confirmation, audit event - Critical
salary.change, step-up auth + principe des quatre yeux recommandé
DevOps
Un panneau de contrôle DevOps pilote l’infrastructure, les déploiements et les secrets. Les classes de risque sont ici particulièrement importantes : lire les logs est inoffensif, lire les secrets est interdit.
-
projects.listLow -
deployments.listLow -
services.statusLow -
logs.queryMedium -
metrics.getLow -
secrets.list_metadataMedium
-
deployments.createHigh -
deployments.rollbackHigh -
services.restartHigh -
dns.create_recordHigh -
ssl.issue_certificateMedium -
firewall.update_ruleCritical -
secrets.rotateCritical -
secrets.readForbidden for AI
Aperçu de la gradation des risques :
- Medium
logs.query, autorisé de manière autonome, scope limité - High
deployment.create/rollback, confirmation requise - Critical
secrets.rotate/firewall.update_rule, toujours step-up auth - Forbidden for AI
secrets.read, inaccessible aux agents
CRM & Ventes
Un assistant commercial a besoin d’accès aux contacts, aux deals et aux communications, mais pas aux droits système, à la facturation ou à la gestion des tenants. MCP-first garantit que l’agent voit exactement les capacités dont il a besoin pour son mandat.
-
contacts.listLow -
contacts.searchLow -
contacts.timelineLow -
contacts.communication_historyMedium -
companies.getLow -
deals.list_activeLow
-
contacts.searchLow -
contacts.add_noteLow -
reminders.createLow -
deals.recommend_next_actionLow -
emails.create_draftMedium -
calendar.create_eventMedium -
emails.send_externalCritical
L’agent peut créer des brouillons, ajouter des notes, recommander les prochaines étapes et préparer des rendez-vous. Les e-mails externes sont Critical, l’humain confirme l’envoi, quelle que soit la clarté apparente du contexte.
Support
Un agent de support a surtout besoin d’un accès en lecture riche : historique des tickets, données de contexte, communications antérieures. Les actions d’écriture se limitent aux brouillons et aux notes internes, jusqu’à l’approbation explicite.
-
tickets.list_openLow -
tickets.getLow -
tickets.threadLow -
contacts.getLow -
contacts.timelineLow -
emails.threadMedium -
communications.timelineLow
-
tickets.get_contextLow -
contacts.searchLow -
tickets.add_internal_noteLow -
emails.create_draftMedium -
tickets.update_statusMedium -
tickets.assignMedium -
emails.send_externalCritical
L’agent de support rassemble le contexte, propose des réponses et ajoute des notes internes. Dès qu’une réponse doit partir en externe, le même principe s’applique partout : l’humain confirme, l’agent prépare.