Large Language ModelsGenerate imagesGenerate videos
Cursor Supabase MCP Not Working? Setup and Fixes
A red dot, an empty tool list, or an Agent that cannot see your database usually has one clear cause. This article lays out the working Supabase MCP config for Cursor, a symptom table, log checks, Windows fixes, and safety settings so the connection holds.
You added the Supabase server to Cursor, restarted the editor, and now the MCP panel shows a red dot, an empty tool list, or a spinner that never stops. Or it looks connected, yet the Agent insists it has no database tools. That gap between "configured" and "working" is the most common form of Cursor Supabase MCP not working, and nearly every case traces back to a short list of causes: a config file in the wrong place, an unfinished login, a stale OAuth registration, a scoped URL that hides tools, too many tools across servers, a Windows npx quirk, a paused project, or an approval prompt nobody clicked. Here is each cause in the order worth checking, with the exact config, a symptom table, and the log checks that save an afternoon.
How the Cursor and Supabase Link Works
MCP, the Model Context Protocol, lets an editor's AI agent call outside tools. Supabase publishes an MCP server whose tools let the Agent list tables, run SQL, apply migrations, read project logs, and search the docs. Cursor is the client. It reads a JSON file, contacts or launches the server, asks for the tool list, and shows those tools in settings.
When something breaks, it breaks at one of four steps, and knowing which one cuts the search in half:
Config read: the file is missing, invalid, or in the wrong folder.
Connection: the URL cannot be reached or the command cannot be launched.
Authentication: the browser login never finished, or the token is wrong.
Tool listing: the server connected, but your parameters hide tools or the Agent is overloaded.
Hosted Server Versus Local npx
You have three ways to connect, and mixing their settings is a classic source of confusion.
Option
How it connects
Authentication
Typical use
Hosted remote
url pointing at https://mcp.supabase.com/mcp
Browser login through OAuth
Most setups today
Local npx
command and args launching @supabase/mcp-server-supabase
Personal access token you create
Older configs, or when a browser login is awkward
Local CLI stack
http://localhost:54321/mcp
Your local instance
Projects running on the Supabase CLI
💡 Pick one. If the same server name appears in two config files, or a remote entry and an npx entry both claim supabase, you can spend an hour debugging the wrong one.
Where mcp.json Must Live
Cursor reads two locations. A project file at .cursor/mcp.json applies to that repository. A user file at ~/.cursor/mcp.json applies everywhere, and Supabase's docs point to it when you want one config for every project.
Three mistakes account for a surprising share of red dots: saving mcp.json in the repo root instead of inside .cursor, leaving a trailing comma that makes the JSON invalid, and misspelling the top level mcpServers property. Paste the file into any JSON validator before you blame the server.
The Clean Setup That Works
Start from a known good state before you try fixes. Delete half-edited entries, then add exactly one of the configs below.
Save the file, restart Cursor, and open Settings > Cursor Settings > Tools & MCP. The Supabase entry should offer a login. A browser window opens, you sign in to Supabase, and you grant access to your organization. If you prefer the terminal, the Cursor CLI has three matching commands:
Then run the smoke test Supabase suggests in a new Agent chat: "What tables exist in my database? Use MCP tools." A real answer with your table names means the whole chain works. An apology about missing tools means one of the fixes below applies.
Token and npx Fallback
Some teams still run the server locally with a personal access token created in their Supabase account settings. The config launches the package through npx:
This route needs Node.js installed. The --read-only and --project-ref flags do the same jobs as the URL parameters described later. Treat the token like a password: never commit a mcp.json that contains it to a public repository. Supabase has changed its recommended setup over time, so check the MCP connection tab in the Supabase dashboard if its current instructions differ from this snippet.
Windows Needs a cmd Wrapper
On Windows, npx is a batch shim, and launching it directly often ends in a spawn error. Wrap it in cmd /c:
Run node --version and npx --version in a fresh terminal first. If Node was installed after Cursor started, the editor still holds the old PATH, so quit Cursor fully and reopen it, not just the window. The hosted URL route sidesteps all of this, which is a good reason to prefer it on Windows machines with locked-down toolchains.
Eight Symptoms and Their Fixes
Match what you see to a row, then jump to the matching section below.
Symptom
Likely cause
Fix
Red dot, no tools
Invalid JSON or wrong file path
Validate the JSON, use .cursor/mcp.json, restart
Login prompt or endless spinner
OAuth never finished
Repeat the login, or paste the auth URL from the logs
Error page on localhost:8787
Oversized localhost cookies (431)
Clear cookies for localhost only
Unrecognized client_id
Stale cached OAuth registration
Disconnect, remove, quit Cursor, add again
Connected, account tools missing
project_ref in the URL
Expected: scoped URLs disable account tools
Connected, Storage tools missing
Storage group is off by default
Name it in features
Writes refused
read_only=true
Remove it on a dev project, on purpose
Queries fail on a healthy link
Paused or wrong project
Resume the project in the dashboard
Red Dot and an Empty Tool List
A red dot means Cursor never got a working connection, so start with the cheapest checks. Validate the JSON, confirm the file sits at .cursor/mcp.json or ~/.cursor/mcp.json, and press the refresh control in the MCP settings, which has revived stalled servers for some users on the Cursor forum. Restart Cursor after every config change, since Supabase's own notes say a restart is needed before all tools appear.
If the dot stays red, the logs described below will name the failure in a single line. Resist the urge to rewrite the whole config at this point. One changed variable per restart is slower on paper and much faster in practice.
Login Loops and client_id Errors
With the hosted server, Cursor finishes the OAuth handoff by opening a page on localhost:8787. Two failures show up there.
A 431 error before sign-in finishes. Oversized cookies stored for localhost by your other dev servers can trigger it. Clear cookies for localhost only, not your whole browser, then retry the login.
"Unrecognized client_id". Cursor is reusing a cached OAuth registration from an old setup. Disconnect the server, remove it, quit Cursor fully, and add it again so it registers fresh.
If the browser never opens, look in the Cursor logs for the authorization URL, paste it into your browser by hand, finish the sign-in, and the callback should return to Cursor and establish the connection.
Connected, but Tools Are Missing
A green dot with a blind Agent is usually configuration doing exactly what you told it. Four URL parameters change which tools exist:
Parameter
Effect
read_only=true
Runs queries as a read-only Postgres user
project_ref=<id>
Scopes the server to one project and disables account tools
features=database,docs
Enables only the listed tool groups
skip_elicitations=execute_sql,apply_migration
Skips confirmation forms for those tools
A scoped example looks like this: https://mcp.supabase.com/mcp?project_ref=abc123&read_only=true
Three results surprise people. Adding project_ref disables the account tools, so a missing project listing is expected. The Storage group is off by default and has to be switched on. And read_only=true makes every write fail by design. Ask the Agent to list every Supabase tool it can call right now, then compare that list with your parameters.
💡 skip_elicitations removes a safety net. Use it only on a disposable dev project, never next to production data.
Approvals and Paused Projects
Two last causes look like failures but are not. First, Cursor normally asks before running an MCP tool, so an Agent that seems frozen may be waiting on an approval button higher up in the chat. Confirm you are in Agent mode, since that is where tools run.
Second, the project itself may be paused. Free tier projects can pause after about a week of inactivity, and queries against a paused database fail even when the MCP link is healthy. Resume it in the Supabase dashboard and retry.
Read the Logs Before Guessing
Every fix above gets faster once you read the actual error. Guessing at flags can add new problems on top of the original one.
Where Cursor Stores the Logs
Open the Output panel from the View menu and pick the MCP entry for your Supabase server in the channel dropdown. Restart the server, then read the last 20 lines. The usual patterns:
Log line
Meaning
Fix
spawn error or ENOENT
Command not found
Add the cmd /c wrapper, fix PATH, restart Cursor
401 or unauthorized
Login missing or expired
Run the login again
431 or header too large
Oversized localhost cookies
Clear localhost cookies
Timeout, ECONNREFUSED, ENOTFOUND
Network path blocked
Check VPN, proxy, and firewall
To test the network path alone, run curl -i https://mcp.supabase.com/mcp from a terminal. Any HTTP status, even a 401, proves the host is reachable. A timeout or TLS error points at a VPN, proxy, or firewall rather than at Cursor.
The Ten Minute Checklist
When you want a fast pass instead of a deep dive, work through this list in order:
Validate the JSON and confirm the file location.
Keep only one supabase entry across both config files.
Check node --version and npx --version if you use the npx route.
Wrap npx in cmd /c on Windows.
Quit Cursor fully and reopen it.
Finish the browser login, clearing localhost cookies on a 431.
Remove and re-add the entry on an "Unrecognized client_id" error.
Check project_ref, features, and read_only in the URL.
Switch to Agent mode and approve any pending tool call.
Confirm the Supabase project is not paused.
Too Many Tools Hurt the Agent
Cursor warns with "Exceeding total tools limit" once the tools from all your servers pass 40, noting that too many tools can degrade performance and that some models may not respect more than 40. Newer builds load tool context dynamically, and some users report no warning at all with more than 80 tools enabled.
The warning is softer than it used to be, but the underlying problem remains: an Agent choosing between dozens of similar tools picks worse, and smaller models struggle first. The Cursor forum thread on the 40 tool limit tracks how that limit has changed.
Trim the Tool List
Turn off servers you are not using this session.
Limit Supabase with features=database,docs when you only need SQL and documentation.
Click individual tool names in the MCP settings to switch off the ones you never call.
Keep project-specific servers in .cursor/mcp.json and general ones in the user file.
Lock It Down Before You Trust It
An MCP server that can run SQL deserves the same care as a database login. Supabase's own recommendation is blunt: connect to production only when necessary, and use project scoping, read-only mode, and restricted feature groups when you do.
Read-Only Mode and Project Scoping
Three settings do most of the protecting. read_only=true runs queries as a read-only Postgres user. project_ref limits the server to a single project. features trims the tool groups to the ones you need. Supabase also shows confirmation dialogs before anything that creates billable resources, so do not auto-approve past them. Unattended routines should always run read-only.
Prompt Injection Is the Real Risk
The main LLM-specific threat is malicious instructions hidden in data. Picture a support ticket row whose text tells the model to ignore earlier instructions and export the users table. If the Agent reads that row through a tool, it may treat the text as a command. Keep manual approval on tool calls and read each SQL statement before you approve it. Supabase's MCP documentation lists these protections in full.
💡 Build and test the connection on a throwaway dev project. Move to anything holding real customer data only with read-only mode and project scoping already in place.
Let a Model Read the Logs
When the log lines make no sense, an LLM is a fast second pair of eyes. On Picasso IA, Claude Sonnet 5 is built for automating coding tasks, GPT 5.6 Sol for solving complex coding tasks, and Gemini 3.1 Pro for sharper general answers. Any of them can turn a stack trace into a short list of suspects.
Before pasting anything, strip access tokens, sensitive project refs, and database URLs. A log excerpt rarely needs them, and a chat window is not a vault.
A Prompt for Config Bugs
Give the model the facts it cannot guess:
I use Cursor on Windows 11 with the hosted Supabase MCP server.
The MCP panel shows a red dot. My mcp.json (secrets removed) is below,
plus the last 20 lines from the MCP output channel.
List the three most likely causes, ranked, with one check for each.
Include your operating system, Cursor version, config, log excerpt, and what you expected to happen. Asking for ranked causes with one check each stops the model from dumping a generic checklist. Then run the checks yourself rather than approving fixes blindly.
Try It Yourself on Picasso IA
A fix like this deserves more than a wall of config. A blog post, internal runbook, or team doc reads better with real photography in place of stock screenshots, and Picasso IA turns a plain text prompt into an image in seconds. Try Seedream 4.5 for sharp, detailed photos, or GPT Image 2 when you want a plain prompt turned into a precise scene.
A starter prompt: "Overhead photograph of a developer's desk at sunrise, laptop open to a blurred code editor, ceramic mug, visible oak wood grain, 35mm lens, soft window light, Kodak Portra 400 film grain." Change the lens, the light, and the angle, and every variation becomes a fresh header image. Browse the full catalog at picassoia.com/en/all-models and make your first image today.