Claude Code sait lire ton code, lancer tes tests, écrire des migrations. Mais il y a une chose qu'il ne peut pas faire tout seul : toucher aux données de ton application. Tes clients, tes tâches, tes commandes vivent dans une base, derrière ton API, hors de sa portée.
Un serveur MCP change ça. Dans la vidéo, on en construit un de zéro, branché sur une app TODO, avec le même principe que celui utilisé sur un CRM en production qui expose plus de 50 outils MCP. À la fin, tu parles à Claude Code, et ton app exécute.
MCP (Model Context Protocol) est un protocole ouvert qui standardise la manière dont un assistant IA se connecte à des outils et à des sources de données. Plutôt que d'écrire une intégration spécifique pour chaque assistant, tu exposes une fois tes capacités sous forme d'outils, et n'importe quel client compatible peut les utiliser. Claude Code en fait partie.
Un outil MCP, c'est simplement :
- un nom (par exemple
create_todo) ;
- une description en langage naturel, que le modèle lit pour savoir quand l'utiliser ;
- un schéma d'entrée, qui décrit les paramètres attendus ;
- une fonction qui fait le travail et renvoie un résultat.
Le modèle ne voit jamais ta base de données. Il voit une liste d'outils, choisit lesquels appeler, avec quels paramètres, et lit les réponses. C'est toi qui contrôles exactement ce qui est possible.
Avant le serveur MCP, il faut une application à piloter. Dans la vidéo, elle est générée avec Claude Code à partir d'un prompt complet :
- Next.js 16 pour le front et l'API ;
- MongoDB Atlas pour la base de données ;
- NextAuth avec connexion par email et mot de passe.
Une app classique : chaque utilisateur a ses propres todos, qu'il peut créer, déplacer entre colonnes, modifier et supprimer. La démo dans le navigateur montre que tout fonctionne avant d'ajouter la couche MCP.
Ce point est important : le serveur MCP ne remplace pas ton app, il vient s'y greffer. Il réutilise tes modèles de données et ta logique métier.
Le protocole a un SDK officiel en TypeScript, publié par le projet Model Context Protocol. Il gère la partie protocole (messages, transport, déclaration des outils). Toi, tu n'écris que la logique.
npm install @modelcontextprotocol/sdk zod
Zod sert à décrire les schémas d'entrée des outils. Le SDK s'en sert pour valider les paramètres envoyés par le modèle avant d'appeler ta fonction.
Ton serveur MCP donne accès à des données d'utilisateurs. Il faut donc savoir qui appelle. La vidéo utilise une approche simple et robuste : des clés API.
Le principe :
- l'utilisateur génère une clé depuis l'app ;
- on ne stocke jamais la clé en clair, seulement son empreinte SHA256 ;
- à chaque appel MCP, on hache la clé reçue et on cherche l'empreinte correspondante ;
- on retrouve ainsi l'utilisateur, et chaque outil ne travaille que sur ses données.
import { createHash } from "node:crypto";
const hashKey = (key: string) => createHash("sha256").update(key).digest("hex");
C'est ce qui rend le serveur multi-tenant : un seul serveur, plusieurs utilisateurs, chacun cloisonné. Si une base fuit, les empreintes ne permettent pas de retrouver les clés.
Pour une app TODO, cinq outils couvrent tout :
| Outil | Rôle |
|---|
list_todos | lister les todos de l'utilisateur |
create_todo | créer un todo |
move_todo | déplacer un todo vers une autre colonne |
update_todo | modifier un todo |
delete_todo | supprimer un todo |
Chaque outil suit le même schéma : un nom, une description, des paramètres validés par Zod, puis un appel à ta logique existante. Les descriptions comptent plus qu'on ne le croit. C'est tout ce que le modèle sait de ton outil : une description claire (« Déplace un todo vers la colonne indiquée ») évite des appels maladroits.
Le serveur est assemblé par une fonction « factory ». Le schéma classique : la factory reçoit l'utilisateur authentifié et enregistre chaque outil avec ce contexte. Il devient alors difficile d'oublier de filtrer par utilisateur, puisque l'identifiant est capturé dès la création.
C'est un pattern qui passe bien à l'échelle. Le jour où tu as 50 outils, tu les ranges par domaine (clients, factures, projets…) et la factory les assemble.
Le serveur est exposé par une route d'API de l'app, /api/mcp, avec le transport HTTP standard du protocole. Pas de processus séparé à lancer, pas de port en plus : ton serveur MCP est déployé avec ton app, au même endroit, derrière le même domaine.
La route fait trois choses :
- lire la clé API dans l'en-tête de la requête ;
- retrouver l'utilisateur (ou répondre 401) ;
- créer le serveur via la factory et lui passer la requête.
Dernière brique côté app : une page Settings pour gérer ses clés. On peut en créer, les copier et les révoquer. Comme seule l'empreinte est stockée, une clé ne peut en général être affichée qu'au moment de sa création. La révocation est essentielle : si une clé traîne dans un fichier de configuration partagé, tu la coupes en un clic.
Tout ce travail se termine par une seule commande. Claude Code sait enregistrer un serveur MCP HTTP, avec un en-tête d'authentification, typiquement :
claude mcp add --transport http todo https://ton-app.example/api/mcp \
--header "Authorization: Bearer TA_CLE_API"
Au lancement suivant, Claude Code découvre les outils. Tu peux vérifier avec /mcp dans une session.
C'est là que tout prend son sens. Tu parles à Claude Code en langage naturel, par exemple pour lister tes todos, en créer plusieurs d'un coup ou en déplacer une série. Claude Code choisit les outils, les appelle, et les enchaîne tout seul pour construire des workflows plus complexes.
Tu n'as programmé aucun de ces workflows. Tu as seulement exposé cinq briques élémentaires. C'est le modèle qui les compose.
- Expose des actions précises, pas un accès brut à la base. Un outil
delete_todo vaut mieux qu'un outil run_query.
- Soigne les descriptions : c'est la documentation que lit le modèle.
- Filtre toujours par utilisateur côté serveur. Ne fais jamais confiance à un identifiant d'utilisateur passé en paramètre.
- Hache les clés, rends-les révocables, et ne les colle pas dans un dépôt Git.
- Commence petit : cinq outils bien pensés font déjà des merveilles.
- Une app existante (ici Next.js 16, MongoDB Atlas, NextAuth).
- Le SDK MCP officiel et Zod.
- Des clés API hachées en SHA256 pour un serveur multi-tenant.
- Cinq outils CRUD, créés par une factory qui connaît l'utilisateur.
- Une route
/api/mcp en transport HTTP.
- Une page pour gérer les clés.
- Une commande
claude mcp add pour tout brancher.
Trente minutes, et ton app devient pilotable en langage naturel. Le pas-à-pas complet est dans la vidéo.
