MCP in Production: What Breaks After Localhost

I ran 6 MCP servers on my laptop for two months and thought I understood the protocol. Then I tried deploying one to a staging server for a client project. That's when things got weird.

The server worked fine locally. stdio transport, Claude Desktop, the whole familiar setup. Fifteen minutes after deploying to a cloud VM, the connection started dropping. No error message. No log entry. Just... silence. The MCP inspector showed the server was running. Claude's client said it was connected. But tool calls were timing out with nothing on either end explaining why.

I spent four hours on that. Turns out the issue was a firewall rule blocking the SSE keep-alive packets. Not an MCP problem, technically. But the kind of problem you never hit on [localhost](http://localhost) and nobody warns you about.

That was my welcome to MCP in production.

The localhost illusion

Here's something I've noticed after indexing 290+ MCP servers on [mcp-find.org](http://mcp-find.org): almost every tutorial, every demo, every "getting started" guide assumes you're running locally. stdio transport. Single user. No auth. No network latency.

And honestly that makes sense for learning. stdio is simple. You start a process, pipe JSON-RPC through stdin/stdout, done. I still use it daily for my own dev work.

But production is a different planet.

The 2026 MCP roadmap that dropped last month basically confirmed what a lot of us already knew. The protocol was designed for local-first use cases and is now being retrofitted for production. David Soria Parra, the lead maintainer, wrote that they're working on transport scalability, agent-to-agent communication, and enterprise readiness. Those aren't small additions. Those are foundational changes.

Which tells you something about where MCP is right now: great for dev machines, still figuring out production.

Security is worse than you think

I spent a weekend last month reading through the source code of popular MCP servers. Not all 290 on my directory, just the top 30 by GitHub stars. What I found was not encouraging.

Seven of them had no input validation at all on tool parameters. Three were passing user-provided strings directly into shell commands. One — a database query tool with over 2,000 stars — was constructing SQL queries by concatenating user input. In 2026.

I didn't name them publicly because I wanted to give the maintainers a chance to fix things first. Most responded within a week. Two haven't responded at all. That database tool? Still vulnerable as of yesterday. I checked.

A HackerNoon article published a few weeks ago documented actual MCP exploits in the wild. Not theoretical attack vectors. Real breaches. The common thread was always the same: someone deployed an MCP server to production without auditing the code, gave it access to sensitive systems, and assumed the protocol itself would handle security.

MCP doesn't handle security. The spec doesn't enforce authentication. It doesn't require input sanitization. It doesn't even mandate TLS. Those are all left as "implementation details" for server authors.

A Reddit post in r/AI_Agents from February put it well: "MCP has become the default way to connect AI models to external tools faster than anyone expected, and faster than security could keep up."

That about sums it up.

What actually breaks in production

After my own deployment adventures and talking to a few people building MCP-based products, here's my running list of things that work on localhost but fall apart in production. This is not comprehensive. I keep adding to it.

Connection management. On localhost, your MCP client and server are on the same machine. Connections don't drop. In production, network hiccups happen constantly. The current MCP spec has no built-in reconnection logic. If the connection drops, your client has to handle it. Most don't, because on localhost they never had to.

Auth and permissions. stdio doesn't need auth because it runs as a local process with your user permissions. The moment you put a server on a network, you need to decide: who can connect? What tools can they access? Can different users have different permissions? MCP has a draft auth spec based on OAuth 2.1, but last I checked most production servers are still rolling their own. I talked to one team that was using API keys passed as environment variables. Another was using... nothing. Their MCP server was open to anyone who could reach the port.

Observability. On localhost, you can read the terminal output. In production, you need proper logging, metrics, tracing. The MCP inspector works great for debugging one connection on your dev machine. It doesn't scale to monitoring 50 concurrent connections in a staging environment. One team I know ended up building a custom proxy that sits between their MCP clients and servers just to get request logging. That shouldn't be necessary.

Cold start latency. Some MCP servers take 3-5 seconds to initialize. On your laptop, you start the server once and it stays up. In a serverless or auto-scaling environment, cold starts happen constantly. I tested one popular file analysis server that took 8 seconds to cold start because it was loading a large model on init. Eight seconds. In a user-facing workflow.

Concurrent access. Most MCP servers I've reviewed were designed for single-user access. One client, one server, one conversation. Production often means multiple users hitting the same server instance. Some servers handle this fine. Others maintain global state that gets corrupted when two requests arrive simultaneously. I found this out the hard way with a note-taking server that started merging two users' notes together.

The Zuplo survey confirms all of this

A survey from Zuplo that came out last month — they polled about 100 technical professionals — had some numbers that validate what I've been seeing.

72% expect their MCP usage to increase this year. So adoption is going up regardless of these issues.

But security was the number one adoption blocker. Not performance, not complexity. Security.

And 58% of builders said they're wrapping existing APIs with MCP. That's interesting because it means most MCP servers aren't doing anything new. They're just putting an MCP interface on top of REST APIs that already existed. Which raises the question: is the MCP layer adding value or adding attack surface?

I think it's both. The value is real — a standard protocol means your AI tools work across Claude, Cursor, VS Code, and whatever comes next. But the attack surface is also real, and most teams aren't treating it seriously yet.

What the 2026 roadmap promises

The official roadmap covers four big areas: transport scalability, agent-to-agent communication, governance, and enterprise readiness.

The transport stuff is overdue. Streamable HTTP transport is supposed to replace the current SSE approach, which has known issues with proxies and load balancers. That alone will fix a lot of production deployment headaches.

Agent-to-agent communication is the ambitious one. Right now MCP is human-to-tool. The roadmap hints at agent-to-agent scenarios where one AI system talks to another through MCP. I haven't seen any concrete spec for this yet, just the direction. I'm skeptical but interested.

Enterprise readiness means things like better auth, audit logging, and compliance features. Basically everything I just complained about. The fact that these are on the roadmap for 2026 tells you they don't exist yet.

Governance-wise, MCP moved to the Linux Foundation's Agentic AI Foundation in December. That's a good signal for long-term neutrality. Nobody wants a protocol controlled by one company.

I keep checking the GitHub SEP (Spec Enhancement Proposals) repository. There are proposals for server-initiated requests, OAuth improvements, and better error handling. Progress is happening. Just not as fast as adoption.

The new hotness: MCP Apps

There's a concept emerging that I find genuinely interesting. Instead of building traditional apps that happen to have MCP servers attached, some teams are building apps that ARE MCP servers. The entire app is designed to be controlled by the user's AI agent.

A post on r/mcp from last week described it like this: "Build the UI and business logic. Let the user's agent provide the intelligence. Zero LLM costs on your side."

I've been thinking about this for mcp-find.org. What if the tool directory itself was an MCP server? You could ask your Claude or Cursor: "find me an MCP server that does PDF extraction" and it would search my database directly instead of you browsing the website.

Haven't built it yet. It's on the list. But the concept makes sense for a lot of products.

My current production checklist

For anyone about to take an MCP server from localhost to production, here's what I check now. Learned all of these from mistakes.

[ ] Audit every tool's input validation. Especially anything that touches the filesystem or runs commands.

[ ] Add authentication. Even if it's just API keys for now. Don't deploy an open MCP server.

[ ] Test with network latency. Use `tc` on Linux to simulate 200ms latency and see what breaks.

[ ] Add reconnection logic to your client. The server will go down. Plan for it.

[ ] Monitor concurrent access. If two users can hit the server at the same time, test what happens when they do.

[ ] Check cold start time. If it's over 2 seconds, consider a warm pool.

[ ] Log every tool call. Input, output, duration, errors. You'll need this for debugging and for knowing what your AI is actually doing.

[ ] Review the MCP server's dependencies. I found one server that pulled in 47 npm packages for a simple file reader. Each one is a potential vulnerability.

Where this is going

Honestly, I think MCP is going to be fine long-term. The protocol itself is solid. The community is active. Having it under the Linux Foundation instead of Anthropic is the right move.

But right now, in April 2026, there's a gap between what MCP promises and what it delivers in production. That gap is mostly around security, observability, and multi-user scenarios. The roadmap addresses all of these, but roadmaps are promises, not code.

If you're building something that only runs on your dev machine with Claude Desktop, MCP is great today. Genuinely useful. I use it every day.

If you're deploying to production with real users and real data, proceed carefully. Read the server code before you deploy it. Add auth even when the tutorial doesn't mention it. Monitor everything.

I'll probably update this post after the next spec release. Things move fast in this space — half the links in this article will probably be outdated by July.

Anyway, that's where things stand from my corner of the MCP world. If you're working on production MCP deployments and want to compare notes, I'm at [lee@mcp-find.org](mailto:lee@mcp-find.org).