MCP's July spec deprecates protocol-level Logging in favour of OpenTelemetry traces

The dev.to guide behind this account opens on a production failure. A tool call failed and the agent's whole report was "I wasn't able to retrieve that." ^[16] The agent was, in its way, accurate. Nothing else came with it: no stack trace, timing or tool name ^[16].

The cause the guide describes is a split trace. The agent framework emits a span for the LLM call and a child span for the tool use ^[11]. When the request crosses into the MCP server, a new trace starts with no parent ^[11]. One operation now has two traces, and neither can be searched by the other's ID ^[11]. In the guide's example, a checkout agent takes 40 seconds. The agent trace shows 40 seconds of "tool call" and the server trace shows 38 seconds of something ^[12]. That leaves 2 seconds between the two with no span to own them ^[1]. "Joining them is manual archaeology," the author wrote ^[12].

The repair is propagation inside the message. The client writes W3C Trace Context into the request's params._meta under the unprefixed keys traceparent, tracestate and baggage ^[5]. The server reads them and opens its span as a child of the client span ^[7]. The guide says that parent link holds regardless of transport ^[7]. That follows from where the keys sit: in the request params, so the link does not depend on HTTP headers ^[2]. Fixing the key names is the right call, because a client and server from different SDKs then only have to agree on three strings. According to the guide, the spec documented exactly that, so traces correlate across SDKs and render as one span tree ^[6].

The deprecation details come from the guide's summary of the spec. Per the guide, MCP servers invented their own log formats and shipped them over the protocol, and those never aggregated well ^[13]. Under the OpenTelemetry model, log detail is attached to a span, not sent as a separate stream ^[14]. Roots, Sampling, Logging and HTTP+SSE are the first deprecations under MCP's new formal feature lifecycle policy ^[3]. Each keeps a minimum twelve-month support window ^[2]. Counted from the spec date, Logging support can end no earlier than 2027-07-28 ^[3].

For teams already on notifications/message logging, the author wrote: "Do not rewrite in a panic, but do not build anything new on it either." ^[9] I think that sequencing is right. The split trace costs debugging time on every slow tool call today, so I'd rebuild tracing now and let the Logging window set only the outer date ^[3].

OpenTelemetry's GenAI semantic conventions now carry a dedicated MCP section with defined span names, attributes and metrics ^[4]. The guide says they are not stable yet and to expect attribute renames ^[8]. Its advice is to pin the instrumentation version ^[8]. I'd treat each version bump as a schema migration, because every dashboard and alert keyed to an attribute name has to move with it.

The rest of the release points the same way, per the guide: a stateless core, header-based routing via Mcp-Method and Mcp-Name, and cacheable list results carrying ttlMs and cacheScope ^[15]. The author argues all of it assumes you can see across many short-lived requests instead of one long session ^[15].