Support for multiple instances of the same MCP

Bug Reports
1

Describe the Bug

Environment collision when adding 2 or more instances of the same MCP server with different configs

See example: cursor correctly sees 2 mcp servers, but when interacting with them, they actually connect to the same clickhouse machine (both connect to HOST_A)

I suspect this is not a clickouse bug, but rather a bug in how cursor spins up multiple instances of MCP clients

Steps to Reproduce

Add these to your config:

// mcp.json
{
  "mcpServers": {
    "mcp-clickhouse-A": {
      "comment": "Clickhouse MCP server for the A region",
      "command": "uv",
      "args": [ "run", "--with", "mcp-clickhouse", "--python", "3.13", "mcp-clickhouse"
      ],
      "env": {
        "CLICKHOUSE_HOST": "<HOST_A>",
        "CLICKHOUSE_PORT": "<PORT_A>",
        "CLICKHOUSE_USER": "<USER_A>",
        "CLICKHOUSE_PASSWORD": "<PASSWORD_A>"
      }
    },
    "mcp-clickhouse-B": {
      "comment": "Clickhouse MCP server for the B region",
      "command": "uv",
      "args": [ "run", "--with", "mcp-clickhouse", "--python", "3.13", "mcp-clickhouse"
      ],
      "env": {
        "CLICKHOUSE_HOST": "<HOST_B>",
        "CLICKHOUSE_PORT": "<PORT_B>",
        "CLICKHOUSE_USER": "<USER_B>",
        "CLICKHOUSE_PASSWORD": "<PASSWORD_B>"
      }
    }
  }
}

Expected Behavior

I expect mcp-clickhouse-A and mcp-clickhouse-B to connect to different servers

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.1.5
VSCode Version: 1.96.2
Commit: ef5eeb47a684b4c217dfaf0463aa7ea952f8ab90
Date: 2025-06-21T05:23:57.743Z (4 days ago)
Electron: 34.5.1
Chromium: 132.0.6834.210
Node.js: 20.19.0
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.5.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

1 Like
2

ping (keepalive)

3

I wasted a lot of time on this today trying to get cursor to connect to a couple of different databases with the same base MCP but different arguments and naming. Modified the MCP itself to be as unique as possible but no dice. Claude Desktop works perfectly with the same setup but cursor always run whichever MCP was defined first. This is with cursor 1.3.5 too.

4

I figured out the problem. I suppose this must impact all cursor versions to date. Cursor must internally route MCP tool calls based on just the tool name, if more than one MCP server uses the same tool name, it will only ever route it to the first MCP server that provides that tool name, no matter how the MCP server is defined. I resolved the issue myself with a workaround - have the MCP generate unique tool names based on the db it connects to. Would be much nicer if cursor was more granular in routing tool calls.

6

hey Mark, could you please share a code example of your workaround?

7

Hi ddobrinskiy.

What it took was modifying the MCP itself so each instance that is created has unique tool names. Essentially I appended an unique identifier onto the end of each tool name e.g.
execute_query → execute_query_srv1
etc. then cursor when instructed will use the correct MCP rather than the first one that registered execute_query.
It worked okay for me but it’s obviously a pain to have to modify the MCP because of the way cursor routes tool calls.

-Mark