Cinq serveurs MCP utiles pour mieux travailler avec Claude Code et Gemini CLI

Un assistant de programmation est particulièrement utile lorsqu’il peut comprendre le projet sur lequel il intervient. Mais, par défaut, un modèle de langage ne voit ni les fichiers d’un ordinateur, ni les dépôts privés, ni les pages web utiles à une tâche. Les serveurs MCP, pour Model Context Protocol, sont conçus pour créer ce pont de manière contrôlée. Avec Claude Code ou Gemini CLI, ils peuvent éviter de nombreux aller-retours entre le terminal, l’éditeur et le navigateur.

Au 8 septembre 2025, cinq serveurs se distinguent par la diversité de leurs usages : Filesystem, Sequential Thinking, GitHub, Fetch et Memory. Ils ne constituent pas un classement universel ni une installation obligatoire. Chacun répond à un besoin précis : agir sur un projet local, organiser un raisonnement, consulter un dépôt, récupérer une ressource en ligne ou retenir du contexte. Leur intérêt dépend donc moins de leur nombre que des autorisations accordées et de la discipline de l’utilisateur.

Ce que change réellement le protocole MCP

MCP est un protocole qui permet à un client d’IA de dialoguer avec des serveurs exposant des outils. En pratique, l’assistant peut demander à utiliser une fonction définie par un serveur : lire un fichier dans un dossier autorisé, rechercher une information dans un dépôt GitHub, récupérer une page web ou enregistrer une note pour plus tard.

Cette architecture apporte une distinction importante. Le modèle ne reçoit pas spontanément un accès global à la machine, à Internet ou aux comptes du développeur. Il passe par des outils explicitement configurés. Un serveur MCP peut donc délimiter les répertoires consultables, exiger un jeton d’accès ou centraliser les requêtes web dans un environnement contrôlé.

Le mot « agent » peut donner l’impression d’une automatisation totalement autonome. Il faut pourtant conserver une vision plus concrète : Claude Code ou Gemini CLI proposent, appellent des outils et exploitent leurs résultats dans le cadre donné. La qualité de la réponse dépend toujours du contexte fourni, des permissions accordées et de la vérification humaine du résultat, notamment avant toute modification de code.

Les cinq serveurs en un coup d’œil

Les cinq outils ne jouent pas le même rôle dans un environnement de développement. Le tableau ci-dessous aide à choisir le bon serveur selon le type de tâche, plutôt que d’installer tous les connecteurs par réflexe.

Filesystem, agir sur le projet sans copier-coller

Le serveur MCP Filesystem donne à l’assistant la possibilité de manipuler directement des fichiers présents sur l’ordinateur. C’est le cas d’usage le plus immédiat pour un développeur : au lieu de copier le contenu d’un fichier dans le terminal, d’attendre une proposition, puis de reporter manuellement les modifications dans l’éditeur, l’agent peut travailler dans le périmètre choisi.

L’intérêt ne réside pas seulement dans le gain de temps. Lorsqu’un problème implique plusieurs fichiers, l’assistant peut examiner l’organisation d’un projet, retrouver les éléments pertinents et proposer une modification plus cohérente avec le reste du code. Il peut aussi créer ou mettre à jour les fichiers nécessaires, dans les limites définies par sa configuration.

La restriction aux répertoires explicitement spécifiés est ici essentielle. Accorder l’accès au dossier du projet n’est pas équivalent à ouvrir tout le disque personnel. Les fichiers de configuration, les clés privées, les documents administratifs ou les archives sans rapport avec le travail ne doivent pas entrer dans le champ de l’outil.

Le serveur prévoit également une journalisation des actions, utile pour suivre ce que l’agent a effectué. Cette traçabilité est précieuse lorsqu’une modification inattendue apparaît : elle permet de distinguer une proposition textuelle d’une action réellement appliquée aux fichiers. Une permission mal définie ou une demande d’autorisation refusée peut toutefois empêcher le serveur de fonctionner comme prévu.

Sequential Thinking, transformer une demande vague en plan vérifiable

Une tâche de développement n’est pas toujours une simple instruction du type « corrige cette erreur ». Il peut s’agir de comprendre un bug difficile à reproduire, de modifier une fonctionnalité qui touche plusieurs composants ou de préparer une migration. Le serveur MCP Sequential Thinking est destiné à décomposer ce type de problème en sous-tâches plus petites et plus lisibles.

Son apport est d’abord méthodologique. Au lieu de recevoir une réponse compacte et difficile à contrôler, l’utilisateur peut demander une séquence d’étapes : examiner la structure concernée, identifier les dépendances, formuler une hypothèse, prévoir une modification, puis vérifier ses effets. Dans Gemini CLI, cette approche peut aider à faire apparaître un chemin de résolution clair et à valider chaque sous-tâche avant de poursuivre.

Ce découpage est particulièrement utile pour conserver la maîtrise d’un projet. Une étape peut être refusée, corrigée ou complétée avant qu’elle ne conduise à la suivante. Il aide également à distinguer ce qui relève de l’analyse, de la modification et du contrôle final.

Pour autant, une procédure bien présentée n’est pas une garantie de justesse. Le serveur structure le travail, mais il ne remplace ni l’exécution des tests, ni l’examen du code, ni la connaissance fonctionnelle du produit. Son meilleur usage est donc celui d’un outil de planification et de clarification, pas d’un arbitre automatique.

GitHub et Fetch, relier l’assistant au dépôt et au web

GitHub, une vue d’ensemble sur le code hébergé

Le serveur MCP GitHub relie l’assistant à des projets hébergés sur GitHub au moyen de l’API de la plateforme. Il peut ainsi aider à analyser les fichiers d’un dépôt, à obtenir une vue d’ensemble d’un projet en cours et à repérer des problèmes éventuels dans le code. Selon les actions autorisées, il peut aussi suggérer des modifications à apporter.

