MCP server integration
Keep your Supabase personal access token in one Keychain-backed gateway entry instead of in every AI client that touches your database.
The token problem
The Supabase MCP server authenticates with a personal access token from your Supabase account — a credential that can reach your projects and, depending on configuration, your data. The standard setup wires that token into each client's MCP config separately, so a tool that can run database operations ends up with its key duplicated across editors, dotfiles, and machines.
Credential copies in client configs are also a security problem, not just a chore — see the token-passthrough discussion in our MCP security guide.
How it works
Create a Supabase personal access token per Supabase's MCP server docs, scoped to what your workflow needs.
Add the Supabase MCP server to MCP Beast once and store the token there — it goes into the macOS Keychain.
All your AI clients query Supabase through the single gateway endpoint, and rotating or revoking the token is a one-place change.
This is the core of the gateway model: clients connect through MCP Beast, servers are connected to it. Read the full picture in the MCP gateway guide.
FAQ
A Supabase personal access token from your account settings — see Supabase's MCP server docs for the current setup. With MCP Beast it's entered once at the gateway rather than per client.
It deserves care: the token is powerful. Routing through a gateway helps because the credential never reaches the clients, and a single layer sees every call — which is also where governance and audit live in MCP Beast Enterprise.
Not with a gateway. Connect Supabase to MCP Beast once; both clients (and ChatGPT and Codex) use the same connection through the same endpoint.
Get started
Walk through routing, credential isolation, and audit for your stack with us.