Meilleurs serveurs MCP pour Claude en 2026 (nos choix)

Un mot sur ce que c'est réellement avant de lire une ligne de plus : SkillProof teste des skills, pas des serveurs MCP. Chaque skill de notre catalogue est installée sur une machine vierge et exécutée sur du vrai travail, puis notée sur l'installation, le déclenchement, la sortie et la documentation. Nous ne faisons pas encore tourner ce même harnais sur les serveurs MCP, donc rien ci-dessous ne porte l'une de nos notes sur 10.

Ce qui suit est notre liste de choix d'ingénierie : les serveurs que nous, et les gens en qui nous avons confiance, utilisons réellement au quotidien, choisis par adoption dans l'écosystème et notre propre usage journalier, pas un test noté. Une méthodologie MCP notée arrive. En attendant, prenez ceci comme une shortlist de gens qui ont connecté la plupart de ces serveurs et en ont déconnecté la moitié à nouveau.

Ce que fait réellement un serveur MCP

Un serveur MCP est un programme qui tourne et qui parle le Model Context Protocol, exposant un jeu d'outils que Claude peut appeler : lire ce fichier, interroger cette table, poster dans ce canal, cliquer sur ce bouton dans un navigateur. C'est le mécanisme par lequel Claude atteint des systèmes qu'il ne pourrait pas toucher autrement. C'est un travail différent de celui d'une skill, qui est une instruction markdown qui change la façon dont Claude aborde une tâche qu'il peut déjà techniquement faire. Nous avons posé le comparatif complet dans Skills Claude vs MCP, et la version courte compte aussi ici : installez un serveur quand le problème est « Claude ne peut pas voir mes données », pas quand le problème est « la sortie de Claude n'est pas assez bonne ».

L'avertissement sur le coût en tokens, avant la liste

Lisez cette section avant d'installer quoi que ce soit ci-dessous, parce qu'elle change quels serveurs valent le coup.

Chaque serveur MCP que vous connectez embarque ses schémas d'outils dans le contexte de Claude à chaque requête, que vous utilisiez le serveur ce tour-ci ou non. Un schéma d'outil, c'est son nom, sa description et sa spécification complète de paramètres, et un serveur typique expose dix à trente outils. Connectez quatre ou cinq serveurs et vous pouvez dépenser des milliers de tokens avant même d'avoir tapé un mot. Nous avons mesuré notre propre configuration pour notre guide du coût en tokens : trois serveurs de taille moyenne ajoutaient environ 10 000 tokens de surcharge permanente par requête, et un serveur officiel plus lourd ajoutait environ 20 000 tokens à lui seul pour un outil que nous avons utilisé deux fois ce mois-là.

Ce n'est pas un coût ponctuel. Il se facture à chaque tour de chaque session, pour toujours, jusqu'à ce que vous déconnectiez le serveur. Un préambule de 10 000 tokens sur une session de 50 messages, c'est 500 000 tokens dépensés en définitions que personne n'a lues. En facturation API, cela apparaît directement sur la facture. Sur un abonnement Pro ou Max, cela se manifeste par le fait d'atteindre vos limites plus tôt dans la journée.

Donc la règle de fonctionnement pour cette liste est : installez moins, pas plus. Décidez si le travail de cette semaine a réellement besoin d'un serveur, ciblez-le sur le projet qui en a besoin, et déconnectez-le la semaine où vous n'en avez plus besoin. Chaque entrée ci-dessous vous dit quand elle mérite cette taxe et quand la sauter, parce que « ça pourrait servir un jour » est la façon dont les gens finissent par faire tourner neuf serveurs et se demandent pourquoi Claude semble moins vif qu'avant.

Nos choix, par catégorie

Ceux-ci sont regroupés par métier, pas classés les uns contre les autres, parce que la bonne réponse est presque toujours « les un ou deux qui correspondent au travail de cette semaine », pas « tous ».

Système de fichiers

Ce qu'il fait : Donne à Claude un accès structuré en lecture et écriture à une arborescence sur disque, au-delà de ce que couvrent les outils de fichiers intégrés d'un client de chat. Utile dans les configurations où Claude tourne quelque part sans accès fichier de première classe déjà présent, ou où vous voulez un ciblage plus étroit que « tout le projet ».

Quand il mérite son coût : Vous faites tourner Claude en dehors de Claude Code (un agent custom, un client de chat avec support MCP) et avez besoin d'une vraie lecture/écriture de fichiers, ou vous voulez restreindre Claude à un sous-répertoire spécifique plutôt qu'à tout un dépôt.

