Checklist MCP-first · MCP-first

Une checklist pour évaluer un système existant ou planifié selon les principes MCP-first.

Produit

Chaque fonctionnalité est-elle décrite comme une capacité, pas seulement comme un écran ou un bouton ?
Existe-t-il une intention utilisateur claire pour chaque capacité ?
Chaque capacité dispose-t-elle d’une forme d’utilisation humaine et d’une forme utilisable par un agent ?
Est-il clairement défini quelles capacités peuvent être exécutées de manière autonome ?
Est-il clairement défini quelles capacités nécessitent une confirmation explicite de l’utilisateur ?

Existe-t-il une couche d’action centrale que toutes les interfaces partagent ?
Toutes les actions sont-elles typées avec des schémas clairement définis ?
Existe-t-il des schémas d’entrée et de sortie pour chaque outil ?
Existe-t-il des codes d’erreur lisibles par les machines clairs par outil ?
Existe-t-il un moteur de politique central que toutes les interfaces partagent ?
Existe-t-il des journaux d’audit pour chaque action exécutée ?
Existe-t-il des tests par outil couvrant les entrées, les sorties et les cas d’échec ?
Existe-t-il un mode dry run pour les actions risquées ?

Tous les outils sont-ils classifiés par niveau de risque (low / medium / high / critical / forbidden) ?
Les outils sont-ils déjà filtrés lors de la tool discovery selon les droits de l’utilisateur, le rôle et les scopes, pas seulement lors de l’appel ?
Existe-t-il une step-up authentication pour les actions particulièrement sensibles ?
Existe-t-il des Human Confirmation Gates pour les actions critiques ?
Existe-t-il une rédaction et un filtrage de contexte pour que les agents reçoivent uniquement le contexte nécessaire à leur tâche ?
Existe-t-il une isolation de tenant afin qu’aucun accès inter-tenant ne soit possible ?
Existe-t-il des rate limits par agent, client et outil ?
Existe-t-il une protection contre les attaques par injection de prompt ?
Les métadonnées d’outil sont-elles validées côté serveur et non acceptées aveuglément depuis le client ?
Existe-t-il un monitoring et des alertes pour les actions d’agents inhabituelles ou anormales ?

L’utilisateur peut-il à tout moment retracer quelles actions un agent a exécutées ou veut exécuter ?
L’utilisateur voit-il clairement et de manière compréhensible ce qui va concrètement se passer lors d’une demande de confirmation ?
L’utilisateur peut-il refuser ou annuler une action d’agent proposée ?
Existe-t-il un mode brouillon dans lequel l’agent prépare et l’humain décide en dernier ?
Existe-t-il des options d’annulation ou de rollback pour les actions réversibles ?
Les actions risquées sont-elles expliquées en langage clair, destinataires, portée, effets externes, niveau de risque ?

Build capabilities once. Expose them everywhere.