Bug: Multiple (Supabase) MCP servers route all calls to first configured instance

[Mann1ng]

Environment

• Cursor Version: [Latest as of Oct 9, 2025]
• MCP Server: @supabase/mcp-server-supabase@latest
• OS: Windows 10 (26100)

Description

When multiple instances of @supabase/mcp-server-supabase are configured in mcp.json with different project references, all MCP tool calls are routed to the first configured server regardless of the tool prefix used in the function call.

Up till recently it seemed that Cursor was able to see both mcp configurations and intelligently determine which supabase project it wanted to operate on. Now it seems 'blind' to successive configurations. (Hopefully that makes some sense)

Configuration

{
  "mcpServers": {
    "my_supabase_project_a": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "@supabase/mcp-server-supabase@latest",
        "--project-ref=aaaaaaaaaaaaaaaaaaaaaa"
      ],
      "env": {
        "SUPABASE_ACCESS_TOKEN": "sbp_..."
      }
    },
    "my_supabase_project_b": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "@supabase/mcp-server-supabase@latest",
        "--project-ref=bbbbbbbbbbbbbbbbbbbbbb"
      ],
      "env": {
        "SUPABASE_ACCESS_TOKEN": "sbp_..."
      }
    }
  }
}

Expected Behavior

• Calling mcp_my_supabase_project_a_execute_sql() should route to project aaaaaaaaaaaaaaaaaaaaaa
• Calling mcp_my_supabase_project_b_execute_sql() should route to project bbbbbbbbbbbbbbbbbbbbbb

Actual Behavior

• Both mcp_my_supabase_project_a_execute_sql() and mcp_my_supabase_project_b_execute_sql() route to project aaaaaaaaaaaaaaaaaaaaaa (the first configured instance)

Reproduction Steps

1. Configure two Supabase MCP server instances with different project-ref values in mcp.json
2. Call mcp_my_supabase_project_b_get_project_url() to verify connection
3. Observe that it returns the URL for the first configured project (aaaaaaaaaaaaaaaaaaaaaa) instead of the second project (bbbbbbbbbbbbbbbbbbbbbb)
4. Execute SQL queries via mcp_my_supabase_project_b_execute_sql() and confirm they target the wrong database by querying pg_namespace or database-specific tables

Verification

// Called: mcp_my_supabase_project_b_get_project_url()
// Expected: "https://bbbbbbbbbbbbbbbbbbbbbb.supabase.co"
// Actual: "https://aaaaaaaaaaaaaaaaaaaaaa.supabase.co"

// Called: mcp_my_supabase_project_b_execute_sql("SELECT schema_name FROM information_schema.schemata")
// Expected: Returns schemas from project-B (includes 'schema_b')
// Actual: Returns schemas from project-A (includes 'schema_a' only)

Impact

• Severity: High - This makes it impossible to work with multiple Supabase projects via MCP
• Use Case: Multi-service architectures (e.g., separate databases for different services)
• Workaround: None identified - must manually switch MCP config and restart

Additional Context

The MCP tool prefix (mcp_my_supabase_project_b_* vs mcp_my_supabase_project_a_*) correctly distinguishes the intended server in the function name, but the routing mechanism appears to ignore this and defaults to the first configured server in mcp.json.

This appears to be a regression or limitation in how Cursor's MCP router handles multiple instances of the same MCP server type with different configurations.

[husgzushu]

+1 Confirmed - Same Issue with dbhub MCP Server

I can confirm this is a widespread Cursor bug affecting multiple MCP server types, not just Supabase.

My Environment

• Cursor Version: Latest (October 2025)
• MCP Server: @bytebase/[email protected]
• OS: Windows 10 (Build 10.0.26100)
• Node.js: v20.18.3

Same Exact Behavior

When configuring multiple dbhub instances for different databases (MySQL + 2 SQL Servers), all instances connect to the first configured database:

{
  "mcpServers": {
    "mysql-lin2web_cms": {
      "command": "dbhub",
      "args": ["--dsn", "mysql://...lin2web_cms", ...]
    },
    "sqlserver_lin2db": {
      "command": "dbhub",
      "args": ["--dsn", "sqlserver://...lin2db", ...]
    },
    "sqlserver_lin2world": {
      "command": "dbhub",
      "args": ["--dsn", "sqlserver://...lin2world", ...]
    }
  }
}

