Skip to content

Python: Update mcp requirement from <2.0,>=1.26.0 to >=1.26.0,<3.0 in /python - #14256

Open
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/pip/python/mcp-gte-1.26.0-and-lt-3.0
Open

Python: Update mcp requirement from <2.0,>=1.26.0 to >=1.26.0,<3.0 in /python#14256
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/pip/python/mcp-gte-1.26.0-and-lt-3.0

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Aug 3, 2026

Copy link
Copy Markdown
Contributor

Updates the requirements on mcp to permit the latest version.

Release notes

Sourced from mcp's releases.

v2.0.0

MCP Python SDK v2 Stable Release

This is v2.0.0, the stable v2 release of the MCP Python SDK. It supports the 2026-07-28 revision of the Model Context Protocol and serves every earlier revision from the same server. pip install mcp now installs 2.x.

pip install "mcp[cli]"
# or
uv add "mcp[cli]"

Documentation Rewrite

The documentation has the full tutorial and API reference. Coming from v1? What's new in v2 is the tour of what changed and why, and the migration guide lists every breaking change with before-and-after code.

V1 Maintenance mode

v1.x is in maintenance mode and will only receive security fixes from now on The 1.x line lives on the v1.x branch, continues to receive critical bug fixes and security patches, and is documented at https://py.sdk.modelcontextprotocol.io/v1/. If your project is not ready to migrate, keep a <2 upper bound on your requirement (for example mcp>=1.28,<2).

Highlights

One SDK, both protocol eras

v2 speaks the 2026-07-28 revision (stateless requests with no handshake, server/discover, subscriptions/listen, multi-round-trip requests) and still serves every 2025-era client from the same MCPServer, over Streamable HTTP and stdio, with nothing to configure. Client(target) negotiates the version automatically.

FastMCP is now MCPServer, and there is a first-class Client

The decorator API is unchanged; the low-level Server is rebuilt around a shared dispatcher engine, and one Client object replaces v1's transport-plus-ClientSession-plus-initialize() layering. It connects to a URL, a stdio subprocess, a custom transport, or straight to a server object in memory for tests.

Multi-round-trip requests and resolver dependency injection

At 2026-07-28 the server can no longer call the client, so tools return the question instead. A Resolve(fn) parameter is filled by your function invisibly to the model and can put a question to the user; one tool body serves both eras.

Extension APIs, OpenTelemetry, and a standalone types package

Servers and clients compose protocol extensions through pluggable extension APIs (MCP Apps built in); OpenTelemetry tracing ships on by default; every protocol type is its own package, mcp-types (imported as mcp_types), published in lock-step with mcp.

Hardened stdio and auth

stdio servers keep handler subprocesses and stray prints off the wire, and stdout is diverted to stderr while serving. OAuth adds RFC 9207 issuer validation, the SEP-990 identity-assertion flow, and the client-credentials extension.

Coming from a v2 pre-release

Since the last release candidate: the per-version wire packages are private (mcp_types._v*), mcp.types is a permanent alias for mcp_types, the auth registration request model is split from the registered-client record, cancelled requests are no longer answered, and log notifications are gated on the per-request log-level opt-in at 2026-07-28. Since the betas: Client(cache=False) is now cache=None with CacheConfig() the default; Context.client_id, RFC7523OAuthClientProvider, and OAuthClientProvider(timeout=) are removed; the client-credentials providers take scope=; message_handler receives notifications and exceptions only; FileResource(is_binary=) becomes encoding; MCP_* env vars are gone with pydantic-settings; Streamable HTTP servers reject bodies over 4 MiB with HTTP 413. The migration guide covers all of it.

Known gaps

The tasks extension (SEP-2663) is not part of this release. On the client, the DPoP proof binding (SEP-1932) and the workload-identity jwt-bearer grant are not implemented; both are additive and can land in 2.x.

Feedback

... (truncated)

