On this page
How MCP Actually Works
The July 2026 Model Context Protocol specification removes protocol-level session state and the initialize handshake to enable stateless HTTP operation and simple round-robin load balancing. While this cuts infrastructure complexity, it shifts security, state management, and input validation responsibilities to application code, creating new risks for teams without dedicated MCP security engineering expertise.
How MCP Actually Works: Inside the July 2026 Stateless Protocol
MCP hit 110 million monthly SDK downloads in April 2026, but most developers still can’t explain what happens on the wire when Claude calls a tool. The Model Context Protocol isn’t magic—it’s a JSON-RPC 2.0 message system with a lifecycle that just got radically simpler at the infrastructure layer and significantly more complex at the application layer. Understanding how MCP actually works matters now because the July 28, 2026 specification removes the protocol-level session entirely, shifting responsibilities that used to be handled for you onto code you’ll have to write yourself.
The Core Mechanics: JSON-RPC Over Two Transports
At its heart, MCP uses JSON-RPC 2.0 as its message system, with all communication encoded as UTF-8 JSON. Three message types move across the wire: Request, Response, and Notification. Requests carry an ID and expect a response. Responses match that ID with either a result or an error. Notifications fire and forget—no ID, no reply expected.
The protocol is bidirectional, which is unusual for something built on HTTP. Either side can initiate requests or push notifications. This lets an MCP server ask the client for LLM sampling, request user input, or announce that a resource changed. That bidirectionality is powerful, but it’s also why the old transport model got messy at scale.
MCP supports two transport mechanisms: stdio and Streamable HTTP. Stdio runs the server as a local subprocess—stdin/stdout, zero network surface, how Claude Desktop talks to your local filesystem tools. Streamable HTTP is the production transport, the one that lets you run remote services. Until now, it carried session state. After July 28, it doesn’t.
Here’s what a tool call looks like under the new spec:
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"search","arguments":{"q":"otters"},
"_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}Notice what’s missing: no initialize handshake, no Mcp-Session-Id header, no sticky session pinning. Every request is self-contained. Any server instance can handle it.
The Stateless Shift: What Disappears and What Replaces It
The 2026-07-28 specification makes MCP stateless at the protocol layer by removing two mechanisms that defined the old model. The initialize/initialized handshake is gone. So is the Mcp-Session-Id header and the protocol-level session it established.
This is the “state redistribution” pattern in action: the protocol sheds complexity, and that complexity reappears as implementation burden. In the stateless model, protocol version, client info, and client capabilities that were previously exchanged during the initialize handshake now travel in a _meta field on every request. A new server/discover method lets clients fetch server capabilities on demand without establishing state first.
The practical upside is real. The stateless design allows MCP servers to run behind plain round-robin load balancers without sticky sessions or shared session stores. No more Redis clusters tracking session affinity. No more load balancer annotations pinning clients to pods. The routing headers—Mcp-Method and Mcp-Name—enable load balancers to route traffic without inspecting the request body. That’s a genuine operational win.
But here’s the tradeoff: clients can cache tools/list responses for the duration specified by the server’s ttlMs value, which sounds benign until you realize that cache invalidation now lives in your application logic, not the protocol’s session lifecycle. And the _meta object can carry custom metadata on any message, but Akamai warns it introduces data leakage risks if sensitive inputs like API keys or PII are mapped to headers visible to proxies and logging systems.
The protocol got simpler. Your security model got harder.
Tasks, Apps, and the Extension Framework
The July spec doesn’t just remove—it adds. The Tasks extension, moved from experimental core to official extension, allows servers to return a task handle from tools/call, with clients managing long-running operations via tasks.get, tasks.update, and tasks.cancel. This is the right shape for operations that outlast an HTTP timeout: code generation, deep research, multi-step data pipelines. Task creation is server-directed—the server decides whether a given call becomes a task, not the client.
MCP Apps provide an extension for server-rendered UIs displayed in sandboxed iframes. This pushes MCP beyond “tool with arguments and return value” into interactive surfaces. It’s early, but it suggests a future where MCP servers ship full interfaces, not just function definitions.
The extensions framework uses reverse-DNS identifiers for capability negotiation. Clients and servers opt in explicitly. This avoids the old problem where experimental features became de facto required because popular clients assumed them.
Authorization: OAuth 2.1 and the Enterprise Reality
Authorization in the 2026-07-28 spec aligns with OAuth 2.1 and OpenID Connect, including mandatory Resource Indicators (RFC 8707) that bind tokens to specific MCP servers. This matters because it closes a class of confused-deputy attacks where a token minted for one server gets replayed against another.
The enterprise authorization story goes further. Enterprise-Managed Authorization (EMA) shifts OAuth consent from per-user flows to centralized identity provider provisioning. Okta is live; Entra ID, Google Workspace, and Ping Identity are in beta. The pattern is clear: the open protocol layer becomes a commodity, while control consolidates around identity and governance infrastructure.
This is where the “open standard vs. proprietary orchestration” tension plays out. MCP’s governance transferred to the Linux Foundation’s Agentic AI Foundation in December 2025. The spec is vendor-neutral. But the gateways, managed registries, and identity integrations that enterprises actually deploy—Cloudflare, Arcade, MintMCP, Okta, Entra ID—are proprietary layers on top. Shadow MCP usage is reportedly 3-10x higher than IT expectations, which is why the consolidation is happening.
The Security Gap Nobody’s Talking About
Akamai’s analysis of the new spec is worth taking seriously. The stateless model eliminates session hijacking—no sessions to hijack—but introduces tracking identifiers and state objects that servers Fremont the client. If those identifiers are predictable, or if the server fails to validate returned state objects, attackers can hijack workflows, access cross-tenant data, or trigger unauthorized actions.
Microsoft identified another vector: poisoned tool descriptions. Attackers can hide commands in the natural-language descriptions that tell agents what a tool does. The agent reads the description, follows the hidden instruction, and exfiltrates data through an approved tool connection. The logs look clean because each individual action is authorized.
The NSA issued dedicated security guidance for MCP in May 2026—the first federal acknowledgment that the protocol has reached enterprise scale. Their timeline suggests regulatory requirements may follow in 12-24 months.
What This Costs and Who Should Care
Here’s the comparison that matters for decision-making:
| Aspect | Self-Hosted | Managed Gateway (Cloudflare, Arcade, MintMCP) |
|---|---|---|
| Base cost | VPS at $40-120/month | $0.50/million requests (Cloudflare) or $1,250/month for 50 seats (MintMCP Teams) |
| Auth implementation | Full OAuth 2.1 + PKCE in your code | Handled by gateway |
| Session/state management | Your responsibility entirely | Abstracted by platform |
| Scaling model | Manual: load balancers, session stores, sticky routing | Automatic: round-robin, no shared state needed |
| Audit/compliance | Build yourself | Built-in, OTel-compatible |
| Best for | Teams with strong platform engineering, strict data residency | Teams prioritizing speed, lacking dedicated MCP infrastructure expertise |
The build-vs-buy decision hinges on whether you have engineers who want to own the protocol stack. The server code is the cheap part. Auth, audit, safety, and token costs consume the majority of budgets—as we’ve covered in MCP for Enterprise Teams: Benefits, Risks, and Costs.
The SDK Fragmentation Problem
The final specification ships on July 28, 2026, with a 12-month deprecation window for legacy versions. The release candidate was locked on May 21, 2026. That ten-week window exists so SDK maintainers can validate against a frozen target.
But adoption is fragmented. Python v2 answers both protocol revisions from one endpoint. TypeScript v2 ships as new package names requiring explicit opt-in. C# defaults to stateless mode. Clients must negotiate versions at runtime. This multi-version ecosystem means “supporting MCP” now requires version negotiation logic that didn’t exist before.
For teams already in production, the migration path is: audit existing servers for session dependencies, replace Mcp-Session-Id reliance with explicit handles, add _meta validation, and test against the beta SDKs. For teams not yet deployed, the July spec is a cleaner starting point—if you invest in the security implementation that the protocol no longer enforces.
The Honest Assessment
The 2026-07-28 spec correctly addresses real production pain points. Stateless HTTP, round-robin load balancing, and header-based routing are genuine improvements over the session-affinity workarounds that plagued 2025 deployments. But the ecosystem will experience a wave of security incidents as teams discover that statelessness shifts risk from infrastructure misconfiguration to application logic flaws—precisely the class of bugs that are harder to detect, audit, and attribute.
The protocol is simpler. Your code is more responsible. The gap between those two truths is where incidents happen.
If you’re evaluating MCP now, start with the What Is MCP (Model Context Protocol)? Full Developer Guide to understand the baseline, then ask: does your team have the security engineering capacity to validate client-provided state, sanitize _meta objects, and implement proper token audience checks? If not, the managed gateway premium may be the cheapest insurance you can buy.