Le MCP (Model Context Protocol) permet à Claude Code de se brancher sur des outils et données externes : GitHub, votre base de données, un navigateur. Comment ajouter et configurer un serveur, lesquels valent le coup pour un MVP, et créer le vôtre.
Claude Code MCP : un hub reliant Claude à des outils externes

Le MCP (Model Context Protocol) est un standard open source qui permet à Claude Code de se brancher sur des outils et des données externes : votre GitHub, votre base de données, un navigateur, votre Sentry. Sans MCP, Claude ne connaît que votre code. Avec un serveur MCP connecté, il lit vos issues, interroge votre base, agit sur ces systèmes directement, au lieu de travailler sur ce que vous recollez à la main dans le chat. Concrètement, on ajoute un serveur avec la commande claude mcp add, et Claude Code peut se connecter à des centaines d'outils recensés dans l'annuaire officiel. Voici ce qu'est le MCP, comment ajouter et configurer un serveur, lesquels valent le coup quand on build un MVP en solo, comment créer le vôtre, et le piège dans lequel presque tout le monde tombe.

Le MCP (Model Context Protocol), c'est quoi ?

Le MCP est une prise standard entre Claude et le reste de votre stack. Le Model Context Protocol est un standard ouvert pour les intégrations entre une IA et des outils : n'importe quel service qui expose un serveur MCP peut être branché sur Claude Code, et Claude gagne alors accès à ses fonctions.

L'analogie qui marche : le MCP est à l'IA ce que l'USB est au matériel. Avant l'USB, chaque périphérique avait son connecteur propriétaire. Depuis, une seule prise pour tout. Le MCP joue ce rôle : un format unique pour connecter Claude à GitHub, à une base PostgreSQL, à un navigateur, à votre outil de monitoring, sans réinventer l'intégration à chaque fois.

Le signal pour brancher un serveur est simple : dès que vous vous surprenez à copier des données depuis un autre outil vers le chat (une issue, un log, une ligne de base), c'est qu'un MCP ferait le travail à votre place. Une fois connecté, Claude lit et agit sur ce système en direct. Vous passez de « je copie-colle le ticket JIRA » à « implémente la feature décrite dans le ticket ENG-4521 et ouvre une PR sur GitHub ». La différence n'est pas cosmétique : Claude travaille sur la donnée réelle, à jour, pas sur votre résumé approximatif.

Ce que ça débloque concrètement, une fois un ou deux serveurs branchés : implémenter une feature décrite dans un ticket puis ouvrir la PR, analyser vos données de monitoring, interroger votre base pour sortir une liste d'utilisateurs, intégrer les derniers designs Figma, automatiser l'envoi de brouillons d'emails. Autant de tâches où Claude cessait avant de vous être utile parce qu'il n'avait pas accès à la donnée. Le MCP lui donne cet accès.

Un mot qui compte pour un founder : le MCP ne remplace pas un skill. Un skill dit à Claude comment faire quelque chose (une procédure). Un MCP lui donne accès à quelque chose (un outil, une donnée). Les deux se complètent, ils ne se concurrencent pas.

Comment ajouter et configurer un serveur MCP dans Claude Code

Ajouter un serveur MCP dans Claude Code tient en une commande : claude mcp add. Ce qui change, c'est le type de connexion. Il en existe trois qui comptent.

Serveur HTTP distant (recommandé). C'est le cas le plus courant pour un service cloud. Vous donnez un nom et une URL :

claude mcp add --transport http notion https://mcp.notion.com/mcp

Si le serveur demande une authentification, vous passez un token en header :

claude mcp add --transport http secure-api https://api.example.com/mcp \
  --header "Authorization: Bearer votre-token"

Serveur stdio local. Pour un outil qui tourne comme un process sur votre machine. Le double tiret -- sépare les options de Claude de la commande qui lance le serveur :

claude mcp add --env AIRTABLE_API_KEY=VOTRE_CLE --transport stdio airtable \
  -- npx -y airtable-mcp-server

