feat(contrib/mark3labs/mcp-go): set session ID on tool spans at start time

[jboolean]

This PR stack ports functionality added in the clone of this contrib in dd-source back to dd-trace-go.

Summary

Pass llmobs.WithSessionID at StartToolSpan time so LLMObs groups tool spans under their MCP session natively. The session is read from server.ClientSessionFromContext(ctx) if present.

The existing mcp_session_id tag is unchanged — they are complementary: the tag exposes the session ID to span search/filtering, while WithSessionID populates the LLMObs session field used for trace grouping.

Provenance

No single dd-source PR — the change landed as part of a series of LLMObs-session changes. The current dd-source middleware lives at mcp-go/tracing.go#L36-L44:

var toolHandlerMiddleware = func(next server.ToolHandlerFunc) server.ToolHandlerFunc {
    return func(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) {
        // Note: WithIntegration is not yet in released llmobs package and cannot be used here
        var startOpts []llmobs.StartSpanOption
        if session := server.ClientSessionFromContext(ctx); session != nil {
            startOpts = append(startOpts, llmobs.WithSessionID(session.SessionID()))
        }
        toolSpan, ctx := llmobs.StartToolSpan(ctx, request.Params.Name, startOpts...)

This PR ports that exact pattern, additionally keeping the existing llmobs.WithIntegration(...) call since the released llmobs package now has it.

Test plan

• Extended TestIntegrationToolCallSuccess to assert toolSpan.SessionID matches the MCP client session.
• Existing tracing tests still pass.

Stacked on #4942.

[jboolean]

• feat(contrib/mark3labs/mcp-go): support redacting tool output in LLMObs traces #4945
• feat(contrib/mark3labs/mcp-go): support per-request intent capture #4944
• feat(contrib/mark3labs/mcp-go): set session ID on tool spans at start time #4943 👈 (View in Graphite)
• feat(contrib/mark3labs/mcp-go): skip telemetry injection for UI-only tools #4942
• feat(contrib/mark3labs/mcp-go): expose captured intent to tool handlers via context #4941
• fix(contrib/mark3labs/mcp-go): preserve raw input schema fields on intent injection #4946
• fix(contrib/mark3labs/mcp-go): avoid map race when normalizing RawInputSchema #4940
• feat(contrib/mark3labs/mcp-go): support intent capture for tools using RawInputSchema #4939
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[datadog-datadog-prod-us1]

 

✨ Fix all issues with BitsAI

⚠️ Warnings

🚦 1 Pipeline job failed

Pull Request Tests | PR Unit and Integration Tests (1.26) / test-core     

ℹ️ Info

No other issues found (see more)

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 62.79%

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: f6787f2 | Docs | Datadog PR Page | Give us feedback!}

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-07-01 16:40:01

Comparing candidate commit f6787f2 in PR branch jb/mcp-tool-span-session-id with baseline commit 2ff4a7b in branch jb/mcp-skip-ui-only-tools.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 321 metrics, 2 unstable metrics, 1 flaky benchmarks without significant changes.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

• 🟩 = significantly better candidate vs. baseline
• 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

Known flaky benchmarks

These benchmarks are marked as flaky and will not trigger a failure. Modify FLAKY_BENCHMARKS_REGEX to control which benchmarks are marked as flaky.

Known flaky benchmarks without significant changes:

• scenario:BenchmarkOTLPTraceWriterFlush

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (jb/mcp-skip-ui-only-tools@5f2c10d). Learn more about missing BASE report.

Additional details and impacted files

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[datadog-datadog-us1-prod]

More details

The diff is a clean, minimal port from dd-source. Three adversarial scenarios were executed: a tool call with a valid session (session_id field matches mcp_session_id tag), a tool call with no session in context (both fields empty, no panic), and a tool call with an empty-string session ID (gracefully falls through to propagation). All 18 tests pass. One test was added covering the no-session branch through toolHandlerMiddleware, which no existing test exercised.

Was this helpful? React 👍 or 👎

_{📊 Validated against 3 scenarios · Open Bits AI session}

_{🤖 Datadog Autotest · Commit 716a66d · What is Autotest? · Any feedback? Reach out in #autotest}