MCP got an update, and OTel got a promotion

The MCP specification release candidate today deprecates protocol-level logging, which is worth paying attention to if you care about observability. With the release, MCP servers stop inventing their own log formats and emit OpenTelemetry data instead. The spec change acts as guidance for every MCP implementer to stop building custom logging, and to use the observability tools built for this.

Before this, MCP logging had its own protocol-specific format. It was structured by severity level, but isolated from the tracing and log infrastructure teams already run. A log message had no natural link to a span, and consuming it meant building MCP-specific tooling instead of pointing your existing OpenTelemetry pipeline at it.

The evolution towards that separation of concerns began with the foundation of OpenTelemetry's GenAI Special Interest Group and LLM call in 2024. The group’s recommendation has since expanded its semantic conventions to cover agent orchestration and MCP tool calling directly. MCP's deprecation today lines up with where the rest of the ecosystem already moved, which is to have tools focused on their specific roles and strengths.

This update to the protocol makes the right call. MCP servers should hand observability data to the observability tools built to handle it, instead of maintaining their own, and focus on the priorities where it delivers critical value.

An MCP server’s job should be to expose tools and handle calls. When a MCP server is trying to also emit traces it’s problematic because it:

• Emits fragmented traces and incomplete instrumentation
• Produces inconsistent definitions of what a span is for each server that is developed. There’s no shared schema across MCP servers and you can’t correlate across spans to perform reliable root cause analysis with the spans. 
• Duplicates cost and effort. This one is simple. Why reinvent the wheel when an instrumentation standard already exists? 
• Rots quickly. 

Where the story usually stops

Tools built specifically to watch AI agents were built to watch agents, not the infrastructure sitting behind them. Their instrumentation stops at the tool-call span because that's the edge of what they were designed to see. The MCP server’s database queries, its downstream calls, and the infrastructure the server runs on are all opaque to those tools.

Think about the example where an agent calls a tool. The tool is slow, or it fails, or it returns something empty. With MCP you could see that the agent picked the right tool and passed the right arguments. What you can't see is why the database query increased in latency or which pod choked under load. 

Where full-stack observability picks up

The decision to deprecate protocol-level logging in favor of full stack OTel traces mirrors the same approach to AI and full stack observability that groundcover has taken from the start. groundcover already traces services, infrastructure, and database calls across a stack, independent of anything AI-related. Extending that trace through an MCP tool call, into what the server actually does next is the same tracing groundcover already does, pointed at a new kind of caller.

Picture one continuous trace: the agent's decision, the tool call, the MCP server picking it up, the database query it runs, the pod it runs on. One trace, one place to look, instead of stitching together an APM tool, an AI-observability tool, and an infra dashboard by hand.

The MCP spec change enabling this is live now. We're building the trace view for it, and we'll show it the moment it's ready. In the interim, engineering teams get OTel support for MCP that gives them a clean span for the tool call. What was formerly a patchwork set of data points now unifies with name, duration, maybe token or cost metadata. That's real, and it's more than most setups had before this release.

What it could look like

To better understand why full stack observability is critical for AI workloads and custom agents, let’s look at the following hypothetical example. 

Hypothetical Scenario: An agent calls a tool to look up a customer's order status. The call takes 3.8 seconds — slow enough that someone notices.

AI-observability-only trace (stops at the tool call)

▾ agent.reasoning                                    0ms → 40ms
  "user asked about order #48213, calling get_order_status"

▾ tool_call: get_order_status                        40ms → 3840ms  ⚠ SLOW
  args: { order_id: "48213" }
  result: { status: "shipped", eta: "2026-08-02" }

▾ agent.response                                     3840ms → 3870ms
  "Your order shipped, arriving Aug 2"

That's the whole trace. The tool call took 3.8 seconds. Why? You have no idea. The span ends the moment the MCP server returns and so did your understanding of the problem-scape.

Full-stack trace (continues into the MCP server and infra)

▾ agent.reasoning                                    0ms → 40ms
  "user asked about order #48213, calling get_order_status"

▾ tool_call: get_order_status                        40ms → 3840ms  ⚠ SLOW
  args: { order_id: "48213" }
  │
  ├─▾ mcp_server: orders-service (pod: orders-7f9d-x2k1)
  │   │
  │   ├─▾ db_query: SELECT * FROM orders WHERE id = ?    120ms → 3690ms  ⚠ SLOW
  │   │   query_plan: seq_scan (missing index on order_id)
  │   │   rows_scanned: 1,240,000
  │   │
  │   └─▾ cache_lookup: redis GET order:48213             3690ms → 3710ms
  │       result: MISS
  │
  └─▾ node: gke-prod-pool-3 (cpu: 91%, mem: 74%)
      note: node under memory pressure during query window

▾ agent.response                                     3840ms → 3870ms
  "Your order shipped, arriving Aug 2"

In this example we see the same tool call spanning over 3.8 seconds, but now the trace shows a missing index causing a sequential scan over 1.2M rows, on a node that was already under memory pressure. That detailed trace highlights a problem with a concrete fix: add the index, or move the pod off that node. 

The first trace just tells you something was slow.

Why this matters

When a tool call is slow, the engineering team has to answer more than just "which tool." They have to know whether the delay came from the model, the tool schema, the MCP server's logic, the database, or the box it ran on. Full-stack tracing turns that into one query instead of three tools and a guess.

The explicit state handles in this same MCP release — a basket_id or task_id passed between calls — double as a filter key once they're attached to spans: pull every span tagged with one task and see the whole workflow. It's a smaller claim than "traceable by design," but it's a real, usable side effect of making state explicit instead of hidden.

Carefully designed custom agents are also shipped with guardrails for tool usage and the new MCP specification lets you verify them. “Call the auth check before the payment.” “Never hit that endpoint without a confirmation step.” “Stay inside these arguments.” The agent will tell you it followed all of these directions. The question is whether an engineer can prove it. Full-stack traces are where the proof lives: you watch the agent pick a tool, see the exact arguments it passed, and follow the call down through the MCP server to what actually ran. Not the plan it reported. 

With agents making tool calls on their own, full stack observability is critical both for the user who gets a broken experience and for the engineering teams that needs to know an agent stayed inside its guardrails instead of just saying it did.

Close

The OTel and MCP convergence is good for the ecosystem, and groundcover is building with it in mind. Want to be first to see the trace once it's ready? Deploy groundcover to your own cluster. It takes an hour or less, and you can see LLM traces in your cloud without instrumentation.