Serveur SSE. L'ancien transport distant, désormais déprécié. Si un service vous le propose encore, préférez sa version HTTP quand elle existe.

Beaucoup de serveurs distants utilisent OAuth plutôt qu'un token en dur : à la première utilisation, Claude Code lance la connexion, mémorise le jeton et le rafraîchit tout seul. Si une session finit par le rejeter, le panneau /mcp vous propose de vous ré-authentifier. Vous n'avez donc pas à gérer les tokens à la main pour ces services.

Pour trouver des serveurs fiables, parcourez l'annuaire officiel des connecteurs sur claude.ai/directory : ce sont des serveurs relus, que vous ajoutez avec la même commande claude mcp add. Un avertissement de sécurité qui n'est pas optionnel : vérifiez que vous faites confiance à chaque serveur avant de le brancher. Un serveur qui va chercher du contenu externe peut vous exposer à de l'injection de prompt. On ne connecte pas un MCP inconnu par curiosité.

Ajouter et configurer un serveur MCP dans Claude Code, étape par étape

Scope projet vs global : où configurer quoi

C'est la question qui perd tout le monde. Quand vous ajoutez un serveur, vous choisissez un scope, et ce scope décide qui voit le serveur et où sa config est stockée. Trois options.

Scope Charge dans Partagé avec l'équipe Stocké dans
local (défaut) Ce projet seulement Non, privé ~/.claude.json
project Ce projet seulement Oui, via git .mcp.json à la racine
user Tous vos projets Non, privé ~/.claude.json

Les 3 scopes MCP : local, project, user. Où charge le serveur, s'il est partagé, où il est stocké

La logique founder :

  • local : votre défaut. Un serveur perso, expérimental, ou avec des credentials que vous ne voulez surtout pas commiter. Il ne suit que vous, sur ce projet.
  • project : quand toute l'équipe doit avoir les mêmes outils. Le serveur est écrit dans un .mcp.json à la racine, que vous commitez. Chacun récupère la config en clonant. Claude Code demande une approbation avant d'utiliser un serveur project, par sécurité.
  • user : un serveur que vous voulez partout, sur tous vos projets (votre base de connaissances, votre outil de recherche). Privé, mais global à votre machine.

Vous fixez le scope avec --scope (ou -s) :

claude mcp add --transport http paypal --scope project https://mcp.paypal.com/mcp

Vérifier qu'un serveur MCP tourne

Un serveur ajouté n'est utile que s'il est bien connecté. Trois commandes pour le savoir :

claude mcp list          # liste tous les serveurs configurés
claude mcp get github    # détail d'un serveur précis
claude mcp remove github # retirer un serveur

Et à l'intérieur de Claude Code, tapez /mcp : le panneau affiche chaque serveur connecté avec son nombre d'outils. Si un serveur project attend votre validation, il apparaît en ⏸ Pending approval dans claude mcp list : lancez claude en interactif pour l'approuver. Un réflexe simple avant de croire que « ça marche » : ouvrez /mcp et vérifiez que le serveur est vert et expose bien des outils.

Bon à savoir sur la robustesse : si un serveur distant (HTTP) se déconnecte en pleine session, Claude Code tente de se reconnecter tout seul, plusieurs fois, avec un délai qui augmente à chaque essai. Le serveur apparaît en attente dans /mcp pendant ce temps. Les serveurs locaux (stdio), eux, ne sont pas relancés automatiquement : si l'un d'eux tombe, c'est à vous de le rouvrir. Ça vous évite de croire à un bug alors que la connexion est simplement en train de se rétablir.

Vérifier qu'un serveur MCP tourne avec claude mcp list

Les serveurs MCP essentiels pour un founder qui build son MVP

On peut brancher des centaines de serveurs. Mais quand on build seul un MVP, la bonne stratégie n'est pas d'en connecter le plus possible, c'est d'en connecter quatre ou cinq qui suppriment vos allers-retours quotidiens. Voici ceux qui changent la vie d'un founder-dev.

