Title: Implement MCP Tracing with openinference-instrumentation-mcp in Langsmith

[mindful-time]

Checked

• I searched existing ideas and did not find a similar one
• I added a very descriptive title
• I've clearly described the feature request and motivation for it

Feature request

We need to integrate the MCP tracing functionality from the openinference-instrumentation-mcp repository into Langsmith. This will allow for better context propagation across distributed systems and improve monitoring and debugging capabilities.

You can find the relevant repository here:
openinference-instrumentation-mcp repository

And the feature request was done here too : langchain-ai/langsmith-docs#773

Motivation

This feature request is motivated by the need for better observability and tracking of requests in Langsmith's distributed system. Implementing MCP tracing would allow us to trace requests across multiple services, track context, and debug issues more effectively. This is essential for maintaining performance and ensuring reliability in a distributed environment.

Proposal (If applicable)

Analysis done by o3 on integration of the 2 modules.

Proposal — Adapting MCP Context-Propagation Patterns to LangSmith

1. Study the “shim-only” design
   openinference-instrumentation-mcp purposefully adds zero telemetry: it limits itself to injecting and extracting OTEL context so any spans created elsewhere link up automatically. That separation of concerns keeps the library tiny (≈8 KB on PyPI) and avoids hard-wiring transport details. LangSmith should emulate this minimal, transport-agnostic approach to stay framework-neutral. PyPI

2. Repurpose its core concepts, not its code

   • Propagator – a slim class that implements inject()/extract() for MCP messages (headers or JSON envelope).

   • Auto-instrumentor – a one-liner (e.g., MCPInstrumentor().instrument()) that plugs the propagator into OTEL’s global propagators.

   • Transport hooks – wrappers around the send and receive paths that call the propagator and forward everything else untouched.
     Those three ideas are the only moving parts; everything else (span creation, exporters, etc.) remains LangSmith’s responsibility. Arize AI | Arize Docs

3. Where it fits in LangSmith

   LangSmith layer | Needed change | Analogy in openinference-instrumentation-mcp -- | -- | -- Client SDK (chains/agents calling external MCP tools) | Before sending a POST /mcp (or equivalent), call inject() to add a traceparent header or context.traceparent field. | Client wrapper Server / Tool runtime | On request entry, call extract() to resume the parent span; on completion, end the server span. | Server middleware Background jobs / async tasks | Pass the same context object through task queues so cross-process traces stay intact. | Queue integrations in OTEL ecosystem

4. Implementation milestones

   1. Spike – copy the interface (not code) of the MCP propagator, wire it to LangSmith’s existing OTEL setup, and run the Phoenix tutorial trace as an integration test.

   2. Hardening – add unit tests for header/JSON injection, concurrency stress-tests, and fallback behaviour when no parent span exists.

   3. Docs & examples – a 10-line quick-start similar to the Phoenix release note:

      python
      CopyEdit
      pip install opentelemetry-sdk opentelemetry-exporter-otlp
      # once merged into LangSmith
      from langsmith.tracing import enable_mcp_propagation
      enable_mcp_propagation()
      

   4. Optional future work – server-side span naming conventions (e.g., mcp.<tool_name>) and attribute enrichment, following OpenInference semantic conventions.

5. Expected benefits

   • End-to-end trace continuity across chains, tools, and services.

   • No additional vendor lock-in—works with any OTEL backend (Phoenix, Honeycomb, Grafana, etc.).

   • Tiny code-surface; easy to maintain and upgrade alongside upstream changes.

Proposal — Adapting MCP Context-Propagation Patterns to LangSmith Study the “shim-only” design openinference-instrumentation-mcp purposefully adds zero telemetry: it limits itself to injecting and extracting OTEL context so any spans created elsewhere link up automatically. That separation of concerns keeps the library tiny (≈8 KB on PyPI) and avoids hard-wiring transport details. LangSmith should emulate this minimal, transport-agnostic approach to stay framework-neutral. [PyPI](https://pypi.org/project/openinference-instrumentation-mcp/)

Repurpose its core concepts, not its code

Propagator – a slim class that implements inject()/extract() for MCP messages (headers or JSON envelope).

Auto-instrumentor – a one-liner (e.g., MCPInstrumentor().instrument()) that plugs the propagator into OTEL’s global propagators.

Transport hooks – wrappers around the send and receive paths that call the propagator and forward everything else untouched.
Those three ideas are the only moving parts; everything else (span creation, exporters, etc.) remains LangSmith’s responsibility.
Arize AI | Arize Docs

Where it fits in LangSmith

LangSmith layer Needed change Analogy in openinference-instrumentation-mcp
Client SDK (chains/agents calling external MCP tools) Before sending a POST /mcp (or equivalent), call inject() to add a traceparent header or context.traceparent field. Client wrapper
Server / Tool runtime On request entry, call extract() to resume the parent span; on completion, end the server span. Server middleware
Background jobs / async tasks Pass the same context object through task queues so cross-process traces stay intact. Queue integrations in OTEL ecosystem

Implementation milestones

Spike – copy the interface (not code) of the MCP propagator, wire it to LangSmith’s existing OTEL setup, and run the Phoenix tutorial trace as an integration test.

Hardening – add unit tests for header/JSON injection, concurrency stress-tests, and fallback behaviour when no parent span exists.

Docs & examples – a 10-line quick-start similar to the Phoenix release note:

python
Copy
Edit
pip install opentelemetry-sdk opentelemetry-exporter-otlp

once merged into LangSmith

from langsmith.tracing import enable_mcp_propagation
enable_mcp_propagation()
Optional future work – server-side span naming conventions (e.g., mcp.<tool_name>) and attribute enrichment, following OpenInference semantic conventions.

Expected benefits

End-to-end trace continuity across chains, tools, and services.

No additional vendor lock-in—works with any OTEL backend (Phoenix, Honeycomb, Grafana, etc.).

Tiny code-surface; easy to maintain and upgrade alongside upstream changes.