[FEATURE] Propagate Cowork/Claude session trace context (prompt.id) into MCP tool calls via _meta (SEP-414)

Preflight Checklist

• [x] I have searched existing requests — this refines the now-stale #54629, #61517, #54010 with fresh empirical evidence and standards backing.
• [x] This is a single feature request.

Problem Statement

Claude Cowork (and Claude Code) do not propagate any session/prompt/trace identifier into the MCP tool-call request. As a result, a remote MCP server that logs its own request/response (for observability, audit, or cost tracking) has no reliable key to correlate its records back to the Cowork session/prompt that triggered them.

This breaks the otherwise-natural "full flow" observability story: Cowork's OTel export carries a prompt.id/session.id linking all events of a turn, but that identifier stops at the MCP boundary — the MCP server never receives it.

Empirical evidence (we verified this directly)

We instrumented a remote MCP server (@modelcontextprotocol/sdk Streamable HTTP) to log the full RequestHandlerExtra on every tool call from a live Cowork session:

• extra._meta → null (Cowork sends no _meta trace context)
• extra.sessionId → null
• HTTP headers present: traceparent, baggage, x-anthropic-client: Cowork, ...
• The traceparent header is a fresh, per-HTTP-request value (e.g. 00-25d9d261b03ab43f416f2dd958a356aa-...) that does not match the Cowork OTel trace id and appears nowhere in the exported traces — so it's useless for correlation.
• The baggage header carries only Sentry context (sentry-trace_id=0000..., sentry-environment, sentry-release), not Cowork's session.id/prompt.id.

So neither the transport traceparent header nor baggage nor _meta carries the OTel prompt.id/session.id. Correlation is currently only possible via a fragile composite of tool-name + server + timestamp-window + duration + success/failure.

Proposed Solution

Inject the active Cowork/Claude session's W3C trace context into every outgoing MCP tools/call request as _meta.traceparent (and _meta.tracestate / _meta.baggage), per:

• MCP SEP-414 / spec RC 2026-07-28 — which standardizes exactly these _meta keys for W3C trace context: https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/
• OTel GenAI MCP semantic conventions: https://opentelemetry.io/docs/specs/semconv/gen-ai/mcp/

Ideally the propagated trace context corresponds to (or embeds) the same prompt.id/session.id used in Cowork's OTel export, so an MCP server can join its logs to the Cowork trace by an exact key.

Why now

• The 2026-07-28 spec RC now standardizes the _meta.traceparent/tracestate/baggage keys, giving this a concrete, interoperable target that the earlier requests (#54629, #61517, #54010 — all auto-closed as stale, not rejected) lacked.
• This is the missing link for MCP-side observability and full-flow tracing (e.g. correlating a self-hosted MCP's request/response logs with Langfuse/Elastic traces of the Cowork session).

Environment

• Claude Cowork (Team), macOS
• Remote MCP servers on Cloud Run using @modelcontextprotocol/sdk Streamable HTTP