Multiple HTTP MCP servers with same URL but different headers — only one tenant loads after 3.12.17 / 3.12.30 restart

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I have five HTTP MCP servers configured in ~/.cursor/mcp.json. Two pairs share the same gateway URL but target different Jira/Confluence tenants via HTTP headers (a standard multi-tenant gateway pattern):

Server key URL Tenant differentiation
mcp-tenant-a-jira https://mcp-gateway.example.com/jira/mcp Jira-Domain: https://tenant-a.jira.example.com/
mcp-tenant-b-jira same URL default tenant B (no Jira-Domain header)
mcp-tenant-a-confluence https://mcp-gateway.example.com/confluence/mcp Confluence-Domain: https://tenant-a.confluence.example.com/
mcp-tenant-b-confluence same URL default tenant B
mcp-tenant-b-bitbucket https://mcp-gateway.example.com/bitbucket/mcp unique URL (always loads)

Before upgrade (2026-07-23 ~08:59): all five servers started and connected.

After upgrade to 3.12.30 (2026-07-23 ~09:43): only three servers started — all tenant B entries (mcp-tenant-b-jira, mcp-tenant-b-bitbucket, mcp-tenant-b-confluence). The two tenant A entries (mcp-tenant-a-jira, mcp-tenant-a-confluence) remained in mcp.json but were never passed to createClient and never appeared in the agent’s available MCP server list.

The failure is silent: no error in Settings, no warning that servers were skipped. Settings → MCP now opens mcp.json directly, so there is no separate UI to re-enable dropped servers.

Whichever server “wins” for a given URL appears to be the one listed first in config for that URL (tenant B Jira beat tenant A Jira; tenant B Confluence beat tenant A Confluence).

Tag: mcp

Steps to Reproduce

Steps to reproduce

  1. Configure two or more HTTP MCP entries in ~/.cursor/mcp.json with the same url but different headers (e.g. different Jira-Domain values routing to different backends through a shared gateway).
  2. Ensure both entries have unique keys under mcpServers (e.g. mcp-tenant-a-jira and mcp-tenant-b-jira).
  3. Restart Cursor 3.12.17 or later (reproduced on 3.12.30).
  4. Open Settings → Tools & MCP or inspect MCP logs (workbench.mcp.files.log).
  5. Observe that only one entry per duplicate URL is started; the others are silently ignored.

Minimal repro config (tokens redacted)

{
  "mcpServers": {
    "mcp-tenant-a-jira": {
      "url": "https://mcp-gateway.example.com/jira/mcp",
      "type": "streamable-http",
      "headers": {
        "Jira-Token": "<TOKEN_A>",
        "Jira-Domain": "https://tenant-a.jira.example.com/"
      }
    },
    "mcp-tenant-b-jira": {
      "url": "https://mcp-gateway.example.com/jira/mcp",
      "type": "streamable-http",
      "headers": {
        "Jira-Token": "<TOKEN_B>"
      }
    }
  }
}


### Expected Behavior
- All entries in `mcpServers` should be started as **separate MCP clients**, keyed by their **server name** (config key), not deduplicated by URL alone.
- HTTP headers are part of the connection identity; two entries with the same URL but different headers should connect to different logical backends.
- This worked correctly before the MCP settings overhaul (confirmed in logs from the same machine, same `mcp.json`, earlier the same day).



### Operating System
Windows 10/11

### Version Information
Version: 3.12.30 (user setup)
VS Code Extension API: 1.128.0
Commit: 63a2996a10d9e476b6c28e951dd7691d9c0cf480
Date: 2026-07-21T22:50:03.568Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.26200





### Additional Information
- Only one server per unique URL is started.
- Additional entries with the same URL are silently dropped from the runtime server list.
- Agent `call_mcp_tool` cannot reach the dropped servers (server identifier not registered).
- Workaround: remove the "winning" entry from `mcp.json` so the other tenant can load — but then the first tenant is unavailable. Cannot run both tenants simultaneously.

### Does this stop you from using Cursor
No - Cursor works, but with this issue
6

Hey Jason!

This is a bug on our side, not your config. A recent change to how Cursor loads MCP servers started grouping HTTP (streamable-http) servers by their URL alone, so two entries that share a url and differ only by headers collapse into one, and only the first entry for that URL starts. The rest stay in mcp.json but are silently skipped, exactly as you described. This is a known regression we’re already tracking, and you’re not the only one who’s hit it with a multi-tenant gateway setup.

Workaround to get all of them loading: add a unique, harmless query parameter to each same-URL entry so Cursor treats them as distinct servers. For your Jira pair, for example:

"mcp-tenant-a-jira": {
"url": "https://mcp-gateway.example.com/jira/mcp?tenant=a",
"type": "streamable-http",
"headers": { "Jira-Token": "<TOKEN_A>", "Jira-Domain": "https://tenant-a.jira.example.com/" }
},
"mcp-tenant-b-jira": {
"url": "https://mcp-gateway.example.com/jira/mcp?tenant=b",
"type": "streamable-http",
"headers": { "Jira-Token": "<TOKEN_B>" }
}

Do the same for the Confluence pair (?tenant=a / ?tenant=b). The query string is part of what Cursor keys on, so each entry lands in its own bucket and all of them start. Your gateway still routes by the headers exactly as before and can safely ignore the extra query param. One caveat: if your team uses an MCP allowlist, make sure the allowlisted URLs include the query-string versions.

I’ll update this thread once there’s progress on the underlying fix. If the query-param trick behaves oddly against your gateway, reply here and I’ll dig in.

More on MCP config: MCP docs