Claude Skills vs MCP : lequel choisir vraiment ?

La question claude skills vs mcp revient dans presque chaque conversation que nous avons sur l'extension de Claude, et les deux sont constamment confondus, y compris par des personnes qui déploient les deux. Après avoir testé plus de 40 skills pour ce catalogue et fait tourner une douzaine de serveurs MCP en parallèle, voici la façon la plus claire que nous connaissions de poser le problème.

En bref : Les skills changent la façon dont Claude pense. Les serveurs MCP changent ce que Claude peut toucher. Une skill, c'est de l'expertise : des instructions markdown qui rendent Claude meilleur dans un travail qu'il peut déjà techniquement faire. Un serveur MCP, c'est de l'accès : un programme en cours d'exécution qui connecte Claude à des systèmes qu'il ne peut sinon pas atteindre, comme votre base de données, votre CRM, ou votre navigateur. Si la tâche échoue parce que Claude manque de jugement, installez une skill. Si elle échoue parce que Claude ne peut littéralement pas voir la donnée, il vous faut MCP.

	Skills	Serveurs MCP
Temps d'installation	Moins d'une minute : copier un dossier	15 minutes à quelques heures : configuration, identifiants, débogage
Coût en tokens	Quasi nul tant que non déclenchée, puis charge ce dont elle a besoin	Les schémas d'outils occupent le contexte à chaque requête
Maintenance	Modifier un fichier markdown	Mettre à jour les dépendances, faire tourner les jetons, gérer les changements cassants
Surface de sécurité	Injection de prompt cachée dans les instructions	Identifiants actifs plus tous les scopes accordés
Fonctionne hors ligne	Oui	Seulement si le serveur et ses données sont locaux
Idéal pour	Méthode, jugement, qualité du résultat	Données en direct, systèmes externes, actions réelles

Ce tableau, c'est tout l'argument. Le reste de cet article en est la preuve.

Ce qu'est vraiment une skill

Une skill est un dossier contenant un fichier SKILL.md : des instructions, des exemples, parfois des scripts et des documents de référence, plus une courte description qui indique à Claude quand l'utiliser. Rien ne s'exécute. Rien n'écoute sur un port. Quand votre demande correspond à la description, Claude fait entrer les instructions en contexte et les suit. Quand elle ne correspond pas, la skill vous coûte presque rien, car seule la description d'une ligne est chargée. Nous avons couvert la mécanique dans ce que sont les Claude skills et comment elles fonctionnent, donc nous ne répéterons pas l'anatomie ici.

Ce qui compte pour cette comparaison, c'est ce qu'une skill ne peut pas faire. Elle ne peut pas atteindre votre instance Postgres, lire vos e-mails, ou appeler une API par elle-même. Elle a exactement les capacités que Claude avait déjà ; elle les utilise simplement mieux. La skill frontend-design est notre preuve préférée : même modèle, même prompt, et le résultat avec skill avait l'air conçu plutôt que généré. Aucun nouvel accès n'était impliqué. La skill a changé la réflexion, ce qui constitue toute la catégorie en un seul exemple.

Ce qu'est vraiment un serveur MCP

Un serveur MCP est un programme séparé qui implémente le Model Context Protocol. Il s'exécute comme son propre processus (localement ou à distance) et expose des outils que Claude peut appeler : query_database, send_slack_message, get_crm_deals. Quand Claude décide qu'un outil convient à la tâche, il envoie une requête, le serveur fait le travail contre le système réel, et le résultat revient dans la conversation. C'est ainsi que Claude lit votre schéma de production, dépose un ticket Linear, ou pilote un navigateur.