GitHub, Playwright, Supabase, base de données

GitHub. Le plus rentable. Claude lit vos issues, ouvre des PR, travaille sur vos repos sans que vous quittiez le terminal. Le serveur GitHub s'authentifie avec un personal access token que vous générez dans vos réglages GitHub, en le restreignant aux dépôts concernés, puis que vous passez en header. Résultat : « implémente l'issue #42 et ouvre une PR » devient une phrase, pas une matinée.

Votre base de données. Un serveur MCP branché sur votre PostgreSQL (ou sur Supabase, qui en propose un) laisse Claude interroger vos vraies données. « Trouve les 10 derniers users qui ont activé cette feature » devient une requête que Claude écrit et exécute, au lieu de vous faire ouvrir un client SQL. Pour un founder qui doit comprendre ses usages sans être data analyst, c'est un raccourci énorme.

Playwright. Un serveur qui donne à Claude le contrôle d'un vrai navigateur. Il peut tester un parcours utilisateur, remplir un formulaire, vérifier qu'une page s'affiche. Quand vous n'avez pas d'équipe QA, laisser Claude cliquer dans votre app pour confirmer qu'un flow marche vaut de l'or.

Le monitoring. Un serveur comme Sentry laisse Claude lire vos erreurs de production directement. « Regarde les erreurs Sentry de la semaine et dis-moi laquelle touche le plus d'utilisateurs » : vous passez du triage manuel à un diagnostic en une phrase.

Vos docs et votre comms. Un serveur Notion ou Slack laisse Claude lire vos specs et vos fils de discussion là où ils vivent. Un founder passe une part folle de sa journée à retranscrire un contexte qui existe déjà quelque part : ces serveurs suppriment cette retranscription. Claude va chercher l'info à la source.

La règle : chaque serveur que vous branchez doit tuer un aller-retour que vous faites déjà dix fois par jour. Si vous ne copiez jamais de données depuis un outil, il n'a pas besoin de son MCP. Quatre serveurs bien choisis (votre code, votre base, votre navigateur de test, votre monitoring) couvrent l'essentiel d'un MVP. Le reste s'ajoute le jour où un vrai besoin apparaît, pas avant.

Les serveurs MCP essentiels pour un founder qui build son MVP

Créer votre propre serveur MCP

Aucun serveur ne couvre votre outil interne maison ? Vous en écrivez un. Un serveur MCP est un programme qui expose des fonctions selon le protocole, et Claude s'y branche comme à n'importe quel autre.

