Je préfère toujours le MCP aux Skills

• MCP est une interface standard fondée sur l’abstraction d’API qui permet à un LLM de demander l’exécution d’une tâche sans connaître la structure interne de l’outil, avec prise en charge de l’usage à distance et des mises à jour automatiques
• Grâce à une architecture Zero-Install, à l’authentification OAuth et à une sécurité par sandboxing, il réduit la charge d’installation et les problèmes de permissions, tout en offrant le même environnement sur n’importe quelle plateforme
• À l’inverse, les Skills entraînent beaucoup de friction en environnement réel en raison de leur dépendance aux CLI, de la complexité de l’authentification et du déploiement, ainsi que des problèmes de compatibilité entre plateformes
• Il faut distinguer les Skills comme couche de connaissance et le MCP comme couche de connexion : lorsqu’un LLM interagit avec des systèmes externes, il est pertinent d’utiliser MCP, tandis que les Skills conviennent à la transmission de connaissances procédurales
• Des services de tunneling cloud comme MCP Nest permettent d’accéder à distance à un serveur MCP local, ce qui en fait un élément clé pour construire un environnement d’intégration IA standardisé

---

Les avantages du MCP

• Le Model Context Protocol (MCP) repose sur une structure d’abstraction d’API permettant à un LLM d’exécuter une tâche par simple requête, sans avoir à comprendre le fonctionnement interne de l’outil
  • Exemple : lorsqu’un LLM interagit avec DEVONthink, il appelle devonthink.do_x() et le serveur MCP se charge de tout le traitement
• L’usage distant en Zero-Install est possible : il suffit au client d’indiquer l’URL du serveur MCP pour fonctionner immédiatement, sans installation supplémentaire
• Les mises à jour automatiques sont prises en charge : si le serveur MCP distant est mis à jour avec de nouveaux outils ou de nouvelles ressources, tous les clients utilisent immédiatement la dernière version
• L’authentification basée sur OAuth renforce la sécurité, sans que l’utilisateur ait à gérer lui-même les tokens
• La portabilité est élevée : accès possible via le même serveur MCP depuis n’importe quel environnement, qu’il s’agisse de Mac, mobile ou web
• Une architecture sandboxée limite les permissions d’exécution directe sur l’environnement local et n’expose qu’une interface contrôlée
• Grâce aux fonctions de recherche intelligente et de mise à jour automatique, seuls les outils nécessaires sont chargés, et même en cas d’installation locale ils peuvent être mis à jour automatiquement à l’exécution

Limites et frictions des Skills

• Les Skills sont utiles pour enseigner à un LLM des connaissances spécifiques ou une manière d’utiliser un outil, mais lors de l’exécution réelle, la dépendance aux CLI devient problématique
• La plupart des Skills exigent l’installation d’une CLI distincte, alors que les versions web de ChatGPT, Perplexity ou Claude, par exemple, ne peuvent pas exécuter de CLI
• Cela entraîne les problèmes suivants
  • Complexité du déploiement : il faut distribuer et gérer les CLI sous forme de binaires, via NPM, uv, etc.
  • Problèmes de gestion des secrets : les tokens d’authentification sont stockés en clair dans des fichiers .env, ou l’authentification disparaît quand la session est réinitialisée
  • Fragmentation de l’écosystème : les méthodes d’installation et de mise à jour des Skills varient selon les plateformes, ce qui provoque des problèmes de compatibilité et des erreurs de parsing YAML
  • Gaspillage de contexte : même si le LLM n’a besoin que d’un seul appel de fonction, il faut charger l’intégralité de SKILL.md
• Un Skill qui inclut l’instruction « installez d’abord la CLI » ajoute une complexité inutile ; le remplacer par un MCP distant est plus efficace

Critères pour choisir le bon outil

• Quand utiliser MCP : comme interface standard lorsque le LLM doit se connecter à des systèmes externes tels que des sites web, services ou applications
  • Exemple : Google Calendar devrait gérer l’authentification et l’exécution via un MCP distant basé sur OAuth, sans exiger l’installation d’une CLI
  • Il serait également idéal que Chrome, Hopper, Xcode, Notion, etc. fournissent chacun un endpoint MCP intégré pour contrôler leurs fonctionnalités respectives
• Quand utiliser les Skills : ils doivent se concentrer sur la transmission de connaissances pures et de contexte
  • Enseigner l’usage d’outils déjà installés (curl, git, gh, gcloud)
  • Normaliser la terminologie interne, les flux de travail et le style rédactionnel d’une organisation
  • Partager des connaissances procédurales comme le traitement de PDF ou la gestion des secrets (par exemple l’usage de fnox)
