MCP Tool Routing Has a Security Problem Nobody Is Talking About

rogueparticle1 pts0 comments

The Hidden Flaws of MCP Routing (And Why We Need to Talk About Them) | by Will Jh | May, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

Press enter or click to view image in full size

Connected to everything. Accountable to nothingThe Hidden Flaws of MCP Routing (And Why We Need to Talk About Them)

Will Jh

2 min read·<br>Just now

Listen

Share

The Model Context Protocol (MCP) is revolutionizing how AI agents interact with the world. But are we ignoring a massive enterprise security gap?<br>If you are building AI agents right now, you are probably incredibly excited by MCP. Being able to plug an agent into HubSpot, Stripe, GitHub, and Slack through a unified protocol feels like magic.<br>But as we scale agentic workflows, we hit a wall.<br>The default method for routing tasks in MCP relies almost entirely on the LLM’s internal probabilistic reasoning. The model looks at a giant list of available tools, guesses which one best fits the user’s intent, and executes it. While this works in isolated local sandboxes, deploying this approach in complex, multi-server enterprise environments exposes serious system-level vulnerabilities.<br>Here are the four major issues keeping me up at night:<br>1. The Context Tax Every time your agent needs to make a decision, it must load every available tool schema first. With 100 MCP connectors, you are burning thousands of tokens on every single request before the agent does any useful work. At scale, this latency and cost become unmanageable.<br>2. Tool Identity Ambiguity and Misbinding MCP clients currently resolve tools based on non-unique names and text descriptions, with no cryptographic identity validation. This creates a serious vulnerability: if a legitimate server and a malicious server both advertise a tool with the same name (e.g., payments.authorize), the orchestrator can be tricked into executing the attacker's version. Wrong-provider tool execution is not a theoretical risk — it is an architectural gap.<br>3. Slash Command Overlap In multi-tool environments, several tools frequently define identical or misleadingly similar slash commands. Without strict disambiguation protocols, the LLM can confuse commands and trigger destructive actions on the wrong platform — deleting production logs instead of temp files, for example.<br>4. The Compositional Attack Surface Most routing architectures only enforce per-invocation safety, checking whether a single tool call is authorized. But individually-authorized, policy-compliant tools can be chained together into harmful emergent behaviors — data exfiltration, financial manipulation, privilege escalation. No per-tool constraint catches this. The danger lives in the sequence, not the individual step.<br>Over to You<br>I am writing this because I believe we need to stop treating tool selection as a text prediction problem and start treating it as an access control decision.<br>Are you deploying MCP at scale? How are you handling schema bloat across dozens of connectors? Have you encountered silent failures, wrong-provider executions, or prompt injections routing your agent to the wrong tool?<br>I’d genuinely like to know — because I think this conversation is overdue.

Artificial Intelligence

Cybersecurity

Technology

Software Development

Written by Will Jh<br>0 followers<br>·1 following

Help

Status

About

Careers

Press

Blog

Privacy

Rules

Terms

Text to speech

tool routing agent tools wrong sign

Related Articles