The split is what makes this usable with an agent: introspection runs on an ordinary authenticated token, and the migration, SQL, auth and storage writes are the ones that need service_role — so how far the assistant reaches is decided by which credential it gets. Over HTTP that split is enforced from the JWT's role claim; over stdio it is not enforced at all, so run that mode only where you would already trust the client with the database. The migrations tools depend on the table the Supabase CLI creates, so a database the CLI has never touched needs it created first.
A database-introspection and management server built for self-hosted Supabase rather than the cloud product, so there is no project selection or cloud API in the way. Tools are split by privilege: most read with any authenticated JWT, while the ones that change things require service_role.
- Schema read out in full: tables, columns, indexes, constraints, foreign keys, triggers and function definitions
- Extensions installed and extensions available to install, plus pg_cron jobs with their run history and pgvector indexes with their statistics
- Migrations listed from the Supabase migrations table, and a new one applied and recorded — that tool needs service_role
- Arbitrary SQL executed and any query explained, both privileged
- Row Level Security status and the policies themselves, listed — the part of a Supabase project hardest to reason about from migrations alone
- Database statistics, live connections and index statistics, plus advisory notices on security and performance
- Auth users listed, read, created, updated and deleted, with passwords hashed by the database rather than stored as given
- Storage buckets and their objects listed, with bucket configuration read and updated
- Edge functions listed with their details and recent logs, realtime publications inspected, and TypeScript types generated from the schema
Bun 1.1 or newer, and a self-hosted Supabase the server can reach: its URL and anon key at minimum. Add the service-role key for the privileged tools, and a direct PostgreSQL connection string for anything that touches the auth or storage schemas or the system catalogs. Over stdio there is no authentication at all — every tool, privileged ones included, is available to whatever launched it, which is why that mode is for a trusted local client. The HTTP transport authenticates each request with a JWT and decides access from its role claim, with rate limiting and a CORS allow-list on top. A whitelist file limits which tools exist at all. MIT.
One command plus a key — npx -y @smithery/cli install @HenkDz/selfhosted-supabase-mcp --client claude, then supply credentials