Nous devrions être honnêtes sur le volet coût, car la plupart des articles sur MCP ne le sont pas. Configurer un serveur signifie éditer du JSON, obtenir des identifiants, et souvent déboguer pourquoi le processus échoue silencieusement à démarrer. Prévoyez 15 minutes pour un serveur bien documenté et une après-midi pour un serveur communautaire. Puis il y a la partie que personne n'annonce : chaque outil qu'un serveur expose embarque un schéma (nom, description, définitions de paramètres) qui se charge dans le contexte de Claude, que vous utilisiez l'outil ou non. Connectez trois serveurs bavards et vous avez dépensé des milliers de tokens par requête avant même de taper un mot. MCP est réellement puissant. Ce n'est pas gratuit, et prétendre le contraire est la façon dont les gens se retrouvent avec dix serveurs connectés et l'impression vague que Claude est devenu plus bête.

Cinq scénarios, cinq verdicts

Les définitions abstraites ne mènent que jusqu'à un certain point. Voici comment se joue la décision serveur mcp vs skill sur des tâches que les gens nous soumettent réellement.

Vous voulez que Claude écrive un texte fidèle à votre marque

Verdict : skill. Votre voix de marque est une connaissance, pas un accès. Encodez une fois la palette, les règles de ton et les expressions bannies, et chaque résultat les respecte. La skill brand-guidelines est le modèle que nous avons testé : inutile tant que vous n'avez pas rempli votre système de marque, disciplinée une fois rempli. Un serveur MCP n'ajoute rien ici. Il n'y a aucun système externe à atteindre ; le problème est le jugement.

Vous voulez que Claude lise votre base de données Postgres

Verdict : MCP. Aucune quantité de markdown ne donne à Claude des yeux sur vos tables. Un serveur MCP Postgres le fait, et c'est le cas canonique pour savoir quand utiliser mcp : la tâche est impossible sans accès externe, point final. Cela dit, l'accès sans jugement, c'est la garantie d'un SELECT * complet sur la production. Nous associerions le serveur à la skill sql-queries, qui a tenu bon lors de notre vérification ligne par ligne des fonctions de fenêtrage et des CTE. Le serveur fournit la portée, la skill fournit la compétence.

Vous voulez de la prospection commerciale ancrée dans les données du CRM

Verdict : les deux, et c'est là qu'ils se combinent. La skill pipeline-review encode comment auditer un pipeline : deals stagnants, inflation des étapes, réalisme des prévisions. Seule, elle a besoin d'un export CSV, ce qui lui a valu un verdict fonctionne-avec-configuration. Connectez un serveur MCP HubSpot ou Salesforce et le flux de travail change de forme : la méthode de la skill s'applique à des données de deals en direct, et les e-mails de suivi référencent des dates de clôture réelles au lieu de ce dont vous vous souveniez avoir collé. Le serveur MCP sans la skill vous donne des données brutes et des conseils génériques. La skill sans le serveur vous donne de la discipline appliquée à des exports périmés. Ensemble, c'est la configuration sur laquelle nous ferions réellement tourner une équipe commerciale.

Vous voulez que Claude arrête de produire des UI génériques

Verdict : skill. C'est un problème de goût. La skill frontend-design a produit le plus grand écart de qualité avant/après de tout ce que nous avons testé dans notre collection code, et elle l'a fait sans aucune dépendance externe. Les gens se tournent parfois vers un serveur MCP d'outil de design ici, et une connexion Figma est utile quand le travail consiste à lire des designs existants. Mais si la plainte est « le résultat de Claude a l'air généré par IA », un serveur MCP est une solution à un problème différent.

Vous voulez que Claude poste des résumés de standup sur Slack

Verdict : MCP, évidemment, mais remarquez ce qui se passe ensuite. Un serveur Slack est le seul moyen pour Claude de poster quoi que ce soit. Puis le premier résumé se lit comme un communiqué de presse, et vous vous retrouvez à écrire des instructions sur le format, la concision, et ce qui compte comme un blocage. Félicitations : vous venez d'écrire une skill. Ce schéma se répète si régulièrement que nous le traitons comme une règle. Chaque intégration MCP finit par faire pousser une skill autour d'elle, parce que l'accès crée le besoin de jugement sur l'usage de cet accès.

