Au-delà de « MCP vs skills » : composer une architecture d'agent à l'échelle

Cadrer le débat comme « MCP vs skills » passe à côté du sujet. Comme Kurtis Van Gent l’a récemment défendu, ces deux approches répondent à des problèmes différents : MCP s’attaque au problème d’intégration N×M, les skills répondent à la saturation du contexte. Exact. Mais la vraie opportunité, c’est de les composer dans une architecture unifiée.

Chez skilder, nous avons construit précisément cela : des skills qui composent des outils MCP en capacités cohérentes, organisés par contexte métier, et exposés via un serveur MCP unique avec une divulgation progressive intégrée au protocole.

Deux problèmes, une seule architecture.

Le problème d’intégration N×M. Vous avez N agents (Claude Code, Cursor, votre SDK maison) et M sources de données (GitHub, Slack, Postgres). Sans standardisation, chaque paire agent-outil exige un connecteur sur mesure. MCP ramène cela à N+M avec un protocole universel.

Le problème de saturation du contexte. Votre agent a accès à 80 outils. Chaque schéma d’outil consomme des tokens. Chargez-les tous d’entrée et vous brûlez 30 000 tokens avant même que l’utilisateur ait dit bonjour. Pire, les modèles raisonnent moins bien lorsqu’ils doivent arbitrer entre des options non pertinentes. L’équipe ADK de Google parle de « signal degradation ».

Les agent skills résolvent cela par la divulgation progressive. L’agent voit d’abord des métadonnées légères. Les instructions complètes et les outils ne se chargent qu’à la demande.

Là où chaque approche échoue, prise isolément.

Le coût de contexte de MCP. Chaque serveur MCP connecté déverse ses définitions d’outils dans votre fenêtre de contexte. Connectez-vous à GitHub, Slack, Postgres et un serveur CI/CD : des centaines de définitions d’outils chargées avant le moindre travail. Les recherches d’Anthropic ont elles-mêmes montré qu’un chargement à la demande faisait passer la consommation de 150 000 à 2 000 tokens dans un cas réel.

Le problème d’isolation. Un skill apprend à un agent à déployer du code. Mais atteindre le système de déploiement effectif suppose des scripts maison (dépendants de l’environnement, fragiles) ou un repli sur MCP (et la perte de l’efficacité contextuelle). Écrivez un skill sur macOS, partagez-le avec une collègue sur Windows, et il cassera.

La prolifération multi-serveurs. Les équipes se retrouvent avec cinq serveurs MCP connectés, une douzaine de skills éparpillés, et aucune relation claire entre les deux. L’agent doit deviner quel skill s’applique à quel serveur, quels outils appartiennent à quel workflow. La charge cognitive s’empile.

La thèse de la composition.

Le correctif : les skills deviennent la couche de composition au-dessus de MCP.

Un skill regroupe des outils MCP liés en une unité cohérente, avec des instructions sur la façon de les utiliser ensemble. Un skill « deploy-to-staging » relie les outils précis dont il a besoin et guide l’agent dans le workflow. L’agent voit « deploy-to-staging » comme un concept unique. Il n’a pas besoin de savoir que GitHub et CircleCI existent comme systèmes distincts.

MCP gère la connectivité. Le skill gère la chorégraphie.

Chez skilder, nous exposons tout cela via un serveur MCP unique. Votre agent se connecte à un seul endpoint au lieu de cinq. La divulgation progressive est inscrite dans le protocole lui-même : l’agent démarre avec un catalogue léger des skills disponibles et ne charge les schémas d’outils complets que lorsque c’est nécessaire.

Résultat : au lieu de payer 20 000 tokens d’entrée pour 10 serveurs d’outils, vous payez environ 2 900 tokens, avec des capacités équivalentes chargées à la demande.

Contexte métier, pas catalogue d’outils.

Une liste plate de skills crée son propre problème. Dans un environnement d’entreprise, des dizaines de skills couvrant plusieurs équipes recréent la même surcharge cognitive, un cran plus haut.

Nous organisons les skills en groupes de contexte métier : des collections nommées par rôle, domaine ou workflow. Un groupe « DevOps » réunit déploiement, monitoring et rollback. Un groupe « Customer Support » réunit recherche, facturation et escalade.

L’agent navigue des concepts métier plutôt que des catégories techniques. Cela fait le pont entre la façon dont les ingénieurs pensent (outils, API) et la façon dont les organisations pensent (rôles, processus, domaines).

De la transparence à la délégation.

Tous les workflows n’exigent pas le même niveau d’implication de l’agent. Les regroupements d’outils simples ont besoin d’un contrôle total de l’agent. Les workflows complexes et éprouvés gagnent à être délégués.

skilder couvre tout le spectre : de l’agent qui orchestre des outils individuels en pleine transparence, jusqu’à l’exécution en sous-agent où un processus autonome absorbe la complexité. Les organisations démarrent en mode transparent et font monter en délégation les workflows éprouvés, à mesure qu’ils prouvent leur fiabilité.

Pourquoi cela passe à l’échelle.

Efficacité du contexte. Les agents paient pour ce qu’ils utilisent. Pas pour ce qu’ils pourraient utiliser.

Charge cognitive réduite. Des capacités pré-composées avec des instructions claires. Les erreurs de sélection d’outils chutent quand les agents travaillent avec des workflows cohérents plutôt qu’avec des schémas d’outils bruts.

Point de connexion unique. Un seul serveur MCP à connecter, configurer et sécuriser. Pas de prolifération d’identifiants.