• Les Skills doivent être distingués comme couche de connaissance, et le MCP comme couche de connexion

Connecteurs et manuels

• Afin de clarifier les rôles respectifs des Skills et du MCP, il est proposé d’appeler les Skills des manuels pour LLM (LLM_MANUAL.md) et le MCP des connecteurs (Connector)
• Exemples réellement exploités en production
  • mcp-server-devonthink : serveur MCP local permettant à un LLM de contrôler directement DEVONthink
  • microfn : MCP distant fourni sur mcp.microfn.dev
  • Kikuyo : MCP distant fourni sur mcp.kikuyo.dev
  • MCP Nest : service permettant un accès distant à un serveur MCP local via un tunnel cloud (mcp.mcpnest.dev/mcp)
• Certains projets fournissent aussi un Skill pour la CLI, mais un Skill expliquant comment utiliser MCP est plus utile
  • Le Skill agit comme une couche de connaissance qui explique les fonctions du MCP, la relation entre les outils et les moments où les utiliser
  • Le MCP se charge de la connexion et de l’exécution réelles
• Cette combinaison permet au LLM d’exploiter efficacement le MCP sans tâtonnements répétés

Utiliser MCP et Skill en parallèle

• Les erreurs de format de date, limitations de recherche et autres schémas peu intuitifs découverts lors de l’usage du MCP peuvent être organisés sous forme de Skill pour être réutilisés
• Le Skill ainsi créé joue alors le rôle d’une antisèche pour le MCP, aidant le LLM à agir correctement sans gaspiller inutilement des tokens
• Le dossier .claude/skills permet de conserver des consignes de comportement IA propres à chaque projet et de gérer les procédures fréquentes sous forme de dotfiles
• L’avenir de l’intégration de l’IA dépend d’interfaces standardisées (MCP), et il faut éviter les approches fragmentées basées sur des CLI
• On peut espérer une prise en charge officielle du MCP par de grands services comme Skyscanner, Booking.com, Trip.com ou Agoda.com

Présentation de MCP Nest

• MCP Nest est un service qui rend accessibles à distance, via tunneling cloud, des serveurs MCP normalement limités au local (Fastmail, Gmail, etc.)
• Il peut être utilisé de la même manière depuis des clients compatibles MCP comme Claude, ChatGPT ou Perplexity
• Il permet de conserver le même environnement MCP sur tous les appareils sans exposer directement la machine locale

[jujumilk3]

Ce sont simplement deux choses complètement différentes, alors pourquoi ce genre de discussions continue-t-il à revenir ?

[xguru]

C’est parce qu’il faut faire la promo de MCP Nest à la fin de l’article… haha. On dirait que pas mal d’arguments comparatifs gagnent en popularité.

[jjw9512151]

Les Skills, c’est l’escrime, et le mcp, c’est l’épée… L’usage est différent, et on a besoin des deux.

[ide127]

Les Skills et le MCP ont des rôles différents, mais j’ai l’impression que ce genre d’articles continue d’entretenir la confusion.

[ide127]

De toute façon, l’industrie de l’IA est déjà en pleine tempête, infestée de pseudo-prédicateurs.

[GN⁺]

Avis sur Hacker News

• Ce que je veux souligner, c’est qu’il faut se concentrer non pas sur les préférences personnelles, mais sur la conception des outils nécessaire pour qu’un LLM travaille de manière optimale
  MCP ajoute plutôt de la friction. Par exemple, si l’on travaille sur des systèmes embarqués, il suffit de créer une interface de supervision en CLI qui permette au LLM de faire directement du débogage, des resets, de lancer l’émulateur, etc., puis d’en documenter l’usage dans un fichier skill
  Pour les tâches simples, MCP est inutile. Par exemple, git ou le calcul de coûts AWS sont déjà bien gérés par les LLM. Il est plus efficace de ne créer et documenter des outils que pour les systèmes complexes

  • J’ai l’impression que le débat sur MCP mélange trop de concepts. Le point clé, c’est la persistance de session
    Pour de l’usage ponctuel, une CLI ou une API suffit, mais si un accès persistant est nécessaire, un serveur MCP devient utile
    Un MCP bien conçu apprend à l’agent comment l’utiliser sans gaspiller de prompt. Simuler un accès persistant avec un fichier skill est inefficace. MCP est la manière la plus efficace d’intégrer des outils externes dans une session d’agent
  • MCP et skill sont complémentaires. Les opposer est une erreur
  • La chaîne d’outils LLM actuelle ressemble encore à une phase transitoire non standardisée. Au lieu de disperser l’information dans différents endroits comme .md ou les skills, il faudrait une norme capable de la ranger au bon endroit via une boucle automatisée d’auto-réflexion
  • J’ai moi aussi une approche proche. La plupart de mes outils CLI ont été créés directement par Claude, et je n’utilise presque jamais d’IDE
    J’ai même remplacé les fonctions de refactorisation de JetBrains par des scripts, ce qui a réduit le temps de session de 5 minutes à 10 secondes
    Je n’utilise toujours pas MCP du tout. La combinaison REST + Swagger + codegen + Claude + skill suffit largement
  • L’avantage de MCP, c’est le contrôle des permissions. Par exemple, si l’on veut empêcher l’IA d’avoir un accès en écriture à git, on peut limiter ce qui est exposé via MCP. Un simple READ_ONLY_SKILL ne suffit pas