Quand le sauter : À l'intérieur de Claude Code lui-même, c'est proche du redondant. Le CLI a déjà des outils de fichiers intégrés, donc ajouter un serveur de système de fichiers ici n'est souvent qu'une taxe de schéma supplémentaire pour une capacité que vous avez déjà gratuitement.

Git

Ce qu'il fait : Expose les opérations git comme des outils appelables : status, diff, log, branch, commit, blame, sur un dépôt local, de façon structurée plutôt que parsée depuis une sortie de commande brute.

Quand il mérite son coût : Vous voulez que Claude raisonne sur l'historique git et les diffs comme des données structurées plutôt qu'en shellant et en parsant du texte, ce qui compte davantage pour des constructions d'agent custom que pour Claude Code, qui exécute déjà git via bash proprement.

Quand le sauter : Dans Claude Code, exécuter git log et git diff via bash donne à Claude la même information à coût de schéma nul. N'ajoutez celui-ci que si vous construisez un agent qui n'a pas d'accès shell pour commencer.

GitHub

Ce qu'il fait : Connecte Claude à l'API GitHub : lire et déposer des issues, ouvrir et revoir des pull requests, vérifier le statut CI, gérer des labels et des jalons, tout ça sans quitter la conversation.

Quand il mérite son coût : Votre travail passe réellement par GitHub comme système : trier un backlog d'issues, rédiger des descriptions de PR à partir d'un diff, vérifier si les checks d'une release sont au vert. Le serveur officiel expose beaucoup d'outils, budgétez donc de vrais tokens de schéma pour lui.

Quand le sauter : Si votre seul usage est git push et lire un diff, le CLI gh via bash fait le même travail sans connexion persistante ni token à gérer. Utilisez le serveur quand Claude doit agir sur l'état de GitHub lui-même : déposer, étiqueter, commenter des choses qui existent déjà là-bas.

Automatisation de navigateur : Playwright et Puppeteer

Ce qu'ils font : Les deux pilotent un vrai navigateur, donc Claude peut cliquer sur une page, remplir des formulaires, attendre que des éléments s'affichent, prendre des captures d'écran, et lire le DOM ou le trafic réseau qui en résulte. Le serveur de Playwright tend à exposer une lecture d'arbre d'accessibilité plus propre ; celui de Puppeteer est la surface plus ancienne et minimale, et apparaît davantage dans les chaînes d'outils existantes déjà standardisées dessus.

Quand ils méritent leur coût : Tests de bout en bout d'une app web, scraping d'une page qui ne se rend qu'après exécution de JavaScript, ou vérification qu'un changement d'UI a bien l'air correct dans un navigateur en direct plutôt que de faire confiance au code. C'est l'une des rares catégories où « Claude ne peut littéralement pas faire ça sans un serveur » est vrai sans réserve ; aucune instruction ne donne à un modèle des yeux sur une page rendue.

Quand les sauter : Si vous avez juste besoin de lire le HTML statique d'une page, un simple fetch fait le travail pour une fraction des tokens et sans processus navigateur à gérer. Ne dégainez pas un serveur d'automatisation de navigateur complet pour lire un article de blog.

Postgres

Ce qu'il fait : Donne à Claude une connexion en direct, généralement en lecture seule, à une base Postgres : introspection de schéma, exécution de requêtes, inspection des plans d'exécution.

Quand il mérite son coût : Vous avez besoin que Claude raisonne sur votre vrai schéma et vos vraies données, pas un dump de schéma collé le mois dernier qui a dérivé depuis. Déboguer une requête lente contre la vraie sortie EXPLAIN, ou écrire une migration qui doit tenir compte de tables déjà existantes, vont tous deux plus vite avec une connexion en direct qu'avec du contexte périmé.

Quand le sauter : Une analyse ponctuelle d'un export CSV n'a pas besoin d'une connexion base de données. Et connecter un identifiant capable d'écrire pour de l'exploration en lecture seule est un vrai risque ; scopez le token en lecture seule dès que la tâche le permet. Associez ce serveur à une skill qui encode une discipline de requête prudente ; une connexion en direct sans couche de jugement, c'est comme ça qu'on obtient un scan de table complet accidentel contre la production.

Fetch

Ce qu'il fait : Un serveur étroit et à faible surcharge qui récupère une URL et retourne son contenu, souvent converti en markdown, pour que Claude puisse lire une page sans navigateur.

Quand il mérite son coût : Vous avez besoin d'informations actuelles depuis une URL connue spécifique, documentation, changelog, réponse d'API publique, sans toute la surcharge de l'automatisation de navigateur. C'est parmi les serveurs les plus légers de cette liste en termes de taxe de schéma.

