MCP, brancher Claude à ton SaaS

C'est quoi MCP

MCP, Model Context Protocol, c'est le standard ouvert créé par Anthropic pour brancher Claude à des services externes. Une façon unique de dire à Claude "voilà ma doc, voilà ma DB, voilà mon GitHub, sers-toi".

L'analogie qui marche : MCP c'est le port USB du code. Avant USB, chaque imprimante avait son câble, chaque appareil photo son adaptateur. Pareil pour les LLM il y a deux ans : chaque app qui voulait brancher un modèle sur un service écrivait son propre connecteur maison. MCP fixe un format commun. Claude parle MCP, le service parle MCP, ça discute.

Concrètement 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.

Claude Code consomme, le serveur MCP fournit. Le serveur peut tourner en local (stdio) ou à distance (HTTP, depuis la GA du remote MCP en octobre 2025).

Pourquoi c'est devenu essentiel

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, il écrit la migration, il l'applique, il lit les logs, il corrige. Tu regardes.

Le vrai changement n'est pas dans la lecture. C'est dans l'action. Claude peut désormais :

• Créer une issue GitHub avec labels et assignés
• Query ta DB Supabase et générer les types TypeScript qui vont avec
• Lire une page Notion et la mettre à jour
• Déployer sur Vercel et checker les logs de build
• Récupérer une erreur Sentry et proposer un fix

Tout ça dans la même session, sans jamais quitter le terminal.

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

La façon la plus simple d'ajouter un MCP à Claude Code, c'est via la commande /plugin ou le menu MCP settings (Cmd+, sur Mac). Pour les MCP officiels listés ci-dessus, tout passe en OAuth : un clic sur "Connect", navigateur qui s'ouvre, tu autorises, c'est branché.

Notion

Ton terrain de copier-coller numéro un. Specs, todos, notes client, roadmap. Brancher Notion c'est virer 80% des allers-retours manuels.

Connexion : /plugin puis chercher "notion", ou directement dans MCP settings. OAuth Notion te demande quelles pages/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 Notion, comprend la structure, crée les issues côté GitHub. Une seule instruction, deux MCP qui discutent.

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 : /plugin ou MCP settings, OAuth Vercel. Choisis le team dont tu veux donner accès.

Commandes utiles :

• 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_deployment_build_logs : les logs complets du build
• get_runtime_logs : les logs runtime (erreurs en prod)
• deploy_to_vercel : 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

Le plus puissant des trois. Claude peut lire ton schéma, écrire du SQL, appliquer des migrations, générer les types TypeScript, lire les logs.

Connexion : OAuth Supabase via /plugin. Tu choisis quelle organisation connecter. Chaque action mentionne le project_ref pour que Claude sache sur quel projet taper.

Commandes 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
• get_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. Zéro copier-coller.

MCP custom, l'exemple Nano Banana

Les serveurs officiels couvrent 80% des besoins. Pour les 20% restants, tu peux héberger ton propre MCP. C'est exactement ce qu'on fait dans le 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 dans ta config MCP (~/.claude/mcp_servers.json pour stdio local, ou une URL HTTP pour un remote MCP)
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)

Depuis la GA du remote MCP (anthropic.com/news/claude-code-remote-mcp), tu peux héberger ton serveur sur Vercel/Fly/Cloudflare et le partager entre plusieurs machines sans avoir à rebuild localement à chaque update.

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 nécessaire. Pour Notion, donne accès aux workspaces concernés, pas à "all pages". Pour GitHub, crée un token avec accès aux repos spécifiques si tu peux. Pour Supabase, sépare bien read et write et ne connecte jamais ton projet prod en auto-approve.
2. /permissions pour auditer. La commande /permissions dans Claude Code te montre ce que chaque MCP peut faire. Regarde-la après chaque install. Si un MCP demande plus que nécessaire, révoque et reconfigure.
3. Approbation manuelle sur l'écriture. Par défaut, Claude Code demande confirmation avant toute action qui modifie ou supprime. Ne passe pas en mode auto-approve sur les MCP qui touchent à de la data prod (Supabase, GitHub writes, Linear delete). Garde le prompt de confirmation.

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.