Commits
  • 6f69a37 Present v2 as the stable release across the README, docs, and policies (#3178)
  • 78e6fbb Serve v2 docs at the site root, with permanent per-major paths (#3176)
  • af06330 Remove unused StreamableHTTPTransport.get_session_id() (#3205)
  • 68ca87e Document the two-line release process for stable v2 (#3179)
  • c9c431b Expose the middleware chain on MCPServer and stop sending unrequested change ...
  • 528e366 Fail fast on server-to-client requests in JSON-response mode instead of hangi...
  • 27f5cc7 Remove unused mcpserver.exceptions.ValidationError (#3199)
  • 89c5e70 Gate log notifications on the per-request log-level opt-in at 2026-07-28 (#3198)
  • b61ce38 docs: fix off-by-one hl_lines in apps.md (#3196)
  • b7c9a91 Add mcp.types as a permanent alias for mcp_types (#3190)
  • Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Updates the requirements on [mcp](https://github.com/modelcontextprotocol/python-sdk) to permit the latest version.
- [Release notes](https://github.com/modelcontextprotocol/python-sdk/releases)
- [Changelog](https://github.com/modelcontextprotocol/python-sdk/blob/main/RELEASE.md)
- [Commits](modelcontextprotocol/python-sdk@v1.26.0...v2.0.0)

---
updated-dependencies:
- dependency-name: mcp
  dependency-version: 2.0.0
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file. Used by Dependabot. python Pull requests for the Python Semantic Kernel labels Aug 3, 2026
Copilot AI review requested due to automatic review settings August 3, 2026 22:14
@dependabot dependabot Bot added the dependencies Pull requests that update a dependency file. Used by Dependabot. label Aug 3, 2026
@dependabot
dependabot Bot requested a review from a team as a code owner August 3, 2026 22:14
@dependabot dependabot Bot added the python Pull requests for the Python Semantic Kernel label Aug 3, 2026
@github-actions github-actions Bot changed the title Update mcp requirement from <2.0,>=1.26.0 to >=1.26.0,<3.0 in /python Python: Update mcp requirement from <2.0,>=1.26.0 to >=1.26.0,<3.0 in /python Aug 3, 2026

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Note

Copilot could not run the full agentic suite for this review because it was automatically requested on a bot-authored pull request. Request a review from Copilot under Reviewers to retry with the full agentic suite. Improved support for bot-authored pull requests is coming soon.

Updates the mcp dependency constraint to allow newer major versions while keeping the minimum version floor unchanged.

Changes:

  • Relax mcp upper bound from <2.0 to <3.0 in main dependencies.
  • Relax mcp upper bound from <2.0 to <3.0 in the optional mcp extra.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread python/pyproject.toml
# explicit typing extensions
"typing-extensions>=4.13",
"mcp>=1.26.0,<2.0",
"mcp>=1.26.0,<3.0",
Comment thread python/pyproject.toml
]
mcp = [
"mcp>=1.8,<2.0",
"mcp>=1.8,<3.0",

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Automated Code Review

Reviewers: 5 | Confidence: 45%

✓ Correctness

The PR raises the mcp upper bound from <2.0 to <3.0 in two places in pyproject.toml. The version specifiers are syntactically valid PEP 440. The key concern—whether the codebase is actually compatible with mcp 2.x's breaking API changes—was already raised in the existing unresolved review comments and I will not duplicate it. No additional correctness issues found in the diff itself.

✓ Security Reliability

This PR widens the mcp dependency from <2.0 to <3.0, admitting the breaking mcp 2.x major version. The existing unresolved review comments correctly identify the core reliability risk: mcp 2.x introduces breaking API changes (FastMCP renamed to MCPServer, Client replaces ClientSession, removed env vars, changed auth flows) with no corresponding code or test updates in this PR. Without verifying the actual mcp usage in the codebase (tool access issues prevented file reads), I cannot add new specific inline findings beyond what the existing review thread already covers.

✓ Test Coverage

This PR widens the mcp dependency upper bound from <2.0 to <3.0, admitting the newly released mcp 2.x which contains significant breaking changes (renamed classes like FastMCP→MCPServer, removed ClientSession layering, changed Client API). The diff contains zero code changes and zero test changes to verify compatibility with mcp 2.x. The previous review comments already flaged the lack of compatibility verification. From a test-coverage perspective, there is no evidence that the existing test suite has been run against mcp 2.x, nor are there any new tests or CI matrix entries to validate the wider range.

✓ Failure Modes

This PR widens the mcp dependency upper bound from <2.0 to <3.0. The existing review thread already notes the risk of admitting mcp 2.x (a major version with documented breaking API changes) without corresponding code adaptations or test coverage. I was unable to access repository files to verify specific import sites or concrete runtime failure paths with file:line evidence, so I cannot add new findings beyond what has already been flaged.

✓ Design Approach

No additional design-approach findings to add from this diff. The only apparent concern is the same broad major-version expansion already covered by the existing unresolved review comments, and I did not find a distinct, well-supported issue to restate here.


Automated review by dependabot[bot]'s agents

Comment thread python/pyproject.toml
# explicit typing extensions
"typing-extensions>=4.13",
"mcp>=1.26.0,<2.0",
"mcp>=1.26.0,<3.0",

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Widening to <3.0 admits mcp 2.x which has documented breaking changes (FastMCP→MCPServer, new Client API, removal of ClientSession). Without corresponding code adaptations or test results showing the existing MCP integration tests pass under mcp 2.x, this risks runtime failures. At minimum, please provide CI evidence that python/tests/ MCP-related tests pass with mcp>=2.0 installed, or add compatibility shims/tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file. Used by Dependabot. python Pull requests for the Python Semantic Kernel

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant