FR
Leçon 2.4

MCP expliqué : connecter votre agent à tout

Comprendre le Model Context Protocol, brancher des serveurs MCP sur votre agent et juger quand MCP bat un simple outil CLI

23 minClaude Code Mastery - Devenir power userDisponible

Ce que tu apprends

  • Ce qu'est MCP et le problème qu'il résout : un connecteur standard pour les capacités d'agent
  • Comment ajouter un serveur MCP avec un vrai .mcp.json et ce qu'il débloque
  • La question de jugement centrale : quand MCP bat un simple outil CLI et quand non

Vue d'ensemble

MCP est un connecteur universel pour les agents. Au lieu que chaque outil invente sa propre intégration sur mesure, un serveur MCP expose ses capacités d'une façon standard que tout agent compatible peut utiliser. Branchez-en un, et votre agent peut soudain interroger une base de données, lire un fichier de design, piloter un navigateur ou fouiller vos docs - et utilise ces actions comme n'importe quel autre outil. Le protocole est la raison de l'explosion des capacités d'agent : bâtir un serveur une fois, et tout agent compatible MCP peut l'utiliser.

Ce que vous allez apprendre

Vous allez apprendre ce qu'est MCP et pourquoi un protocole partagé compte, la différence entre un serveur et un client, comment ajouter un serveur à Claude Code avec une vraie configuration .mcp.json, et le jugement le plus important et le plus négligé de tout ce domaine : quand un serveur MCP est vraiment le bon outil versus quand un simple outil en ligne de commande décrit dans votre CLAUDE.md fait le travail avec moins d'overhead.

Prérequis

Un setup d'agent fonctionnel et les leçons sur le contexte du Cours 1, car chaque serveur connecté consomme du contexte - ses définitions d'outils occupent la fenêtre - et le performance cliff s'applique toujours. Les leçons sur CLAUDE.md et les hooks aident aussi, car la décision CLI versus MCP se ramène souvent à une règle ou un script que vous savez déjà écrire.

Le problème

Votre agent est brillant à l'intérieur de vos fichiers et aveugle partout ailleurs. Il ne peut pas voir votre base de données de production, vos fichiers de design, l'état en direct d'une page web ou le contenu d'un service externe. Alors vous devenez le presse-papiers humain : vous copiez des données depuis un outil, les collez dans l'agent, recopiez la sortie de l'agent. Cette navette manuelle est lente, sujette aux erreurs et plafonne la quantité de vrai travail que vous pouvez déléguer. Avant MCP, le seul moyen de corriger cela était une intégration sur mesure par outil, que presque personne n'a bâtie.

Le problème que MCP résout

MCP définit un connecteur standard. Un serveur parle MCP pour exposer une capacité - une base de données, un stockage de fichiers, un navigateur, une API. Un client (votre agent harness) parle MCP pour utiliser n'importe quel serveur. Comme le protocole est partagé, l'intégration s'écrit une fois par outil et fonctionne sur tout agent qui supporte MCP, tout comme l'USB signifiait que vous n'aviez plus besoin d'un câble différent par appareil. Cette seule décision explique pourquoi le support s'est répandu si vite et pourquoi il existe désormais un serveur MCP pour presque tout ce que vous voudriez connecter.

  • Serveur : expose une capacité via MCP (une base de données, un outil de design, un navigateur, un index de recherche).
  • Client : votre agent harness, qui peut utiliser tout serveur MCP que vous branchez.
  • Connecteur standard : une intégration par outil fonctionne sur tout agent compatible MCP, au lieu de N intégrations sur mesure.
  • Un serveur peut offrir des tools (actions que l'agent exécute) et des resources (données que l'agent lit).

Ajouter un serveur

Dans Claude Code, vous enregistrez les serveurs MCP dans un fichier .mcp.json à la racine de votre projet (committé, pour que l'équipe partage les mêmes connexions) ou dans votre configuration utilisateur pour les personnels. Chaque entrée nomme un serveur et comment le démarrer. Voici un vrai .mcp.json qui branche deux serveurs courants : un serveur filesystem restreint à un dossier, et un serveur Playwright qui laisse l'agent piloter un vrai navigateur. Branchez-les une fois, et ces actions deviennent disponibles pour l'agent comme n'importe quel autre outil.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "./data"]
    },
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest"]
    }
  }
}
.mcp.json - brancher un serveur filesystem et un serveur navigateur

Les serveurs qui ont besoin de credentials (une base de données, une API hébergée) les prennent via des variables d'environnement plutôt que des clés en dur, donc la même discipline .env du Cours 1 s'applique : les secrets restent hors de la configuration committée. Après avoir ajouté un serveur, votre agent peut lister et appeler ses outils directement. Consultez les docs propres à chaque serveur pour sa commande de démarrage exacte et les variables d'environnement requises.

MCP versus un simple outil CLI

