Serveur MCP de Supabase : un assistant IA dans sa base de données, à garder en interne

Supabase est une plateforme d'hébergement de bases de données Postgres, souvent choisie pour lancer rapidement une application. Son serveur MCP relie un assistant IA à vos projets : il peut lister les tables, exécuter du SQL, appliquer une migration, consulter les journaux, déployer une fonction ou chercher dans la documentation.

Installation

Le serveur est hébergé par Supabase à l'adresse https://mcp.supabase.com/mcp. Pour Claude Code, la documentation donne ce fichier .mcp.json :

{
  "mcpServers": {
    "supabase": {
      "type": "http",
      "url": "https://mcp.supabase.com/mcp"
    }
  }
}

À la première connexion, une fenêtre de navigateur s'ouvre : on se connecte à Supabase et on choisit l'organisation. Aucun jeton à créer ni à copier. Pour un usage automatisé (intégration continue), il reste possible de passer un jeton d'accès personnel dans un en-tête Authorization.

Pour le développement local avec l'outil en ligne de commande de Supabase, l'adresse est http://localhost:54321/mcp.

Trois réglages à connaître

Ils s'ajoutent directement à l'adresse du serveur :

• read_only=true : toutes les requêtes passent par un utilisateur Postgres en lecture seule.
• project_ref=<id> : le serveur est limité à un seul projet. Les outils de gestion du compte sont alors désactivés.
• features=<groupes> : seuls les groupes d'outils listés sont actifs.

Exemple combiné, tiré de la documentation : https://mcp.supabase.com/mcp?project_ref=abc123&read_only=true.

Les groupes disponibles couvrent la base de données, le débogage, le développement, les fonctions Edge, le compte, la documentation, les branches (expérimental, réservé aux offres payantes), le stockage (désactivé par défaut) et les notebooks.

Les confirmations intégrées

Le serveur peut interrompre un appel pour demander une validation : avant de créer un projet ou une branche (pour confirmer le coût), avant un SQL destructeur ou une migration. La documentation est claire sur leur portée : ce sont des garde-fous, pas des garanties. Elles dépendent du client utilisé, certains pouvant y répondre automatiquement, et ne remplacent pas l'approbation manuelle des appels d'outils.

Les risques, dits par l'éditeur

Supabase consacre une partie entière de sa page à la sécurité, et c'est à lire avant le reste.

• L'injection d'instructions. Un contenu non maîtrisé, par exemple un ticket de support stocké dans la base, peut contenir un texte qui pousse l'assistant à exécuter une requête nuisible. Supabase encadre les résultats SQL de consignes pour décourager ce comportement, tout en précisant que la protection n'est pas infaillible.
• Les droits hérités. Le serveur agit avec vos permissions de développeur.
• Les tâches sans surveillance. Une routine automatique ne peut pas demander d'approbation à chaque étape : elle doit rester en lecture seule.

Les recommandations qui en découlent : ne se connecter à la production que si la tâche l'exige, limiter le serveur à un projet, restreindre les groupes d'outils, garder l'approbation manuelle activée, tester les changements sur une branche. Et ne jamais mettre ce serveur entre les mains de clients ou d'utilisateurs finaux : c'est un outil interne pour développeurs.

Notre lecture

Ce serveur est pratique pour qui développe sur Supabase : générer une migration, comprendre une erreur dans les journaux, obtenir les types TypeScript. Mais une base de production contient souvent des données personnelles, et le RGPD s'applique quel que soit l'outil qui les lit.

Pour une petite entreprise, la configuration raisonnable tient en une ligne : un projet de développement, project_ref et read_only=true par défaut. L'écriture ne s'active que ponctuellement, sous surveillance. Si un prestataire vous propose de brancher un assistant sur votre base de production, demandez-lui quels réglages il applique. Nous n'avons pas testé ce serveur : cette fiche s'appuie sur sa documentation.