Remember 2016? When every team decided their monolith needed to be 47 microservices? And then two years later everyone was writing blog posts titled "Maybe We Didn't Need Microservices" while quietly hiring a platform team to wrangle the mess?
Yeah. We're doing it again. Except this time it's MCP servers.
The Pattern We Keep Repeating
Here's how this plays out every single time in our industry:
New thing emerges. New thing is genuinely useful. New thing is easy to spin up. Every developer spins one up. Nobody tracks them.
Nobody governs them. Eighteen months later, someone with "Platform" in their title gets hired to clean it up.
Containers. Microservices. Lambdas. Kubernetes clusters. And now, MCP servers.
The Model Context Protocol has become the standard way AI agents talk to external tools and data sources. Anthropic open-sourced it, Google launched managed MCP servers in December, and the Linux Foundation just stood up the Agentic AI Foundation around it. It's real. It's not going anywhere.
But the adoption curve is outpacing the governance curve by a mile. And if you've been in this industry long enough, you know exactly what that means.
The Numbers Are Already Ugly
Unofficial registries like mcp.so are indexing over 16,000 MCP servers. GitHub likely has north of 20,000 repositories implementing them. And that's just what's public.
Inside enterprises? It's worse. Any developer can spin up an MCP server in minutes. Which means they are. Across teams, across projects, with no central catalog, no consistent auth, and no visibility into what's actually running.
Here's the stat that should concern you: a large-scale analysis of over 5,200 open-source MCP server implementations found that 88% require credentials to operate. Of those, 53% rely on long-lived static secrets — API keys and personal access tokens sitting in environment variables or, let's be honest, hardcoded in config files. Only 8.5% use OAuth.
That's not a security posture. That's a collection of future incident reports.
"But It's Just a Protocol"
This is the thing I keep hearing. "MCP is just a protocol. It's fine."
Sure. HTTP is just a protocol too. And we still managed to build entire categories of security tooling around the fact that people used it carelessly.
MCP doesn't solve authentication. It doesn't solve identity management. It doesn't provide audit trails, observability, compliance, rate limiting, or error handling. It describes how servers and clients communicate. That's it. Everything else is your problem.
And right now, most organizations are treating that "everything else" as someone else's job. Security teams can't monitor what they don't know exists. And most companies don't even have an internal MCP registry — which, to me, is the absolute bare minimum.
So what actually happens? Two things:
Shadow MCP. Developers introduce servers that IT has no idea about. Works fine until it doesn't. And when it doesn't, security has no context on what that server touches, who owns it, or what credentials it holds.
Server sprawl. Multiple teams build slightly different MCP servers for the same API. Nobody decommissions the old ones. The attack surface expands quietly, like mold behind drywall.
Sound familiar? It should. We had the exact same conversation about microservices in 2018 and Kubernetes namespaces in 2020.
Real Vulnerabilities, Right Now
This isn't theoretical. Researchers have already found serious vulnerabilities in some of the most popular MCP servers, including ones from Microsoft and Anthropic themselves.
Path validation bypasses. Arbitrary file overwrites. Credential exposure through cloud metadata services. And the fun one: chaining multiple medium-severity issues into full remote code execution.
These aren't exotic zero-days. They're the boring, predictable result of moving fast without governance. The same kind of bugs we've been finding in rushed microservice deployments for years.
What Actually Needs to Happen
I'm not here to say "MCP bad, don't use it." MCP is genuinely useful. My team uses it. The protocol itself is solid. The problem is the operational model around it.
If you're adopting MCP at any kind of scale, here's my short list:
Build an internal registry. If you don't know what MCP servers exist in your org, you can't secure them. This doesn't need to be fancy. A spreadsheet with owner, purpose, permissions, and last review date is better than nothing. But build toward something with automated discovery.
Standardize on OAuth 2.1. The 53% of servers running on static API keys need to stop. Short-lived tokens, PKCE for user-facing apps, mutual TLS for service accounts. This is solved work. We just need to actually do it.
Deploy a gateway. An MCP gateway is the same pattern as an API gateway — single entry point, centralized policy enforcement, consistent logging. It turns a chaotic multi-server topology into something you can actually operate. If you learned anything from the microservices era, it's that you need a control plane before you need more services.
Treat MCP servers like infrastructure, not experiments. The moment an MCP server touches production data, it's infrastructure. It needs an owner, a lifecycle, and a decommission plan. The "I'll just spin one up real quick" mindset is how you end up with 200 unmanaged endpoints and a SOC 2 auditor asking questions you can't answer.
The Part Nobody Wants to Hear
Gartner is predicting 40% of agentic AI projects will fail by 2027. Not because the tech doesn't work, but because organizations are automating broken processes. MCP sprawl is a symptom of that exact problem.
We keep doing this thing where we adopt the technology first and figure out the operations later. And every time, we act surprised when it gets messy. Microservices taught us that distributed systems need centralized governance. MCP is a distributed system. The lesson applies.
The organizations that get this right won't be the ones with the most MCP servers. They'll be the ones that actually know how many they have.
Top comments (6)
I tried many MCPs last year, but I haven’t built one into a project at work yet. Thank you for your valuable suggestion! 😄
I am doing one now at work and it is somewhat rocky....
Oh! I hope everything goes well… 😅
Spot on, Evan. The microservices parallel is painfully accurate.
One of the root causes is that there's no tooling nudging teams toward governance from day one. The MCP SDK gives you the protocol, but nothing to track behavioral contracts, audit what changed, or detect semantic drift.
We've been thinking about this exact problem with MCP Fusion (github.com/vinkius-labs/mcp-fusion), a TypeScript framework we built for production MCP servers. One of its core features is the Capability Lockfile (
mcp-fusion.lock) — basicallypackage-lock.jsonfor your MCP server's behavioral surface. It captures every tool's schema, egress rules, entitlements, and a cryptographic digest. Any change shows up in your PR diff, classified as BREAKING, RISKY, SAFE, or COSMETIC.We also just shipped Vercel and Cloudflare Workers adapters, so teams can deploy MCP servers as serverless functions with proper egress firewalls and concurrency guards built in — which directly addresses the "spin one up real quick" culture you're describing.
Your point about OAuth is also something we tackled: the framework includes a built-in OAuth module with RFC 8628 Device Flow, so auth isn't an afterthought.
The tooling gap is real. If teams are building on raw SDKs with no governance layer, sprawl is inevitable.
Wow thats incredible! I will check out your Git for sure. I am really interested in this as well. I am so glad to hear your team is taking this into account. It blows my mind organizations and development teams ive seen just spin up an MCP server with access to EVERYTHING and go about their business...
Love this take! The industry really does have a pattern of 'new shiny thing everyone overdoes it platform teams clean up.' MCP servers deserve better than becoming the next spaghetti architecture.