C'est le jugement qui sépare les gens qui comprennent les agents de ceux qui collectionnent les intégrations. Un serveur MCP n'est pas automatiquement meilleur qu'un outil en ligne de commande. Claude Code peut déjà exécuter tout CLI que vous avez installé, et une instruction d'une ligne dans votre CLAUDE.md - « utilise la CLI gh pour GitHub, la CLI stripe pour Stripe » - est souvent plus simple, plus léger et plus transparent qu'un serveur MCP dédié. Les outils CLI brillent quand une interface en ligne de commande mûre existe déjà, quand vous voulez voir exactement quelle commande a tourné, et quand vous voulez zéro overhead de contexte supplémentaire. MCP mérite sa place quand il n'y a pas de bon CLI, quand vous avez besoin de données structurées et de resources plutôt que de sortie texte, ou quand l'interaction est vraiment interactive, comme piloter un navigateur ou interroger une base de données en direct via une interface typée. Saisissez d'abord le CLI ; saisissez MCP quand le CLI ne peut vraiment pas bien faire le travail.

  • Préférez un CLI quand : un bon outil en ligne de commande existe déjà, vous voulez une transparence totale et un coût de contexte minimal.
  • Préférez MCP quand : il n'y a pas de CLI correct, vous avez besoin de tools et resources structurés, ou la tâche est interactive (navigateur, base de données en direct).
  • Chaque serveur connecté ajoute des définitions d'outils à votre context window, donc chacun a un coût réel et continu.
  • Connectez délibérément. Trois serveurs que vous utilisez battent quinze qui boursouflent votre contexte.

Erreurs fréquentes

Les erreurs courantes : brancher chaque serveur MCP que vous trouvez et noyer votre context window sous des définitions d'outils que vous n'utilisez jamais ; saisir un serveur MCP quand un outil CLI que vous avez déjà ferait le travail plus simplement ; mettre des credentials en dur dans .mcp.json au lieu d'utiliser des variables d'environnement ; et oublier qu'un serveur MCP est du code tiers avec accès à vos affaires, donc vous devriez examiner ce que vous branchez comme vous examineriez une dépendance. Connectez peu, connectez délibérément, connectez des choses en qui vous avez confiance.

ROI business

MCP est ce qui transforme un agent de code en un opérateur polyvalent pour votre business. Connectez les bons serveurs, et l'agent n'a plus besoin de vous comme presse-papiers : il peut lire votre base de données, inspecter une page en direct, tirer d'un service et réagir à de vraies données du début à la fin. C'est la différence entre un agent qui esquisse du code et un agent qui pilote un workflow. La discipline de connecter délibérément - et de choisir un CLI quand un CLI suffit - garde cette puissance bon marché et votre contexte tranchant, si bien que vous obtenez la portée sans payer la taxe du cliff.

Checklist

Vous êtes prêt à avancer quand chacun de ces points est vrai. La prochaine leçon passe d'un agent bien équipé à plusieurs.

  • Vous savez expliquer MCP comme un connecteur standard et nommer les rôles serveur et client.
  • Vous avez ajouté au moins un serveur MCP via .mcp.json à un vrai projet.
  • Vous savez nommer un cas clair où un outil CLI bat un serveur MCP, et inversement.
  • Vous comprenez que chaque serveur connecté coûte du contexte et de la surface d'attaque.

Ressources

Gardez en favoris la page officielle du Model Context Protocol et la documentation MCP de Claude Code pour le format de configuration à jour et le répertoire des serveurs disponibles. Les serveurs filesystem, Playwright et base de données sont de bonnes premières connexions. Associez MCP à une règle dans votre CLAUDE.md qui dit à l'agent quel CLI préférer pour quel job, pour qu'il ne saisisse un serveur que si le CLI ne peut vraiment pas aider.

Votre mission

Branchez un serveur MCP via .mcp.json sur un vrai projet - le serveur filesystem ou Playwright est un début léger. Faites ensuite délibérément l'inverse : choisissez une tâche pour laquelle vous auriez peut-être saisi un serveur, et ajoutez à la place une règle d'une ligne dans votre CLAUDE.md qui dit à l'agent d'utiliser un outil CLI existant. Remarquez lequel a semblé plus facile. Cet instinct est la vraie compétence ici.

Prochaine leçon

Un unique agent bien équipé est puissant, mais il ne peut tenir que tant de choses dans le contexte. La prochaine leçon passe à plusieurs agents : sub-agents, équipes d'agents, la motivation du context cliff derrière et comment empêcher une équipe de multiplier silencieusement vos coûts.

Commentaires

Chargement des commentaires.

Poster un commentaire
CommentairesSuivant
Étape suivante

Prêt à mettre l’IA au service d’un véritable workflow ?

Commencez par le cours de base, conservez vos progrès localement et synchronisez tout sur votre compte gratuit quand vous le souhaitez.