fix(databricks-mcp): support mcp 2.x and drop the temporary <2.0.0 pin - #458
Merged
Merged
Conversation
PR databricks#457 pinned `mcp>=1.13.0,<2.0.0` as a stopgap because mcp 2.0.0 removed the legacy `streamablehttp_client` symbol (and reworked the transport/session and auth APIs), which broke `databricks-mcp` at import time on fresh installs that resolved to mcp 2.x. This is the proper fix: make the code compatible with mcp 2.x while staying backward compatible with mcp 1.x, then remove the install-time cap so future mcp majors are not blocked at resolve time. ## Summary - Detect the installed mcp major (`_MCP_V2 = try: from mcp import Client`) and route both code paths through a single `_open_mcp_session()` helper: - mcp 2.x: attach `DatabricksOAuthClientProvider` (now an `httpx2.Auth`) to an `httpx2.AsyncClient` handed to `streamable_http_client(url, http_client=...)`, wrapped in `mcp.Client` (which performs the initialize handshake itself). - mcp 1.x: `streamablehttp_client(url, auth=...)` + `ClientSession` + explicit `initialize()`, as before. - `oauth_provider.py`: no code change needed (subclassing `OAuthClientProvider` picks up `httpx2.Auth` automatically on v2); docstring updated to show both usage patterns. - Widen the dependency to `mcp>=1.13.0` (no upper bound). - Bump `databricks-mcp` to 0.9.2. - Update tests for mcp 2.x API renames while keeping them runnable on 1.x: build `Tool` via `model_validate({"inputSchema": ...})` (2.x renamed the field to `input_schema`), import `MCPError` (renamed from `McpError`) with a fallback, and patch the version-agnostic `_open_mcp_session`. The integration-test `raw_mcp_session` helper is now version-aware. ## Test Plan - `uv run pytest tests/unit_tests/` — 113 passed against mcp 1.24.0. - Same suite — 113 passed against mcp 2.0.0. - `ty check` (ty 0.0.23) clean against mcp 2.0.0; `ruff check` / `ruff format` clean. - Verified the real v2 wiring (`httpx2.AsyncClient` + `streamable_http_client` + `Client`) constructs and reaches the transport layer end-to-end. ## Type of change - [x] Bug fix (non-breaking change which fixes an issue) ## Changelog databricks-mcp is now compatible with mcp 2.x (and remains compatible with mcp 1.x). Signed-off-by: Zeyi (Rice) Fan <zeyi.f@databricks.com>
fanzeyi
force-pushed
the
fix/databricks-mcp-mcp2-compat
branch
from
July 31, 2026 00:21
3e724fb to
5b0ea78
Compare
aravind-segu
approved these changes
Jul 31, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
PR #457 pinned
mcp>=1.13.0,<2.0.0as a stopgap because mcp 2.0.0 removed the legacystreamablehttp_clientsymbol (and reworked the transport/session and auth APIs), which brokedatabricks-mcpat import time on fresh installs that resolved to mcp 2.x.This is the proper fix: make
databricks-mcpcompatible with mcp 2.x while remaining backward compatible with mcp 1.x, then drop the install-time cap so future mcp majors are not blocked at resolve time._MCP_V2 = try: from mcp import Client) and route both code paths through a single_open_mcp_session()helper:DatabricksOAuthClientProvider(now anhttpx2.Auth) to anhttpx2.AsyncClienthanded tostreamable_http_client(url, http_client=...), wrapped inmcp.Client(which performs the initialize handshake itself).streamablehttp_client(url, auth=...)+ClientSession+ explicitinitialize(), as before.oauth_provider.py: no code change needed (subclassingOAuthClientProviderpicks uphttpx2.Authautomatically on v2); docstring updated to show both usage patterns.mcp>=1.13.0(no upper bound).databricks-mcpto0.9.2._open_mcp_session; make the integration-testraw_mcp_sessionhelper version-aware.Test Plan
uv run pytest tests/unit_tests/— 113 passed against mcp 1.24.0.httpx2.AsyncClient+streamable_http_client+Client) constructs and reaches the transport layer end-to-end.ruff check/ruff formatclean.Type of change
Changelog
databricks-mcp is now compatible with mcp 2.x (and remains compatible with mcp 1.x).