Décompte : deux skills, deux MCP, un les deux. Ce ratio correspond à peu près à ce que nous observons dans les configurations réelles, avec une réserve : le travail quotidien de la plupart des gens penche encore plus vers la colonne skill qu'ils ne l'imaginent. Documents, revue de code, écriture, analyse de fichiers que vous avez déjà ; rien de tout cela n'a besoin d'un serveur.

Le coût en tokens dont personne ne parle

Cela mérite sa propre section car ça se voit sur votre facture.

Les schémas d'outils MCP se chargent d'entrée de jeu et restent résidents. Chaque définition d'outil, avec sa description et ses spécifications de paramètres, occupe du contexte à chaque requête de la session, utilisée ou non. Les serveurs varient beaucoup individuellement, et les plus lourds sont saisissants : des serveurs complets de type GitHub avec des dizaines d'outils ont été mesurés en train de dévorer des dizaines de milliers de tokens avant même le début du travail. Dans notre propre configuration, trois serveurs de taille moyenne ont ajouté environ 10 000 tokens de surcharge permanente. Sur l'API, ce n'est pas une abstraction. Les tokens d'entrée sont facturés par requête, donc un préambule d'outils de 10k tokens sur une session de travail de 50 messages, c'est un demi-million de tokens dépensés rien qu'en définitions. Cela empiète aussi sur la mémoire de travail : le contexte dépensé en schémas d'outils est du contexte indisponible pour votre code et vos documents réels, et les modèles se dégradent à mesure que le contexte se remplit.

Les skills inversent cela. Au repos, une skill coûte sa ligne de description, quelques dizaines de tokens. Les instructions complètes ne se chargent que quand la tâche correspond, et les grosses skills séparent le contenu en fichiers de référence que Claude lit à la demande. Vingt skills installées qui ne se déclenchent pas vous coûtent quelques centaines de tokens. Vingt outils MCP connectés vous coûtent leurs schémas complets, tout le temps.

Les règles pratiques que nous suivons : connectez les serveurs MCP par projet plutôt que globalement, déconnectez ce que vous n'utilisez pas cette semaine, et préférez les serveurs qui exposent cinq outils ciblés à ceux qui en exposent vingt exhaustifs. Nous avons détaillé l'approche de mesure et le reste de notre méthode d'élagage dans comment réduire les coûts en tokens de Claude. La version en une ligne : le gonflement de contexte de la plupart des gens vient des schémas MCP, pas de l'historique de conversation.

Sécurité : ce que chacun peut faire à votre machine

Des architectures différentes, des modes de défaillance différents. Les classer « sûr vs pas sûr » rate l'essentiel ; vous vous défendez contre des choses différentes.

Le risque d'une skill est une injection de prompt avec un mécanisme de livraison. Vous insérez volontairement des instructions dans le contexte de Claude, et une skill malveillante ou négligente peut orienter le comportement d'une façon que vous n'aviez pas prévue : exfiltrer discrètement des données via un appel curl de « télémétrie », affaiblir le code qu'elle touche, ou demander à Claude d'ignorer d'autres garde-fous. Les skills qui embarquent des scripts peuvent exécuter du code quand Claude les fait tourner, donc « ce n'est que du markdown » n'est pas une défense complète. L'atténuation est banale et efficace : lisez le SKILL.md avant d'installer, traitez les scripts embarqués comme n'importe quelle dépendance, et préférez les skills qui ont été relues. Auditer les appels réseau cachés fait partie de chaque test SkillProof, et cela a déjà signalé une soumission. Notre checklist complète est dans les Claude skills sont-elles sûres.

Le profil de risque d'un serveur MCP est celui d'un processus actif détenant des identifiants réels. Quels que soient les scopes de ce jeton, le serveur peut les exercer, et il les exercera à la discrétion du modèle. Un identifiant de base de données en lecture-écriture signifie que Claude peut écrire dans votre base de données. Le risque de composition est plus vicieux : un serveur qui lit du contenu non fiable (pages web, e-mails entrants) placé à côté d'un serveur avec accès en écriture crée un chemin d'injection allant d'un inconnu jusqu'à vos systèmes, sans aucune skill nécessaire. Atténuations : des jetons en lecture seule autant que possible, des identifiants cantonnés par serveur, et un vrai scepticisme envers les serveurs communautaires, qui sont des programmes que vous exécutez avec vos secrets. La règle du paquet npm s'applique. Feriez-vous un npm install depuis un compte à 12 étoiles et lui donneriez-vous votre clé CRM ?

