Called It: MCP Security Is Already Falling Apart 🔓

So that didn't take long.

Oligo Security just dropped a critical RCE vulnerability in MCP Inspector - CVSS 9.4. The attack is beautifully simple: visit a dodgy website while running the inspector, attacker gets code execution on your machine. DNS rebinding chained with CSRF. Classic web attack vector, brand new attack surface.

I wrote about exactly this back in May, covering tool poisoning, rug pulls, shadowing attacks, the full catalogue. Took about six weeks for the first real CVE to land. Not exactly chuffed about being right on this one, but the IDE extension exploits surfacing the same week just prove the point.

---

The Bigger Problem: MCP Is Solving Something That Doesn't Need Solving 🧱

The security holes are bad. But honestly? They're a symptom of a deeper problem.

Here's my spicy take: MCP is the EAI bloat of the AI era.

We already have curl. We have native APIs. We have CLIs. Every provider already exposes their functionality through well-documented, battle-tested interfaces. MCP is middleware nobody asked for, wedged between the provider and the consumer, bringing along an entirely new aggregated auth problem and unnecessary logic creeping into layers where it has no business being.

If you've been around long enough to remember Enterprise Application Integration - the SOAP gateways, the ESBs, the message brokers that were supposed to unify everything and instead created a new class of problems - this should feel familiar. Same pitch. Same trajectory. Different decade.

📚 Geek Corner

The EAI parallel: Enterprise Application Integration promised universal interoperability through middleware. What it delivered: XML hell, schema sprawl, vendor lock-in, and an entire industry of consultants debugging message transformations. MCP is walking the same path - a protocol layer between AI agents and tools that duplicates what HTTP APIs, CLIs, and native SDKs already provide, while introducing new failure modes and security surfaces.

---

Context Windows Are Gold. MCP Is Kryptonite. 💎

This is the part that really gets me.

The Playwright MCP server loads 12.8k tokens just by existing in your context window. Not using it. Not running a single browser command. Just loading the tool definitions.

Write a Python class skeleton with all the same browser automation functions? About 1k tokens. Dynamic scripts generated from that cost basically nothing in additional context.

That's a 13x overhead for the privilege of running through a protocol layer.

Context is going to be the gold of building good AI-assisted software. Every token in your context window is a trade-off - that's a token that could hold actual code, actual documentation, actual reasoning. And MCP is hoovering up thousands of tokens on JSON tool schemas before you've even asked it to do anything.

# MCP Playwright: ~12,800 tokens just loaded
# Your tools: navigate, click, fill, screenshot, evaluate...
# All described in verbose JSON schemas
# None of them doing anything yet

# Python wrapper: ~1,000 tokens total
class Browser:
    def navigate(self, url): ...
    def click(self, selector): ...
    def fill(self, selector, value): ...
    def screenshot(self, path): ...
    def evaluate(self, js): ...
# Dynamic scripts from here cost nothing extra

When context window size determines how much of your codebase an AI agent can reason about, burning 12k tokens on tool definitions is like paying rent on an office you never visit.

📚 Geek Corner

The context tax math: MCP tool definitions get injected as JSON schemas - name, description, parameter types, examples, per tool. Playwright MCP has dozens of tools. At ~12.8k tokens, that's roughly 10% of a 128k context window gone before any work starts. In a 200k window, it's still 6.4%. Scale that across multiple MCP servers and you're losing a quarter of your reasoning capacity to protocol overhead. A lightweight native wrapper achieves the same functionality at 1/13th the context cost.

---

Where The Smart Money Is Going Instead 💰

Ben Tossell ran a piece this week on investing in AI devtools - "bundling productivity is the new game."

He's spot on. The standalone AI tool market is already getting crowded - everyone and their nan has a coding assistant. The winners will be the ones that bundle: code + tests + deployment + monitoring in one agentic flow. Not twenty MCP servers duct-taped together.

The irony is thick: the MCP ecosystem is unbundling by design - separate servers for everything, each burning context tokens, each with its own auth surface. Meanwhile the market is clearly moving toward bundling - integrated tools that do more with less overhead.

Whether that's Claude Code eating the terminal, Cursor eating the IDE, or something we haven't seen yet - the future is native integrations, not protocol middleware.

---

Bottom line: Mark my words, MCP will go the way of SOAP, ESBs, and every middleware layer that promised interoperability and delivered complexity. The tools that win will be the ones that talk directly to what they need, not through yet another abstraction layer burning your context window for the privilege. For a deeper look at the architecture itself and where I reckon the real gaps are, see the MCP under the hood deep dive.