The Future of MCP: Scaling Wins, Billing Breaks

Ninety-seven million monthly SDK installs and over ten thousand public servers built the MCP ecosystem on free experimentation — but the July 28 stateless spec exposes the bottleneck nobody solved: how to meter sub-cent agent calls and reconstruct audit trails when traffic hits 100x human pace.

The protocol won the adoption race. Now it has to survive contact with enterprise economics.

Adoption Was Free; Scale Is Not

MCP’s growth curve is the kind of thing that usually gets called unprecedented, and the numbers back it up. The TypeScript and Python SDKs are pulling 97 million combined installs per month as of early 2026. Over 10,000 active public servers exist in the ecosystem. OpenAI, Google DeepMind, Microsoft, Cohere, and Mistral all committed to support. First-class clients span Claude, ChatGPT, Cursor, Gemini, Microsoft Copilot, and VS Code.

Here’s the problem: less than 5% of MCP servers are monetized. That figure holds across multiple ecosystem analyses. The ecosystem grew through zero-cost experimentation — solo developers and small teams standing up servers because the barrier was low and nobody wanted to be the first to charge. That was sustainable when MCP was a developer playground. It breaks when enterprise traffic arrives.

The Agentic AI Foundation surpassed CNCF in membership within three months of launch, with 170+ member organizations as of April 2026. Enterprise keynotes from Uber, Nordstrom, Bloomberg, Duolingo, and PwC demonstrated MCP running in production. Google Cloud launched a fully managed remote MCP server for Gemini Enterprise Agent Platform on June 30, 2026. Apple released Safari Technology Preview 247 with an MCP server for AI agent integration on July 1, 2026.

The signal is clear: MCP is moving from demos to infrastructure. Infrastructure has a billing problem that demos don’t.

The Stateless Spec Solves Scaling, Breaks Auditability

The 2026-07-28 specification removes the stateful initialize handshake and Mcp-Session-Id, making the protocol stateless at the core. Servers can now run behind plain round-robin load balancers. The final spec ships on July 28, 2026, with a 12-month deprecation window for legacy versions.

This is a genuine architectural win. The old stateful model required sticky sessions, shared session stores, and deep packet inspection at gateways. A single server restart could blow up every in-flight session. The new spec makes every request self-contained — protocol version, client info, and capabilities travel in _meta on each call. Any server instance can handle any request.

But the session ID was doing double duty. It wasn’t just routing — it was the implicit audit boundary. When you needed to reconstruct what happened during a specific agent interaction, the session ID gave you a thread to pull. Remove it, and that thread disappears.

Akamai’s analysis, reported by SecurityWeek, found that the stateless spec removes several vulnerability classes — session hijacking, unsolicited server-initiated prompts — but introduces new attack surfaces. Predictable tracking-ID hijack. Header desync attacks. Data leakage via x-mcp-header when developers accidentally map API keys or PII into headers visible to every proxy and logging system along the path.

The spec warns developers to validate state objects but doesn’t standardize how. For solo builders who lack enterprise security teams, that’s a gap they’ll hit in production, not in planning.

The Metering Problem: Sub-Cent Calls at Agent Scale

Here’s the pattern I’ve observed — what I’d call “meter before scale.” The protocol solved scaling. It didn’t solve billing. And without billing, the ecosystem stalls commercially.

The numbers tell the story. Per-call micro-pricing at $0.01 per call with 50 calls per day yields roughly $15/month. That’s barely worth the engineering effort to meter. The metering overhead — idempotent dedup, per-tool rates, per-agent caps, aggregating sub-cent calls into one invoice — can exceed the revenue collected.

Agent traffic makes this worse. Some data suggests agent traffic via MCP can be 10x to 100x the load of human-paced API usage. A human might make 50-200 actions per day in Salesforce. An agent researching a lead might fire 500 tool calls in 10 seconds. Same infrastructure. Same database queries. Same egress costs. Radically different billing profile.

A single Claude conversation averages 8-15 tool calls, causing per-call pricing to scale roughly 4x faster than headcount. That’s the asymmetry that breaks human-paced pricing models. You can’t forecast agent load the way you forecast seat count.

Pricing Model	Revenue Profile	Best Fit	Key Risk
Per-call ($0.01/call)	~$15/mo at 50 calls/day	Autonomous, anonymous agents	Metering overhead exceeds revenue
Subscription (flat monthly)	Predictable, forecastable	Named, heavy, repeat customers	Onboarding friction for long-tail agents
Freemium / open core	Conversion-gated	Servers with premium features	Most servers stay free forever
Outcome-based	Tied to agent results	High-value, measurable outcomes	Hard to attribute and verify

The table above maps the four models competing for MCP monetization. None of them solve the sub-cent metering problem at typical call volumes. The servers that survive 2026 will be the ones with a revenue model that fits how agents actually use them — and a billing stack that doesn’t collapse under thousands of micro-transactions.