Une asymétrie qui mérite d'être dite clairement : une skill dans le pire des cas manipule la session en cours. Un serveur MCP dans le pire des cas a vos identifiants et un accès réseau. C'est pourquoi nous sommes détendus à l'idée d'essayer de nouvelles skills et prudents à l'idée de connecter de nouveaux serveurs.

Les mythes qu'on entend sans cesse

« MCP remplace les skills. » Non, et cette affirmation confond les couches. MCP standardise les connexions ; les skills encodent la procédure. Anthropic livre les deux et utilise des skills pour apprendre à Claude à construire des serveurs MCP, ce qui devrait clore la question. Quand nous avons fait tourner cette skill, elle a produit un serveur fonctionnel enveloppant une API REST interne en environ une heure.

« Les skills ne sont que des prompts. » Une skill est versionnée, en fichiers sur disque, à déclenchement automatique, chargée progressivement, et peut embarquer des scripts exécutables et des documents de référence. Si c'est « juste un prompt », alors une bibliothèque n'est qu'un fichier texte. Le dédain vient généralement de gens qui n'ont jamais observé une bonne skill se déclencher au bon moment au fil d'une semaine de sessions.

« MCP est réservé aux développeurs. » La configuration favorise actuellement les personnes à l'aise avec le JSON, c'est vrai. Mais les extensions de bureau et les connecteurs en un clic font régulièrement reculer cette barrière, et les personnes qui bénéficient le plus d'une connexion CRM ou calendrier ne sont précisément pas des développeurs.

« Il faut minimiser les skills car le contexte est précieux. » À l'envers. Les skills sont la chose bon marché ; leur chargement progressif a été conçu exactement pour cela. Si vous rationnez le contexte, auditez d'abord vos schémas d'outils MCP. C'est là que sont partis les tokens.

FAQ

Une skill peut-elle appeler un outil MCP ? Pas directement ; une skill est constituée d'instructions, pas de code avec une pile réseau. Mais une skill peut dire à Claude quand et comment utiliser les outils MCP connectés, ce qui en pratique est tout l'intérêt de les combiner. Notre configuration pipeline-review fonctionne exactement ainsi.

Lequel faut-il configurer en premier ? Les skills. Elles prennent une minute, coûtent presque rien au repos, et couvrent la majorité du travail quotidien (guide d'installation ici). Ajoutez votre premier serveur MCP quand vous heurtez un mur qui relève de l'accès plutôt que de la qualité, et vous saurez faire la différence le moment venu.

Les skills fonctionnent-elles sans connexion internet ? Les fichiers de skill eux-mêmes, oui ; ce sont des fichiers markdown locaux, et tout se charge depuis le disque. Il vous faut quand même la connexion qu'exige votre client Claude. Les serveurs MCP ont en plus besoin que leur système cible soit joignable, donc un serveur d'API distante n'est hors ligne que dans la mesure où cette API l'est.

MCP est-il excessif pour un utilisateur solo ? Souvent, oui. Si votre travail consiste en documents, code, et analyse de fichiers locaux, les skills plus les outils intégrés de Claude suffisent. MCP rentabilise sa configuration quand un système externe précis (votre base de données, votre CRM, votre calendrier) est central à votre travail quotidien.

Combien de serveurs MCP, c'est trop ? Quand vous ne pouvez plus dire à quoi sert chaque serveur connecté cette semaine, vous en avez trop. Nous en faisons tourner deux ou trois par projet et gardons le reste déconnecté. Chaque serveur inactif paie un loyer en tokens et détient un identifiant pour aucun bénéfice.

La version courte, encore une fois : les skills pour le jugement, MCP pour la portée, les deux quand des données en direct ont besoin de discipline. Commencez par le moins cher.