Include OpenTelemetry Trace identifiers as part of the MCP client -> server protocol

[samsp-msft]

OpenTelemetry has quickly become the defacto standard for observability, and is being adopted as the observability platform for LLMs.

Distributed tracing enables tracking of complex calls within and between a set of services. Each service collects and transmits its own telemetry to a backend, which can stitch the records together to form the bigger picture based on a couple of identifiers being included in each request. This takes the form of a TraceId which is common for all related activity across a series of requests, and a parent SpanId which is used to form the activity graph. Http, database, LLM requests are typically all modelled as their own spans.

For http, those are a W3C standard header https://www.w3.org/TR/trace-context/.

For the stdio transport, there should be a standard field as part of the protocol for passing the telemetry IDs down. Including the traceparent and tracestate as optional parameters as part of JSON payload will make it much easier to track telemetry across the system.

For http based transports, if there are separate requests for each call, then no additional work is needed. I am not an expert on SSE, but if it streams over a single web request similar to websockets, then there probably needs to be a way to express the TraceIds as part of the JSON RPC payload.

[allenporter]

I've come across open-telemetry as difficult dependency when unit testing. For example, a python library enabled by open-telemetry by default and it was difficult to turn off or patch out network dependencies when unit testing. If considering this, please make sure its possible to not bring unnecessarily (I acknowledge it is totally possible to propagate tracing information without bloating a package and my experience may be based on a dependency unideal way to adopt/integrate this standard).

[samsp-msft]

I acknowledge it is totally possible to propagate tracing information without bloating a package and my experience may be based on a dependency unideal way to adopt/integrate this standard

This specific request is for the MCP protocol to include fields to propagate the trace correlation ids. The trace correlation data can/should be propagated without any MCP sdk having to take a dependency on OTel libraries. This is just passing the correlation information, and does not on its own require SDK dependencies or emitting data.

Each individual process uses their respective OTel SDKs to collect the telemetry, and transmit it to the Collector. That is done outside of the MCP SDKs. AFAIK most OTel SDKs are designed to be optional and shouldn't force additional dependencies on the MCP SDK for the respective languages.

Ideally the MCP SDKs for each language should look to see how OTel is done for that language and provide the hooks or use the core primitives (eg Activity in C#) to enable MCP as part of the telemetry ecosystem.

[Cirilla-zmh]

For the stdio transport, there should be a standard field as part of the protocol for passing the telemetry IDs down.

Definitely I support!

Including the traceparent and tracestate as optional parameters as part of JSON payload will make it much easier to track telemetry across the system.

I wonder weather you will enumerate all required keys (traceparent/tracestate) in specification or just leave a generic trace context carrier and recommend them as the parameters? Please consider the second solution given there're not only one choice of tracing protocol (some of what may be heterogeneous), even though in the opentelemetry world. ;)