Ce serveur devient utile dès qu’un projet n’est plus limité aux fichiers ouverts localement. Il peut permettre à l’assistant de retrouver les éléments essentiels d’un dépôt, de comparer des parties de code ou de répondre à une question qui nécessite une vision plus large de l’organisation du projet.

Son installation implique l’utilisation d’un token GitHub, à renseigner dans la configuration. C’est un point de sécurité déterminant. Ce jeton doit être considéré comme un secret : il ne doit pas être copié dans un échange public, inscrit dans un fichier versionné ou doté de droits plus étendus que nécessaire. Avant d’autoriser des modifications, mieux vaut commencer par des usages de consultation et vérifier systématiquement les propositions faites.

Fetch, récupérer des contenus sans ouvrir un accès réseau direct

Le serveur MCP Fetch sert de passerelle entre l’agent et des ressources web. Il peut exécuter des requêtes vers une page, une API ou toute autre ressource disponible à une URL. Pour un développeur, cela peut servir à consulter une documentation, à récupérer le contenu d’une page de référence ou à demander un résumé d’informations accessibles en ligne.

L’intérêt de cette approche est de ne pas laisser l’agent naviguer librement sur le réseau sans cadre. Les requêtes passent par le serveur, qui joue le rôle d’intermédiaire dans un environnement contrôlé. Le client peut ainsi interroger des ressources externes sans avoir à gérer lui-même la mécanique des demandes réseau à chaque étape.

Cette capacité a deux limites. D’abord, certains sites bloquent les accès automatisés, ce qui peut empêcher Fetch de récupérer le contenu attendu. Ensuite, une page consultée sur le web reste une source externe : son contenu peut être incomplet, obsolète ou inadapté au projet. Un résumé produit par l’assistant doit donc être confronté à la ressource d’origine lorsque la décision technique est importante.

Memory, conserver du contexte d’un échange à l’autre

Le serveur MCP Memory répond à une frustration fréquente avec les assistants : la perte de contexte entre plusieurs demandes. Il stocke et gère des informations relatives aux échanges précédents afin de les retrouver plus tard. Une préférence de l’utilisateur, une règle de nommage, une décision technique ou une note sur l’architecture peuvent ainsi être conservées.

Les commandes add, search et delete correspondent à cette logique simple. La première ajoute une information, la deuxième permet de la retrouver et la troisième la supprime lorsqu’elle n’est plus pertinente. Pour un projet suivi dans la durée, cette mémoire peut éviter de répéter les mêmes consignes à chaque interaction et rendre les réponses plus cohérentes avec les choix déjà établis.

Cette persistance demande toutefois un minimum d’hygiène. Une mémoire encombrée de notes anciennes ou contradictoires risque d’apporter plus de confusion que d’aide. Le stockage peut aussi provoquer des ralentissements lorsqu’il est saturé. Il est donc utile de supprimer régulièrement les éléments devenus inutiles et de ne pas enregistrer de secrets, mots de passe, tokens ou informations personnelles qui n’ont rien à y faire.

Configurer les serveurs sans élargir inutilement les permissions

Le principe de configuration est commun aux cinq serveurs : il faut déclarer les instructions nécessaires dans le fichier de paramètres du client. Dans le cadre présenté ici, ces éléments sont ajoutés à settings.json. Pour Gemini CLI, la commande /MCP permet ensuite de vérifier l’installation et de s’assurer que le serveur est reconnu.

Les détails de déclaration varient selon le serveur, car chacun a besoin de paramètres différents. Filesystem doit connaître les répertoires autorisés. GitHub nécessite son token. Fetch a besoin d’être activé pour les requêtes web. Memory doit disposer de son espace de stockage. Sequential Thinking doit être déclaré pour que l’assistant puisse appeler son outil de décomposition.

Avant d’intégrer un serveur à un projet de travail, quelques réflexes réduisent nettement les risques :

• n’autoriser que les dossiers, dépôts et ressources réellement nécessaires ;
• vérifier les actions proposées avant de les appliquer au code ou aux fichiers ;
• conserver les tokens en dehors des fichiers partagés ou versionnés ;
• tester d’abord le serveur sur un projet non sensible ;
• supprimer les connexions et les données de mémoire qui ne sont plus utiles.

Ces précautions ne ralentissent pas forcément le développement. Elles évitent surtout qu’un outil très pratique devienne une source de modifications difficiles à retracer ou d’exposition inutile de données.

Ce qu’il faut surveiller dans l’usage des serveurs MCP

La force de MCP est de rendre les assistants de code plus opérationnels dans leur environnement réel. Mais cette force correspond aussi à une surface d’action plus grande. Un assistant qui peut lire un dépôt, écrire dans un dossier, consulter le web et retenir du contexte doit être encadré avec davantage de soin qu’un simple outil conversationnel.

Le bon choix n’est donc pas nécessairement d’installer les cinq serveurs d’emblée. Un développeur travaillant seul sur un projet local pourra commencer par Filesystem et Sequential Thinking. Une équipe qui centralise son travail sur GitHub ajoutera le connecteur correspondant, avec un token limité. Fetch sera pertinent pour des besoins documentaires précis, tandis que Memory apportera surtout de la valeur aux projets longs ou aux consignes récurrentes.

À terme, l’enjeu sera moins de multiplier les connexions que de savoir lesquelles sont réellement utiles, à quelles données elles accèdent et comment leurs actions sont contrôlées. Pour Claude Code comme pour Gemini CLI, les serveurs MCP deviennent intéressants lorsqu’ils réduisent les tâches répétitives sans faire perdre au développeur la visibilité sur son code, ses données et ses décisions.