Qu’est-ce que Faucet ?
Faucet, de la start-up américaine FaucetDB, se connecte à PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, Snowflake ou SQLite, lit le schéma et en génère à l'exécution une API REST CRUD, une spécification OpenAPI 3.1 et un serveur MCP. Les rôles, les clés d'API, les comptes administrateur et les informations de connexion sont stockés dans un fichier SQLite intégré, et une interface d'administration incluse dans le même binaire connecte les bases, crée les rôles et fournit des configurations MCP prêtes à l'emploi pour Claude Code, Cursor, VS Code et Windsurf.
Le serveur MCP est servi sur /mcp, sur le même port que l'API REST (8080 par défaut), en Streamable HTTP avec authentification par l'en-tête X-API-Key, ou lancé en stdio. Il expose 8 outils et 2 ressources. Le dépôt, créé en février 2026 et écrit presque entièrement par un seul développeur, compte environ 172 étoiles sur GitHub ; la v0.1.15 est sortie le 9 octobre 2026, et le paquet npm a été téléchargé 346 fois sur le mois clos le 10 novembre.
Tout est sous licence MIT, sans offre payante. Un Faucet Cloud hébergé est annoncé, avec liste d'attente et sans prix.
Installer Faucet
npx @faucetdb/faucet serveFaucet vaut-il le coup ?
L'idée de Faucet est saine : plutôt que de confier à l'agent un prompt SQL, il lui donne des outils structurés (faucet_query, faucet_insert, faucet_update, faucet_delete) qui correspondent à des verbes HTTP, et vérifie chaque appel par rapport au rôle de la clé d'API, par service et par table. Les filtres arrivent dans une petite syntaxe d'expressions que Faucet paramètre lui-même, de sorte que le modèle n'écrit jamais la chaîne SQL exécutée. Le SQL brut est un outil à part qui exige à la fois raw_sql_allowed sur le service, désactivé par défaut, et un rôle accordant les cinq verbes ; les services marqués read_only refusent toute écriture, SQL brut compris. DBHub, à l'inverse, remet au modèle un outil execute_sql ; MCP Toolbox de Google arrive à un résultat voisin en vous faisant écrire les requêtes à l'avance, là où Faucet génère ses outils à partir du schéma.
L'historique justifie la prudence. La version v0.1.13, du 3 septembre 2026, a corrigé une faille que les mainteneurs ont eux-mêmes jugée de gravité élevée : jusque-là, les règles des rôles étaient enregistrées mais jamais consultées, si bien que n'importe quelle clé d'API valide, y compris celle confiée à un agent, pouvait lire et écrire toutes les tables de tous les services, en REST comme en MCP. La même version a empêché le SQL brut d'ignorer l'indicateur read_only et a remplacé un secret de signature JWT par défaut, codé en dur, par un secret aléatoire. La faille a été signalée dans les notes de version et non comme avis de sécurité GitHub, et le dépôt n'en recense aucun. Les filtres par ligne sont toujours enregistrés sans être appliqués, une lacune que la documentation reconnaît ouvertement.
Les réglages réseau par défaut demandent une attention prioritaire. faucet serve écoute sur 0.0.0.0, c'est-à-dire toutes les interfaces, sur le port 8080 et en HTTP non chiffré ; la documentation renvoie le TLS à un proxy inverse. Tant que le premier compte administrateur n'existe pas, l'endpoint de configuration accepte le premier venu, donc une instance neuve sur un réseau partagé devrait être lancée avec --host 127.0.0.1. Le mode stdio s'exécute avec des droits d'administrateur local et n'applique aucun rôle, ce qui signifie insertion, mise à jour et suppression sans restriction sur toutes les tables connectées. Les mots de passe de connexion sont stockés en clair dans le fichier SQLite de configuration, que Faucet limite à des permissions propriétaire. La télémétrie est activée par défaut : un envoi horaire à PostHog avec le nombre de tables, de clés et de rôles, sans noms ni données, désactivable avec FAUCET_TELEMETRY=0.
Notre avis : Faucet a sa place lorsqu'une équipe veut une seule couche REST et MCP au-dessus d'un parc SQL Server ou Oracle que des outils SQL à la manière de DBHub exposeraient trop librement. Il faut le traiter comme un produit v0.1, créer malgré tout un utilisateur de base de données en lecture seule et le tenir à l'écart des interfaces publiques.
Là où il fait la différence
L'équipe des opérations d'un industriel dont l'ERP tourne sur SQL Server
Laisser Claude répondre aux questions sur les stocks et les commandes sans toucher aux chemins d'écriture de l'ERP
Connectez l'ERP avec un utilisateur de base de données limité à SELECT, marquez le service read_only et attribuez à l'agent une clé liée à un rôle GET uniquement sur les tables de stock et de commandes. L'agent filtre via faucet_query, plafonné à 1 000 lignes par appel ; rien à acheter hormis une petite VM.
Une agence de deux personnes qui construit un outil interne sur Postgres
Obtenir une API CRUD et un accès d'administration modifiable par l'agent sans écrire de backend
Pointez Faucet vers la base, utilisez dans le front end les endpoints /api/v1 générés et donnez à l'agent une clé distincte dont le rôle n'autorise POST et PATCH que sur deux tables. Verrouillez le contrat de schéma pour qu'une migration ne casse pas l'API en silence.
Un analyste de données disposant d'un entrepôt Snowflake
Explorer les tables et extraire des échantillons depuis Cursor en langage courant
Ajoutez Snowflake avec une authentification par paire de clés, créez une clé GET uniquement et déclarez l'endpoint /mcp dans Cursor. faucet_describe_table fournit au modèle les colonnes et les types ; le vrai coût reste les crédits d'entrepôt Snowflake consommés par chaque requête.
Avant de vous engager
- Mise en route
- npx @faucetdb/faucet serve, Homebrew, Docker ou un binaire publié ; l'assistant de configuration sur localhost:8080 crée ensuite l'administrateur et connecte une base avec hôte, port, utilisateur et mot de passe. Créez un rôle et une clé d'API, puis lancez claude mcp add --transport http avec l'en-tête X-API-Key ; Claude Desktop a besoin de la passerelle mcp-remote. Le README présente le passage de la base à l'API comme un démarrage rapide de 60 secondes ; les rôles et les clés ajoutent quelques minutes.
- Intégrations
- 8 outils MCP (faucet_list_services, faucet_list_tables, faucet_describe_table, faucet_query, faucet_insert, faucet_update, faucet_delete, faucet_raw_sql) et 2 ressources ; quatre des outils peuvent écrire. La même instance sert l'API REST, /openapi.json pour les Custom GPT Actions de ChatGPT, /healthz et /readyz. Pas d'OAuth, donc pas de prise en charge des connecteurs ChatGPT.
- Données et confidentialité
- Auto-hébergé ; les lignes ne partent que chez le fournisseur du modèle de l'agent. L'agent peut faire tout ce que permet le rôle de sa clé, dans les limites de l'utilisateur de base de données. HTTP écoute par défaut sur 0.0.0.0, port 8080 ; stdio s'exécute avec des droits d'administrateur. Les mots de passe des bases sont stockés en clair dans le fichier SQLite de configuration (permissions propriétaire) ; les clés d'API sont hachées en SHA-256. La télémétrie anonyme part chez PostHog toutes les heures sauf désactivation. Les lignes renvoyées au modèle peuvent contenir une injection de prompt, comme tout texte issu d'une base.
- Coût à grande échelle
- Gratuit ; les coûts sont une machine pour le binaire et la charge sur la base. faucet_query renvoie 25 lignes par défaut et 1 000 au maximum ; le SQL brut renvoie 100 lignes par défaut, 10 000 au maximum, et s'interrompt au bout de 30 secondes (jusqu'à 300). Les requêtes Snowflake consomment des crédits d'entrepôt à chaque appel.
- Limites
- Version 0.1.x d'un projet à un seul développeur, que le README juge adapté aux outils internes et aux prototypes. Six tickets ouverts, dont la justesse du générateur de requêtes SQLite. Pas de GraphQL ni d'OAuth, filtres par ligne non appliqués, et chaque réplique Kubernetes a besoin de son propre stockage de configuration.
Les points forts
- Sept moteurs SQL, dont Oracle et Snowflake, depuis un seul binaire
- Droits par verbe et par table à chaque appel d'outil MCP
- Outils structurés avec filtres paramétrés ; SQL brut désactivé par défaut
- L'interface d'administration génère les configurations MCP avec la clé déjà renseignée
Les points faibles
- Les règles des rôles n'étaient pas appliquées du tout avant la v0.1.13
- Écoute sur 0.0.0.0 en HTTP non chiffré ; configuration ouverte tant qu'il n'y a pas d'administrateur
- Le mode stdio s'exécute en administrateur sans appliquer de rôles
- Filtres par ligne enregistrés mais non appliqués ; télémétrie activée par défaut
Idéal pour
Les équipes qui veulent qu'un agent et leurs applications internes partagent une couche REST et MCP encadrée au-dessus de bases SQL Server, Oracle, Snowflake ou Postgres déjà en service.
Alternatives à Faucet
Faucet : questions fréquentes
- Faucet vaut-il le coup ?
- La bonne architecture pour donner à un agent un accès encadré aux tables de sept moteurs SQL, dans un projet si jeune que ses contrôles de rôles ne fonctionnent que depuis septembre. Nous lui donnons 3.6 sur 5.
- Combien coûte Faucet ?
- Gratuit et open source (MIT), toutes les fonctions incluses. Un Faucet Cloud hébergé est sur liste d'attente ; aucun prix publié.
- Quels sont les inconvénients de Faucet ?
- Les règles des rôles n'étaient pas appliquées du tout avant la v0.1.13; écoute sur 0.0.0.0 en HTTP non chiffré ; configuration ouverte tant qu'il n'y a pas d'administrateur; le mode stdio s'exécute en administrateur sans appliquer de rôles; filtres par ligne enregistrés mais non appliqués ; télémétrie activée par défaut.
- À qui s’adresse Faucet ?
- Les équipes qui veulent qu'un agent et leurs applications internes partagent une couche REST et MCP encadrée au-dessus de bases SQL Server, Oracle, Snowflake ou Postgres déjà en service.
- Combien coûte Faucet pour une équipe ou en production ?
- Gratuit ; les coûts sont une machine pour le binaire et la charge sur la base. faucet_query renvoie 25 lignes par défaut et 1 000 au maximum ; le SQL brut renvoie 100 lignes par défaut, 10 000 au maximum, et s'interrompt au bout de 30 secondes (jusqu'à 300). Les requêtes Snowflake consomment des crédits d'entrepôt à chaque appel.
- Faucet est-il sûr pour les données de l’entreprise ?
- Auto-hébergé ; les lignes ne partent que chez le fournisseur du modèle de l'agent. L'agent peut faire tout ce que permet le rôle de sa clé, dans les limites de l'utilisateur de base de données. HTTP écoute par défaut sur 0.0.0.0, port 8080 ; stdio s'exécute avec des droits d'administrateur. Les mots de passe des bases sont stockés en clair dans le fichier SQLite de configuration (permissions propriétaire) ; les clés d'API sont hachées en SHA-256. La télémétrie anonyme part chez PostHog toutes les heures sauf désactivation. Les lignes renvoyées au modèle peuvent contenir une injection de prompt, comme tout texte issu d'une base.
- Quelles sont les meilleures alternatives à Faucet ?
- Les alternatives les plus proches que nous avons testées sont DBHub, MCP Toolbox for Databases, Supabase MCP Server et database-mcp (cocaxcode).
Réponses vérifiées le 11 nov. 2026.