This page is what happened when we ran it. The project itself — code, maintenance, community — has its own review: full repo review →

DatabasesMCP servermeasured 19 Aug 2026

Supabase

The Supabase MCP server is Supabase's own bridge between an AI client and your Supabase organization: list projects, run SQL, inspect schemas, manage branches, fetch logs. It publishes as @supabase/mcp-server-supabase on npm and speaks stdio. Authentication is a personal access token tied to your Supabase account rather than to one project or one database.

Supabase · measured by Keyoor

BootDID NOT BOOTWe started it and it never completed initialize: exited with code 1 before initialize completed

Tools0tools/list payload 0 bytes

Context tax~0estimated tokens for the whole tools/list, chars/4 estimate

Resources / prompts— / —counts returned by resources/list and prompts/list

Measured19 Aug 2026one run of the harness, clean environment, no credentials · how we test

How we started it

npx -y @supabase/mcp-server-supabase

Verdict

Use it, but only after you have decided how you feel about the token. We started it in a clean environment with no secrets, which is how we start everything, and it refused: exit code 1 before initialize completed, with stderr asking for a personal access token via --access-token or SUPABASE_ACCESS_TOKEN (measured 2026-08-19). That is correct behaviour for a server that can run SQL, and it is also the whole cost of admission, because a Supabase PAT is account-wide and the model holding it can reach every project you own. Skip it unless you are willing to point it at a read-only or throwaway org.

Use it if

You already build on Supabase daily and want the assistant to read your actual schema instead of guessing column names

You can create a PAT on a scratch or staging organization and keep production out of reach

You want migrations and branch operations driven from chat and accept reviewing every generated SQL statement before it lands

You are debugging and want log-fetching in the same session as the code, without tab-switching to the dashboard

Skip it if

The only token you have is one that reaches your production organization

You wanted a plain Postgres connection: this is an account-level control plane, and a direct database MCP server or psql is a smaller blast radius

Your client cannot store per-server environment variables, so the token would end up in a shared config file or shell history

You are evaluating servers on a locked-down machine and cannot mint credentials at all, in which case you will see exactly the failure we saw

You want a zero-config trial before committing: there isn't one here

The bill for your context window

We have no Context Tax for this one, and that absence is itself the measurement: with no token, the process died before initialize, so tools/list never happened and the tool payload weighed nothing we could count. Judging from the documented surface, expect it to land well above the batch median of 1,913 tokens once it does start, because project management, SQL execution, branching, logs and docs search are distinct tool families with long parameter schemas. If your context budget is tight, the --project-ref and --read-only flags are the lever, since they prune whole groups of tools rather than trimming descriptions.

Setup reality

Nothing runs until SUPABASE_ACCESS_TOKEN exists, and the server says so plainly instead of hanging, which is more courtesy than most. You mint the token in the Supabase dashboard under account access tokens, then either export it or pass --access-token on the command line; the environment variable is the safer of the two, since arguments show up in process lists. The README documents a --read-only flag and a --project-ref flag that pins the server to one project, and both are worth setting before you ever attach a real organization. Transport is stdio over npx, so there is no port, no OAuth round trip, and no daemon to supervise.

SUPABASE_ACCESS_TOKEN

Questions people ask

Why did the Supabase MCP server exit immediately?

It wants credentials before it will talk MCP at all. Our clean-environment run ended with exit code 1 and a stderr line asking for a personal access token through --access-token or SUPABASE_ACCESS_TOKEN. Provide one and the handshake proceeds normally.

Is the access token scoped to a single project?

No. A Supabase personal access token carries your account's reach, which is why the server also accepts a --project-ref flag to narrow what it will touch. Pair that with --read-only if the assistant only needs to look.

Does a failed boot mean the server is broken?

Not at all. Most servers in this batch completed a handshake with no credentials; the rest, like this one, are gated by design. A refusal to start unauthenticated is a reasonable stance for something that can execute SQL against your projects.

Other databases servers we started

Server	Vendor	Boots	Context tax
Chroma	Chroma	✗	~0 tokens
Elasticsearch	Elastic	✗	~0 tokens
MongoDB	MongoDB	✓	~9,462 tokens
MySQL	community (benborla29)	✓	~100 tokens
Pinecone	Pinecone	✓	~6,165 tokens
PostgreSQL (archived)	Anthropic (archived)	✓	~33 tokens
Qdrant	Qdrant	✗	~0 tokens

How this page is made: the server is spawned as an unprivileged user with a clean environment and no credentials, then asked for its tools, resources and prompts over stdio. Token figures are estimates at four characters per token, not a tokenizer count. One run, one machine. Corrections: contact the desk.

← All measured MCP servers