MCP : connecter Claude à tes outils

C'est quoi MCP

Avant l'USB, chaque imprimante avait son câble et chaque appareil photo son adaptateur. Les LLM en étaient là avant MCP : chaque app qui voulait brancher un modèle sur un service écrivait son propre connecteur maison. MCP joue le rôle du port USB avec un format commun. Claude parle MCP, le service parle MCP, ça discute.

Un serveur MCP expose deux choses :

• Des outils (tools) : des fonctions que Claude peut appeler. create_issue, execute_sql, get_deployment.
• Des ressources (resources) : de la data que Claude peut lire. Une page Notion, un fichier, un schéma de DB. Tu les cites avec @, comme un fichier : tape @ dans ton prompt et elles apparaissent dans l'autocomplétion.

Claude Code consomme, le serveur MCP fournit. Le serveur peut tourner en local sur ta machine (stdio) ou à distance (HTTP).

Ce que MCP change au quotidien

Avant MCP, ta vie ressemblait à ça : tu demandes à Claude un changement dans ta DB, tu copies le schéma depuis Supabase, tu colles, il te sort du SQL, tu copies le SQL, tu le colles dans l'éditeur Supabase, tu exécutes, tu reviens dans Claude, tu lui dis "ça a planté, voilà l'erreur". Quinze allers-retours pour un truc simple.

Avec MCP, Claude fait les allers-retours tout seul. Il lit ton schéma, écrit la migration, l'applique, relit les logs et corrige pendant que tu regardes.

Le gros du gain est dans l'action. Dans la même session, sans quitter le terminal, Claude peut créer une issue GitHub avec labels et assignés, puis interroger ta base Supabase et générer les types TypeScript qui vont avec. Il met à jour une page Notion, déploie sur Vercel en surveillant les logs de build, ou part d'une erreur Sentry pour proposer un fix.

Les serveurs officiels

Voici les MCP officiels les plus utiles pour un solobuilder qui bosse sur du SaaS :

La liste bouge vite. Référence à jour sur code.claude.com/docs/en/mcp.

Setup pas-à-pas, 3 MCP essentiels pour un solobuilder

Trois façons d'ajouter un MCP à Claude Code, de la plus simple à la plus manuelle :

1. Un connecteur claude.ai. Tu le connectes une fois dans les réglages de claude.ai (section Connecteurs), et il apparaît tout seul dans /mcp côté Claude Code, sur toutes tes machines. C'est ce que j'utilise pour Notion, Supabase et Vercel.
2. claude mcp add pour un serveur distant ou local :

# serveur distant (HTTP), exemple tiré de l'aide de la CLI
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

# serveur local (stdio) avec une variable d'environnement
claude mcp add mon-serveur -e API_KEY=xxx -- npx mon-serveur-mcp

Par défaut le serveur est ajouté pour le projet courant (scope local). --scope user le rend dispo partout, --scope project l'écrit dans un .mcp.json versionné que ton équipe partage.

1. Un plugin qui embarque son serveur MCP (chapitre 16).

Pour les serveurs qui demandent un login (OAuth), tu t'authentifies avec claude mcp login <nom> dans le terminal ou depuis /mcp dans la session : le navigateur s'ouvre, tu autorises, c'est branché. En SSH, sans navigateur, claude mcp login <nom> --no-browser affiche l'URL à ouvrir sur ta machine.

Notion

Chez la plupart des solobuilders, c'est là que se fait le plus de copier-coller : specs, todos, notes client, roadmap. Si tu ne branches qu'un MCP, commence par celui-là.

Connexion : le connecteur Notion de claude.ai, puis vérifie qu'il apparaît dans /mcp. L'OAuth Notion te demande quelles pages et databases rendre accessibles. Donne accès aux workspaces sur lesquels tu bosses, évite "all pages" par défaut.

Scopes utiles :

• Pages (lecture + écriture)
• Databases (query + update)
• Comments (si tu utilises les reviews Notion)

Commandes côté Claude : notion-search, notion-fetch, notion-create-pages, notion-update-page, notion-create-database.

Exemple de prompt :

Va chercher dans mon Notion la page "Roadmap Q2" et génère
une issue GitHub pour chaque item en statut "Todo",
avec le contexte de la page en description.

