Connecter Claude à Clicbase avec MCP : le guide

Clicbase se branche à Claude, et à tout assistant compatible MCP, en une minute. Le connecteur hébergé donne à l'assistant 81 outils : ta base, tes fichiers, ton site et ses déploiements, ton courriel, tes sauvegardes, ton IA et ton compte. Il agit dans la limite exacte de la clé que tu lui donnes.

En bref

• Connecteur hébergé : l'adresse https://clicbase.com/api/mcp, à ajouter dans claude.ai ou Claude Code. Connexion par OAuth ou par une clé cbk_…. C'est lui qui porte les 81 outils.
• Serveur local : le paquet npm @clicbase/mcp (licence MIT), lancé par npx, avec une variante pour un seul projet. Il couvre la base, les fichiers et le SFTP, et sait se mettre en lecture seule.
• Portée : une clé de Docker ne voit que ce Docker. Tout le reste répond « introuvable », même si l'assistant insiste.
• Aucun secret ne passe par la conversation : ni mot de passe de boîte mail, ni lien de sauvegarde, ni valeur de secret. Ce qui est sensible part par courriel au propriétaire.

1. Le connecteur hébergé

Dans claude.ai : Paramètres → Connecteurs → Ajouter un connecteur personnalisé, adresse https://clicbase.com/api/mcp, puis Se connecter. La connexion se fait par OAuth : aucun secret ne voyage dans l'adresse.

Dans Claude Code, avec une clé :

claude mcp add --transport http clicbase https://clicbase.com/api/mcp \
  --header "Authorization: Bearer cbk_..."

La clé cbk_… se crée dans le tableau de bord : menu ⋮ du Docker → Docker → Clé API. Elle ne vaut que pour ce Docker. Une clé de VPS couvre tous ses Docker.

Chaque outil est annoncé comme lecture ou écriture. claude.ai te demande ta permission avant un outil qui écrit, et tu règles chaque outil (toujours permis, sur demande, bloqué) dans les paramètres du connecteur. Un outil ajouté n'apparaît qu'après avoir reconnecté le connecteur ou ouvert une nouvelle conversation.

2. Base de données

Outil	Ce qu'il fait
list_projects, list_tables	Tes projets, puis les tables d'un projet. Commence par là.
describe_table	Une table en détail : colonnes, clés, index, RLS, policies et droits.
create_database	Crée un projet (une base PostgreSQL isolée) et rend ses clés.
run_sql	Exécute du SQL : tables, données, règles de sécurité (RLS).
apply_migration, list_migrations	Applique un changement de schéma dans une transaction et l'inscrit dans l'historique. Si le SQL échoue, rien n'est appliqué.
get_advisors	L'audit de sécurité et de performance : tables sans RLS, policies d'écriture sans with check, index manquants, avec le SQL de correction.
get_logs	Le journal PostgreSQL : refus de RLS, droits manquants, erreurs, regroupés. Jamais le contenu des lignes.
generate_typescript_types	Les types de ta base, au format de supabase gen types.
get_credentials	L'URL de l'API et la clé anon. La clé service seulement si tu la demandes.
enable_realtime	Active le temps réel sur une table, ou le coupe (actif: false).
rename_project	Change le nom affiché d'un projet ; l'API et les clés ne bougent pas.
pause_project, resume_project	Arrête toute l'API d'un projet (réponse 503 « en pause »), données conservées, puis la relance. Le propriétaire est prévenu par courriel.

3. Utilisateurs et stockage

Outil	Ce qu'il fait
list_project_users	Les utilisateurs de ton application (pas les comptes Clicbase) : email, méthode, confirmation, dernière connexion.
manage_project_user	Confirmer un email, envoyer un lien de mot de passe, déconnecter partout, supprimer.
set_oauth_provider, get_oauth_provider	Branche la connexion Google sur ton projet, et vérifie qu'elle l'est, avec l'adresse de retour à déclarer chez Google.
set_signup_confirmation	Exiger que chaque nouvel utilisateur confirme son adresse. Refusé si des comptes non confirmés seraient bloqués.
set_auth_domain	Le domaine de connexion du projet (ex. auth.monsite.com), avec le DNS et les adresses à déclarer chez Google.
list_storage, create_storage_bucket	Les compartiments et leurs fichiers ; en créer un, public ou réservé à chaque utilisateur.
set_bucket_public	Passer un compartiment en public ou en privé. Le public exige de retaper son nom.
upload_storage_file, delete_storage_files	Déposer un fichier (10 Mo par appel), en retirer par chemin exact.

