Compétences des agents vs serveurs MCP : cadre de décision

Les compétences d’agent et les serveurs MCP sont souvent présentés comme des moyens concurrents d’étendre un agent IA. Cette présentation est fausse : une compétence enseigne à l’agent comment travailler, tandis qu’un serveur MCP lui donne un accès réglementé à des capacités en direct.

La question utile n’est pas « Quel standard gagne ? » mais « Où cette responsabilité doit-elle se situer ? » Ce guide répond à cela pour les assistants hébergés comme Hermes Agent et OpenClaw, où la taille du contexte, les connexions de longue durée, les identifiants et la sécurité opérationnelle importent plus qu’une démonstration élégante.

Ce n’est pas une comparaison académique. C’est un cadre décisionnel pratique construit à partir d’une expérience réelle de déploiement avec les deux mécanismes, y compris les compromis de coût contextuel qui ne deviennent visibles qu’une fois l’agent en production. Si vous construisez des systèmes multi-agents, vous voudrez peut-être aussi lire notre comparaison des protocoles A2A vs MCP, qui couvre un autre axe du même espace de problèmes.

Compétences d’agent vs serveurs MCP en un tableau

Utilisez une compétence pour la procédure, le jugement et les connaissances opérationnelles réutilisables. Utilisez un serveur MCP pour l’état autoritaire, les opérations protégées et un contrat de capacité stable.

Mon choix par défaut est délibérément conservateur : commencez avec une compétence quand le travail est local, intensif en lecture et procédural. Ajoutez un serveur MCP quand l’agent traverse une frontière de confiance, touche un état externe changeant ou a besoin d’une opération qui doit rester correcte même lorsque le modèle est confus.

La distinction fondamentale : procédure vs capacité

Une compétence d’agent est un répertoire centré sur SKILL.md, avec scripts, références et assets optionnels. La spécification des compétences d’agent définit les métadonnées requises et un modèle de divulgation progressive : l’hôte peut découvrir un petit nom et une description en premier, charger les instructions complètes quand c’est pertinent, et récupérer les fichiers de support seulement si nécessaire.

Cela fait d’une compétence un bon endroit pour une grille d’incident, une liste de contrôle de release, une méthode de recherche ou des instructions pour utiliser un outil en ligne de commande existant. Sa valeur centrale est la procédure encodée : séquence, jugement, contraintes, exemples et définition d’un bon résultat. Pour les détails d’auteur spécifiques à Hermes y compris la structure de frontmatter et l’activation conditionnelle, voir Auteur de compétences Hermes Agent.

MCP résout un problème différent. La spécification du protocole de contexte de modèle donne à un client et serveur un contrat basé sur JSON-RPC pour des capacités incluant outils, ressources et prompts, avec transports standards et comportement de découverte. Des guides d’implémentation pratiques pour les serveurs MCP en Python et les serveurs MCP en Go montrent à quel point la couche d’intégration peut être simple une fois que le protocole fait le gros du travail.

Un serveur MCP est donc une bonne frontière autour d’un système de tickets, d’un plan de contrôle cloud, d’une base de données source de vérité ou d’un service de recherche interne. Il possède la mécanique pour atteindre ce système et peut appliquer validation, autorisation, délais, limites de débit et comportement d’audit en dehors des instructions en prose du modèle.

Une règle plus précise

Demandez-vous si une responsabilité doit rester correcte sans que le modèle se souvienne d’une instruction. Si la réponse est oui, elle appartient dans du code déterministe ou une politique serveur, pas seulement dans SKILL.md.

Par exemple, « collecter trois signaux de soutien avant d’escalader » est une instruction de compétence utile. « Rejeter un changement de statut sauf si l’appelant a la portée incident-manager » doit être appliqué par le service ou serveur MCP, même si la compétence répète la règle.

C’est la frontière qui compte :

• Une compétence peut dire à l’agent quand une action est appropriée.
• Un outil MCP peut rendre l’action disponible via une interface typée.
• Le service sous-jacent doit décider si l’action est réellement autorisée.

