How to Connect Supabase to Cursor with MCP (2 Ways)

The short answer

There are two legitimate ways to connect Supabase to Cursor through MCP:

1. Use the official Supabase MCP server when Cursor needs Supabase platform tools such as migrations, project logs, Edge Functions, advisors, or generated TypeScript types.
2. Connect the underlying PostgreSQL database through datamcp when Cursor primarily needs schema and SQL tools with a separate MCP link, table-level operation policy, and query activity history.

Supabase is PostgreSQL, so the second option does not require a special Supabase integration. datamcp connects using the standard PostgreSQL connection string available from the Supabase dashboard.

This guide covers both approaches, explains their different security boundaries, and provides the complete database-focused setup.

If you are still choosing the access model, start with the Supabase MCP server decision guide. For the same database-focused workflow without Supabase-specific platform tools, use the Cursor and PostgreSQL setup tutorial.

The current official hosted setup uses browser-based authorization for compatible clients; a personal access token is no longer required for the normal interactive flow. Scope the URL deliberately: without project_ref, the official server can access all projects available in the authorized organization, and all feature groups except Storage are enabled by default.

Official Supabase MCP vs datamcp

The official server is the better choice for broad Supabase development workflows. datamcp is the better fit when you want the same database-focused control plane for Supabase and other PostgreSQL environments, or separate access policies for different AI clients and teammates.

These approaches can coexist, but do not give both servers broad write access by default. Duplicate capabilities make it harder to predict which server Cursor will call and harder to audit the effective permission boundary.

Option A: Use the official Supabase MCP server

Supabase operates a hosted remote MCP server at:

https://mcp.supabase.com/mcp

The current Supabase MCP documentation lets you scope the server to one project, enable read-only database execution, and limit feature groups. Project scope also disables account-management tools. A database-focused URL can look like:

https://mcp.supabase.com/mcp?project_ref=YOUR_PROJECT_REF&read_only=true&features=database,docs

Add it to .cursor/mcp.json for one repository or ~/.cursor/mcp.json for every project:

{
  "mcpServers": {
    "supabase": {
      "url": "https://mcp.supabase.com/mcp?project_ref=YOUR_PROJECT_REF&read_only=true&features=database,docs"
    }
  }
}

Then open Cursor Settings → Tools & MCP, find the server, and complete the Supabase authorization flow in the browser. A personal access token is no longer required for this normal hosted setup. Cursor may need a restart before it discovers the tools.

Choose this route when you want Cursor to inspect Supabase service logs, apply migrations, work with Edge Functions, run security or performance advisors, or generate project types. Review every enabled feature group rather than accepting a larger tool surface than the task requires.

Supabase explicitly recommends using its MCP server for development and testing rather than production data. Its security guidance also recommends project scoping, read-only mode, restricted feature groups, and manual approval of tool calls. Storage tools are disabled by default, but the other feature groups are enabled unless the URL narrows them.

Official Supabase MCP defaults to review

Option B: Connect Supabase PostgreSQL through datamcp

This route treats Supabase as a hosted PostgreSQL provider. Cursor receives database tools through a datamcp link; it does not receive Supabase project-management, Auth, Storage, Edge Function, or organization tools.

The setup path is:

Supabase Postgres → DataMCP connection → scoped MCP link → Cursor

Use this route when the goal is schema-aware SQL work and you want separate MCP policies or activity history around those queries.

Step 1: Get the correct Supabase connection string

Open your Supabase project and click Connect. Supabase currently offers several PostgreSQL connection modes:

• Direct connection at db.[project-ref].supabase.co:5432 for persistent clients that can reach the project's IPv6 endpoint, or projects with the relevant IPv4 option.
• Shared pooler, session mode at aws-[region].pooler.supabase.com:5432 for persistent clients connecting over IPv4.
• Shared pooler, transaction mode at aws-[region].pooler.supabase.com:6543 for temporary serverless or edge workloads.

For a hosted MCP service maintaining normal PostgreSQL sessions, start with the session pooler on port 5432 when direct IPv6 connectivity is unavailable. Supabase's database connection guide identifies session mode as the persistent-client alternative for IPv4 networks.

The session-pooler string looks like:

postgres://postgres.PROJECT_REF:YOUR_PASSWORD@aws-0-REGION.pooler.supabase.com:5432/postgres

Do not paste a Supabase publishable key, anon key, or service_role key into the PostgreSQL connection form. Those keys belong to Supabase APIs. datamcp needs PostgreSQL host, database, user, and password credentials.

Treat the complete connection string as a secret. Do not place it in Cursor, a prompt, a repository, or a screenshot.

Step 2: Create a restricted PostgreSQL role

For a quick development test, you can connect with the database credential Supabase provides. For a shared or sensitive environment, create a dedicated login instead of giving an MCP service the owner-level postgres role.

The exact grants depend on your schema. A minimal read-only example is:

create role cursor_mcp login password 'GENERATE_A_STRONG_UNIQUE_PASSWORD';

grant connect on database postgres to cursor_mcp;
grant usage on schema public to cursor_mcp;
grant select on all tables in schema public to cursor_mcp;

alter default privileges in schema public
grant select on tables to cursor_mcp;

Review this SQL before running it. If your tables live outside public, grant only the required schemas and tables. If future tables should not be exposed automatically, omit the default-privileges statement and grant access explicitly.

Supabase Row Level Security and direct PostgreSQL role grants are related but distinct controls. Do not assume the RLS behavior used by a frontend Supabase client will automatically produce the intended policy for a new direct database login. Test the effective role against representative tables before connecting Cursor.

Step 3: Add Supabase as a PostgreSQL connection

In the datamcp dashboard, create a new connection and choose PostgreSQL.