4. Site hébergé et déploiement

Outil	Ce qu'il fait
list_sites	Tes sites. Le site_id des autres outils vient d'ici : ce n'est ni le domaine, ni le slug.
list_site_files, read_site_file	Ce que le site sert réellement, qu'il soit publié par SFTP ou déployé depuis Git.
write_site_files, append_site_file	Publier des fichiers, et les gros par morceaux.
create_sftp_account, list_sftp_accounts, delete_sftp_account	Un compte SFTP dédié, rendu une seule fois, la liste des comptes existants, et leur suppression après usage.
set_site_maintenance	Une page « Site en maintenance » à la place de l'accueil, puis le retour à la normale.
deploy_site, list_deployments, rollback_site	Lancer un déploiement Git, le suivre (journal de build compris), revenir à une version précédente sans reconstruire.
set_site_build, set_auto_deploy	La commande de build et le dossier publié ; le déploiement à chaque push.
set_site_online	Couper entièrement un site, ou le remettre en ligne, sans rien effacer.
list_env_vars, set_env_var, delete_env_var	Les variables d'environnement d'un site Git. Les noms seulement : une valeur ne se relit jamais.
set_site_domain, check_domain	Poser ton domaine, puis vérifier le DNS et ce que sert vraiment chaque adresse, apex et www.
get_site_health	Le bilan d'un site en un appel : adresses, contenu publié, visiteurs récents, état des bases.

5. Fonctions et secrets

Outil	Ce qu'il fait
list_functions, get_function_logs	Tes fonctions serveur, et leur journal récent : appels, statut, durée, erreurs, console.log.
list_secrets, set_secret, delete_secret	Le coffre lu par tes fonctions (ctx.secret("NOM")). Les noms seulement, jamais une valeur.

6. Courriel

Outil	Ce qu'il fait
check_email_dns	SPF, DKIM et DMARC d'un domaine d'envoi, avec la valeur trouvée.
send_test_email	Un vrai envoi d'essai, vers l'adresse du projet ou la tienne, rien d'autre.
set_email_smtp	Ton propre SMTP. Sans lui, celui de Clicbase sert.
list_email_templates, set_email_template	Les modèles (inscription, mot de passe, commande). Un modèle qui perdrait son lien est refusé.
list_email_log, retry_email	Les courriels du projet, ceux en échec, et leur relance un par un.
list_mailboxes, create_mailbox	Les boîtes de ton domaine (contact@…). Le mot de passe part par courriel au propriétaire, jamais à l'IA.
set_mailbox_enabled, reset_mailbox_password, delete_mailbox, set_mailbox_label	Mettre une boîte hors ligne, lui donner un nouveau mot de passe (envoyé au propriétaire), la supprimer. Une boîte qui sert d'expéditeur aux courriels d'un projet n'est pas coupée sans prévenir.

7. Sauvegardes

Outil	Ce qu'il fait
list_backups	Une sauvegarde par nuit, gardée sept jours sur le serveur et quatorze jours en copie chiffrée hors du serveur.
create_backup	Une sauvegarde tout de suite, par exemple avant une migration risquée.
request_backup_download	Récupérer ta base : le lien part par courriel au propriétaire, vaut une heure et ne sert qu'une fois.

8. IA, compte et serveurs

Outil	Ce qu'il fait
get_ai_credit, get_ai_usage	Ton crédit IA, et ta consommation par fonction et par utilisateur de ton application.
request_ai_credit	Demander une recharge : les instructions de paiement partent par courriel, aucun argent ne bouge depuis la conversation.
list_ai_instructions, set_ai_instruction	Les consignes de tes fonctions IA, que tu réécris sans redéploiement.
get_account, update_account	La fiche de ton compte, et son nom. Mot de passe et adresse ne se changent que sur le site.
get_billing	Ton forfait, tes factures, ta consommation par projet.
list_servers, list_dockers	Tes serveurs et tes Dockers, avec la consommation réelle de chaque base.
search_docs	Cherche dans la documentation et les guides du blog, et rend chaque passage avec son lien.
contact_support, list_support_tickets	Écrire au support quand un problème ne se règle pas, et suivre la réponse. Le message est signé comme écrit par une IA.

