Skills

Exemples de skills

Six skills d'agent pour créer, piloter et auditer un serveur MCP, eux-mêmes construits selon les règles MCP-first.

Un skill est un workflow encapsulé, le troisième composant d’un système MCP-first (Prompts / Workflows). Il guide un agent à travers un processus en plusieurs étapes, sans que celui-ci ait à cliquer dans des interfaces.

Les skills d’exemple suivants opèrent sur le serveur MCP lui-même : le créer, le piloter et l’auditer. Ce qui est essentiel : ces skills respectent les mêmes règles qu’ils font appliquer. Chaque étape risquée porte un niveau de risque, les étapes d’écriture et critiques sont protégées par une approbation (Confirmation Gate), et chaque action génère un audit event.

Créer

mcp.scaffold_server
High

Bootstrap un serveur MCP capability-first : domain actions en premier, schémas typés, moteur de politique, métadonnées de risque et audit, avant qu'une interface quelconque existe.

trigger "Crée un serveur MCP pour …" Créer

Ablauf

  1. Modéliser les domain actions, la logique métier reste dans le domaine, pas dans le serveur. Low
  2. Générer des schémas d'entrée, de sortie et d'erreur typés pour chaque action. Low
  3. Attribuer un niveau de risque et une politique de confirmation à chaque outil. Medium
  4. Câbler le moteur de politique (can(user, action, resource, context)) et les audit events. Medium
  5. Générer le serveur comme adaptateur : discovery, exposition de schémas, vérifications de politique, audit logging. High
  6. Enregistrer les outils d'écriture et critiques uniquement après approbation explicite. Critical ⏸ Freigabe

Hält sich an

  • Capacités avant écrans, les capacités d'abord, pas d'hypothèses sur l'interface.
  • Entrées et sorties typées, pas de JSON libre.
  • Politiques plutôt que confiance, chaque capacité reçoit des droits et un risque.
  • Audit plutôt qu'opacité, chaque action génère un audit event.
capability.add
High

Ajoute une nouvelle capacité selon le standard du contrat d'outil. Sans contrat complet, rien n'est enregistré.

trigger "Ajoute un outil/une ressource pour …" Créer

Ablauf

  1. Clarifier l'intention de l'utilisateur et la catégorie ; vérifier une capacité existante comme modèle. Low
  2. Définir les schémas d'entrée, de sortie et d'erreur ainsi que les scopes nécessaires. Low
  3. Définir le niveau de risque, les effets secondaires et l'audit event. Medium
  4. Déterminer la politique de confirmation (autonome, confirmation, step-up, four-eyes, pas pour l'IA). Medium
  5. Prévoir un mode dry run pour les outils risqués. Medium
  6. Enregistrer la capacité et l'activer dans la discovery. High ⏸ Freigabe

Hält sich an

  • Outils plutôt que boutons, un contrat unifié par capacité.
  • Confirmation plutôt qu'automatisation aveugle, politique avant l'enregistrement.
  • Dry run pour les actions risquées.

Piloter

mcp.control_visibility
High

Pilote la visibilité des outils par utilisateur, client, tenant, rôle et scope, dès la discovery, pas seulement lors de l'appel.

trigger "Quels outils l'agent X peut-il voir ?" Piloter

Ablauf

  1. Résoudre l'identité et le contexte : utilisateur, client MCP, identité d'agent, tenant. Low
  2. Calculer les droits effectifs (utilisateur + agent + niveau de confiance client + sensibilité de la ressource). Low
  3. Filtrer la liste d'outils sur les capacités autorisées ; ne pas exposer du tout les outils bloqués. Medium
  4. Adapter les politiques de confirmation selon le rôle. High ⏸ Freigabe

Hält sich an

  • Visibilité des outils selon les droits, filtrer à la discovery.
  • Contexte plutôt que données brutes, uniquement ce dont l'agent a besoin.
  • Politiques plutôt que confiance.
mcp.connect_client
Critical

Connecte un client MCP de manière contrôlée : OAuth 2.1 Authorization Code avec PKCE, allowlist, tokens courts, rotation de refresh.

trigger "Connecte le client … au serveur MCP" Piloter

Ablauf

  1. Vérifier le client contre l'allowlist ; valider les redirect URIs. Medium
  2. Configurer OAuth 2.1 + PKCE, définir des durées courtes pour les access tokens. High
  3. Attribuer les scopes minimaux (least privilege), activer la rotation de refresh. High
  4. Activer le client, avec step-up auth de l'administrateur. Critical ⏸ Freigabe

Hält sich an

  • Interface humaine / clients comme client, le cœur reste la couche de capacités.
  • Step-up authentication pour les actions critiques.
  • Audit plutôt qu'opacité, l'activation du client est auditée.

Auditer

mcp.audit_trail
Low

Revue en lecture seule : lit l'audit trail et la couverture des risques, parcourt la checklist MCP-first et signale les lacunes. Ne modifie rien.

trigger "Audite le serveur MCP contre MCP-first" Auditer

Ablauf

  1. Lire l'inventaire des capacités et leurs niveaux de risque. Low
  2. Vérifier l'exhaustivité des audit events et la rédaction des entrées sensibles. Low
  3. Marquer les outils sans classification de risque ni politique de confirmation. Low
  4. Comparer les capacités Forbidden-for-AI avec leur visibilité réelle. Low
  5. Produire les résultats sous forme de rapport structuré, aucune action d'écriture. Low

Hält sich an

  • Audit plutôt qu'opacité, chaque action traçable.
  • 100 % contrôlable, pas 100 % autonome, l'audit lui-même ne modifie rien.
  • Contexte plutôt que données brutes, rapport plutôt que dump de base de données.
mcp.harden_security
Critical

Vérifie et renforce la protection : classes de protection, couverture step-up, rédaction, rate limits et protection contre l'injection de prompt. Les modifications nécessitent une approbation.

trigger "Renforce la sécurité du serveur MCP" Auditer

Ablauf

  1. Vérifier les zones sensibles et les classes de protection par ressource/outil. Low
  2. Vérifier la step-up auth pour les outils critiques ; proposer les manquants. Medium
  3. Vérifier les règles de rédaction et le filtrage de contexte pour l'accès IA. Medium
  4. Évaluer les rate limits et la protection contre l'injection de prompt. High
  5. Appliquer les modifications de politique, avec approbation admin (four-eyes). Critical ⏸ Freigabe

Hält sich an

  • Politiques plutôt que confiance, l'IA est contrôlée, pas seulement approuvée.
  • Confirmation avant automatisation aveugle, les modifications de politique nécessitent une approbation.
  • Contexte plutôt que données brutes, rédaction pour les données sensibles.

Build capabilities once. Expose them everywhere, auch an die Skills, die den Server selbst betreiben.

Les skills sont des workflows