MCP deprecates protocol Logging, Roots, Sampling and HTTP+SSE; OpenTelemetry is the replacement

Four protocol features are now on a clock

According to a dev.to write-up on MCP observability, the 2026-07-28 revision of the Model Context Protocol deprecated four protocol-level features in a single release: Logging, Roots, Sampling and the legacy HTTP+SSE transport. These were the first deprecations issued under MCP's formal feature lifecycle policy, and each carries a minimum twelve-month support window. For teams whose servers emit log notifications over the protocol, that puts the practical cutoff at roughly mid-2027.

Logging is the deprecation with the most immediate operational fallout. Servers had been free to invent their own log formats and push them across the wire, and the result never aggregated cleanly across servers or backends. Notably, the spec's replacement is not a new MCP logging feature — it is OpenTelemetry.

What replaces protocol logging

Two pieces come together. First, the revision documents W3C Trace Context propagation with fixed, unprefixed keys — traceparent, tracestate and baggage — carried inside the request's params._meta. Because _meta travels with each request regardless of transport, context survives gateways that rewrite headers and even stdio, which has no headers at all. The client-side span becomes the parent of the server-side span no matter the transport, which is what repairs previously split traces.

Second, OpenTelemetry's GenAI semantic conventions gained a dedicated MCP section, maintained in the semantic-conventions-genai repository by a special interest group that formed in April 2024. The guidance is to prefer the MCP conventions over generic RPC conventions, since MCP spans can record tool identity, protocol version and the message exchanges inside a streaming call that RPC spans cannot represent.

Why traces break at the MCP boundary

The dev.to post describes a familiar failure mode: the agent framework emits a span for the LLM call and a child span for tool use, then the request enters the MCP server and a fresh, parentless trace begins. One logical operation ends up as two traces that cannot be correlated by ID, and working out why an agent stalled for forty seconds means hand-matching timestamps across two systems.

The root cause is structural. JSON-RPC over HTTP has no obvious home for trace headers, and the transport's headers are not always yours to control. The stateless direction of the new spec made this harder, not easier: without Mcp-Session-Id, teams lost the one correlation key many had quietly leaned on. Every request now travels alone, carrying its protocol version, client identity and capabilities in _meta — which is exactly where trace context lives too.

The vocabulary to migrate toward

The conventions define one span name format for both sides: {mcp.method.name} {target}, so a tool call appears as tools/call get_invoice rather than a generic POST /mcp. The client span is kind CLIENT, the server span kind SERVER, and dashboards can group by tool without parsing request bodies.

The required attribute is mcp.method.name. Conditional attributes include rpc.request.id, mcp.resource.uri, error.type and rpc.response.status_code. Recommended ones include gen_ai.operation.name (set to execute_tool for tool calls), mcp.protocol.version, mcp.session.id and network.transport. Two attributes — gen_ai.tool.call.arguments and gen_ai.tool.call.result — are opt-in because tool payloads routinely contain customer records, tokens and internal identifiers; the advice is to enable them in staging, sample aggressively in production and scrub before export.

Four metrics round out the set: client and server operation duration, plus client and server session duration. The client/server split is deliberate, since the gap between them measures transport, gateway and queueing cost, which is often where unexplained time goes. The post also singles out mcp.protocol.version as the most useful attribute once you support two spec revisions, because it shows which clients remain on the old path.

Practical migration notes

The post's read on the deadline: do not rewrite in a panic, but build nothing new on the deprecated features. Also expect churn — the semantic conventions are not stable yet, so pin your instrumentation versions and anticipate attribute renames. The rest of the 2026-07-28 release pushes the same stateless direction, including header-based routing via Mcp-Method and Mcp-Name and cacheable list results carrying ttlMs and cacheScope, all of which assume visibility across many short-lived requests rather than one long session.

Why it matters

This deprecation turns observability from a nice-to-have into a scheduled migration item for anyone running MCP servers in production. Teams that skip it face a deadline around mid-2027 and, in the meantime, agent failures investigated by hand across disconnected traces — including the most expensive kind, where a model returns a confident, incorrect answer built on a bad tool result that nobody flags. The pieces needed to fix this now exist and are vendor-neutral; the remaining work is adopting them before the clock runs out.