The MCP Composability Trap: When 'Just Add Another Server' Becomes Dependency Hell

The MCP ecosystem has 10,000+ servers and 97 million SDK downloads. It also has 30 CVEs filed in sixty days, 502 server configurations with unpinned versions, and a supply chain attack that BCC'd every outgoing email to an attacker for fifteen versions before anyone noticed. The composability promise — "just plug in another MCP server" — is real. But so is the dependency sprawl it creates, and most teams discover the cost after they're already deep in integration debt.

If you've built production systems on npm, you've seen this movie before. The MCP ecosystem is speedrunning the same plot, except the packages have shell access to your machine and credentials to your production systems.

The npm Parallel Is Not a Metaphor

When people compare MCP's ecosystem growth to early npm, they usually mean it as a compliment — rapid adoption, vibrant community, composable building blocks. But the parallel extends to the failure modes too, and the failure modes are worse.

A scan of 42,000+ MCP tools across seven registries found patterns that mirror npm's worst supply chain incidents. The numbers paint a specific picture:

• 502 configurations use npx without version pinning, pulling whatever is latest on every agent startup
• 1,050 configurations point to remote URLs with no certificate pinning or authentication
• 448 configurations enable auto-install flags that skip user confirmation before executing code
• 467 tools reference mutable GitHub raw URLs that change when branches update
• 1,679 tools include embedded pip commands; 742 include system package managers

The critical difference from npm: npm packages run in a sandbox. MCP servers execute with full machine access — your filesystem, your shell, your credentials. When the event-stream attack hit npm in 2018, one compromised maintainer reached millions of downloads. The blast radius was limited by the browser sandbox. MCP has no equivalent containment.

The postmark-mcp attack in early 2026 demonstrated this perfectly. The attacker built trust over fifteen normal-looking versions before adding code that BCC'd every outgoing email to an external address. Because the MCP server had legitimate email-sending permissions, the malicious behavior was indistinguishable from normal operation at the tool-call level.

The Trust Model Is Broken by Default

Most MCP clients implement Trust On First Use (TOFU). You approve a server once during initial setup, and subsequent updates go unverified. This creates a window where approved servers can be silently compromised — and it's the exact window attackers target.

The problem compounds at scale. Server references live in JSON config files, often checked into repositories or shared across teams. A typical agent configuration might reference eight to twelve MCP servers, each with its own version (or lack thereof), credentials, and trust assumptions. Here's what breaks:

• Silent updates: Without version pinning, your agent's capabilities change every time it restarts. A server that worked yesterday might expose different tools today, or the same tool might behave differently.
• Credential sprawl: 88% of MCP servers require credentials, but 53% rely on long-lived static secrets passed as environment variables. When you're running ten servers, that's ten sets of credentials with no centralized revocation.
• Inherited permissions: The MCP spec doesn't include authorization. Every server inherits whatever permissions it's granted, and every request flows through without verification unless you add external controls.

Between January and February 2026, researchers filed over 30 CVEs targeting MCP infrastructure. The vulnerabilities ranged from trivial path traversals to a CVSS 9.6 remote code execution flaw in a package downloaded nearly half a million times. The root causes were consistent: missing input validation, absent authentication, and blind trust in tool descriptions.

Tool Conflicts at Scale: The Discovery Problem

The composability promise assumes that adding servers is additive — more servers means more capabilities. In practice, combining MCP servers creates conflicts that are invisible until they cause failures.

The most immediate problem is tool naming. When two servers expose tools with the same name, the agent has to pick one, and the resolution strategy varies by client. Some take the last-registered server. Some error. Some silently shadow one tool with another. None of these outcomes is correct when you didn't expect the conflict.

Namespacing — prefixing tools like calendar.list_events and slack.search_messages — solves the syntactic collision. But semantic conflicts are harder. Two different MCP servers might both offer a send_email tool with different parameter schemas, different authentication contexts, and different side effects. The agent sees two tools that do roughly the same thing and has to choose based on descriptions alone.

This gets worse as tool counts grow. Research on tool selection accuracy shows that agent performance degrades as tool inventories scale — what works cleanly with four tools becomes unreliable at fifty. Each MCP server you add isn't just adding capabilities; it's expanding the decision space the agent navigates on every turn.

MCP's capability negotiation — the initialization handshake where client and server declare supported features — handles protocol-level compatibility. It doesn't handle semantic compatibility between tools from different servers that operate on the same domain. That gap is left entirely to the agent's reasoning, which means it's left to chance.

Loading…