Claude lit la page Notion, repère les items en "Todo" et crée les issues côté GitHub.

Vercel

Utile dès que tu déploies. Tu n'as plus à copier les logs de build dans Claude quand un deploy échoue, il va les chercher tout seul.

Connexion : connecteur Vercel de claude.ai, ou le plugin Vercel du marketplace officiel. OAuth Vercel, choisis le team auquel tu donnes accès.

Outils utiles (les noms bougent d'une version à l'autre, /mcp affiche la liste à jour) :

• list_projects : liste tes projets
• list_deployments : historique des deploys d'un projet
• get_deployment : détails d'un deploy précis (URL, status, commit)
• get_runtime_logs : les logs runtime (erreurs en prod)
• create_deployment : déclencher un deploy

Exemple de prompt :

Mon dernier deploy sur le projet "carbonara" a échoué.
Récupère les logs de build, trouve l'erreur, propose un fix.

Claude récupère les logs, identifie le module manquant ou l'erreur TypeScript, edit le fichier, tu review, tu commit. Trois minutes au lieu de quinze.

Supabase

Celui qui fait le plus de choses. Claude peut lire ton schéma, écrire du SQL, appliquer des migrations, générer les types TypeScript, lire les logs.

Connexion : connecteur Supabase de claude.ai (OAuth). Tu choisis quelle organisation connecter. Chaque action mentionne le project_ref pour que Claude sache sur quel projet taper.

Outils utiles :

• list_projects + get_project : identifier le bon project_ref
• list_tables : voir le schéma actuel
• execute_sql : query directe (lecture + écriture)
• apply_migration : appliquer une migration nommée
• generate_typescript_types : générer le fichier database.types.ts
• query_logs : logs Postgres, API, auth, edge functions
• get_advisors : warnings de sécurité et de performance

Exemple de prompt :

Ajoute une table "invoices" avec les colonnes classiques
(id, user_id, amount, status, created_at), mets une RLS
policy "user can read own invoices", applique la migration
sur le projet carbonara-prod, puis régénère les types.

Claude écrit la migration, l'applique via apply_migration, appelle generate_typescript_types, met à jour le fichier local.

MCP custom, l'exemple Nano Banana

Les serveurs officiels couvrent 80% des besoins. Pour les 20% restants, tu peux héberger ton propre MCP. On le fait au chapitre 15 avec Nano Banana, un serveur MCP maison qui branche l'API Gemini Image sur Claude Code pour générer des visuels directement depuis le terminal.

Le principe est toujours le même :

1. Tu écris un petit serveur (Node ou Python) qui expose des tools
2. Tu le déclares avec claude mcp add (une commande locale pour un serveur stdio, une URL pour un serveur HTTP)
3. Claude Code le détecte au démarrage et les tools deviennent appelables

Cas typiques où créer ton propre MCP a du sens :

• API interne de ton SaaS (pour que Claude puisse tester des endpoints en dev)
• Workflows custom sur une API qui a déjà un MCP mais pas l'action dont tu as besoin
• Tool spécifique à ton métier (générateur de factures, export compta, scraper)

Avec un remote MCP (anthropic.com/news/claude-code-remote-mcp), tu héberges ton serveur sur Vercel, Fly ou Cloudflare et tu le partages entre plusieurs machines sans rebuild local à chaque update.

Gérer tes serveurs au quotidien

Les connecteurs claude.ai apparaissent dans /mcp à côté de tes serveurs locaux. Tu y trouves aussi ceux d'Anthropic, dont Claude Docs, qui permet à Claude Code de créer et modifier des documents partagés (chapitre 15).

Sécurité

Trois règles à tenir :

1. OAuth et scopes minimaux. Quand tu connectes un MCP, l'OAuth te demande quels scopes autoriser. Choisis le minimum. Pour Notion, donne accès aux workspaces concernés, pas à "all pages". Côté GitHub, un token limité aux repos concernés si tu peux. Pour Supabase, ne connecte jamais ton projet prod sans garde-fou.
2. /permissions pour auditer. Les outils MCP y apparaissent sous la forme mcp__<serveur>__<outil>. Regarde ce qui est autorisé après chaque install.
3. Bloque l'écriture en prod par une règle. Les nouvelles sessions démarrent en auto mode (le mode par défaut, voir chapitre 9) : un classifieur approuve ce qui lui semble sûr et bloque le destructif et la prod. Le classifieur peut rater un cas. Pour les outils qui écrivent en prod, ajoute une règle deny explicite :

