The headline everyone pulled out of the Model Context Protocol (MCP) 2026-07-28 Release Candidate is that MCP is going stateless. Fair enough — it’s a genuine architectural improvement. Stateless protocols scale horizontally without sticky sessions, they cut operational complexity, and they make the infrastructure easier to deploy and reason about.

But I don’t think statelessness is the change that will matter most for enterprise adoption. I think traceability is.

When I gave a conference talk on building MCP servers earlier this year, the hallway questions afterward were rarely about what a server could do. They were about what it takes to run one: how the traffic shows up in gateway logs, what a trace looks like when a tool call fails, whether any of it can be audited later. So when the release candidate landed, I read it with those questions in mind.

Two changes stood out to me, and they work as a pair.

The first is SEP-2243 , which makes two headers, Mcp-Method and Mcp-Name, required on the Streamable HTTP transport. The spec is clear about their job: they exist so load balancers, gateways, and rate limiters can route on the operation without inspecting the JSON-RPC body. What interests me is the side effect. Every layer of the stack now gets a piece of standardized, protocol-level metadata — and standardized metadata is exactly the raw material enterprise observability and audit tooling is built on.

The second is SEP-414 , which locks the W3C Trace Context keys — traceparent, tracestate, and baggage — into the spec as reserved keys inside params._meta of every JSON-RPC request. Note where they live: in the message, not in HTTP headers. That’s deliberate. MCP is transport-agnostic and stdio has no headers, and a single Streamable HTTP connection can multiplex many JSON-RPC messages, so trace context has to belong to the individual request rather than the connection. A trace that starts in the host application can now follow a tool call through the client SDK, the MCP server, and whatever the server calls downstream, and land in an OpenTelemetry-compatible backend as one span tree:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "location": "New York" },
    "_meta": {
      "traceparent": "00-0af7651916cd43dd8448eb211c80319c-00f067aa0ba902b7-01"
    }
  }
}

Several SDKs were already doing this — the release candidate fixes the key names so traces correlate across implementations instead of by convention. And in the same release, MCP’s own logging capability is deprecated, with OpenTelemetry named as the path for structured observability. Read those together and the direction is unambiguous: the protocol didn’t invent its own tracing story, it adopted the one enterprises already run.

That matters because enterprises are not building greenfield. They already have API gateways, OpenTelemetry, centralized logging, SIEM platforms, operational dashboards, and distributed tracing — and years of trust invested in all of it. A new protocol gets adopted when it slots into that existing machinery, not when it asks to be operated as a special case beside it. Routing headers at the transport layer, W3C Trace Context in the message — small design decisions with a large consequence, because together they mean MCP can be operated alongside everything else instead of babysat beside it.

What Enterprise Traceability Looks Like

The important property is that the new metadata enriches an existing trace without changing how distributed tracing works.

                    End User
                       │
                       ▼
                  API Gateway ────────────────┐
                       │                      │
                       ▼                      │
            Spring Boot / Spring AI           │
                       │                      │
                       ▼                      ▼
                  MCP Client         Logs · Metrics · SIEM
                       │                      ▲
    Mcp-Method         │                      │
    Mcp-Name    ──────►│ ─────────────────────┤
    (HTTP headers)     │                      │
                       │                      │
    traceparent        │                      │
    tracestate  ──────►│                      │
    (in _meta)         │                      │
                       ▼                      │
                  MCP Server ─────────────────┤
                       │                      │
                       ▼                      │
                      Tool ───────────────────┘

  W3C Trace Context propagates through every hop above — over HTTP
  headers on ordinary hops, inside _meta on the MCP hop. The routing
  headers add protocol-specific metadata to that same trace.

The distributed trace flows exactly as it does today. The routing headers give the infrastructure something to key on, and the _meta trace keys keep the MCP hop stitched into the trace you’re already collecting.

The Questions a Platform Team Asks First

Enterprise engineering organizations rarely get stuck because they can’t scale a service. They get stuck because they can’t answer questions after the fact:

• Which MCP method executed, on which server, running which tool?
• Which distributed trace contains this interaction, and how does it line up with the gateway logs?
• Which agent initiated the request, and why did it fail?
• Can we reproduce it — and can we audit it six months from now?

These aren’t exotic questions. They’re the ones a platform team asks before it agrees to support new infrastructure in production, and standardized protocol metadata is what makes them answerable. With Mcp-Method and Mcp-Name riding alongside the trace context, requests correlate across services and gateways without custom parsing, dashboards and rate limits key off the operation instead of the payload, and the telemetry looks the same across different MCP implementations. That’s the difference between something a platform team can confidently run in production and something that stays a proof of concept.

Fan-Out Is Where This Gets Expensive

The stakes go up as organizations move toward agentic software. A single user request can fan out across multiple agents, several MCP servers, and dozens of tool invocations before anything comes back. Without standardized metadata, reconstructing what actually happened in that fan-out is slow and often guesswork.

With the routing headers and trace-context keys in place, each MCP interaction correlates cleanly with the telemetry you already collect, and the whole system gets easier to operate and troubleshoot. This is the same argument I keep coming back to: agentic systems only become enterprise systems when they’re as observable, governable, and auditable as every other critical application in the estate. This release moves MCP another step toward that bar.

More Than Stateless

Statelessness earns its headlines. Simpler deployments, better scalability, and lower operational complexity are real wins, and the changelog is worth reading in full. But the larger enterprise story is the standardized metadata that integrates naturally with the observability and tracing ecosystems organizations already trust.

Platform teams want a protocol that fits the infrastructure they already run, and the technologies that win in the enterprise are rarely the ones with the longest feature lists.

The claim I’ll defend is narrower than “MCP is enterprise-ready”: two required routing headers and three reserved trace-context keys quietly gave every gateway, trace, and audit log a common vocabulary for MCP traffic. In my experience, that’s the kind of unglamorous change that decides whether a protocol makes it out of the proof-of-concept stage.