claude-code - 💡(How to fix) Fix [BUG] Two HTTP MCP servers with identical URL but different headers — only one registers (silent dedup) [1 comments, 2 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

When .mcp.json declares two HTTP-type MCP server entries that point to the same url but use different headers (e.g. distinct Authorization bearer tokens for different tenants/projects of the same SaaS), only the first entry registers. The second silently disappears from the available servers list — no error, no warning, no entry in claude mcp list.

This blocks a legitimate and increasingly common pattern: multi-tenant SaaS APIs that expose a single MCP endpoint and discriminate by bearer token (e.g. Mem0 personal vs work projects, Pinecone projects, multiple GitHub orgs).

I hit this trying to use a plugin (claude-user-memory) that ships two Mem0 MCP instances:

{
  "mcpServers": {
    "mem0-personal": {
      "type": "http",
      "url": "https://mcp.mem0.ai/mcp",
      "headers": { "Authorization": "Bearer ${MEM0_PERSONAL_API_KEY}" }
    },
    "mem0-work": {
      "type": "http",
      "url": "https://mcp.mem0.ai/mcp",
      "headers": { "Authorization": "Bearer ${MEM0_WORK_API_KEY}" }
    }
  }
}

Only mem0-personal registered. mem0-work was missing entirely — no diagnostic indication that the entry had been seen at all.

What Should Happen?

Both server entries should register as independent MCP servers with their own auth contexts, regardless of whether their url happens to match. Server identity should be the entry key (mem0-personal / mem0-work), not the URL.

If for some reason the dedup-by-URL behaviour is intentional, it should at minimum log a warning: "Skipping duplicate HTTP MCP server mem0-work — same URL as mem0-personal" so plugin authors and users can diagnose what's happening.

Error Messages/Logs

(none — this is a silent failure)

Steps to Reproduce

1. Create a .mcp.json (project-level or via a plugin) with two HTTP-type MCP server entries pointing at the same url but with different headers values, e.g.:

   {
     "mcpServers": {
       "server-a": {
         "type": "http",
         "url": "https://example.com/mcp",
         "headers": { "Authorization": "Bearer token-a" }
       },
       "server-b": {
         "type": "http",
         "url": "https://example.com/mcp",
         "headers": { "Authorization": "Bearer token-b" }
       }
     }
   }

2. Start Claude Code in a directory where this .mcp.json is loaded.

3. Run claude mcp list (or check available tools).

4. Observed: only server-a is listed; server-b is silently absent.

5. Expected: both server-a and server-b are listed as separate servers.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.111

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Workaround: configure a single MCP entry and pass tenant/project scope as a parameter on every tool call. Works, but defeats the per-server isolation model — e.g. you lose the ability to namespace tools per tenant, scope OAuth flows separately, or have different auth headers picked up by different plugins.

Why filing now: this surfaced via the claude-user-memory plugin, where two mem0-* HTTP servers were defined identically except for their bearer tokens — a textbook case for the pattern. The plugin's docs even mention passing project_id per call as the official workaround, which suggests the author hit the same wall.

Affected scope (suspected): HTTP-type MCP servers only. stdio-type servers presumably aren't affected since their command lines naturally differ.