An operations team wants each tools/call request from a host to appear in the same distributed trace as the spans the server sends to their tracing backend. How should trace context travel with the MCP request?
Select an answer to reveal the explanation.
Short Explanation
You want a relay baton that every runner passes along, and MCP already reserves one: traceparent, tracestate and baggage in _meta. Stuff the trace ID anywhere else and you've broken something else to do it. Ids and progress tokens have their own jobs.
Full Explanation
The base protocol reserves the _meta keys traceparent, tracestate and baggage for OpenTelemetry trace context propagation, as an explicit exception to the prefix rule for _meta keys. When present, their values MUST follow the W3C Trace Context and W3C Baggage formats, which keeps MCP compatible with the OpenTelemetry semantic conventions for MCP, so a server can continue the caller's trace and its spans join the same distributed trace. Hiding a trace ID in clientInfo abuses a field meant to carry the client's name and version for display, logging and debugging, and tracing tools would not recognize it. Using the trace ID as a progressToken overloads a value that must be unique across active requests and only opts the request into progress notifications. Reusing it as the JSON-RPC id breaks protocol rules: a sender must not reuse an id still awaiting a response, and a multi round-trip retry MUST carry a new id, so the trace would fork exactly where it is most needed. Exam caveat: the deprecated Logging feature's migration path is OpenTelemetry for structured observability, which is the same toolchain this trace context feeds. Operational check: send a tools/call with a known traceparent and confirm the server's spans appear under that trace ID in the backend.