Dans un article publié le 11 octobre 2026, The New Stack rapporte que son auteur, ingénieur chez Bit Cloud, a utilisé MCP pour aider une session Claude Code sans code local ni historique de conversation à retrouver les dépendances d’un projet. Deux appels, read_scope puis read_components, ont révélé quatre éléments : une application React, un service Express adossé à MongoDB, une entité ticket partagée et une passerelle.
Ce que la session a retrouvé
L’application et le service dépendaient de la même version de l’entité ticket. Les quatre éléments s’appuyaient sur 16 composants préexistants, dont dix issus de Bit Design Sparks. Ces enregistrements, associés aux versions des composants, ont fourni à la session une carte des dépendances sans conversation préalable ni fichiers de code locaux.
Les notes de mémoire répondent à une autre question : elles peuvent conserver des décisions et des intentions de projet, comme la raison pour laquelle une fonctionnalité a été écartée. Dans le récit de The New Stack, ces notes portent un horodatage, mais ne sont pas rattachées à une version du code. Pour approfondir la mémoire de Claude Code entre projets, retrouvez notre article consacré à cette fonction.
Ce que le test a vérifié
Claude a importé les quatre composants, inspecté leur code et ajouté dans l’application un filtrage côté client par statut et par personne assignée, sans modifier l’entité ticket ni le service. Le résultat rapporté comprenait 41 tests réussis, dont neuf nouveaux tests de filtrage. Les tests d’intégration MongoDB pouvaient toutefois être ignorés si le serveur d’intégration continue ne parvenait pas à démarrer la base temporaire.
La documentation d’API de l’application répertoriait GET /tickets, POST /tickets, PATCH /tickets/:id et POST /tickets/:id/comments pour un faux service utilisé dans les tests. L’auteur précise ne pas avoir vérifié ces routes avec le service réel. La découverte des dépendances a donc guidé l’inspection du code et la modification de l’application ; la vérification des routes réelles et du comportement à l’exécution n’a pas fait partie de ce test.
L’auteur décrit également une vérification manuelle de la persistance : créer un ticket, ajouter un commentaire, redémarrer la plateforme sur la même base, puis constater que les deux étaient toujours présents. La démonstration utilisait un compte prédéfini et un secret de signature public. La gestion de la concurrence, les migrations, les procédures de récupération et l’exécution obligatoire des tests de base de données restaient à réaliser.
Choisir la portée de configuration MCP
MCP, le Model Context Protocol, relie Claude Code à des services et outils externes. Anthropic distingue cette connexion des Skills, qui fournissent des connaissances ou des processus réutilisables. La documentation d’Anthropic définit trois portées de configuration pour adapter l’installation à l’usage :
| Portée | Où s’applique-t-elle ? | Qui peut utiliser la configuration ? |
local | Au projet courant sur la machine du développeur | Le développeur pour ce projet |
project | Dans le fichier .mcp.json à la racine du projet | L’équipe du projet |
user | Aux projets du développeur | Le développeur dans ses projets |
La portée local est celle utilisée par défaut. Pour partager une configuration MCP avec une équipe, c’est project qui convient : le fichier .mcp.json se trouve à la racine du projet. La portée user, elle, permet au développeur de retrouver sa configuration dans ses différents projets.
Ce que Claude Code charge dans le contexte
Claude Code charge les noms des outils MCP au démarrage de la session et diffère le chargement de leurs schémas complets jusqu’au moment où ils sont nécessaires. Anthropic qualifie de faible le coût de contexte des outils MCP inactifs, sans assimiler ce chargement à un coût nul. La présentation des fonctionnalités de Claude Code précise ce fonctionnement.
