MCP servers : j'en ai testé 30, voici les 7 qui valent

Les MCP servers sont à Claude Code ce que les extensions sont à VS Code : il y en a 400+ listés officiellement, la plupart sont médiocres ou abandonnés, quelques-uns sont essentiels, et tu ne découvres les vrais gagnants qu'après les avoir tous essayés. J'ai passé 3 week-ends à installer et tester 30 serveurs sur mes projets réels. Voici les 7 qui restent dans mon .mcp.json aujourd'hui, et brièvement les 23 que j'ai désinstallés — avec la raison.

Les critères que j'utilise

Pour qu'un MCP reste dans ma config, il doit remplir 3 critères :

1. 1.Utilisé au moins 3 fois par semaine sur 2 semaines de mesure
2. 2.Zéro crash en usage réel sur cette même période
3. 3.Gain mesurable (temps, qualité, ou capacité nouvelle) vs l'équivalent en commande shell

30 serveurs testés, 7 gardés. Taux de rejet : 77%. Voici le classement.

Les 7 gagnants

1. `filesystem` (officiel Anthropic) — ⭐⭐⭐⭐⭐

Le fondamental. Lit/écrit/liste des fichiers dans un répertoire autorisé. Sans ça, Claude Code ne peut rien faire d'utile sur ta codebase. 50+ utilisations par jour chez moi.

Why essential : c'est la porte d'entrée. Désactive-le, ton agent est aveugle.

2. `git` (officiel Anthropic) — ⭐⭐⭐⭐⭐

Commit, diff, log, branch, stash. L'agent peut voir l'historique et créer des commits propres. 20-30 utilisations par jour.

Why essential : sans ça, l'agent code sans contexte historique et fait des commits que tu dois renommer toi-même.

3. `brave-search` — ⭐⭐⭐⭐⭐

Recherche web par API Brave (2 000 requêtes gratuites/mois). Plus rapide que Google pour le contexte dev, et sans cookies tracking.

Why essential : quand l'agent a besoin de vérifier une syntaxe récente, un changement d'API, ou un bug connu, il cherche en ligne. Sans ça, il hallucine les docs.

4. `postgres` / `sqlite` (officiel) — ⭐⭐⭐⭐

Query ta base de données directement depuis Claude Code. L'agent peut voir le schéma réel, tester des requêtes, valider des migrations.

Why essential : c'est la différence entre « l'agent devine le schéma » et « l'agent lit le schéma ». Un coût en latence minime pour une fiabilité drastiquement meilleure.

5. `slack` — ⭐⭐⭐⭐

Lire et poster dans mes channels Slack perso. L'agent peut répondre à des questions techniques dans #dev sans que j'y sois, et me notifier quand un build échoue.

Why essential (pour moi) : remote team, asynchrone. Le gain vient de pouvoir « déléguer » les questions factuelles à l'agent.

6. `puppeteer` — ⭐⭐⭐⭐

Browser automation. L'agent peut ouvrir une URL, screenshot, cliquer, remplir un form. Utile pour le debug frontend et les tests E2E.

Why essential : quand tu debug un bug qui n'apparaît qu'en conditions réelles dans un navigateur, cette capacité est magique. Sans, tu dois faire l'aller-retour manuel.

7. `memory-graph` (community) — ⭐⭐⭐⭐

Stockage persistant de facts sur tes projets (people, preferences, decisions). Permet à l'agent de « se souvenir » entre sessions.

Why essential : sans ça, l'agent réapprend tes préférences à chaque session. Avec, il sait déjà que tu préfères les tests Vitest à Jest et les imports relatifs.

Les 23 qui n'ont pas survécu

Je les groupe par catégorie avec la raison principale du rejet.

Les doublons officiels (5 rejetés)

• •fetch (community) → redondant avec brave-search
• •sqlite-alternative → moins fiable que l'officiel
• •time → date en commande shell suffit
• •weather → gadget, jamais utilisé en vrai
• •calculator → Claude calcule déjà très bien

Raison commune : ils font ce qu'une commande shell fait en mieux.

Les intégrations SaaS abandonnées (8 rejetés)

• •linear → API obsolète, crashes fréquents
• •notion → lent, rate-limited
• •jira → auth complexe, pas worth it pour mes usages solo
• •github-issues → gh CLI est meilleur
• •twitter → API payante, pas rentable
• •discord → lag pour usage dev
• •trello → abandonné par son auteur
• •asana → pas maintenu depuis 2024

Raison commune : intégrations SaaS mal maintenues ou redondantes avec un CLI natif.

Les « intelligents » qui ne l'étaient pas (6 rejetés)

• •code-search → naïvement basé sur grep, moins bon que ripgrep direct
• •ast-walker → lent et cassait sur mon TypeScript récent
• •docs-searcher → hallucinait les URLs de docs
• •stackoverflow → réponses souvent obsolètes
• •npm-registry → npm search est plus rapide
• •crates-io → idem pour Rust

Raison commune : ils rajoutaient une couche LLM là où une commande native était plus fiable.

Les trop invasifs (4 rejetés)

• •aws-ec2 → donne trop de pouvoir à l'agent (peur de facture)
• •terraform-state → risque de casser l'infra en prod
• •kubectl → je préfère exécuter moi-même sur la prod
• •docker-manager → recours au shell direct préféré

Raison commune : je ne veux pas que Claude Code touche à mon infra sans supervision.

Mon `.mcp.json` actuel

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/home/patrice/dev"]
    },
    "git": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-git", "--repository", "/home/patrice/dev"]
    },
    "brave-search": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-brave-search"],
      "env": {"BRAVE_API_KEY": "..."}
    },
    "sqlite": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-sqlite", "--db-path", "./db.sqlite"]
    },
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": {"SLACK_BOT_TOKEN": "..."}
    },
    "puppeteer": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-puppeteer"]
    },
    "memory-graph": {
      "command": "npx",
      "args": ["-y", "mcp-memory-graph"]
    }
  }
}

La leçon en 3 points

1. 1.77% des MCP testés sont jetables. Ne les installe pas par défaut.
2. 2.Les officiels Anthropic sont presque toujours mieux que leurs équivalents community (stabilité, support).
3. 3.Méfie-toi des MCP qui ajoutent une couche LLM là où une commande shell ferait le travail — tu payes pour un gadget.

Ce qu'il faut retenir

1. 1.7 MCP servers sur 30 ont survécu à mon test réel sur 6 semaines.
2. 2.Les fondamentaux (filesystem, git, search, db) sont les seuls incontournables.
3. 3.Les intégrations SaaS sont souvent mal maintenues — préfère les CLIs natifs.
4. 4.Règle test-driven : 3 utilisations/semaine minimum, sinon on vire.

Pour aller plus loin sur la configuration optimale de Claude Code et les patterns Ralph Loop qui rendent tout ça productif, j'ai écrit un livre dédié :

La Boucle Ralph

Guide Pratique du Coding Autonome par IA.

Découvrir →