Table des matières
Ça fait 6 mois que je vibecode tous les jours. J'ai testé des dizaines de MCPs. La plupart sont inutiles ou trop lourds.
Voici ceux que j'ai gardés, ceux qui me font vraiment gagner du temps.
(Si tu ne sais pas ce qu'est un MCP, commence par là.)
Ce qui reste valable ici : comment on installe, la distinction entre global et local, comment évaluer un MCP avant de lui ouvrir sa machine, et les risques. Ce qui a changé, c'est ma liste. Je dis plus bas quand un MCP garde l'avantage, et ce n'est plus la règle mais l'exception.
Comment installer un MCP
Si tu utilises Claude Code, c'est simple :
claude mcp add <nom-du-mcp>Pour voir les MCPs installés :
claude mcp listPour en activer/désactiver :
claude mcp enable <nom>
claude mcp disable <nom>Tous les MCPs publics sont listés sur le MCP Hub.
Global vs local : où installer ses MCPs
Par défaut, quand tu ajoutes un MCP dans un projet, il est local : configuré dans le fichier .mcp.json à la racine du projet. Il n'existe que là.
Le problème ? Certains MCPs me servent dans tous mes projets. Sequential Thinking, Context7, Claude in Chrome... je les veux partout, sans avoir à les copier-coller dans chaque .mcp.json.
La solution : les installer en global.
Pour ça, il faut éditer le fichier ~/.claude.json (à la racine de ton dossier utilisateur). C'est le fichier de config global de Claude Code. Dedans, cherche ou ajoute une section mcpServers :
{
"mcpServers": {
"firecrawl-mcp": {
"command": "npx",
"args": ["-y", "firecrawl-mcp"],
"env": {
"FIRECRAWL_API_KEY": "ta-clé-api"
}
},
"context7": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@upstash/context7-mcp"]
},
"sequential-thinking": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
}
}
}Après un redémarrage de Claude Code, ces MCPs apparaissent dans la section "User MCPs" quand tu tapes /mcp. Ils sont disponibles dans tous tes projets.
Ma règle : en global, je mets uniquement les MCPs qui me servent tout le temps (recherche web, réflexion, documentation, navigateur). Tout le reste reste en local, dans le .mcp.json du projet concerné. Ghost, N8N, DaVinci... chaque MCP spécialisé n'a pas besoin d'être chargé partout. Ça évite de consommer du contexte inutilement.
Mes 4 MCPs quotidiens
Ce sont ceux que j'ai installés en global. Ils me servent sur tous mes projets.
1. Sequential Thinking (global)
C'est le MCP qui force Claude à réfléchir étape par étape avant d'agir.
Sans lui, Claude a tendance à foncer tête baissée. Avec, il décompose le problème, identifie les étapes, et avance méthodiquement.
Je l'utilise surtout pour :
- Planifier une feature complexe
- Debugger un problème que je ne comprends pas
- Prendre des décisions d'architecture
C'est comme avoir un senior dev qui prend le temps de réfléchir avant de coder.
2. Claude in Chrome (global)
Claude peut contrôler ton navigateur. Cliquer, scroller, remplir des formulaires, prendre des screenshots.
Mon use case principal : tester mon app en conditions réelles. Je lui dis "va sur mon site, connecte-toi, et vérifie que le dashboard s'affiche correctement". Il le fait et me montre des screenshots.
Avant j'utilisais Playwright pour ça. C'est plus précis, tu as une maîtrise fine de la navigation. Mais c'est lourd à setup et lourd en contexte. Depuis Claude in Chrome, je ne l'utilise quasi plus.
Note : pour le frontend pur (CSS, animations, responsive), je passe plutôt par Cursor. Claude Code c'est pas son point fort.
3. Context7 (global)
C'est le MCP qui donne à Claude accès à la documentation à jour des librairies.
Le problème : Claude a été entraîné sur des données qui datent. Si tu utilises Next.js 15 ou la dernière version de Supabase, il peut te donner des infos obsolètes.
Context7 résout ça. Claude va chercher la doc officielle en temps réel.
Je l'utilise dès que je travaille avec une lib que je ne maîtrise pas parfaitement ou qui évolue vite.
4. Bright Data (global)
Bright Data donne à Claude un vrai accès au web. Recherche, scraping, extraction de pages entières.
Ce qui m'a convaincu : le modèle pay-as-you-go, et un mode scrape as markdown qui renvoie du contenu propre, optimisé pour les LLM. Pas de HTML brut à parser, pas de bruit.
C'est justement celui que je n'utilise plus en MCP. Je suis passé à leur API REST, et surtout j'ai mis une extraction gratuite en premier rideau, qui suffit sur la grande majorité des sites. J'explique la bascule et la nuance qui m'a le plus servi ici : un service anti-bot résout un problème de blocage, pas un problème d'adresse IP, et ce ne sont pas les mêmes sites qui posent l'un ou l'autre.
Mon use case principal : quand je demande à Claude de faire des recherches pour moi (comparer des outils, analyser une page, trouver de la doc), Bright Data est ce qui lui permet d'aller chercher l'info à la source.
Mais ça va plus loin. J'utilise Bright Data dans mes agents. J'ai un agent deep-search qui lance des recherches approfondies sur un sujet donné, scrape les pages pertinentes, et me livre une synthèse complète. Bright Data est le moteur de recherche derrière. Si les agents t'intéressent, j'en parle en détail ici.
Alternative recommandée : Firecrawl. Si tu préfères un abonnement classique, Firecrawl est excellent. Leur output markdown est très propre. Le free tier suffit pour tester avant de décider. C'est ce que j'utilisais avant de repasser sur Bright Data.
Les MCPs "doc lourde"
Ces MCPs sont spécialisés sur un outil/service spécifique. Ils embarquent toute la documentation, tous les endpoints, toutes les subtilités.
Le problème : ils sont lourds. Ils consomment beaucoup de contexte. Je ne les active que quand j'en ai besoin.
Brevo, pour l'emailing. Tous les endpoints API, les webhooks, les templates.
Stripe, pour les paiements. Indispensable si tu intègres Stripe, la doc est énorme et les edge cases nombreux.
N8N, pour l'automation. Quand je dois créer des workflows complexes, ce MCP me fait gagner un temps fou.
Playwright, pour les tests de bout en bout. Je ne l'ai gardé que pour les scénarios qui doivent tourner seuls, en intégration continue, où il faut exactement le même parcours à chaque fois. Pour vérifier une page à la main pendant que je développe, Claude in Chrome a pris sa place.
Construire ses propres MCPs
À force d'utiliser des MCPs tiers, j'ai commencé à voir leurs limites. Trop de tokens consommés, pas assez de contrôle, des réponses qui ne correspondent pas à ma façon de travailler.
Du coup, j'ai commencé à construire les miens.
Ghost Optimized
Mon premier MCP custom. Le MCP officiel Ghost bouffait tellement de tokens que Claude devenait inutilisable après un seul appel. J'ai créé Ghost Optimized : mêmes fonctionnalités, 98% de tokens en moins.
→ L'article dédié : comment j'ai construit Ghost Optimized
Et après, j'en ai créé d'autres
Obsidian Writer : 75 outils pour gérer mon vault Obsidian (4000+ notes). Création de notes, tâches, CRM, recherche sémantique.
Obsidian RAG : moteur de recherche sémantique sur mes notes, avec embeddings et interface web.
Ces deux-là, je ne les utilise plus. Obsidian Writer a été remplacé par une ligne de commande qui fait le même travail, et Obsidian RAG par un outil de recherche sémantique en local. Le plus dur à avaler, c'est que je les avais construits moi-même, précisément pour les raisons que je donne juste en dessous.
Ce qui a changé n'est pas la qualité de ces MCP, c'est l'endroit où ils tournaient. Une commande, je peux l'appeler depuis Claude Code, depuis un autre assistant, depuis un script lancé par mon serveur à trois heures du matin. Un MCP ne vit que dans l'assistant qui le charge, et il occupe du contexte tant qu'il est là.
DaVinci MCP : Automatisation de DaVinci Resolve pour mes vidéos YouTube (insertion de B-rolls, zooms animés). Inspiré de Firecut mais avec un accès direct pour Claude Code. Je monte mes videos désormais en language naturel.
Metricool MCP : celui-là n'en est pas vraiment un. J'ai construit mon propre service branché sur mes réseaux sociaux, avec mes endpoints, en m'inspirant de ce que fait Metricool. La raison était bêtement économique : leur API se paie plusieurs dizaines d'euros par mois, et je ne voulais pas payer ça pour publier mes propres posts.
Depuis, ils ont sorti un connecteur Claude gratuit. Mon service n'a plus beaucoup de raisons d'exister.
C'est le risque de tout ce qu'on construit dans cet écosystème : la brique que tu codes aujourd'hui parce qu'elle manque peut arriver gratuitement six mois plus tard, sans prévenir. Ce n'est pas une raison pour ne rien construire, sinon tu attends indéfiniment. C'est une raison pour construire petit et ne pas s'attacher : le jour où l'officiel sort, tu jettes le tien sans regret parce qu'il t'a coûté deux soirées, pas deux mois.
Le vrai intérêt
Quand tu crées ton propre MCP, tu ne donnes à l'IA que les outils que tu choisis. Tu définis la méthodologie. Elle est obligée de lire la documentation du MCP pour comprendre comment l'utiliser.
Résultat : elle fait les choses exactement comme toi tu les fais, sans que tu aies à lui expliquer à chaque fois.
C'est ce qui protège aujourd'hui mes projets vidéo dans DaVinci : Claude ne peut pas faire n'importe quoi, il est limité aux outils que je lui donne, avec les garde-fous que j'ai définis. Là où l'outil manipule quelque chose d'irremplaçable, le verrou vaut son coût en contexte.
Pour mes notes, en revanche, j'ai fini par préférer une ligne de commande. Le risque n'est pas le même : un vault versionné se restaure, un projet de montage beaucoup moins.
Script vs MCP : une distinction importante
Un script dans un skill, Claude peut le modifier s'il veut. Les outils d'un MCP, non, ils sont figés.
C'est la différence fondamentale :
- Un script dans un skill : portable, léger, lançable sans IA. C'est devenu mon défaut, y compris pour des choses qui ne sont pas simples du tout.
- Un MCP custom : quand tu veux verrouiller le comportement et t'assurer que l'IA ne touche pas à ce qu'elle ne devrait pas. C'est ce qui protège mon vault Obsidian et mes projets DaVinci, et c'est la seule raison pour laquelle j'en construis encore.
Et bonne nouvelle : c'est devenu assez simple à construire. Si tu sais décrire ce que tu veux que l'IA fasse, tu peux créer un MCP. Claude Code peut même t'aider à le coder.
Où trouver des MCPs (et comment les évaluer)
Il y a de plus en plus de MCPs disponibles. Le problème, c'est la qualité : certains sont excellents, d'autres consomment trop de contexte, et quelques-uns posent de vrais problèmes de sécurité.
Voici comment je fais :
Pour trouver : je cherche principalement sur Smithery et sur Claude Code Template. Mais honnêtement, ma méthode préférée c'est de demander directement à Claude Code de chercher pour moi. Il trouve souvent des MCPs que je n'aurais pas trouvés seul.
Pour évaluer : Avant d'installer un MCP, je le fais passer par un skill d'évaluation créé par jeredblud. Il analyse le code source du MCP, vérifie la sécurité, la fiabilité, la vie privée, et donne un score sur 5 dimensions.
Ce qui est bien, c'est que ça me fait souvent découvrir de meilleures alternatives. Tu cherches un MCP pour un service, l'évaluateur te dit "celui-là est moyen, mais regarde celui-ci".
Les risques à connaître
Installer un MCP, c'est donner à un programme l'accès à ta machine avec tes privilèges. C'est pas anodin.
Voici les risques principaux :
Tool poisoning : un MCP peut cacher des instructions malveillantes dans la description de ses outils. L'IA les lit, les exécute, et tu ne vois rien.
Supply chain, ou "rug pull" : un MCP légitime peut être remplacé par une version piégée lors d'une mise à jour. Tu fais confiance au nom, mais le code a changé.
Exfiltration de données : un MCP peut envoyer tes données ailleurs en douce. En septembre 2025, un package npm qui imitait le service d'emailing Postmark envoyait secrètement une copie de chaque email à un attaquant.
L'OWASP a publié un Top 10 spécifique aux MCPs pour documenter ces risques.
Mon conseil : évalue systématiquement avant d'installer. Privilégie les MCPs connus et audités. Et si un MCP n'existe pas ou ne te convient pas, construis le tien. Au moins, tu sais exactement ce qu'il y a dedans.
Une note sur le contexte
Les MCPs, ça consomme du contexte. Chaque outil chargé prend de la place dans la fenêtre de conversation de l'IA.
Bonne nouvelle : depuis début 2026, Claude Code utilise le lazy loading (MCP Tool Search). Au lieu de charger tous les outils au démarrage, il ne les charge que quand il en a besoin. Sur ma propre configuration, début 2026, 7 MCP actifs coûtaient environ 67 000 tokens avant même d'écrire une ligne. Après le lazy loading, la même configuration retombait autour de 8 700. Ces chiffres sont les miens et dépendent des MCP installés : ce qui compte est l'ordre de grandeur, un facteur proche de dix.
En pratique, c'est mieux mais c'est pas encore parfait. Certains MCPs restent gourmands une fois utilisés. Mon conseil : n'hésite pas à déléguer certaines tâches à des sous-agents pour libérer du contexte.
Le mot de la fin
Les MCPs, c'est ce qui transforme Claude d'un assistant généraliste en un outil spécialisé pour TON workflow.
Commence par les 4 quotidiens (Sequential Thinking, Claude in Chrome, Context7, Bright Data). Installe-les en global, et ajoute les autres en local au fur et à mesure de tes besoins.
Évalue chaque MCP avant de l'installer : la sécurité, c'est pas optionnel.
Et si un MCP n'existe pas pour ton use case, ou s'il ne te convient pas... construis le tien. C'est comme ça que tu gardes le contrôle.
Commentaires