Deux chemins. Le premier, à la main : la documentation du protocole sur modelcontextprotocol.io couvre les fondamentaux (comment déclarer vos outils, gérer l'authentification, tester). Le second, plus rapide et très founder-friendly : laissez Claude le scaffolder pour vous. Claude Code a un plugin officiel pour ça.

/plugin install mcp-server-dev@claude-plugins-official

Puis, dans la session :

/mcp-server-dev:build-mcp-server

Claude vous interroge sur votre cas d'usage et génère la structure d'un serveur, distant en HTTP ou local en stdio. Vous partez d'une base qui marche au lieu d'une page blanche. Pour un founder non spécialiste des protocoles, c'est la différence entre « je me lance » et « j'abandonne à la première page de doc ».

Un détail pratique si votre serveur local doit lire des fichiers de votre projet : Claude Code lui fournit le chemin racine du projet dans une variable d'environnement (CLAUDE_PROJECT_DIR), que votre code lit directement. Votre serveur résout donc ses chemins sans dépendre du répertoire courant, ce qui évite la classe de bugs la plus fréquente quand on écrit son premier serveur stdio. Commencez petit : un serveur qui expose une seule fonction utile bat un serveur ambitieux que vous ne finissez jamais.

Créer votre propre serveur MCP : la voie founder

Les pièges à éviter (trop de MCP tue le résultat)

Voici ce qu'on ne vous dit pas et qui fait la vraie différence entre un setup qui aide et un setup qui ralentit Claude. Le réflexe naturel, quand on découvre le MCP, c'est d'en brancher partout. C'est une erreur.

Chaque serveur que vous connectez ajoute ses outils à ce que Claude doit prendre en compte. Historiquement, plus vous ajoutiez de serveurs, plus vous gonfliez le contexte, et plus Claude devait trier parmi des dizaines d'outils dont la plupart ne servaient pas à la tâche du moment. Claude Code atténue ça aujourd'hui avec le tool search, actif par défaut sur les modèles récents : les définitions d'outils ne sont chargées qu'à la demande, donc ajouter un serveur pèse peu sur votre fenêtre de contexte. Mais atténuer n'est pas annuler. La limite pratique reste votre budget de contexte, et un point mesurable subsiste : la sortie d'un outil MCP déclenche un avertissement au-delà de 10 000 tokens et est plafonnée à 25 000 par défaut. Une requête qui ramène toute une table peut donc être tronquée.

La discipline à tenir, en trois points :

  1. Ne branchez que ce que vous utilisez vraiment. Un MCP connecté « au cas où » est du contexte que Claude traîne sans bénéfice.
  2. Scopez juste. Un serveur perso en local, un serveur d'équipe en project. Ne mettez pas en user un truc que vous n'utilisez que sur un projet.
  3. Méfiez-vous des requêtes trop larges. Demander à un MCP de base de données de tout ramener se heurte au plafond de sortie. Cadrez la requête.

Un bon setup MCP ressemble à un établi bien rangé, pas à un tiroir fourre-tout. Trois outils que vous saisissez sans réfléchir battent quinze que vous cherchez.

Les pièges à éviter avec le MCP : trop de serveurs tue le résultat

MCP : ce qu'un founder doit retenir

Pour aller plus loin

FAQ

Qu'est-ce que le MCP dans Claude Code ?

Le MCP (Model Context Protocol) est un standard open source qui connecte Claude Code à des outils et données externes : GitHub, une base de données, un navigateur, un outil de monitoring. Une fois un serveur MCP branché, Claude lit et agit sur ces systèmes directement, au lieu de travailler sur ce que vous copiez dans le chat. On ajoute un serveur avec la commande claude mcp add.

Comment ajouter un serveur MCP dans Claude Code ?

Utilisez claude mcp add. Pour un serveur distant : claude mcp add --transport http <nom> <url>. Pour un serveur local : claude mcp add <nom> -- <commande>. Vous pouvez passer un token d'authentification avec --header, et choisir la portée avec --scope (local, project ou user). Parcourez les connecteurs relus sur claude.ai/directory.

Où est stockée la configuration d'un serveur MCP ?

Ça dépend du scope. Un serveur local (le défaut) et un serveur user sont stockés dans ~/.claude.json et restent privés. Un serveur project est écrit dans un fichier .mcp.json à la racine du projet, conçu pour être commité et partagé avec l'équipe via git. Vérifiez toujours l'état d'un serveur avec claude mcp list ou le panneau /mcp.

Quels sont les meilleurs serveurs MCP pour un founder ?

Les plus rentables quand on build un MVP : GitHub (issues, PR, repos), un serveur pour votre base de données (interroger vos vraies données), Playwright (piloter un navigateur pour tester), et un outil de monitoring comme Sentry (lire vos erreurs de prod). La règle : ne branchez que les serveurs qui suppriment un aller-retour que vous faites déjà tous les jours.

Est-ce risqué de connecter trop de serveurs MCP ?

Oui, dans une certaine mesure. Chaque serveur ajoute des outils que Claude doit prendre en compte, et même si le tool search limite l'impact sur le contexte, la sortie d'un outil MCP est plafonnée à 25 000 tokens par défaut. Un serveur inconnu peut aussi vous exposer à de l'injection de prompt. Ne connectez que ce que vous utilisez, et ne faites confiance qu'à des serveurs vérifiés.