Les serveurs MCP peuvent aussi exposer des prompts, donc les standards se chevauchent aux bords. Mais mettre une procédure opérationnelle entière dans une description d’outil géante produit généralement un catalogue de capacités fragile, tandis que mettre un client API privilégié dans un script shell caché dans une compétence produit généralement un problème de sécurité évitable.

Quand un SKILL.md suffit

Une compétence suffit quand l’agent a déjà un accès sûr à tout ce qui est requis et que l’ingrédient manquant est le savoir-faire. C’est courant pour l’analyse de dépôt, la transformation de documents, la génération de rapports ou un flux de travail local construit sur des commandes CLI matures.

Les données sont locales ou fournies par l’utilisateur

Supposons qu’un agent doit inspecter un dépôt vérifié, exécuter des linters en lecture seule, comparer des fichiers de configuration et produire un rapport de migration. Les fichiers sont déjà dans l’environnement de travail et l’hôte expose déjà les outils système de fichiers et processus, donc un autre service réseau ajoute peu de valeur.

La compétence peut décrire quels fichiers inspecter, l’ordre des commandes, la gestion des échecs et les preuves requises. Un script inclus peut normaliser la sortie, mais le sandbox existant de l’hôte et les permissions de commande restent la frontière d’exécution réelle.

Le flux de travail dépend du jugement

Les compétences sont particulièrement utiles quand plusieurs actions techniquement valides existent mais que l’organisation préfère une méthode opérationnelle. Une compétence de revue de code peut expliquer quels risques méritent des commentaires bloquants, quand demander une reproduction et comment séparer les problèmes de correction du goût.

Ces règles changent à mesure que les équipes apprennent. Les garder comme prose sous contrôle de version et petites références est souvent plus clair que recompiler ou redéployer un serveur pour chaque ajustement éditorial.

La portabilité compte plus que le contrôle central

Le format ouvert des compétences d’agent est conçu comme un dossier portable plutôt qu’un runtime distant. Une compétence bien délimitée peut se déplacer entre hôtes compatibles avec ses instructions, exemples et assets de support intacts, bien que les noms d’outils et le comportement du sandbox nécessitent encore des tests spécifiques à l’hôte.

Cette portabilité est utile pour les flux de travail Hermes Agent et OpenClaw qui partagent une méthode mais pas nécessairement le même déploiement. Gardez les notes spécifiques à l’hôte dans de courtes références plutôt que de forker la procédure centrale au premier désaccord. Le guide de l’écosystème de compétences OpenClaw couvre quelles compétences valent la peine d’être installées et comment les contrôler sûrement par rôle d’agent.

Une CLI existante fournit déjà la capacité

Ne construisez pas un serveur simplement pour envelopper une commande locale fiable. Si un assistant monousager peut appeler une CLI étroite qui gère déjà l’authentification, la sortie structurée et les erreurs, une compétence peut être la solution plus petite et plus maintenable.

La mise en garde est importante : une CLI n’est pas automatiquement sûre parce qu’elle est locale. Évitez l’interpolation shell large, préférez la sortie structurée, contraindez les cibles d’écriture et ne traitez pas la liste blanche d’outils suggérée par une compétence comme un système d’autorisation complet.

Quand vous avez besoin d’un serveur MCP

Choisissez MCP quand le problème n’est pas seulement de se souvenir quoi faire. Un serveur MCP devient précieux quand l’agent a besoin d’un pont durable, typé et gouvernable vers un système changeant.

L’état est en direct et autoritaire

Les tickets clients, le statut de déploiement, l’inventaire, les enregistrements de facturation et les métriques de production peuvent changer entre deux tours de modèle. Copier cet état dans une compétence le rend obsolète par construction, tandis que demander au modèle de gratter une interface produit un contrat instable.

Une ressource ou outil MCP peut récupérer l’enregistrement actuel au moment de l’exécution. Le serveur peut normaliser les bizarreries en amont et retourner un résultat compact au lieu d’exposer toute la réponse du fournisseur au modèle.

