Skills vs MCP : arrête de brûler ton context window

Si tu as ajouté des MCP à ton setup Claude Code comme la plupart des gens ajoutent des packages npm (un pour GitHub, un pour Figma, un pour ta base de données, un parce que le README avait l'air sympa), tu te demandes probablement pourquoi tes sessions semblent plus lourdes qu'elles ne devraient.

Le problème, ce ne sont pas les tools. C'est que la décision Skills vs MCP sous Claude Code, c'est une décision que la plupart des gens ne prennent jamais consciemment. Les MCP sont visibles, bien documentés et faciles à installer. Les Skills restent cachées sauf si quelqu'un te montre qu'elles existent. Alors les gens se tournent par défaut vers les MCP et finissent par payer un coût de contexte dont ils ne savent pas qu'ils le paient.

Ces deux mécanismes résolvent des problèmes différents. Les confondre dégrade chaque session silencieusement.

Ce que les MCP te coûtent vraiment

Quand Claude Code démarre une session, il charge le schéma complet de chaque serveur MCP que tu as configuré. Chaque description de tool, chaque paramètre, chaque annotation. Avant que tu tapes un seul mot.

J'ai mesuré ça sur un setup avec 5 serveurs MCP et 58 tools. Consommation totale de tokens au démarrage de la session : à peu près 55 000 tokens. Sur une limite de contexte de 200K, c'est près de 28 % de ton espace de travail dépensés avant que la conversation ne commence. Sur les anciennes limites, c'était pire.

Le coût évolue avec le nombre de serveurs et avec le degré de verbosité des descriptions de tools. Un chercheur a documenté un seul serveur MCP consommant 14 214 tokens, puis l'a réduit à 5 663 en consolidant les tools similaires et en raccourcissant les descriptions. C'est une réduction de 60 % juste par nettoyage.

La fonctionnalité Tool Search de Claude Code aide en différant le chargement du schéma des tools jusqu'à ce qu'un tool soit réellement appelé, réduisant l'overhead initial d'environ 47 %. Mais tous les MCP n'en bénéficient pas également, et le coût fixe d'initialisation de la connexion au serveur lui-même ne disparaît pas.

Le propos n'est pas que les MCP sont une mauvaise idée. C'est le bon choix dans des situations spécifiques. Le propos, c'est que chaque serveur que tu ajoutes a un coût mesurable, et la plupart des développeurs ne savent pas quel est ce coût avant que la session commence à se comporter bizarrement.

Ce que sont les Skills et pourquoi elles sont différentes

Une skill Claude Code est un fichier Markdown. C'est tout.

Tu crées un répertoire .claude/skills/ dans ton projet. Chaque fichier dans ce répertoire est une skill : un ensemble d'instructions, de contexte ou de procédures que Claude peut lire quand on l'invoque. Les Skills se chargent en tant que texte à l'appel. Si une session n'a jamais besoin de la skill de code-review, ces tokens ne touchent jamais le context window.

C'est la distinction centrale. Les Skills se chargent à la demande. Les MCP se pré-chargent au démarrage de la session.

Une skill encode de la connaissance. Elle dit à Claude comment faire quelque chose : comment écrire des commit messages dans le format de ton équipe, comment parcourir la checklist de code-review pour ce codebase spécifique, comment structurer une migration de base de données sûrement. Les Skills sont des procédures, des conventions et de l'expertise métier stockées comme texte lisible.

Un MCP fournit de l'accès. Un repo GitHub en direct. Une base de données qui tourne. Un fichier Figma. L'état courant d'un système externe qui change dans le temps et qui ne peut pas être capturé dans un fichier statique.

Si l'information est statique ou change lentement, une skill est presque toujours plus efficace. Si l'information est en direct, externe, ou exige une action sur un système distant, un MCP mérite son coût.

Je vais plus loin sur la gestion du budget de contexte et la structure du répertoire .claude/ dans le cours d'agentic coding.

Le framework de décision Skills vs MCP

Avant d'ajouter quoi que ce soit à mon setup Claude Code, je pose une seule question : est-ce que ça a besoin d'accès en direct, ou est-ce que ça a besoin de connaissance ?

Utilise un MCP quand :

• Tu dois lire ou écrire sur un système externe en direct : issues GitHub, tickets Linear, ta base de données de staging
• Les données changent fréquemment et un snapshot périmé causerait des erreurs
• Tu dois déclencher une action sur un système distant, pas juste fournir du contexte

Utilise une skill quand :

• Tu veux que Claude suive une procédure spécifique de façon constante : code reviews, rédaction de spec, étapes de migration
• Le contexte est spécifique au projet et change lentement
• Tu veux encoder des conventions, des style guides, ou des arbres de décision qui s'appliquent à ce repo
• La tâche est quelque chose que tu fais à répétition et que tu veux que Claude gère de la même façon à chaque fois

Il y a une troisième catégorie qu'il vaut distinguer : les règles qui appartiennent dans CLAUDE.md plutôt que dans l'un ou l'autre. Les instructions courtes et toujours pertinentes vont dans CLAUDE.md. Il se charge à chaque session, coûte quelques centaines de tokens, et façonne le comportement de base pour tout. CLAUDE.md, c'est pour les règles. Les Skills, c'est pour les procédures. Les MCP, c'est pour les connexions.

Ce que je fais vraiment tourner en production

Sur une codebase React Native en production, mon setup actuel est délibérément minimal.

MCP :

• GitHub (pour lire les issues et PRs pendant les phases de planning)
• Supabase (pour l'inspection en direct du schéma pendant les migrations)

C'est tout. Deux serveurs avec des cas d'usage spécifiques et irremplaçables.

Tout le reste est une skill :

• code-review.md : la checklist que j'utilise pour chaque PR sur ce projet
• commit-message.md : format des commits, conventions de scope, quand splitter en plusieurs commits
• migration.md : pas à pas pour écrire et tester des migrations Supabase sûrement
• blog-pipeline.md : le pipeline complet pour les workflows de contenu automatisés

Pas de MCP pour Figma (je lis le contexte de design une fois et je le colle dans la session). Pas de MCP pour Slack (si quelque chose doit être communiqué, je le fais). Pas de MCP pour les sites de documentation (une skill qui dit à Claude de chercher dans la doc officielle est plus flexible qu'un MCP câblé pour une librairie spécifique).

Le résultat : l'initialisation de session est rapide et bon marché. Les Skills qui ne s'appliquent pas à une tâche donnée ne se chargent jamais. Et quand une procédure a besoin d'une mise à jour, j'édite un fichier Markdown, pas une configuration de serveur.

La partie que la plupart des tutoriels zappent

La plupart du contenu sur Claude Code commence par les MCP parce que les MCP font penser à de la capability. Ils connectent ton IA au monde. En installer un a l'air d'être du progrès.

Les Skills sont moins impressionnantes en apparence. Ce sont des fichiers Markdown dans un répertoire caché. Mais elles passent à l'échelle d'une façon dont les MCP ne sont pas capables. Elles encodent la connaissance institutionnelle, les conventions d'équipe et les workflows reproductibles sous une forme que Claude peut utiliser sans consommer de contexte au startup.

Le trade-off Skills vs MCP sous Claude Code n'est pas une question de capability vs efficacité. C'est une question de compréhension que ces deux mécanismes résolvent des problèmes différents. Traiter un MCP comme le default pour tout, c'est comme lancer tous les imports en haut du fichier indépendamment de s'ils sont nécessaires. Techniquement correct. Mais gaspilleur par design.

Utilise les MCP pour l'accès en direct. Utilise les Skills pour la connaissance. Utilise CLAUDE.md pour les règles qui s'appliquent partout. Cette division des responsabilités, c'est ce qui garde les sessions rapides, focalisées et prévisibles dans le temps.

Je couvre l'architecture .claude/ complète dans le cours d'agentic coding, des skills aux hooks jusqu'au blueprint qui garde les sessions propres.