Build Costs vs. Monetization Reality

The economic gap between building and monetizing is stark. Building a production MCP server in 2026 costs between $100K and $1M+. Read-only connectors run $100K-$300K. Action-taking servers run $300K-$700K. Agent-resident rebuilds start at $1M.

The server code is the cheap part. Auth, audit, safety, and distribution are where the budget goes. A serious actions-depth build for a single client is one to two quarters of work for a properly staffed team. Teams that scope it as a two-week sprint routinely discover by month three that they’re short two engineers and a designer.

Now set that against the monetization data. Less than 5% of servers charge anything. The ones that do often pick per-call pricing that generates revenue below the cost of metering it. You’re spending $100K-$700K to build something that, if you’re lucky, earns $15/month per agent — and you’re spending engineering time on the meter instead of the product.

This is the core tension: free servers drove protocol dominance and 97M installs, but zero monetization leaves builders unable to recoup build costs. The ecosystem grew because nobody charged. It can’t mature until somebody does.

Security Tradeoffs: Enterprise-Ready or Solo-Exposed?

The stateless spec is hailed as enterprise-ready, and for good reason. It removes session fragility, adds OAuth 2.1 hardening with PKCE, and runs on ordinary HTTP infrastructure. Google Cloud’s managed remote MCP launch explicitly cited governance as the driver. The MCP blog and WorkOS both frame it as the largest revision since launch, with enterprise auth moving from experimental to stable.

But “enterprise-ready” and “secure by default” are different claims. The spec shifts security responsibilities to developers. Session hijacking is gone — but predictable tracking-ID hijack replaces it. The protocol no longer enforces session boundaries; it expects developers to mint explicit handles and validate them. That’s fine if you have an enterprise security team. It’s a liability if you’re a solo builder who was relying on the protocol’s implicit session boundary for audit and security.

The Akamai analysis outlines the specific risks: tracking IDs that an attacker can guess or alter to hijack another user’s workflow, cross-tenant data access, and unauthorized actions triggered through manipulated state objects. The spec warns developers to verify those objects but doesn’t set a standard for how.

For the typical solo MCP builder — the demographic that built half the ecosystem — the July 28 update degrades out-of-box security. They gained horizontal scaling. They lost the protocol-enforced session that was doing implicit audit work. And they’re now responsible for validation patterns the spec doesn’t specify.

The Decision Framework: What to Do Before July 28

The final specification ships on July 28, 2026. You have a 12-month deprecation window for legacy versions, but the migration work starts now. Here’s how to think about it based on your position in the ecosystem.

If you’re running a production MCP server:

1. Audit your session dependencies. Find every place where Mcp-Session-Id was doing audit or security work implicitly.
2. Design explicit application handles to replace protocol sessions. A basket_id, browser_id, or workflow_id that the model passes back as an ordinary argument.
3. Implement server-side validation for all client-provided state objects. Don’t trust tracking IDs without verifying integrity.
4. Review your header usage. Ensure no API keys, tokens, or PII are mapped into Mcp-Method, Mcp-Name, or other MCP-specific HTTP headers.

If you’re building a new MCP server:

1. Budget realistically. Read-only connectors start at $100K. Action-taking servers start at $300K. Don’t scope it as a two-week sprint.
2. Choose your pricing model before you ship. Per-call works when calls are expensive — when they hit a paid upstream API, run a model, or do real compute. It doesn’t work for cheap lookups where metering overhead exceeds revenue.
3. Design for the audit trail from day one. Don’t rely on protocol sessions for audit evidence. Build per-invocation logging with explicit correlation IDs you control.

If you’re evaluating MCP for enterprise adoption:

1. The stateless spec makes horizontal scaling viable. That’s real.
2. Security now depends on implementation quality, not protocol enforcement. Vett your MCP server providers accordingly.
3. Agent traffic could be 10x-100x your human-paced API traffic. Budget for that asymmetry before you commit.

The Open Question

The MCP ecosystem will stall commercially unless a standard metering-and-audit handle layer emerges before the stateless spec propagates. The July 28 transport fix solves scaling. It doesn’t solve billing. It doesn’t solve audit. It doesn’t solve the gap between $100K build costs and $15/month revenue.

The protocol maintainers drew a clear scope line at the MCP Dev Summit: MCP connects AI applications to data sources and will not expand into observability, identity, or governance. Those problems belong to other projects and other standards. That’s disciplined stewardship. It also means the metering and audit gap won’t be solved inside the protocol.

Who builds that layer — and whether it arrives before the ecosystem’s free-tier economics collapse — is the question that will determine whether MCP becomes durable infrastructure or a cautionary tale about protocols that won adoption but couldn’t capture value.