Des identifiants ou une identité utilisateur sont impliqués

Les identifiants ne devraient pas vivre dans SKILL.md, les exemples ou les scripts assistants inclus. Pour les déploiements HTTP distants, la spécification d’autorisation MCP définit un modèle basé sur OAuth ; pour les serveurs stdio locaux, les identifiants peuvent être fournis via l’environnement de processus ou un autre mécanisme contrôlé par l’hôte. Voir le guide officiel d’autorisation MCP.

La raison plus profonde d’utiliser un serveur n’est pas seulement le stockage de secrets. Un serveur peut mapper l’identité aux portées, restreindre les locataires, masquer des champs et enregistrer qui a demandé une mutation, tandis qu’une instruction en prose ne peut que demander au modèle de bien se comporter.

Les écritures ont besoin de garanties transactionnelles

Créer une facture, changer le statut d’un ticket ou démarrer un déploiement nécessite plus qu’un objet JSON plausible. L’opération peut avoir besoin de clés idempotentes, de concurrence optimiste, de validation côté serveur et d’une piste d’audit durable.

Ces propriétés appartiennent en dessous du modèle. La compétence peut définir la politique d’approbation, mais le serveur MCP devrait rejeter une transition invalide et rendre une demande réessayée sûre.

Plusieurs agents ont besoin de la même capacité

Un serveur MCP partagé peut présenter un contrat unique à plusieurs hôtes d’agent, langages et fournisseurs de modèle. Cela donne aux équipes plateforme un endroit central pour améliorer les schémas, corriger le comportement des API en amont et appliquer des contrôles d’accès sans copier la logique d’intégration dans chaque compétence.

La centralisation n’est pas gratuite. Le serveur devient une dépendance opérée avec versioning, observabilité, disponibilité et obligations de réponse aux incidents, donc il devrait mériter son existence avec une frontière réelle plutôt qu’un enthousiasme architectural.

La question du coût contextuel

Le coût contextuel est souvent réduit au slogan « les compétences sont progressives, les outils sont toujours chargés ». Les hôtes réels sont plus nuancés et la différence devrait être mesurée en entrée de modèle sérialisée plutôt que supposée à partir du format d’extension.

La documentation des compétences d’agent décrit environ 100 jetons de métadonnées de découverte par compétence, recommande de garder les instructions activées sous 5 000 jetons et permet aux références de charger sur demande. Une estimation de planification simple est :

C_skill = métadonnées de découverte + instructions activées + références sélectionnées

Les clients MCP découvrent les définitions d’outils des serveurs, mais le protocole n’exige pas que chaque schéma découvert apparaisse dans chaque appel de modèle. Les hôtes peuvent filtrer, différer, mettre en cache ou router les outils, donc l’estimation pratique est :

C_mcp = schémas d'outils exposés à ce tour + résultats d'outils conservés dans le contexte

La spécification des outils MCP note aussi qu’un ordre stable d’outils peut améliorer le comportement de la mise en cache de prompt. La mise en cache peut réduire le coût de traitement répété, mais elle ne rend pas un catalogue surdimensionné plus facile pour un modèle à choisir.

Un budget de jetons illustratif

Considérez un assistant hébergé avec 20 compétences installées. Au coût de découverte approximatif de la documentation des compétences d’agent, l’index compact de compétences est autour de 2 000 jetons ; activer une compétence de triage ciblée pourrait ajouter 1 200 jetons et une référence de 600 jetons.

Comparez maintenant deux designs MCP. Un serveur de tickets mince avec quatre schémas concis pourrait sérialiser à 500-800 jetons, tandis qu’un serveur d’entreprise large avec 35 outils verbeux pourrait consommer plusieurs milliers de jetons avant qu’un résultat n’arrive.

Ce sont des nombres de planification illustratifs, pas des garanties de protocole ou des benchmarks. Mesurez le prompt exact généré par votre hôte parce que la verbosité du schéma, les descriptions, le routage, la conservation des résultats et le choix du tokenizer peuvent déplacer le total substantiellement.