Gouvernance d’entreprise. Chaque invocation de skill et chaque appel d’outil sont tracés. Les pistes d’audit complètes alimentent l’optimisation : skills inutilisés, patterns de timeout, points chauds d’échec. Les skills s’améliorent à partir des données d’usage au fil du temps.

Suivi des dépendances. Quand un serveur MCP sous-jacent change, les skills affectés sont identifiés automatiquement. Les mises à jour se propagent dans le système au lieu d’exiger des audits manuels.

Compromis.

Complexité d’écriture. Créer des skills composés suppose de comprendre à la fois le workflow et les outils sous-jacents. Notre approche : la génération de skills assistée par IA. Décrivez un workflow en langage naturel. skilder amorce la structure du skill.

Complexité du débogage. Les couches d’abstraction ajoutent de la complexité au débogage. Mitigation : une télémétrie structurée à chaque couche, avec un contexte de trace qui circule à travers toute la stack.

Surcoût de découverte. La divulgation progressive ajoute un aller-retour avant que l’agent n’utilise les outils. Les skills préchargés contournent cela pour les workflows connus. Pour la plupart des cas d’usage en entreprise, les économies de contexte dépassent largement ce coût.

Pour démarrer.

1. Identifiez les workflows à forte valeur. Trouvez trois à cinq workflows où votre équipe coordonne régulièrement plusieurs outils. Ce sont vos premiers skills composés.
2. Commencez simplement, montez vers la délégation. Démarrez avec des skills qui regroupent des outils liés et de bonnes instructions. Promouvez les workflows stables vers plus d’automatisation à mesure qu’ils prouvent leur fiabilité.
3. Organisez par contexte métier dès le départ. Structurez les skills par rôle ou domaine dès le début. Imposer une structure plus tard est plus difficile.
4. Exposez via une passerelle unique. Connectez vos agents à travers un seul serveur MCP. Ajouter des skills n’augmente pas le coût de contexte de base.

Perspectives.

La proposition SEP-2076 suggère d’ajouter les Agent Skills directement à la spécification MCP. Un support natif des skills composés, avec dépendances d’outils et divulgation progressive, ferait de ce pattern un standard plutôt qu’un montage maison.

Au-delà : les graphes de skills fédérés. Des organisations publient des collections de skills que d’autres consomment et étendent. Des graphes DevOps maintenus par la communauté, enrichis de workflows spécifiques à chaque entreprise. La composition à l’échelle de l’écosystème.

Le débat MCP vs skills est une fausse opposition. MCP résout la connectivité. Les skills résolvent l’efficacité du contexte. Le modèle que nous avons construit chez skilder les compose : des skills au-dessus de MCP, organisés par contexte métier, exposés via un serveur unique avec divulgation progressive au niveau du protocole.

L’avenir de l’architecture d’agent, c’est des skills au-dessus de MCP, composés en un graphe de connaissances qui passe à l’échelle de votre organisation.

Questions fréquentes

Quelle est la différence entre MCP et les agent skills ? +

Ils répondent à des problèmes différents. MCP (Model Context Protocol) s'attaque au problème d'intégration N×M : sans lui, chaque agent a besoin d'un connecteur sur mesure pour chaque source de données ; MCP ramène N agents × M sources à N+M avec un protocole universel. Les skills s'attaquent à la saturation du contexte : ils permettent à l'agent de voir d'abord des métadonnées légères et de charger les schémas d'outils complets à la demande, pour ne pas brûler 30 000 tokens avant même que l'utilisateur ait dit bonjour.

Peut-on utiliser MCP et skills ensemble ? +

Oui. Composer des skills au-dessus de MCP est le pattern recommandé. MCP gère la connectivité vers vos sources de données ; les skills gèrent la chorégraphie (regroupement d'outils MCP liés en workflows cohérents avec instructions). L'agent voit une capacité nommée comme « deploy-to-staging » au lieu d'un catalogue plat de tous les outils exposés par tous les serveurs.

Pourquoi les agents deviennent-ils plus lents ou moins bons quand on connecte de nombreux serveurs MCP ? +

Chaque serveur MCP connecté déverse ses définitions d'outils dans la fenêtre de contexte de l'agent. Connectez-vous à GitHub, Slack, Postgres et un serveur CI/CD, et vous chargez des centaines de définitions d'outils avant le moindre travail. Les modèles raisonnent aussi moins bien lorsqu'ils doivent arbitrer entre des options non pertinentes : l'équipe ADK de Google parle de « signal degradation ». Les recherches d'Anthropic ont montré qu'un chargement à la demande faisait passer la consommation d'une charge de travail de 150 000 à 2 000 tokens.

Combien de contexte économise-t-on vraiment en composant des skills au-dessus de MCP ? +

En pratique, environ 85 % de réduction. Une configuration plate à 10 serveurs paie environ 20 000 tokens d'entrée pour toutes les définitions d'outils. Exposer les mêmes capacités via des skills avec divulgation progressive coûte environ 2 900 tokens, en ne chargeant les schémas complets qu'au moment où un skill est invoqué.

Faut-il organiser les skills par catégorie d'outils ou par contexte métier ? +

Organisez-les par contexte métier : rôle, domaine ou workflow. Un groupe « DevOps » réunit déploiement, monitoring et rollback. Un groupe « Customer Support » réunit recherche, facturation et escalade. Les catalogues d'outils à plat recréent la surcharge cognitive un cran plus haut ; les groupes par contexte métier permettent à l'agent de naviguer les rôles et les processus (la façon dont les organisations pensent) plutôt que les API et les catégories (la façon dont les ingénieurs pensent).