• Ce débat revient au fond à une question de développeur individuel vs collaboration à l’échelle d’une organisation
  Si l’on travaille seul et qu’on veut une boucle de feedback rapide, la CLI est préférable ; si l’on a besoin de contrôle et de cohérence à l’échelle d’une organisation, MCP est plus adapté
  Aujourd’hui, MCP consomme beaucoup de contexte, mais cela devrait s’améliorer avec une exposition progressive

  • Dans les organisations, il y a aussi le problème du contrôle d’accès MCP. Un humain peut faire une erreur en supprimant deux éléments, mais un agent peut en supprimer des milliers en un instant. Avec une CLI, on peut limiter le périmètre d’accès, ce qui est plus sûr
  • Le gaspillage de contexte est un problème d’implémentation côté client. Le chargement progressif est possible sans même modifier la spécification
  • MCP et CLI sont des outils conçus pour des objectifs différents, et ils sont les plus puissants lorsqu’on les utilise ensemble

• Je veux un agent qui utilise directement les outils CLI existants plutôt qu’une API
  J’utilise déjà la CLI en local, donc je n’ai aucune raison d’ajouter MCP. Je ne veux pas non plus de modèle distant
  Si des appels API sont nécessaires, un skill suffit

  • Moi aussi, j’insère directement des commandes curl dans un skill pour appeler des API personnalisées. Les LLM gèrent très bien ce genre de choses
  • Mais pour la gestion des clés secrètes, MCP est plus sûr. Si l’on lance d’abord un serveur MCP, les clés ne sont pas exposées dans l’environnement de l’agent
  • MCP joue le rôle de couche de frontière de sécurité entre l’agent et le monde extérieur. Ce n’est pas toujours nécessaire, mais c’est utile
  • Dans certains environnements, le LLM peut ne pas avoir accès à la CLI. Dans ce cas, les appels CLI basés sur des skills ne servent à rien
  • Il y a aussi les questions d’authentification (authn) et d’autorisation (authz). MCP permet de les contrôler via un middleware

• MCP et Skill ne sont pas dans une relation à somme nulle
  MCP fournit une interface standardisée au niveau de l’infrastructure, tandis que Skill gère le contexte comportemental propre au projet
  En les combinant, on obtient à la fois stabilité et flexibilité

  • MCP n’est au fond qu’un emballage autour d’une CLI. En réalité, MCP a même un surcoût de contexte plus important
  • Certains MCP payants ont une vraie valeur. Par exemple, un MCP pour la recherche web est plus pratique que de lancer soi-même un crawler
  • Pour les agents hébergés dans le cloud, la combinaison Skill + MCP constitue une architecture clé. L’authentification et la gestion des dépendances y sont plus simples
  • L’auteur soutient lui aussi cette combinaison. MCP offre une forte portabilité : on peut l’utiliser de la même manière dans ChatGPT, Claude, Perplexity, etc.
  • Un skill peut être ignoré par le LLM, alors qu’une politique MCP a une force contraignante côté serveur

• La plupart des discussions sont centrées sur les personnes qui font tourner des agents de code en local
  Dans ce type d’environnement, Skill est plus pratique, mais les utilisateurs ordinaires passent par des solutions cloud comme ChatGPT
  Dans ce cas, MCP devient l’option par défaut. Ses points forts sont l’authentification et l’accès distant

  • Mais certains considèrent que MCP n’est qu’un wrapper d’API bruyant
    Il faut lancer un serveur, et pour le LLM c’est plutôt une charge supplémentaire. Skill est plus simple, car il encode la documentation d’API de manière compatible avec les LLM
  • Il y a aussi eu des objections disant que l’affirmation « la plupart des utilisateurs n’utilisent pas d’agents locaux » aurait besoin d’être étayée
  • Il y a même eu une blague corrigeant la faute de frappe « agronomic » en « ergonomic »

