Support for upcoming Python MCP SDK v2.0.0

[dleehr]

The Python MCP SDK is about to release version 2.0.0 with support for the forthcoming 2026-07-28 protocol version. It's currently available in prerelease 2.0.0b2, but expected to release soon. The migration guide (https://py.sdk.modelcontextprotocol.io/v2/migration/) indicates it is a breaking change, so I'm curious if it will be compatible here.

Is langchain-mcp-adapters being tested with this v2 SDK?

[dleehr]

FYI, from https://github.com/modelcontextprotocol/python-sdk:

If your package depends on mcp, add a <2 upper bound to your version constraint (for example mcp>=1.27,<2) before the stable release lands.
v2 is a major rework of the SDK, both to support the 2026-07-28 MCP specification release and to fix long-standing architectural issues. See What's new in v2 for the tour of what changed, and the migration guide for every breaking change. Stable v2 is targeted for 2026-07-27, alongside the spec release. Try the pre-releases and tell us what breaks, or discuss in #python-sdk-dev on the MCP Contributors Discord.

[dleehr]

I forked and created a branch to try the upgrade: main...dleehr:langchain-mcp-adapters:mcp-v2-upgrade.

Seems to be working and the tests passed locally. It's mostly converting to snake_case and correcting imports. Plus, the websocket transport is removed

[mokronos]

MCP 2.0.0 is now stable, and fresh installs currently resolve it because the adapter declares only mcp>=1.24.0. The adapter then fails at import time with:

ImportError: cannot import name 'RequestContext' from 'mcp.shared.context'

I opened #588 to add the recommended <2.0.0 upper bound as an immediate safeguard. The broader MCP v2 migration can remain tracked here.

[AadhavanP313]

MCP 2.0.0 is now stable, and fresh installs currently resolve it because the adapter declares only mcp>=1.24.0. The adapter then fails at import time with:

ImportError: cannot import name 'RequestContext' from 'mcp.shared.context'

I opened #588 to add the recommended <2.0.0 upper bound as an immediate safeguard. The broader MCP v2 migration can remain tracked here.

+1

[miriyald]

Two data points that may affect the scope of #588.

1. The unbounded constraint isn't specific to 0.3.1 — it spans every published release.

version	mcp constraint
0.1.12	mcp>=1.9.2
0.1.14	mcp>=1.9.2
0.2.2	mcp>=1.9.2
0.3.0	mcp>=1.9.2
0.3.1	mcp>=1.24.0

So installs pinned to an older adapter break too, and fail on a different symbol. In a clean venv, pip install langchain-mcp-adapters==0.1.12 resolves mcp 2.0.0, and importing MultiServerMCPClient gives:

File "langchain_mcp_adapters/callbacks.py", line 7, in <module>
    from mcp.shared.session import ProgressFnT as MCPProgressFnT
ModuleNotFoundError: No module named 'mcp.shared.session'

In 0.3.1 the mcp.shared.context import precedes that line, which is why that version surfaces RequestContext first.

Since #588 targets main, it protects the next 0.3.x release but not anyone pinned to 0.1.x/0.2.x. It may be worth deciding whether a patch release on the older lines is in scope — for those users the capped 0.3.2 isn't a drop-in replacement either, because it additionally requires langchain-core>=1.3.3.

2. Two v2 removals beyond import renames, from checking every mcp symbol 0.3.1 imports against the 2.0.0 wheel:

• create_mcp_http_client is no longer in mcp/client/streamable_http.py (streamable_http_client is still present)
• mcp/client/websocket.py is removed entirely, so websocket_client has no home — consistent with Dan Leehr (@dleehr)'s note that the websocket transport is gone
• mcp/shared/session.py is removed; ProgressFnT now lives in mcp/shared/dispatcher.py
• RequestContext is gone from mcp/shared/context.py

mcp.client.stdio, mcp.client.sse, mcp.client.session (ElicitationFnT, LoggingFnT), and the top-level mcp exports (ClientSession, StdioServerParameters) all still resolve.

[shreeramkulkarni]

1. The unbounded constraint isn't specific to 0.3.1 — it spans every published release.

version mcp constraint
0.1.12 mcp>=1.9.2
0.1.14 mcp>=1.9.2
0.2.2 mcp>=1.9.2
0.3.0 mcp>=1.9.2
0.3.1 mcp>=1.24.0

+1
Release of mcp v2.0.0 is breaking these versions.

[chrfsa]

Hi Mason Daugherty (@mdrxy) John Kennedy (@jkennedyvz),

I've been working on a full migration of the adapter to mcp 2.0.0 and the 2026-07-28 stateless spec, and it's ready for review. Before opening a PR I wanted to check in here first, since the contribution policy asks for maintainer approval on the linked issue. If you're happy with the approach below, could you assign this issue to me? I'll open the PR right away.

The work is on my fork, in 6 small commits with the test suite green: https://github.com/chrfsa/langchain-mcp-adapters/tree/feat/mcp-v2 (diff against main)

Why a migration rather than a version cap. Right now the adapter fails at import time as soon as mcp 2.0.0 gets installed, which is what #588 and #590 work around by capping the dependency (the dependabot PRs #595 and #596 fail CI for the same reason). But a cap only buys time: even with imports fixed, an adapter that only speaks the legacy handshake silently downgrades every modern server to 2025-11-25, and it will stop working entirely against the modern-only servers that are starting to appear. So this branch implements both eras properly.

How it works. On connect, the adapter probes server/discover at 2026-07-28. If the server answers, great, we're modern and stateless. If the probe fails at the RPC level (unknown method, a 4xx, an unparseable result), we fall back to the classic initialize handshake. Transport errors always propagate, so a network outage is never misread as "legacy server". I stuck to public SDK APIs only (send_discover / adopt / initialize), deliberately avoiding the SDK's private mcp.client._probe module.

For tool calls I implemented the SEP-2322 multi round-trip loop (InputRequiredResult, capped at 10 rounds with the same backoff constants as the SDK's own driver). Embedded input requests go through the public ClientSession.dispatch_input_request, so they reach the exact same callback table as the legacy back-channel path. That's what brings elicitation back on modern connections, since elicitation/create no longer has a back-channel there by design.

The websocket transport is gone, following the SDK, and logging now opts in via log_level since 2026-07-28 requires per-request opt-in.

Breaking changes. A few were unavoidable because the SDK removed the underlying modules: the websocket transport is dropped (use streamable_http), custom httpx_client_factory callables must now return httpx2.AsyncClient (httpx2 installs alongside httpx 0.x without conflict), and get_server_info() returns InitializeResult | DiscoverResult depending on which era the server speaks. The dependency becomes mcp>=2.0.0,<3.

Testing. Beyond the unit suite (98 passed, 2 skipped via make test in the locked CI environment, make lint output identical to main), I tested against four real deployed servers: DeepWiki over HTTP (legacy), Playwright MCP over stdio with an actual headless Chromium navigation, the hosted Supabase server with PAT auth through the headers config, and the MCPJam stateless reference server, which is modern-only and rejects legacy requests outright. That last one exercised the discover negotiation, 13 tools, and a full elicitation round-trip where the server asked for a name mid-call, the callback answered, and the retry came back with the personalized result. All of it passed.

If you'd rather shape this differently (split it into smaller PRs, keep get_server_info non-breaking, stage the websocket removal separately, whatever), just say the word and I'll adjust. Thanks!

[mdrxy]

Planning to allocate time toward this very soon!