-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
feat(develop): Add distributed tracing for MCP #15752
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
betegon
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
btw we don't support mcp clients, is something we're considering now?
| ## Distributed Tracing | ||
|
|
||
| Traces should be continued when a client makes a tool call request to an MCP server and both the client and server are instrumented. To do so, we inject both the trace parent (sentry-trace) and baggage into the `_meta` field of the request, and pick these up on the server. The tracing metadata attached in the `_meta` field is the same as the metadata contained in HTTP headers in HTTP-based trace continuation. | ||
|
|
||
| The SDK must respect any existing metadata in `_meta`. If previously empty, the `_meta` field must have the form | ||
|
|
||
| ```json | ||
| "_meta": { | ||
| "sentry-trace": "...", | ||
| "baggage": "...", | ||
| } | ||
| ``` | ||
|
|
||
| where "sentry-trace" is analogous to the [`sentry-trace` HTTP header](/sdk/telemetry/traces/#header-sentry-trace) and "baggage" is analogous to [`baggage` HTTP header](/sdk/telemetry/traces/dynamic-sampling-context/#baggage-header). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can already think about how we can support mixed OTLP/Sentry instrumentation here. As in, can we rely on the traceparent header instead of our sentry-tace header?
Also, which options should define if we perform propagation? tracePropagationTargets or something new?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good call, I don't see any reason we shouldn't use traceparent instead of sentry-trace for MCP.
I should also spec out what happens over Streamable HTTP. Both headers and MCP _meta can be used to propagate tracing metadata in that case, but headers have the limitation that in Streamable HTTP there's one connection for multiple tool calls.
In terms of options, we could have tracePropagationTargets for tool names instead of URLs. See the params.name field in tools/call requests:
https://modelcontextprotocol.io/specification/2025-06-18/server/tools#calling-tools
But tracePropagationTargets should probably still apply when the MCP is mounted on HTTP.
DESCRIBE YOUR PR
Add specification for trace propagation over the MCP protocol.
IS YOUR CHANGE URGENT?
Help us prioritize incoming PRs by letting us know when the change needs to go live.
SLA
Thanks in advance for your help!
PRE-MERGE CHECKLIST
Make sure you've checked the following before merging your changes:
LEGAL BOILERPLATE
Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.
EXTRA RESOURCES