La conclusion pratique n’est pas « les compétences sont bon marché » ou « MCP est cher ». C’est que la divulgation progressive et la sélection de capacité sont des caractéristiques d’architecture : gardez les métadonnées de compétence discriminantes, activez seulement les instructions pertinentes, exposez le plus petit ensemble utile d’outils et retournez des projections plutôt que des charges utiles brutes en amont.

Le motif du serveur mince : MCP en dessous, compétence au-dessus

Le design le plus durable combine souvent les deux mécanismes. Mettez une petite frontière de capacité dans MCP, puis placez la méthode opérationnelle dans une compétence qui l’appelle.

Considérez un flux de travail d’incident de support utilisé depuis Hermes Agent ou OpenClaw. L’agent doit lire un ticket, collecter des preuves, classifier la sévérité, rédiger une note opérateur et changer le statut seulement après l’approbation requise.

Ce que le serveur MCP possède

Gardez l’interface du serveur étroite et littérale :

Le serveur ne devrait pas contenir un outil appelé triage_everything avec une description longue et une douzaine de drapeaux non liés. Quatre opérations bornées sont plus faciles à autoriser, tester, observer et réutiliser.

Ce que la compétence possède

La compétence possède la séquence et le jugement. Un SKILL.md compact pourrait ressembler à ceci :

---
name: incident-triage
description: Triage incidents de support en utilisant les preuves du ticket et la grille de sévérité.
---

1. Lire le ticket et sa version actuelle.
2. Collecter au moins deux signaux indépendants avant d'assigner la sévérité.
3. Séparer les faits observés des hypothèses dans la note.
4. Demander l'approbation opérateur avant toute note visible par le client ou changement de statut.
5. Relire le ticket avant une écriture ; s'arrêter si sa version a changé.
6. Terminer avec sévérité, preuves, incertitude et action suivante recommandée.

Ce fichier est lisible, révisable et facile à modifier quand la politique de triage change. Une référence liée peut contenir la grille de sévérité, tandis que les instructions principales restent courtes pour s’activer sans traîner un manuel opérationnel dans chaque tour.

Comment cela fonctionne dans Hermes Agent

La documentation MCP native d’Hermes Agent décrit la découverte au démarrage, les connexions persistantes, les transports stdio et Streamable HTTP, et les outils MCP namespacés. Sa configuration actuelle filtre aussi l’environnement pour les serveurs stdio et passe des variables explicitement configurées, ce qui est une défense utile contre l’héritage accidentel de secrets.

Dans ce design, Hermes découvre les quatre outils de ticket, tandis que la compétence d’incident s’active seulement pour les demandes pertinentes. Le modèle suit la compétence, le serveur MCP exécute des opérations bornées et le service de ticket reste l’autorité finale.

Comment cela fonctionne dans OpenClaw

La documentation des compétences OpenClaw suit la structure des compétences d’agent et construit une liste compacte de compétences éligibles pour le modèle. Le même dossier d’incident peut porter la procédure centrale, avec une courte référence spécifique à l’hôte expliquant les noms d’outils de ticket disponibles.

Ne mettez pas le jeton de ticket dans la compétence partagée. OpenClaw traite explicitement les compétences partagées comme des entrées plutôt que du stockage de secrets, et les compétences tierces devraient être révisées comme du code non fiable avant d’être activées.

Pourquoi la séparation survit au changement

Si l’équipe de support révise sa grille de sévérité, mettez à jour la compétence. Si le fournisseur de ticket change l’authentification ou la pagination, mettez à jour le serveur MCP sans réécrire la politique opérationnelle.

Si un deuxième hôte d’agent arrive, il peut réutiliser le même contrat MCP et adapter la petite couche spécifique à l’hôte de la compétence. Cette séparation réduit la logique d’intégration dupliquée sans transformer chaque modification procédurale en déploiement de service.