You can paste the full connection string or enter the fields individually:

• host: the direct or session-pooler hostname
• port: 5432
• database: usually postgres
• username: postgres.PROJECT_REF for the shared pooler, or your dedicated role where supported
• password: the matching database password
• SSL mode: choose a verified TLS mode supported by your Supabase connection

Validate the connection before saving it. datamcp reads the PostgreSQL schema and available database permissions from that connection. It does not connect to the Supabase Management API and does not receive access to the rest of the Supabase platform.

Step 4: Create a read-only MCP link

Open the connection and create an MCP link. For the first Cursor setup, choose Read Only.

datamcp currently supports:

• Read Only for schema inspection and SELECT
• Read & Write for data-changing operations without broad DDL
• Full Access for the operations available to the underlying database role
• Custom for table-specific operation policies

The effective permission is the intersection of the MCP link and PostgreSQL grants. A read-only database role remains read-only even if someone later selects a broader MCP preset. A read-only MCP link can further restrict a more capable database credential.

For production data, use both layers. Do not rely only on the prompt or Cursor's confirmation dialog.

Step 5: Create or select a datamcp API key

The Cursor configuration uses a datamcp API key to authenticate to the remote MCP endpoint. In the connection's setup guide, select an existing key. If none exists, create one from the dashboard's API Keys page and return to the setup guide.

Use a separate key for each person or automation when practical. That makes targeted rotation and investigation easier than sharing one key across an entire team.

The API key is not the Supabase password. Cursor receives the MCP credential while the PostgreSQL connection string stays on the datamcp side, encrypted at rest.

Step 6: Add the datamcp server to Cursor

For a project-specific server, create:

.cursor/mcp.json

For a global server available in every Cursor project, use:

~/.cursor/mcp.json

Add the configuration generated by the datamcp setup guide:

{
  "mcpServers": {
    "supabase-database": {
      "url": "https://api.datamcp.app/api/mcp/YOUR_CONNECTION_ID",
      "headers": {
        "Authorization": "Bearer YOUR_DATAMCP_API_KEY"
      }
    }
  }
}

Do not commit a real API key in a project configuration. Use a local ignored file or Cursor's supported secret-handling workflow for your environment.

Restart Cursor, then open Cursor Settings → Tools & MCP. Confirm that the server is connected and its database tools are visible.

Step 7: Test schema discovery before querying data

Start with a request that does not need sensitive rows:

Use the Supabase database MCP server to list the available schemas and summarize the tables in public. Do not run write operations.

Then inspect one table:

Show the columns, types, primary key, foreign keys, and indexes for public.orders.

Only after the schema looks correct should you test a bounded query:

Return at most five recent orders using only columns that do not contain customer contact or payment data.

Review the proposed tool call before approving it. Check the datamcp activity page afterward and confirm the query, status, execution time, row count, connection, and MCP link are attributable.

Which option should you choose?

Choose the official Supabase MCP server when

• Cursor needs migrations, advisors, service logs, Edge Functions, or generated types
• Supabase OAuth is the preferred identity boundary
• one project plus selected feature groups describes the required scope
• the environment is development or testing, as Supabase recommends

Choose datamcp when

• Cursor needs PostgreSQL schema and query tools rather than platform administration
• you want separate MCP links for multiple clients, users, or environments
• table-specific query permissions are required
• query activity and denied operations need to be reviewed in one dashboard
• you also use PostgreSQL outside Supabase and want the same connection model

Use neither against production until

• a dedicated non-owner role or equivalent database boundary exists
• the MCP access starts read-only
• sensitive tables are excluded or explicitly reviewed
• credentials can be revoked independently
• tool-call approval remains enabled where supported
• logs and an incident procedure have been tested

For the complete review, use the MCP security checklist for production databases. The PostgreSQL MCP server comparison helps evaluate hosted, provider-specific, local, and self-hosted alternatives before standardizing the connection model.

Troubleshooting

The official server shows more projects or tools than expected

Check the URL in .cursor/mcp.json. Add project_ref to scope one project, read_only=true to execute database queries through a read-only PostgreSQL user, and features to expose only the required tool groups. Reauthorize or restart Cursor after changing the server URL.

The direct Supabase hostname does not connect

The direct endpoint may require IPv6 unless the project has an IPv4 option. Copy the Shared Pooler → Session mode string from the Supabase Connect panel and use port 5432.

Password authentication failed

Confirm that the password belongs to the PostgreSQL user in the selected connection string. For the shared pooler, the username normally includes the project reference. Reset the database password in Supabase if necessary, then update the datamcp connection.

Cursor shows the server as disconnected

Validate the JSON, confirm the remote URL, verify that the Authorization value starts with Bearer , and check that the datamcp API key and MCP link are still active. Restart Cursor after changing mcp.json.

Cursor can see tools but a query is denied

That usually means either the MCP link or PostgreSQL role does not permit the operation. Treat the denial as a working control. Review the requested table and operation before expanding either permission layer.

New tables do not appear

Resync the datamcp connection schema after migrations. Then verify that the PostgreSQL role has permission to inspect and query the new tables.

Final setup checklist

• Choose official Supabase MCP for platform tools or datamcp for database-focused access
• Scope the server to one project or one PostgreSQL connection
• Use a development project or restricted database role
• Start read-only
• Keep the PostgreSQL password out of Cursor
• Keep real MCP API keys out of Git
• Verify tools in Cursor Settings
• Test schema discovery before row queries
• Review the first activity log
• Confirm that one link or key can be revoked independently

For the datamcp route, start with one free PostgreSQL connection and one MCP link, then follow the Cursor PostgreSQL integration for the current configuration flow.