Quand le sauter : Si votre client a déjà un fetch web intégré (Claude Code l'a), un serveur fetch séparé est généralement une capacité en doublon. Vérifiez ce que vous avez déjà avant d'ajouter celui-ci.

Recherche (Brave Search ou similaire)

Ce qu'il fait : Exécute des recherches web via une API de recherche et retourne des résultats que Claude peut lire, par opposition à récupérer une seule URL connue.

Quand il mérite son coût : Recherche ouverte où vous ne connaissez pas l'URL source à l'avance : « quel est l'état actuel de X », recherche concurrentielle, trouver les correctifs connus d'un message d'erreur spécifique.

Quand le sauter : Si votre client a déjà une recherche web intégrée, c'est une capacité redondante avec sa propre clé API à gérer et sa propre taxe de schéma. Confirmez ce que votre configuration couvre déjà avant d'ajouter un second chemin de recherche.

Slack

Ce qu'il fait : Lit et poste sur Slack : historique de canal, DM, threads, réactions, pour que Claude puisse résumer un canal ou poster une mise à jour sans que vous copiiez-colliez dans un sens ou dans l'autre.

Quand il mérite son coût : Travail de communication récurrent : poster des résumés de standup, extraire du contexte d'un thread avant de rédiger une réponse, trier un canal devenu ingérable. C'est aussi l'exemple canonique d'un serveur autour duquel une skill pousse vite : connectez Slack, postez un résumé qui sonne comme un communiqué de presse, et vous vous retrouverez à écrire des règles de formatage en une journée. Ce n'est pas un reproche fait au serveur ; c'est le schéma normal MCP-plus-skill.

Quand le sauter : Si votre usage de Slack est occasionnel, la taxe de schéma d'outils tourne tous les jours pour une capacité que vous utilisez deux fois par semaine. Envisagez de ne le connecter que les jours où vous en avez besoin, ou de le cibler sur le seul projet où la communication fait partie du vrai travail.

Mémoire

Ce qu'il fait : Donne à Claude un magasin de connaissances persistant à travers les sessions, généralement un petit graphe d'entités et de relations, pour que les faits de la conversation de la semaine dernière ne disparaissent pas quand la session se termine.

Quand il mérite son coût : Projets à long terme où réexpliquer le contexte à chaque session est la vraie dépense, pas la taxe de schéma. Si vous vous retrouvez à retaper « rappelle-toi, on a décidé X » au début de chaque conversation, c'est le signal.

Quand le sauter : Les tâches courtes et autonomes n'en profitent pas ; il n'y a rien à mémoriser sur une session qui se termine en vingt minutes. Notez aussi qu'une skill mémoire résout une bonne partie de ce même problème sans aucun serveur, puisqu'elle peut maintenir des notes dans un fichier sur disque que Claude lit et met à jour directement. Vérifiez si vous avez besoin de la connexion toujours active ou juste d'une habitude de persistance avant d'ajouter le serveur.

La voie du fais-le-toi-même

Toute liste comme celle-ci rate votre API interne, votre système de tickets maison, l'outil unique que votre équipe a construit dont personne d'autre n'a entendu parler. Pour ceux-là, le chemin le plus rapide n'est pas d'attendre que quelqu'un publie un serveur ; c'est d'en construire un.

MCP Builder, issu du dépôt officiel de skills d'Anthropic, a obtenu 8.8/10 dans nos tests (verdict : pass) : il guide Claude à travers la mécanique réelle d'un serveur MCP, définitions d'outils, schémas, auth, gestion d'erreurs, plutôt que de vous laisser assembler ce boilerplate à partir de la documentation. Dans notre test, il a construit un serveur fonctionnel enveloppant une API REST interne, complet avec schémas d'outils et gestion d'erreurs, en environ une heure de travail supervisé. C'est la skill qu'Anthropic elle-même utilise pour apprendre à Claude à construire la chose même dont cet article est une liste, ce qui règle tout débat sur le fait que skills et MCP seraient concurrents plutôt que des couches.

Si le blocage de votre équipe est « personne n'a construit de serveur pour notre outil interne », c'est un chemin plus direct que de chercher un serveur qui n'existe pas.

Skills vs MCP, le rappel de décision

La question sous-jacente à la plupart de cet article est une que l'on nous pose constamment : avez-vous besoin d'une skill ou d'un serveur pour un problème donné ? Le test qui fonctionne réellement est de demander ce qui échoue. Si Claude a techniquement l'information ou la capacité mais la gère mal, formatage incohérent, cas limites manqués, sortie générique, c'est un problème de jugement, et une skill le corrige pour un coût au repos proche de zéro. Si Claude ne peut tout simplement pas atteindre la chose du tout, aucune connexion base de données, aucun navigateur, aucun canal Slack en direct, c'est un problème d'accès, et seul un serveur comble cet écart.

La plupart du travail quotidien penche davantage du côté skill que les gens ne l'imaginent. Rédaction, revue de code, génération de documents, analyse de fichiers déjà devant Claude : rien de tout cela n'a besoin d'un serveur. MCP mérite son temps de configuration et sa taxe de tokens spécifiquement quand un système externe en direct est central à la tâche, une vraie catégorie, juste plus étroite que ce que suggèrerait la taille de la plupart des configurations MCP des gens. Notre parcours de configuration complet séquence cela en un vrai ordre de construction de 30 minutes : les skills d'abord, puisqu'elles sont gratuites au repos, puis les un ou deux serveurs dont le projet a réellement besoin.

Combien de serveurs, c'est trop

Notre réponse, avec parti pris : la plupart des configurations ont besoin de deux ou trois, ciblés sur le projet spécifique, pas connectés globalement.

Le test que nous utilisons sur nos propres machines est simple. Pour chaque serveur connecté, pouvez-vous dire à quoi il sert cette semaine ? Si la réponse est « je l'ai configuré pour un truc que j'ai fait le mois dernier », il ne mérite pas sa taxe ; il est juste là à détenir un identifiant et à coûter des tokens de schéma indépendamment. Nous faisons cet audit mensuellement et gardons rarement plus de trois serveurs connectés à un projet donné une fois honnêtes avec nous-mêmes.

Le mode d'échec n'est pas un plafond dur ; c'est que les serveurs MCP n'annoncent pas leur coût comme le ferait une réponse lente. Un CLAUDE.md boursouflé est évident dès que vous le faites défiler. Les schémas MCP inactifs restent invisibles jusqu'à ce que vous exécutiez /context et voyiez quarante mille tokens de définitions d'outils assis devant votre vraie question. Vérifiez ce chiffre avant d'ajouter un quatrième serveur, pas après.

FAQ

Quels sont les meilleurs serveurs MCP pour Claude en 2026 ?

Pour la plupart des configurations : un serveur système de fichiers ou git si vous êtes en dehors de Claude Code (les deux sont proches du redondant à l'intérieur), GitHub si les issues et PR sont centrales à votre travail, Playwright ou Puppeteer pour l'automatisation de navigateur, Postgres pour le travail sur base de données en direct, et Slack si la communication passe par là quotidiennement. Deux ou trois d'entre eux, pas tous, est la réponse réaliste pour la configuration d'une seule personne.

Ai-je besoin de serveurs MCP si j'utilise Claude Code ?

Moins que vous ne le pensez. Claude Code a déjà un accès fichier, un accès shell (donc git et gh fonctionnent via bash), et un fetch web intégrés. Les serveurs qui ajoutent une vraie nouvelle capacité par-dessus sont ceux qui atteignent des systèmes vers lesquels Claude Code n'a aucun chemin natif : une base de données en direct, un navigateur, Slack, l'API d'un système de tickets.

Combien de contexte les serveurs MCP coûtent-ils réellement ?

Cela varie selon le serveur, et c'est exactement pourquoi vous devriez vérifier le vôtre plutôt que de faire confiance à une règle générale. Les serveurs petits et ciblés tournent autour de 1 000 à 3 000 tokens de schéma. Les gros serveurs officiels avec des dizaines d'outils ont été mesurés dans la fourchette de 15 000 à 25 000 dans nos propres audits. Exécutez /context avec un serveur connecté puis à nouveau déconnecté pour voir votre vrai chiffre.

Ces serveurs sont-ils notés de la même façon que SkillProof note les skills ?

Non, et nous l'avons dit exprès en haut de cet article. Notre notation sur l'installation, le déclenchement, la sortie et la documentation est une méthodologie skills que nous avons exécutée sur 73 skills jusqu'ici. Une méthodologie notée comparable pour les serveurs MCP est en cours ; cette liste est notre jugement d'ingénierie et notre usage quotidien, pas un résultat de test.

Une skill peut-elle remplacer un serveur MCP ?

Pas pour l'accès lui-même ; une skill ne peut pas ouvrir une connexion base de données ou piloter un navigateur toute seule. Mais une skill peut tout à fait remplacer la couche de jugement que les gens attendent à tort d'un serveur. Beaucoup de serveurs connectés que nous avons vus se font suivre presque immédiatement d'une skill décrivant comment bien les utiliser, des schémas de requête prudents pour un serveur base de données, des règles de formatage pour un serveur Slack. Le serveur vous y amène ; la skill décide quoi faire une fois arrivé.