Un cadre décisionnel en cinq étapes

La séquence suivante est plus fiable que choisir le type d’extension à la mode en premier.

1. Identifier la source de vérité

Écrivez chaque entrée et sortie que le flux de travail touche. Les guidances statiques, les fichiers de dépôt et les documents fournis par l’utilisateur penchent vers une compétence ; les enregistrements distants mutables et les systèmes autoritaires penchent vers MCP.

Pas tout état justifie un serveur. Un artefact de build local est un état, mais une CLI sandboxée existante peut déjà fournir une frontière suffisante.

2. Localiser la frontière de confiance

Marquez où les identifiants, l’identité locataire, les données privilégiées ou les actions irréversibles apparaissent. Si l’agent traverse cette ligne, introduisez un point d’application déterministe, typiquement un serveur MCP soutenu par l’autorisation du service.

Traitez le modèle et la compétence comme des planificateurs de requête, pas des moteurs de politique. Ils peuvent proposer une action autorisée, mais ils ne devraient pas pouvoir redéfinir la permission en changeant leurs propres instructions.

3. Séparer la capacité de la politique

Nommez les capacités comme des verbes étroits avec des entrées typées : obtenir un ticket, ajouter une note ou changer le statut. Mettez les conditions pour choisir ces verbes, la norme de preuve et la séquence préférée dans la compétence.

Certaines politiques doivent exister dans les deux couches pour des raisons différentes. « Demander à l’utilisateur avant de déployer » appartient à la compétence pour la qualité d’interaction, tandis que « rejeter le déploiement sans un jeton d’approbation » appartient au code pour l’application.

4. Estimer le coût contextuel et opérationnel

Capturez une trace de prompt réelle et comptez les métadonnées de compétence, les instructions activées, les définitions d’outils et les données retournées. Ajoutez ensuite le coût non-jeton d’un service MCP : déploiement, authentification, monitoring, versioning et propriété on-call.

Si un catalogue de 30 outils supporte un flux de travail, exposez un sous-ensemble spécifique à la tâche ou séparez le serveur par domaine de capacité cohérent. Si une compétence charge répétitivement une référence de 200 pages, créez une étape de récupération ou des références plus petites au lieu de vous féliciter pour la divulgation progressive.

5. Tester la frontière, puis le comportement

Testez le serveur MCP comme logiciel et la compétence comme comportement d’agent. Ils échouent différemment et un transcript de chat happy-path unique cache les deux classes de défauts.

Pour la sécurité des outils, la spécification MCP recommande la validation d’entrée, les contrôles d’accès, les limites de débit, la sanitisation de sortie, les délais, les confirmations pour les opérations sensibles et la journalisation d’audit. Les annotations d’outils sont des indices, pas une preuve fiable qu’une opération est en lecture seule ou inoffensive. Le guide de sécurité des agents A2A et MCP couvre le modèle de menace plus large y compris l’injection de prompt et l’empoisonnement d’outils.

Règles de sécurité qui ne rentrent pas dans un slogan

Les compétences réduisent le besoin de certains serveurs, mais elles n’éliminent pas le risque. Une compétence peut inclure des scripts et persuader un agent d’appeler des outils hôtes puissants, donc réviser ses instructions et fichiers exécutables comme du code, fixer les versions de confiance et limiter les outils hôtes disponibles à la session.

MCP ajoute une autre frontière : un sous-processus local ou service distant avec ses propres dépendances, entrées, sorties et identifiants. Appliquez le moindre privilège, validez l’audience de ressource pour l’autorisation distante, utilisez HTTPS, sanitizez le contenu non fiable et gardez l’approbation visible pour les écritures conséquentes.

Le plus important, ne confondez pas la découvrabilité avec l’autorité. Un outil apparaissant dans le catalogue du modèle ne signifie pas que l’utilisateur actuel devrait être autorisé à exécuter chaque opération qu’il décrit.

Anti-modèles courants

Cacher un client API distant dans une compétence

