MCP Tools Name Collision Causing Cross-Service Tool Call Failures

Bug Reports
1

MCP Tools Name Collision Causing Cross-Service Tool Call Failures

Forum Checked

:backhand_index_pointing_down:I’ve reviewed related issues and found a similar problem : :backhand_index_pointing_down:
MCP servers: Conflict Between Cursor’s edit_file and Filesystem MCP Server
, but my issue specifically concerns tool name collisions between different MCP servers.

Bug Description

When configuring multiple MCP servers (such as GitHub and Obsidian), tools with identical function names create conflicts. Specifically: when attempting to use the get_file_contents tool, the system incorrectly routes to the GitHub tool, requesting a missing owner parameter (required for GitHub’s tool but not for Obsidian’s).

Steps to Reproduce

  1. Configure GitHub MCP server
  2. Configure Obsidian MCP server
  3. In an AI conversation, attempt to use the get_file_contents tool
  4. Receive error: “Error calling tool: Required parameter ‘owner’ is missing for tool get_file_contents”

Error Message

When trying to call the Obsidian file contents tool, the error message indicates the system is attempting to use GitHub’s version instead, as it requests the “owner” parameter specific to GitHub’s implementation.

System Information

  • Operating System: macOS 15.1.1
  • Cursor Version: 0.48.2

Impact

This issue severely hampers the ability to use multiple MCP servers, especially in development scenarios where handling multiple resource types (such as GitHub code and Obsidian notes) simultaneously is necessary. Currently, the only workaround is to abandon using one of the MCP servers.

Suggested Solution :yellow_heart:

Implement namespace isolation mechanisms, such as:

  1. Enforcing tool name prefixes (e.g., github-get_file_contents, obsidian-get_file_contents)
  2. Implementing backend namespace routing based on the prefix mcpName-mcp_servicename
  3. Allowing users to “define tool aliases to avoid conflicts” or “edit(or select) tool command like AI calling terminal and user can edit the command”. :smiling_face_with_three_hearts:
2

yes，Mcp servers: Conflict Between Cursor's `edit_file` and Filesystem MCP Server in Composer Agent Mode

This is the issue I raised before, and the solution I adopted directly is to declare it using the exact method in the rules.

1 Like
3

(post deleted by author)

1 Like
4

This is a big issue in Cursor’s MCP Client implementation, IMO. The MCP spec basically leaves it up to client to disambiguate between two tools with the same name (it doesn’t specify how, but the most obvious conceptual solution would be for the client to namespace tool names under the name of the server (as per the mcp config json)).

But Cursor doesn’t do this at all: so if you want to use two different MCP servers that both expose a tool called “query” or “list_tables” or “fetch” or whatever, the Cursor agent currently can’t handle it - and it’s a really common use case!