[FEATURE] Propagate MCP session/trace context in tool calls (`_meta`, SEP-414)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code currently does not provide a stable way for MCP servers/gateways to correlate tool calls that belong to the same Claude Code conversation/session.

This matters for MCP servers that need per-session policy, audit, security review, observability, or live dashboards. Today, an MCP server can see individual tool calls and transport sessions, but it cannot reliably answer:

• are these tool calls part of the same Claude Code chat/session?
• did this request come from the same Claude Code instance after reconnect?
• should this tool call inherit prior per-session policy state?
• how do I correlate Claude Code tool calls into one trace across my gateway, backend, and downstream services?

This becomes especially painful with Streamable HTTP/SSE behavior. The transport can disconnect or refresh, and clients may reconnect or create new MCP sessions. Without a stable client session id or propagated trace context, MCP servers have to infer identity from transport lifecycle, which is fragile.

ChatGPT recently added similar metadata for Apps SDK tool calls: _meta["openai/session"], described as an anonymized conversation id that can be used to correlate requests within a ChatGPT session.

Proposed Solution

Please add support for propagating session/trace context on MCP tool calls from Claude Code.

Ideally Claude Code would the standard OpenTelemetry/W3C trace context in params._meta, following SEP-414:

  {
    "method": "tools/call",
    "params": {
      "name": "some_tool",
      "arguments": {},
      "_meta": {
        "traceparent": "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01",
        "tracestate": "...",
        "baggage": "..."
      }
    }
  }

The stable session id should be:

• consistent for tool calls in the same Claude Code conversation/session
• anonymized and not directly user-identifying
• stable across MCP transport reconnects where the user is continuing the same conversation
• different for unrelated Claude Code sessions/conversations
• available to all MCP transports, not only stdio or HTTP

This would let MCP servers implement reliable per-session policy state, audit logs, dashboards, and trace correlation without coupling correctness to SSE/transport lifetimes.

Alternative Solutions

Do the same as ChatGPT/OpenAI and implement an anonymized Claude Code session id in params._meta, for example:

  {
    "method": "tools/call",
    "params": {
      "name": "some_tool",
      "arguments": {},
      "_meta": {
        "anthropic/session": "anon-stable-session-id"
      }
    }
  }

Priority

Critical - Blocking my work

Feature Category

MCP server integration

Use Case Example

I run an MCP gateway that applies organization policy to tool calls and shows a live dashboard of connected MCP sessions.

Example workflow:

1. I open Claude Code and connect it to an MCP server.
2. Claude Code calls a safe/read-only tool.
3. Later in the same conversation, Claude Code calls a state-changing or private-data tool.
4. The MCP gateway needs to know this is the same Claude Code session so it can apply policy using prior session context.
5. If the MCP transport reconnects, the gateway should not lose the ability to correlate future tool calls with the same user workflow.
6. In production, I also want logs/traces from Claude Code → MCP gateway → downstream services to be correlated in OpenTelemetry.

Without client-provided session/trace metadata, the gateway has to treat transport lifecycle as session lifecycle, which is not reliable.

Additional Context

• OpenAI Apps SDK changelog, 2026-01-15: ChatGPT tool calls include _meta["openai/session"], an anonymized conversation id for correlating requests within a ChatGPT session
• MCP SEP-414 documents OpenTelemetry trace context propagation conventions using params._meta keys:
• traceparent
• tracestate
• baggage
• OpenTelemetry MCP semantic conventions also recommend propagating W3C trace context through MCP params._meta