Les serveurs MCP qui servent vraiment avec Claude Code

Chaque semaine, un nouveau classement “les 50 meilleurs serveurs MCP” circule. J’en ai installé une bonne douzaine en suivant ces listes. Un mois de travail client plus tard, il m’en reste trois. Les autres ont été retirés pour la même raison : ils coûtaient plus de contexte qu’ils ne rendaient de service.

Voici les trois survivants, pourquoi ils sont restés, et la méthode pour évaluer n’importe quel serveur MCP en dix minutes avant de l’imposer à votre config.

Le coût caché d’un serveur MCP

D’abord, le critère que les classements ignorent : chaque serveur MCP injecte ses définitions d’outils dans le contexte de Claude Code, à chaque session. Un serveur avec vingt outils, c’est plusieurs milliers de tokens consommés avant même votre premier prompt. Trois serveurs comme ça, et vous avez amputé votre fenêtre de contexte d’une part significative pour des outils que vous n’utiliserez peut-être pas de la session.

La question n’est donc jamais “ce serveur est-il utile ?” mais “ce serveur rend-il plus que ce qu’il coûte ?”. C’est le filtre qui a éliminé la plupart de ma douzaine initiale.

1. Playwright : les yeux de Claude sur votre frontend

Le problème qu’il résout : sans lui, Claude Code modifie votre CSS, vous dit “c’est corrigé”, et vous découvrez que non. Avec lui, Claude pilote un vrai navigateur, prend des captures, lit la console, et vérifie lui-même son travail.

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest"]
    }
  }
}

Le moment où il s’est payé : une régression d’affichage sur un formulaire de paiement que Claude a détectée seul, capture à l’appui, avant que je relise le code. Le cycle “modifie, vérifie, corrige” tourne sans moi.

À savoir : c’est le serveur le plus gourmand des trois en tokens (beaucoup d’outils). Je l’active par projet, dans le .mcp.json des projets frontend uniquement, jamais dans ma config utilisateur globale.

2. Context7 : la fin des signatures d’API inventées

Le problème qu’il résout : Claude connaît les bibliothèques telles qu’elles existaient à sa date d’entraînement. Sur une lib qui bouge vite, il invente des options plausibles mais fausses. Context7 lui donne accès à la documentation à jour, versionnée, au moment où il en a besoin.

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    }
  }
}

Le moment où il s’est payé : une migration Astro où Claude utilisait une API de la version précédente. Avec Context7, il a vérifié la doc de la version installée et corrigé son propre code sans aller-retour d’erreurs.

À savoir : deux outils seulement, coût en contexte minimal. C’est le seul des trois que je laisse dans ma config utilisateur globale.

3. GitHub : utile, mais pas pour ce que vous croyez

Le problème qu’il résout : lire les issues, examiner les PRs, chercher dans les repos, sans quitter la session. Pour un freelance qui jongle entre plusieurs repos clients, c’est le fil qui relie tout.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_MCP_TOKEN}"
      }
    }
  }
}

La nuance honnête que les listicles ne font jamais : si vous avez le CLI gh installé, Claude Code sait déjà l’utiliser via Bash, sans aucun serveur MCP. Pour créer une PR ou lire une issue de temps en temps, gh suffit et coûte zéro token de définition d’outils. Le serveur MCP ne se justifie que si votre flux de travail est réellement centré sur GitHub : triage d’issues, revues en série, recherche multi-repos.

Notez la référence ${GITHUB_MCP_TOKEN} : le token vit dans votre environnement, jamais dans le fichier versionné. Si vous partagez ce .mcp.json avec une équipe, j’ai détaillé les règles dans partager une config Claude Code en équipe.

Ceux que j’ai retirés, et pourquoi

• Le serveur de base de données en usage quotidien : trop d’outils pour mon besoin réel, qui était “lance cette requête de temps en temps”. psql via Bash fait la même chose. Je le réactive ponctuellement pour les grosses sessions d’exploration de schéma.
• Les serveurs de services SaaS (gestion de projet, notes, calendrier) : l’intégration était réelle mais le besoin ne venait qu’une fois par semaine. Un onglet navigateur coûte moins cher qu’un jeu de définitions d’outils permanent.
• Tout serveur non maintenu : un serveur MCP qui n’a pas été mis à jour depuis six mois casse en silence après une mise à jour de Claude Code ou de l’API qu’il enrobe. Vérifiez la date du dernier commit avant d’installer.

Évaluer n’importe quel serveur MCP en dix minutes

1. Comptez ses outils. Plus de dix outils pour votre cas d’usage d’un seul, c’est un mauvais ratio contexte/service.
2. Cherchez l’équivalent CLI. Si un binaire que Claude sait déjà piloter fait le travail (gh, psql, curl), le serveur doit apporter plus que la commodité.
3. Testez sur une tâche réelle, pas sur la démo du README. La démo est optimisée, votre cas ne l’est pas.
4. Regardez ce qu’il demande. Un serveur qui veut un token large alors que votre besoin est en lecture seule mérite un token restreint, ou un refus.
5. Décidez de sa place : config utilisateur (toutes les sessions le paient) ou .mcp.json projet (seul le projet concerné le paie). En cas de doute, projet.

La règle des trois

Ma config stable : Context7 en global, Playwright et GitHub par projet, selon le besoin. Trois serveurs actifs au maximum dans une session donnée. Chaque ajout au-delà doit en faire sortir un autre.

Ce n’est pas une limite technique, Claude Code accepte bien plus. C’est une discipline de budget : le contexte que vos serveurs MCP ne consomment pas, c’est du contexte disponible pour votre code. Et si vous voulez vérifier ce que votre fenêtre de contexte contient vraiment, j’ai écrit sur comment la mesurer.