Skip to content

SEP-2448: MCP server execution telemetry#2448

Open
savula15 wants to merge 4 commits intomodelcontextprotocol:mainfrom
savula15:feat/server-execution-telemetry
Open

SEP-2448: MCP server execution telemetry#2448
savula15 wants to merge 4 commits intomodelcontextprotocol:mainfrom
savula15:feat/server-execution-telemetry

Conversation

@savula15
Copy link
Copy Markdown

@savula15 savula15 commented Mar 24, 2026

Motivation and Context

This PR proposes a new MCP Standards Track SEP, Server Execution Telemetry, which defines an optional capability for MCP servers to return OpenTelemetry spans to clients in-band via _meta.otel on tools/call and resources/read responses.

Today, SEP-414 enables clients to propagate traceparent into MCP servers, but there is no standard way for servers to return execution telemetry to clients. This creates an observability gap in cross-organization MCP deployments, where tool execution and resource reads are otherwise opaque to the caller.

This SEP addresses that gap by:

  • introducing the serverExecutionTelemetry server capability
  • allowing clients to explicitly request span passback per call
  • requiring returned spans to use standard OTLP JSON (resourceSpans) so they can be ingested directly into the client’s existing observability backend

The proposal is explicitly opt-in on both sides and is additive to the protocol.

How Has This Been Tested?

This PR is backed by:

  • specification design and review against existing MCP request/response patterns
  • alignment with SEP-414 for request-side trace propagation
  • a reference implementation in Arcade MCP: feat/server-execution-telemetry (PR #797)

Breaking Changes

None.

This is a specification-only change that introduces a new optional capability. Existing MCP clients and servers that do not recognize or implement this capability continue to behave as they do today.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

This SEP complements SEP-414 by defining the response-side mechanism for distributed trace stitching across MCP boundaries.

Reference implementation:

  • Arcade MCP: feat/server-execution-telemetry (PR #797)

Explainer video: TBD

Acknowledgements

@savula15 savula15 force-pushed the feat/server-execution-telemetry branch from 0efab48 to 3a7ba19 Compare March 24, 2026 00:30
@localden localden added proposal SEP proposal without a sponsor. SEP labels Mar 24, 2026
@localden localden changed the title mcp server execution telemetry SEP-2448: MCP server execution telemetry Mar 24, 2026
@savula15 savula15 force-pushed the feat/server-execution-telemetry branch from 180b328 to 3faa2f4 Compare March 24, 2026 16:52
EricGustin pushed a commit to ArcadeAI/arcade-mcp that referenced this pull request Mar 25, 2026
…pability (#797)

**Implements**: [SEP-2448: server execution telemetry]
(modelcontextprotocol/modelcontextprotocol#2448)



**Description:**

**The Observability Gap (The Problem)**

MCP clients propagate trace context to servers, but server-side
execution remains a black box. The client sees a single tools/call or
resources/read span; everything the server does (auth checks, policy
evaluation, API calls, sub-tool invocations) is invisible. In
cross-organization deployments, clients and servers use separate
observability backends with no shared collector access, making
traditional span export useless.

<img width="1015" height="450" alt="Screenshot 2026-03-23 at 3 43 21 PM"
src="https://github.com/user-attachments/assets/58c817b5-fee6-46a3-9877-d523a25368ad"
/>


**Server Execution Telemetry (The Solution)**

Servers advertise serverExecutionTelemetry and return a curated slice of
their execution spans directly in _meta.otel of the response. Clients
ingest these verbatim OTLP spans into their own collector, stitching
server-side execution into their distributed trace; no shared
infrastructure required. The black box becomes transparent.

<img width="945" height="574" alt="Screenshot 2026-03-23 at 3 43 44 PM"
src="https://github.com/user-attachments/assets/38d97c94-aa73-4e62-9b4e-3264600e5ed0"
/>

.
**Summary:**

Implement MCP serverExecutionTelemetry capability that enables
cross-organization distributed tracing by returning server-side
OpenTelemetry spans to clients inline via _meta.otel.traces.

  Server-side (middleware):
  - TelemetryPassbackMiddleware intercepts tools/call and resources/read
- ContextVarSpanCollector isolates span collection per-request via
ContextVar
- Propagates traceparent from client request for distributed trace
stitching
- Serializes collected spans to verbatim OTLP JSON (resourceSpans
format), directly POSTable to /v1/traces
- Top-level span filtering by default; full span tree via detailed
opt-in
- Middleware advertises capabilities via get_capabilities() on the
Middleware base class
  - Provisional API: FutureWarning emitted until SEP-2448 is ratified

  Client-side (reference agent):
- LangChain ReAct agent connects to MCP server via
streamable_http_client with OAuth 2.1
  - Detects serverExecutionTelemetry capability at initialization
- Dynamically wraps discovered MCP tools with traceparent propagation
and _meta.otel span request
- Ingests returned server spans into Jaeger (OTLP JSON) and Galileo
(OTLP protobuf)
- Two-act demo: --no-passback (black box) vs default (full server-side
visibility)

  Dependencies:
  - opentelemetry-api and opentelemetry-sdk added to arcade-mcp-server

  Bump arcade-mcp-server version to 1.18.0.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

proposal SEP proposal without a sponsor. SEP

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

2 participants