MCP Is a Transport Layer Pretending to Be a Brain

A viral HN post this week called the MCP explosion a "distributed systems nightmare." The argument: we now have hundreds of MCP servers, agents call them freely, and nobody has solved the coordination problem of which tool to call when. The result is infinite loops, burned credits, and solo founders staring at a $20 hole in their API balance after lunch.

I know this problem personally because I caused it.

The $20 Lunch Break

I was building an educational project last year. The code had a loop that retried API calls when the response came back null — standard defensive pattern. Except the responses were not actually failing. They were not being saved properly. The storage code was broken, so the loop kept seeing null, kept retrying, kept calling Anthropic.

I went for lunch. Came back an hour later. Entire $20 in credits gone.

Now $20 is not a life-changing amount. But sitting there looking at the usage dashboard, two things hit me at the same time. First, most of those calls were simple tasks — summarize this, extract that — that did not need the model I was sending them to. I was paying Sonnet prices for tasks that a much cheaper model could handle without breaking anything. Second, there was nothing between me and the API that could have caught this. No budget. No monitor. No circuit breaker. Just a loop and a model that was happy to keep answering.

That is what made me build Prism.

The Real Problem With MCP

MCP is genuinely convenient. It standardized the transport — how agents talk to tools. That part works. The problem is what it did not standardize: intent.

Right now, when an agent has access to MCP servers, it calls whatever it deems necessary unless you give it very specific instructions. There is no budget awareness. There is no complexity classification. There is no "this is a simple lookup, use the cheap path" logic built into the protocol. The agent just fires, and you pay.

The HN post framed this as an M×N coordination problem — M agents talking to N tools with no orchestration layer. I think that is directionally right but misses the sharper framing. The problem is not that we have too many tools. The problem is that we are treating a transport layer like it is intelligence.

MCP tells the agent how to call a tool. It does not tell the agent whether to call it, which model should handle the call, or how much that call should be allowed to cost. Those are routing and governance decisions, and right now they live nowhere. They are not in the protocol. They are not in the agent. They are in the developer's head, encoded as prompt engineering that breaks the moment the context gets complicated.

What Actually Needs to Happen

Gemini's take on this was "over-standardizing transport, under-standardizing semantic intent." I agree with the diagnosis. But I think the fix is more specific than "standardize intent."

What we need is not a smarter MCP spec. What we need is a layer between the agent and the tools that does three things:

Budget-aware routing. Every MCP call should have a cost ceiling. Not a global budget that you check after the fact when the bill arrives, but a per-task budget that the routing layer enforces before the call goes out. Simple query? Route to a cheap model. Complex reasoning? Route to Sonnet or Opus. Unknown complexity? Classify first, then route. The classification itself should cost almost nothing.

Fixed paths for regular queries. Most agent workflows have a small number of query patterns that repeat constantly. Extracting a name from an email. Summarizing a document. Looking up a schema. These should not go through the full agent reasoning loop every time. They should hit a pre-defined path that is tight, focused, and cheap. Think of it like MCP agents with fixed budgets and fixed routes — the regular stuff stays hyper-optimized, and the full reasoning path is reserved for genuinely novel tasks.

A feedback loop that learns. The routing layer should get smarter over time. If a task consistently gets routed to an expensive model and the output is indistinguishable from what a cheap model produces, the system should notice and adjust. If a specific MCP server consistently triggers retries, the system should flag it. This is not AI magic — it is logging, scoring, and thresholds. Boring infrastructure that nobody wants to build but everyone needs.

Where Prism Fits

Prism exists because of the $20 lunch break. The first version solves the most obvious piece — routing queries to the cheapest model that will not break them. Three modes: Eco, Balanced, Sport. The classification happens before the call, not after. That alone would have saved my $20 because half those retried calls were simple tasks being sent to Sonnet.

But routing is just the first layer. The vision is closer to becoming the Vercel of AI API management — a control plane that sits between your code and the models, handling routing, memory, budgets, monitoring, and continuous optimization. Not another model provider. Not another MCP server. The layer that makes all of them usable without burning your credits while you eat lunch.

We are not there yet. Prism today does routing and session memory. The budget enforcement, the fixed paths, the feedback loop — that is what we are building toward. But the architecture is designed for it, and the $20 lunch break is the reason every decision starts with "what does this cost per call."

The Bigger Picture

The MCP explosion is a good thing. More tools, more standardized access, more capability for solo builders. But we are in the phase where everyone is excited about the access and nobody is thinking about the governance. It is the same pattern as microservices in 2016 — everyone adopted the architecture, nobody built the observability, and then everyone spent the next three years bolting on monitoring after production caught fire.

MCP without a routing and governance layer is the same trap. The transport works. The intelligence does not exist yet. And until someone builds it, every indie hacker with an MCP-connected agent is one broken storage function away from buying their API provider lunch.

---

I am building that layer. Prism is live at prism.ssimplifi.com — routing and session memory today, budget governance and optimization next. If you have burned credits on a dumb loop, you know why this matters.