• Je préfère Skill, parce qu’il permet de réutiliser tels quels les outils CLI conçus pour des humains
  Skill est une documentation lisible et modifiable par des humains, ce qui permet au LLM et aux personnes de partager les mêmes outils
  En revanche, avec MCP il faut créer de nouvelles API réservées aux LLM et maintenir une documentation séparée
  Skill n’est chargé que lorsqu’on en a besoin, ce qui garde le contexte propre

• Ceux qui défendent le « tout Skill » sont souvent des non-techniciens, tandis que le « tout CLI » est surtout fréquent chez les développeurs individuels
  MCP est bien adapté aux environnements d’entreprise. Il standardise l’authentification et les interfaces

  • Beaucoup de gens ont une mauvaise opinion de MCP à cause de l’instabilité du JIRA MCP. Un skill basé sur acli était plus stable
  • J’ai moi-même construit un MCP interne pour mon entreprise. J’y ai intégré l’authentification Google Workspace afin que Claude puisse consulter des données internes ou déployer des applications en toute sécurité
    MCP est facile à mettre à jour et à déployer, ce qui le rend accessible même aux non-techniciens
  • Certains soutiennent aussi qu’en entreprise, comme il existe déjà des systèmes d’authentification internes, la CLI est préférable
    MCP ne serait au fond qu’une structuration d’un sous-ensemble de l’API
  • MCP peut être mis en place rapidement. Une pile Codex → LiteLLM → VLLM → MCP se monte en quelques minutes
  • Je considère les systèmes SaaS existants comme du legacy. Une base SQL locale est plus efficace que des API difficiles d’accès pour interroger les données
    MCP n’est qu’un protocole RPC de plus, et les problèmes d’authentification restent non résolus

• Je pense que MCP est nécessaire à cause de l’irrationalité humaine
  Beaucoup d’organisations ne fournissent toujours ni API ni CLI. MCP comble cette fracture numérique
  Les circuits de reporting et les structures politiques en entreprise bloquent l’automatisation, et MCP peut contourner cela

  • Je suis d’accord. Si les agents des collègues pouvaient collaborer entre eux, la numérisation des organisations serait bien plus facile. MCP est intéressant parce qu’il masque cette complexité de câblage

• Skill pose un problème de context bloat, car il faut injecter tout le document dans le contexte
  MCP a un problème similaire, mais il permet un chargement progressif grâce à la découverte des outils
  Le vrai souci, plus important, est que la sortie de MCP entre directement dans le contexte de l’agent. Si l’on appelle un service MCP via une CLI, il devient possible de filtrer ou de mettre en cache

  • Certains ont réagi par : « dans ce cas, pourquoi ne pas simplement utiliser des requêtes HTTP ? »
  • L’auteur explique que les versions récentes de MCP ont déjà réglé ce point via du lazy loading basé sur la découverte d’outils. Claude Code utilise des sous-agents pour éviter l’explosion des logs
  • Moi, j’ai résolu le problème en plaçant un cache mémoire autour de mon MCP local. J’attribue un identifiant à la sortie de chaque outil, puis j’appelle d’autres outils avec cet identifiant. C’est efficace pour économiser des tokens et accélérer le traitement

• Skill est bien adapté pour contenir des connaissances intuitives, tandis que MCP convient mieux à une automatisation répétable
  Si le LLM écrit plusieurs fois le même script, il devient plus efficace d’en faire un outil fixe

  • La plupart des processus devraient être prétraités par des scripts, et le LLM ne devrait intervenir que pour la planification et la validation
    Autrement dit, l’essentiel est de prétraiter autant que possible avec des scripts
  • On peut aussi inclure directement des scripts dans un skill. Un skill peut contenir du code
  • L’auteur original précise que le texte a été écrit par une vraie personne pendant un vol, et non par une IA
  • Quelqu’un disait aussi utiliser des skills pour des tâches répétitives, ce qui a mené à une explication sous l’angle du contrat d’API de MCP
    S’il s’agit d’un petit script, il suffit simplement de le mettre dans le contexte et de dire : « utilise ça »