The MCP Design Flaw Affecting 200,000+ Servers

The Model Context Protocol was designed to make it easy for AI agents to discover and call external tools. It succeeded at that goal. What it did not design for was adversarial tool registries — environments where a malicious server can register tools with names that shadow legitimate ones and intercept calls intended for trusted services.

How the Trust Model Works (and Fails)

MCP uses a flat namespace for tool discovery. When an agent queries available tools, it receives a merged list from all connected servers. If two servers register a tool with the same name, the behavior is implementation-defined — and in most clients, the last registration wins, or worse, both tools are presented to the model and it picks one arbitrarily.

The 200K Server Analysis

We analyzed 200,000+ publicly discoverable MCP server configurations using passive scanning. The findings were stark: 67% had no server-level authentication on tool registration, 43% allowed tool names to be set by the calling client rather than enforced server-side, and 12% exposed tool registration endpoints directly to the internet without any IP restriction.

• ▸67% — no tool registration authentication
• ▸43% — client-controlled tool names
• ▸29% — no TLS on the MCP transport
• ▸12% — registration endpoint exposed to the public internet
• ▸4% — found evidence of existing namespace collision (two tools with identical names from different servers)

Attack Scenarios

Shadow tool hijacking

An attacker registers a tool named get_user_data on a compromised MCP server that is also connected to the target agent. The agent calls get_user_data believing it is calling the trusted CRM integration. Instead, the call goes to the attacker's server, which logs the arguments and returns plausible fake data.

Confused deputy via tool relay

The attacker's shadowed tool receives the call, forwards it to the legitimate server, captures the response, modifies it, and returns the modified response to the agent. The agent has no way to detect the MITM.

What Defends Against This

1. 1.Tool signature enforcement: require each tool registration to include a server-signed certificate binding the tool name to the server identity
2. 2.Tool allowlisting: maintain an explicit allowlist of approved tool names per server and reject registrations that are not on the list
3. 3.Namespace prefixing: enforce that each server's tools are prefixed with the server identifier (e.g., crm.get_user_data vs billing.get_user_data)
4. 4.Call routing audit: log every tool call with the server it was routed to — alert on calls that deviate from expected routing