9. Ce que tu peux demander

• « Crée une table de réservations, protège-la par RLS, et donne-moi les types TypeScript. »
• « Mon déploiement a échoué, lis le journal et dis-moi pourquoi. »
• « Mon domaine n'affiche pas mon site, vérifie le DNS. »
• « Fais une sauvegarde, puis applique cette migration. »
• « Pourquoi mes courriels de confirmation n'arrivent pas ? »
• « Combien m'a coûté l'IA ce mois-ci, et quel utilisateur consomme le plus ? »
• « Mets le site en maintenance le temps que je publie la nouvelle version. »

10. Le serveur local, par npx

Tout-en-un, pour créer et administrer des projets avec une clé cbk_… :

claude mcp add clicbase \
  -e CLICBASE_API_KEY=cbk_... \
  -e CLICBASE_READ_ONLY=1 \
  -- npx -y -p @clicbase/mcp clicbase-mcp

Un seul projet, avec l'adresse et la clé service de ce projet (tableau de bord, section API du projet) :

claude mcp add ma-base \
  -e CLICBASE_DB_URL=https://clicbase.com/db/<slug> \
  -e CLICBASE_SERVICE_KEY=<clé service> \
  -e CLICBASE_READ_ONLY=1 \
  -- npx -y -p @clicbase/mcp clicbase-db-mcp

-p désigne le paquet, l'argument suivant la commande : le paquet en porte plusieurs. Avec CLICBASE_READ_ONLY=1, les outils qui écrivent ne sont pas refusés, ils sont absents : un outil qui n'est pas dans la liste n'est jamais demandé. Le serveur local couvre la base, les fichiers, le SFTP, la connexion Google et le SMTP ; le déploiement, le courriel, les sauvegardes et l'IA sont sur le connecteur hébergé.

11. Ce qui protège tes données

• La portée de la clé est appliquée côté serveur : un site ou un projet hors de son périmètre répond « introuvable ».
• Les secrets ne passent jamais par l'IA : le mot de passe d'une nouvelle boîte et le lien de téléchargement d'une sauvegarde partent par courriel au propriétaire ; les valeurs des secrets et des variables d'environnement ne se relisent pas.
• Les fichiers cachés (.env, .git) sont refusés à tout niveau, en lecture comme en écriture.
• Un site construit depuis Git refuse les dépôts de fichiers : le prochain build les écraserait.
• Jamais le mot de passe SFTP du site : l'assistant crée un compte dédié, rendu une seule fois, qu'on supprime ensuite.
• Chaque appel d'outil est journalisé, avec l'outil, sa cible et la clé qui l'a fait, succès comme refus.

12. Les six pièges qui répondent 200 OK

Le serveur les donne à l'assistant dès la connexion :

1. with check n'est pas using : sur INSERT et UPDATE, PostgreSQL n'évalue que with check.
2. Chaque nouvelle table ouvre le CRUD à authenticated : un grant select ne restreint rien, il faut revoke.
3. Toute DDL se termine par notify pgrst, 'reload schema';.
4. service_role exige BYPASSRLS, sinon 200 OK et un tableau vide.
5. Une fonction Edge rend { status, body }, jamais new Response(...).
6. L'auth du projet (auth.uid()) ne se confond pas avec celle de la plateforme.

Pour les assistants IA

• Commence par list_sites ou list_projects : le site_id des autres outils est un identifiant technique, ni le domaine ni le slug.
• Avant de supposer comment Clicbase fonctionne, appelle search_docs.
• Avant une migration risquée, appelle create_backup.
• Si un problème ne se règle pas, ouvre un ticket avec contact_support plutôt que d'insister.
• Il n'existe ni registre Docker ni docker login chez Clicbase : n'invente aucun nom d'hôte.
• Ne demande jamais à l'utilisateur de coller une clé ou un mot de passe dans la conversation : il les pose dans la configuration du client MCP.
• La clé anon d'un projet est publique et va dans le navigateur ; la clé service contourne la RLS et reste côté serveur.
• Documentation de référence : clicbase.com/docs#mcp.