{
  "permissions": {
    "deny": [
      "mcp__claude_ai_Supabase__execute_sql",
      "mcp__claude_ai_Supabase__apply_migration"
    ]
  }
}

Le nom suit la forme mcp__<serveur>__<outil>. Un connecteur claude.ai prend le préfixe claude_ai_ suivi de son nom (ici claude_ai_Supabase). Un serveur ajouté avec claude mcp add supabase ... donnerait mcp__supabase__execute_sql. Vérifie le nom exact dans /mcp avant d'écrire la règle. Les règles deny bloquent dans tous les modes, bypassPermissions compris.

Si tu bosses avec des données sensibles (clients, paiements), sépare tes MCP : un profil "dev" avec les MCP qui tapent en staging, un profil "read-only" avec uniquement les MCP de lecture pour les sessions d'exploration.

MCP ou CLI ?

Quand un service a une bonne CLI, elle fait souvent mieux qu'un MCP. gh pour GitHub, vercel pour Vercel, supabase pour Supabase : Claude les connaît déjà, elles ne demandent aucune définition d'outil dans le contexte, et tu peux filtrer leur sortie (| grep, | jq, | tail) avant qu'elle n'arrive dans la conversation. La doc coûts de Claude Code le recommande explicitement.

Garde le MCP quand il n'existe pas de CLI, quand il faut une authentification OAuth que la CLI ne gère pas, ou quand le service expose des actions que la CLI n'a pas (les outils Notion, par exemple).

Ce que tes MCP coûtent en contexte

Le conseil qui a longtemps circulé : « débranche les MCP que tu n'utilises pas, ils bouffent ton contexte ». Il était juste jusqu'à l'arrivée du tool search.

Mesuré sur une installation réelle avec neuf serveurs branchés :

MCP tools    376 tools · 0 tokens

Ce qu'ils pèseraient s'ils étaient tous chargés :
  Canva  edit-design               8.7k
  Notion query-meeting-notes       6.8k
  Qonto  create_client             6.7k
  … 373 autres
  Total théorique                 244.1k

376 outils annoncés, zéro token consommé. Chargés d'un bloc, ils occuperaient presque un quart d'une fenêtre de 1M.

C'est le comportement par défaut de Claude Code, tu n'as rien à activer. Tous les modèles actuels le gèrent. Les exceptions : un proxy branché via ANTHROPIC_BASE_URL, les anciens modèles sur Google Cloud et les déploiements Microsoft Foundry hébergés sur Azure, où les outils sont chargés d'emblée. Autre effet utile : avec le tool search, connecter ou retirer un MCP en pleine session ne casse plus le cache de prompt.

Trois réglages à connaître. alwaysLoad se met dans la config du serveur (par exemple dans .mcp.json), les deux autres sont des variables d'environnement :

• alwaysLoad: true sur un serveur charge ses outils d'emblée. À réserver à un serveur que tu appelles à chaque session, sinon tu repaies son poids pour rien.
• ENABLE_TOOL_SEARCH (true, auto, auto:N ou false) pilote le tool search globalement. auto ne diffère les outils qu'au-delà de 10 % de la fenêtre de contexte. Laisse le défaut sauf raison précise.
• MAX_MCP_OUTPUT_TOKENS plafonne la réponse d'un outil MCP, 25 000 tokens par défaut (avec un avertissement dès 10 000). Une requête SQL qui renvoie 10 000 lignes ou un export de logs peut taper ce plafond : demande à Claude de filtrer côté serveur plutôt que de monter la limite.

{
  "mcpServers": {
    "mon-serveur": {
      "type": "http",
      "url": "https://mon-serveur.exemple.com/mcp",
      "alwaysLoad": true
    }
  }
}

Ce qui pèse aujourd'hui, ce sont les réponses des outils : chaque résultat entre dans le contexte et repart avec chaque message suivant. Trie donc tes MCP sur la sécurité, les scopes et le volume de ce qu'ils renvoient.

Sources

• MCP dans Claude Code (doc officielle)
• Claude Code, gérer les coûts
• Claude Code, prompt caching
• Routines dans Claude Code