La ceinture d'outils MCP

Ce qu'une session Claude Code sur ce depot peut atteindre, par quel chemin, et ce qu'elle ne peut pas atteindre parce que le serveur n'existe pas.

Deux surfaces, pas une

C'est la confusion qui coute le plus cher, alors elle passe en premier : deux mecanismes differents posent des outils MCP dans une session, ils ne se recouvrent pas, et aucun des deux ne voit la configuration de l'autre.

Un connecteur claude.ai suit la personne. Un serveur de .mcp.json suit le code. Un nouvel arrivant qui clone ce depot herite du second et de rien du premier : c'est exactement pour ca que le fichier existe.

Etat au 2026-09-11

Deja branche, rien a faire

Ajoute par ce depot

Les quatre serveurs de .mcp.json. Aucun n'etait joignable avant, dans aucune session.

Volontairement absents

Poser les cles

Claude Code ne lit pas .env. Les ${VAR} de .mcp.json sortent du shell qui lance claude, donc ils vont dans le profil du shell, pas dans un fichier du depot. C'est aussi pour ca qu'aucune de ces trois cles n'est declaree dans src/env/server.ts : ce sont des cles de poste de developpeur, jamais lues par l'application, et env-var-consumed.test.ts refuserait a raison une cle declaree que personne ne lit.

# ~/.zshrc ou ~/.bashrc
export NEON_API_KEY="napi_…"                 # console.neon.tech -> Account settings -> API keys
export STRIPE_MCP_RESTRICTED_KEY="rk_live_…" # dashboard.stripe.com -> Developers -> API keys -> Restricted
export DATAFAST_API_TOKEN="dft_…"            # datafa.st -> Settings -> API & MCP

Une variable absente ne casse rien : le serveur se charge, Claude Code previent, et ses appels repondent 401 jusqu'a ce que la cle existe.

Verification, et c'est la seule qui compte :

claude mcp list      # les quatre doivent afficher "connected"

Cette verification n'est pas une formalite. Les quatre URL sont documentees, aucune n'est observee : le proxy d'egress de la CI et des sessions distantes refuse le CONNECT vers mcp.neon.tech, mcp.stripe.com, datafa.st et mcp.context7.com. Ecrire un contrat qu'on n'a pas vu repondre est exactement comment growth-web/0363 est arrive. Les sources sont citees ci-dessous ; le poste tranche.

Les deux permissions qui ne sont pas un detail

Neon pointe sur la production

Il n'y a qu'une base sur cette plateforme. Le schema.prisma est pousse par db push, il n'existe pas de prisma/migrations/, et la base Neon derriere DATABASE_URL est la source de verite de toutes les organisations, tous les stores, tous les credits.

Neon documente sa propre position sans ambiguite : « The Neon MCP server is intended exclusively for development and testing environments. Users should never connect MCP agents to production databases or expose PII. »

D'ou le ?readonly=true dans l'URL versionnee, pas dans une consigne. Il desactive les outils d'ecriture cote serveur : pas de branche creee, pas de configuration modifiee, pas de DDL. Ce qui reste est un SELECT, et un SELECT sur cette base lit des donnees clients. Le garde-fou tient l'ecriture ; il ne rend pas la lecture anodine, et c'est au proprietaire de decider si un agent doit l'avoir.

Retirer le readonly=true est une decision, pas un reglage.

Stripe : la cle EST la permission

Depuis la bascule du toolkit Stripe vers le MCP, configuration.actions a disparu : « Tool permissions are now controlled entirely by your Restricted API Key (RAK) on the server side. »

Autrement dit, rien cote client ne peut restreindre ce serveur. La seule barriere est la cle qu'on lui donne. D'ou deux regles :

1. Jamais STRIPE_SECRET_KEY. La cle secrete de l'application peut rembourser, annuler un abonnement, creer un transfert Connect. Une variable separee, STRIPE_MCP_RESTRICTED_KEY, existe pour que le nom rende la confusion difficile.
2. Une RAK en lecture seule, cochee au minimum : Customers, Products, Prices, Subscriptions, Invoices, Charges, Disputes, Balance, Connect, toutes en read. Aucune case write.

Le jour ou une ecriture est reellement necessaire, elle se fait avec une seconde RAK, sur un seul scope, posee le temps de l'operation.

Ce que ca change concretement

Trois questions qui demandaient un aller-retour avec le proprietaire et qui n'en demandent plus :

Limites connues

• Aucune ecriture nulle part. Neon est readonly, Stripe est borne par une RAK en lecture. Rien ici ne modifie l'etat de production, par construction et pas par convention.
• datafast ne mesure pas ce que emitServer( envoie. Le site est en mode cookieless, donc les goals serveur n'atteignent rien. Le serveur MCP lit ce que le script client a collecte, et c'est tout ce qui existe. Cf. growth-web/0609.
• shopify-dev est un processus npx. Premier lancement plus lent, et il lui faut le reseau. En session distante, l'egress peut le refuser.
• Rien ici n'est un connecteur produit. Les MCP servis aux boutiques clientes vivent dans src/config/native-mcps.ts et n'ont aucun rapport avec ce fichier.

Guard

src/test/mcp-toolbelt.test.ts derive cette page de .mcp.json : chaque serveur declare doit avoir sa ligne avec son URL, chaque ligne doit correspondre a un serveur declare, et aucune valeur ressemblant a un secret ne peut entrer dans le fichier versionne.