Un script shell qui lit un jeton bearer statique et appelle une API de production peut fonctionner dans une démo. Il mélange aussi procédure, identifiants, comportement réseau et autorisation dans un package conçu pour être copié et lu par les hôtes d’agent.

Déplacez l’intégration protégée derrière un serveur étroit ou une CLI approuvée existante. Gardez seulement le flux de travail et les guidances d’appel dans la compétence.

Encoder le flux de travail dans les descriptions d’outils

Les descriptions d’outils devraient aider le modèle à sélectionner une capacité et remplir son schéma. Elles sont un mauvais substitut pour une procédure opérationnelle multi-étapes avec exemples, exceptions, règles d’escalade et conventions de sortie.

Les longues descriptions gonflent chaque tour où l’outil est exposé et rendent le contrat de service plus difficile à réutiliser. Mettez la procédure dans une compétence et gardez les sémantiques d’outil précises.

Construire un outil execute_anything

Un shell, SQL ou proxy HTTP générique effondre plusieurs permissions en une seule capacité difficile à auditer. Il déplace la validation vers le modèle et rend le moindre privilège largement fictif.

Exposez des opérations alignées sur les actions commerciales réelles. Si les opérateurs experts ont vraiment besoin d’une soupape de sécurité, séparez-la, restreignez-la et exigez une approbation et journalisation plus fortes.

Publier un serveur MCP fourre-tout

Un serveur avec des dizaines d’outils non liés alourdit la sélection, le contexte de schéma, les permissions et la maintenance. Séparez par domaine cohérent ou laissez l’hôte exposer un sous-ensemble pertinent pour la tâche actuelle.

La guidance FastMCP d’Hermes Agent fait une recommandation de départ sensée : commencez avec un à trois endpoints à haute valeur et préférez un serveur mince avec des noms et schémas clairs. Voir la documentation officielle de compétence FastMCP.

Traiter les indices d’outils comme politique de sécurité

Un champ expérimental allowed-tools ou l’annotation en lecture seule d’un outil peut améliorer le comportement de l’hôte, mais ni l’un ni l’autre ne remplace le sandboxing et l’autorisation côté serveur. Les métadonnées peuvent être obsolètes, mal configurées ou fournies par un composant non fiable.

Utilisez les indices pour améliorer l’interface. Utilisez du code et l’infrastructure pour appliquer la frontière.

Utiliser MCP pour des connaissances statiques

Si une procédure ou référence change seulement avec le dépôt, un aller-retour distant ajoute des coûts de déploiement et disponibilité sans rendre l’information plus autoritaire. Emballez le matériel concis avec la compétence et versionnez-le avec le flux de travail.

Introduisez un service de récupération seulement quand le corpus est large, contrôlé par accès, mis à jour indépendamment ou a vraiment besoin de recherche. L’architecture devrait suivre le cycle de vie des données, pas l’acronyme.

Décision finale : compétence, serveur MCP ou les deux ?

Choisissez une compétence d’agent quand la partie difficile est de savoir quoi faire. Choisissez un serveur MCP quand la partie difficile est d’atteindre sûrement quelque chose qui change, appartient à un autre domaine de confiance ou doit appliquer un contrat.

Choisissez les deux quand un flux de travail réel a besoin de jugement au-dessus d’une capacité protégée. Ce n’est pas de la duplication : la compétence rend l’agent utile, le serveur rend l’intégration gouvernable et le système sous-jacent rend la décision finale autoritaire.

Pour la plupart des assistants hébergés, la meilleure première architecture est modeste : une compétence ciblée, une petite surface MCP seulement où l’accès en direct l’exige, et une trace de prompt capturée pour vérifier le coût contextuel. Ajoutez la complexité après que la frontière est claire, pas avant.

Références

• Spécification des compétences d’agent
• Spécification du protocole de contexte de modèle
• Guide d’autorisation MCP
• Documentation MCP native d’Hermes Agent
• Documentation des compétences OpenClaw
• Documentation de compétence FastMCP