Two MCP Servers, One Tool Name: What Actually Happens to Your Bot's Call?

The problem: MCP has no global tool namespace

MCP defines tools per server, not across your whole bot's toolbox. The specification states that each tool is uniquely identified by a name within that server's own list, and it recommends names stay unique within a server. Nothing in the protocol stops two independent servers from both naming a tool search, create_event, or send_message.

That matters the moment your bot connects to more than one MCP server at a time, which is normal for a small-team setup: a calendar server plus a CRM server plus a local filesystem server, all feeding tools into the same agent loop. If two of them happen to expose the same tool name, the protocol does not pick a winner for you.

Sources: Tools - Model Context Protocol.

What the current spec actually says

The current MCP specification is explicit that this is a known edge case, not an oversight to be fixed later. It states that tool name uniqueness is scoped to a single server, and that clients or proxies which aggregate tools from multiple servers may encounter naming collisions and should implement a disambiguation strategy such as prefixing tool names with a server identifier.

The spec also closes off an obvious workaround: don't use the server's declared name to tell two servers apart. It warns that the server name from serverInfo is not guaranteed to be unique across servers and should not be relied upon for disambiguation. In practice, two unrelated servers can report the identical serverInfo.name, which breaks any disambiguation scheme built on that field alone.

Sources: Tools - Model Context Protocol.

Worked example: two calendar-adjacent servers, one name

Illustrative case. Say your bot connects to a company scheduling MCP server and a personal Google Calendar MCP server, both chosen independently by different team members. Both happen to name their write tool create_event with nearly identical input schemas — a title, a start time, an end time.

If your host (the application hosting the MCP client, such as an IDE or an agent runtime) does not namespace tool names, you now have two tools fighting for one name in the list the model sees. Depending on the host's implementation, one of three things happens: the second registration silently overwrites the first, the host rejects the whole tool list with a duplicate-name error, or the host appends an unstable disambiguator that changes between restarts. None of these are a protocol-level guarantee — they are host-specific choices, because the spec leaves the decision to the client.

Failure paths you should actually check for

Three concrete failure modes show up in practice, and each has a different blast radius for your bot.

Silent overwrite: the host's tool registry is a simple map keyed by name, so the second server's tool definition replaces the first. Your bot thinks it's calling the scheduling server's create_event but the call actually routes to the Google Calendar server, or vice versa, with no error at all. This is the most dangerous case because nothing visibly breaks.

Hard rejection: some hosts validate the merged tool list before sending it to the model and refuse to proceed if two names collide, so every request fails until you disable one of the servers. Noisy, but at least it fails loud.

Unstable disambiguation: a host appends a generated suffix to one of the colliding names on each reload, with no config-readable mapping back to which server owns which suffix. Your bot's tool choice may work one session and silently point at the wrong server the next, because the suffix assignment is not guaranteed to stay fixed across restarts.

What to actually do before connecting two servers

Check whether your host supports explicit server-prefixed tool names, and turn that setting on deliberately rather than hoping default behavior is safe. The OpenAI Agents SDK, for example, exposes an include_server_in_tool_names option on MCP server configuration: when enabled, each local MCP tool is exposed to the model with a deterministic server-prefixed name, which helps avoid collisions when multiple MCP servers publish tools with the same name. The SDK still calls the original tool name on the original server underneath the prefix, so this is purely a routing fix, not a renaming of the underlying tool.

Note that this prefixing is opt-in, not the default. If your host doesn't offer an equivalent switch, you have two fallback options: rename or wrap one of the conflicting tools yourself before it reaches the model (for example, running a thin proxy that renames create_event to calendar_create_event for one server), or simply avoid connecting both servers' write tools to the same bot at once. For a small team, the second option is often the pragmatic one — connect only the servers whose tool names you've actually checked for overlap, and re-check whenever you add a new server to an existing bot.

The underlying decision is this: never assume MCP itself will keep two servers' tools apart. Confirm your host's disambiguation behavior once, in a test connection with both servers live, before you let the bot run the combination unattended.

Sources: Model context protocol (MCP) - OpenAI Agents SDK.