Result: All three tools connect to lin2web_cms instead of their configured databases.

Extensive Troubleshooting (All Failed)

We tried 8 different workarounds, all failed:

1. ❌ Different wrapper batch files with unique env vars
2. ❌ Different working directories (cwd)
3. ❌ Different environment variables (MCP_SERVER_NAME, DBHUB_INSTANCE)
4. ❌ Different DSN query parameters (unique identifiers)
5. ❌ Different command launch methods (dbhub vs npx vs node)
6. ❌ Different server names in mcp.json
7. ❌ Completely independent dbhub copies (different package.json names, separate node_modules, different file paths)
8. ❌ Mixed transport protocols (stdio + SSE/HTTP)

Critical Evidence

🎯 The same mcp.json configuration works perfectly in Claude Desktop!

This proves:

• ✅ MCP protocol supports multi-instance configuration
• ✅ dbhub/Supabase MCP servers work correctly
• ❌ The bug is specifically in Cursor's MCP client implementation

When running dbhub from command line, it connects to the correct database every time.

Root Cause Hypothesis

Cursor appears to:

1. Cache or reuse the first MCP connection
2. Share state/connection pools between MCP instances
3. Fail to distinguish multiple instances of the same MCP server type

Impact

This makes it impossible to work with multiple databases/projects via MCP in Cursor, which is critical for:

• Microservices (multiple databases)
• Multi-tenant systems
• Data migration projects
• Any scenario requiring multiple database connections

Related Resources

• dbhub GitHub Issue: https://github.com/bytebase/dbhub/issues/101
• Detailed troubleshooting: Available upon request

---

This appears to be a critical bug in Cursor's MCP routing/instance management that affects all MCP servers, not just Supabase. Would greatly appreciate if the Cursor team can prioritize this! 🙏

[SammYWin]

Same issue! Please fix it!

[SammYWin]

Can you please report the same thing here? Maybe there is more chance devs will see this https://forum.cursor.com/c/bug-report/6

[mahavita12]

Annual subscriber here- this issue makes Cursor pretty much useless for my plugin development. This is a high-severity issue preventing legitimate multi-environment workflows. Please prioritize a fix.

Comment Template:

Experiencing the Same Issue with Moodle MCP Servers

I can confirm this bug affects all MCP server types, not just Supabase.

My Configuration

• Cursor Version: [Check Help > About in Cursor]
• OS: Windows 11
• MCP Servers: Custom Moodle MCP servers (3 instances: local, staging, production)

Configuration (mcp.json)

{
  "mcpServers": {
    "zzz-local-moodle": {
      "command": "python",
      "args": ["C:/MCP_servers/moodle_mcp_server/moodle_mcp_server.py"]
    },
    "growminds-staging": {
      "command": "C:/Windows/System32/OpenSSH/ssh.exe",
      "args": ["-i", "C:/Users/[user]/.ssh/id_key", "user@host", "cd /path/to/staging && exec python3 -u moodle_staging_mcp.py"]
    },
    "growminds-production": {
      "command": "C:/Windows/System32/OpenSSH/ssh.exe",
      "args": ["-i", "C:/Users/[user]/.ssh/id_key", "user@host", "cd /path/to/production && exec python3 -u moodle_production_mcp.py"]
    }
  }
}
Observed Behavior
When using @growminds-staging execute_sql, Cursor always routes to the first configured server (zzz-local-moodle), ignoring the @ mention completely. Verification:
Direct SSH query to staging: Returns database srfshmcmyg with 582 config rows
Cursor query using @growminds-staging: Returns database moodle with 580 config rows (local DB)
MCP logs confirm: execute_sql tool calls go to zzz-local-moodle even when @growminds-staging is specified
Impact
This makes Cursor completely unusable for multi-environment development. I have an annual Cursor subscription but cannot query staging/production databases without manually disabling servers and restarting. Note: The same mcp.json configuration works perfectly in Claude Desktop, confirming this is a Cursor-specific bug.
Request
This is a high-severity issue preventing legitimate multi-environment workflows. Please prioritize a fix.

[camborambo]

I am running into the same issue with both hosted and CI. Very challenging when working on a project that pulls in from different project sets. Please fix this issue.