Model Context Protocol just crossed 97 million monthly SDK downloads with over 5,800 registered servers. As of June 2026, MCP is no longer experimental — it's the de facto standard for connecting AI agents to tools, data sources, and external systems. Anthropic's updated roadmap and the upcoming July 28 specification release candidate confirm it: MCP is being built for enterprise scale.
But here's what I keep seeing in my engagements: teams adopt MCP enthusiastically, demo it beautifully, then hit the same three walls when they try to run it in production. I've now helped deploy MCP-based agent systems across healthcare, fintech, and SaaS platforms. The pattern of failure is remarkably consistent.
The Stateful Session Trap
MCP's original design assumes stateful sessions between client and server. In a demo or single-instance deployment, this works perfectly. In production — behind a load balancer, with horizontal scaling, with container orchestration — it falls apart fast.
Here's the concrete problem: an MCP client establishes a session with Server Instance A. The load balancer routes the next request to Instance B. The session state is gone. The agent loses context mid-workflow and either fails silently or retries from scratch, burning tokens and time.
Every team I've worked with hits this within the first week of production deployment. The workarounds are ugly:
- Sticky sessions — works until the instance crashes or scales down, then you're back to the same problem
- External session stores (Redis/DynamoDB) — adds latency and a new failure domain; you're essentially building your own session layer on top of a protocol that should handle it
- Stateless wrappers — serialize full context into each request, which balloons payload sizes and negates MCP's streaming advantages
The good news: the 2026 roadmap explicitly calls out evolving Streamable HTTP to work statelessly across multiple server instances. The July spec release candidate includes a stateless protocol core. This is the single most important change coming to MCP.
What I do now: design MCP server deployments with session externalization from day one, even for "simple" use cases. The cost of adding it later — after agents are in production and workflows depend on session continuity — is 3-5x higher than building it in upfront.
Authentication Is Still a Hack
The second wall is authentication. MCP has no standard for enterprise auth. No SSO integration path. No OAuth flow that IT administrators can manage from their existing identity provider console.
In practice, this means every MCP server you deploy requires its own authentication mechanism. I've seen teams use API keys hardcoded in environment variables, custom JWT validation middleware, and even basic auth over HTTPS. Each MCP server becomes a bespoke integration point from a security perspective.
For a startup running 2-3 MCP servers, this is manageable. For an enterprise with 20+ MCP servers connecting agents to internal APIs, databases, compliance tools, and third-party services — it becomes an identity management nightmare. Your security team can't audit it from their existing tooling. Your IAM policies don't apply. Your SOC 2 auditor has questions you can't answer.
The MCP roadmap acknowledges this: the 2026 plan calls for "paved paths toward SSO-integrated flows" and identity provider integration. But as of June 2026, the spec doesn't include it. You're on your own.
What I build: a thin authentication gateway that sits in front of all MCP servers. One auth layer, one audit trail, one place for your security team to enforce policy. It adds about 3ms of latency per request. It saves about 3 months of compliance work per audit cycle.
Discovery and Governance Don't Exist Yet
The third problem is less obvious but more dangerous long-term: there's no standard way for a registry or crawler to learn what an MCP server does without actually connecting to it.
This means:
- No catalog of available tools. Your agents can't discover what MCP servers are available in your organization without hardcoded configuration.
- No capability negotiation. An agent can't ask "which of these 15 MCP servers can help me with this task?" without connecting to all 15 and asking.
- No governance layer. When a new MCP server appears in your infrastructure, there's no automated way to assess what it can do, what data it accesses, or whether it should be allowed.
I've seen this create real problems in regulated industries. A healthcare client deployed an MCP server for claims processing. Three months later, another team deployed a different MCP server for patient scheduling — which also had read access to claims data. Nobody knew about the overlap because there was no registry, no discovery, no governance.
The July spec adds an Extensions framework and what they're calling "MCP Apps" — which should eventually address discovery. But governance tooling is explicitly listed as a 2026 roadmap item, not a shipped feature.
What I recommend: maintain a manual MCP server registry from day one. A spreadsheet works. Track: server name, owner, data access scope, auth method, deployment location, last security review date. It's not glamorous, but it's the difference between "we know what our agents can touch" and "we hope our agents can't touch patient data."
The July Spec Changes That Actually Matter
The upcoming release candidate (due July 28, 2026) includes several changes that will fix real production pain points:
- Stateless protocol core: sessions can be created, resumed, and migrated transparently across server restarts and scale-out events
- Extensions framework: standardized way to add capabilities without forking the core protocol
- Tasks: long-running operations with progress tracking — critical for multi-agent workflows that take minutes, not milliseconds
- Authorization hardening: not full SSO, but a formal deprecation of the current "figure it out yourself" approach
- Formal deprecation policy: so you can finally plan upgrades without worrying about breaking changes
My advice: don't wait for the July release to start production MCP deployments, but do architect your integration layer to be swappable. The session management and auth patterns you build today will need to change when the new spec lands. Budget for it.
My Production MCP Checklist
After deploying MCP across multiple enterprise environments, here's the pre-production checklist I run through with every client:
- Session strategy decided and implemented — externalized state store, not sticky sessions
- Authentication gateway deployed — single auth layer in front of all MCP servers
- Server registry created — every MCP server cataloged with owner, data scope, and auth method
- Health checks and circuit breakers — MCP servers need the same production observability as any other service
- Token budget monitoring — MCP tool calls trigger LLM inference; one chatty MCP server can 10x your API costs in a day
- Blast radius analysis — what's the worst thing each MCP server can do? Write to a database? Delete records? Transfer money? Gate accordingly
- Upgrade path documented — how you'll migrate when the July spec drops, without breaking running agent workflows
Skip any of these and you'll be patching in production within the first month. I've seen it happen at least four times now.
The Bottom Line
MCP is the right protocol. The adoption numbers prove it. The ecosystem is real — 5,800+ servers, 97M monthly downloads, every major AI framework integrating it. The July spec release will fix the worst production gaps.
But right now, in June 2026, deploying MCP in production requires the same engineering discipline as deploying any distributed system: session management, authentication, observability, governance. The protocol doesn't give you those things yet. You have to build them.
The teams that treat MCP as "just connect and go" are the ones calling me six weeks later. The ones that treat it as a production integration — with all the operational rigor that implies — are shipping agent workflows that actually work.