MCP integration broken with mcp>=2.0.0: ModuleNotFoundError: No module named 'mcp.shared.session'

[felipepaivawebmotors]

Summary

The MCP integration (ddtrace.contrib.internal.mcp.patch) fails to patch when the mcp SDK is on 2.0.0+, because it imports mcp.shared.session.BaseSession and mcp.shared.session.RequestResponder, both of which no longer exist in mcp 2.0.0 (the module/architecture was rewritten around a dispatcher/peer design instead of the old Session class).

Environment

• ddtrace==4.8.2 through 4.13.0rc3 (latest available at time of filing) — confirmed the same import is still present in all of these
• mcp==2.0.0
• fastmcp==4.0.0b1 (the only fastmcp release line that resolves mcp>=2.0)
• Python 3.13/3.14

Steps to reproduce

1. Install ddtrace (any version up to 4.13.0rc3) alongside mcp==2.0.0 / fastmcp==4.0.0b1
2. Enable LLM Observability (LLMObs.enable(...)) in an application that imports mcp
3. Observe the integration fail with:

ModuleNotFoundError: No module named 'mcp.shared.session'

(In our case this is caught non-fatally by our own error handling, so it doesn't crash the app — but the MCP tool-call tracing/observability is silently disabled.)

Root cause

ddtrace/contrib/internal/mcp/patch.py does:

from mcp.client.session import ClientSession
from mcp.server.fastmcp.tools.tool_manager import ToolManager
from mcp.shared.session import BaseSession
from mcp.shared.session import RequestResponder

mcp.shared.session does not exist anywhere in mcp==2.0.0 — BaseSession and RequestResponder were removed as part of a broader architectural rewrite (the SDK now uses dispatcher.py, direct_dispatcher.py, peer.py, inbound.py, etc. instead of the old Session-based design). This isn't a renamed import path; there doesn't appear to be a direct equivalent to shim.

Why this matters now

mcp==2.0.0 was released the same day (2026-07-28) that it started being required to support a newer MCP protocol version (2026-07-28) that some MCP clients/gateways are starting to require for basic connectivity. Anyone upgrading mcp/fastmcp to stay compatible with those clients will silently lose ddtrace's MCP/LLM Observability instrumentation with no clear error surfaced unless they happen to have their own try/except around integration setup (as we did).

Ask

Could the MCP integration be updated to support mcp>=2.0's new dispatcher/peer architecture (with graceful fallback/version detection for older mcp<2.0 installs that still use BaseSession)? Happy to provide more repro details or test a patch against our setup if useful.