Skip to content

chore(deps): update dependency mcp to v2 - #874

Open
renovate[bot] wants to merge 1 commit into
masterfrom
renovate/mcp-2.x
Open

chore(deps): update dependency mcp to v2#874
renovate[bot] wants to merge 1 commit into
masterfrom
renovate/mcp-2.x

Conversation

@renovate

@renovate renovate Bot commented Jul 29, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
mcp >= 1.25.0, < 2.0.0 → >=2.1.1, <2.2.0 age confidence
mcp >= 1.25.0, < 2.0.0 → >=2.1.1, <2.2.0 age confidence

Warning

Some dependencies could not be looked up. Check the warning logs for more information.

Release Notes

modelcontextprotocol/python-sdk (mcp)

v2.1.1

Compare Source

What's Changed

Full Changelog: modelcontextprotocol/python-sdk@v2.1.0...v2.1.1

v2.1.0

Compare Source

Highlights

  • Client accepts StdioServerParameters directly: Client(StdioServerParameters(command="uv", args=["run", "server.py"])) (#​3321).
  • Prompt messages accept Image and Audio, prompt functions may return bare content blocks, and Message / UserMessage / AssistantMessage are exported from mcp.server.mcpserver (#​3320).
  • The 4 MiB request body limit now also covers the SSE transport and the OAuth endpoints; SseServerTransport and MCPServer.sse_app() take max_request_body_size, and the SSE message endpoint answers 405 to non-POST requests (#​3336).

Behaviour changes to be aware of

  • Handler exceptions (#​3314): an unexpected exception from a tool, resource or prompt handler is logged once at ERROR with its traceback, and the client now sees only Error executing tool <name> (or the resource/prompt equivalent) rather than the exception text. Raise ToolError / ResourceError when the message is meant for the model; those still reach the client and are logged at INFO without a traceback.
  • Content-block return annotations (#​3320): a tool annotated to return TextContent, EmbeddedResource, Image, Audio, or lists/unions of them no longer advertises outputSchema or returns structuredContent; its content is unchanged. Pass structured_output=True to keep the previous shape.

Fixes

  • TypedDict tool results: NotRequired keys are omitted instead of serialized as null, and registration no longer fails on Python 3.10 (#​3224, #​3227); recursive return types get an object-rooted outputSchema that pre-2026 clients accept (#​3337).
  • 2026-07-28 over HTTP: a POSTed notification such as notifications/cancelled is acknowledged with 202 instead of rejected with 400 (#​3324).
  • Pre-2026 sessions ignore cache-hint fields from later revisions instead of failing list_tools() (#​3223), and accept boolean sub-schemas in tool schema properties (#​3353).
  • mcp install reads and preserves a Claude Desktop config containing non-ASCII text on any Windows code page (#​3296).

What's Changed

New Contributors

Full Changelog: modelcontextprotocol/python-sdk@v2.0.0...v2.1.0

v2.0.1

Compare Source

One off backport of the FastMCP import warning for 2.0.x, this is due to a lot of people running into this error and making issues on other repos about it. Ideally either pin mcp<2 or upgrade to 2.

What's Changed

Full Changelog: modelcontextprotocol/python-sdk@v2.0.0...v2.0.1

v2.0.0

Compare Source

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

Something rough, confusing, or broken? Open an issue or find us in #python-sdk-dev on the MCP Contributors Discord.

Full Changelog: modelcontextprotocol/python-sdk@v2.0.0rc1...v2.0.0

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • "every weekday"
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate
renovate Bot requested review from DaveHanns and l2ysho as code owners July 29, 2026 16:13
@renovate

renovate Bot commented Jul 29, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

  • any of the package files in this branch needs updating, or
  • the branch becomes conflicted, or
  • you click the rebase/retry checkbox if found above, or
  • you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: uv.lock
Command failed: uv lock --upgrade-package mcp
Using CPython 3.14.7 interpreter at: /opt/containerbase/tools/python/3.14.7/bin/python3
  × No solution found when resolving dependencies for split (markers:
  │ python_full_version >= '3.14' and sys_platform == 'win32'):
  ╰─▶ Because fastmcp-slim[full]<=3.3.0b1 depends on mcp>=1.24.0,<2.0 and
      fastmcp==3.3.0b1 depends on fastmcp-slim[full]==3.3.0b1, we can conclude
      that fastmcp==3.3.0b1 depends on mcp>=1.24.0,<2.0. (1)

      Because fastmcp-slim[client]>=3.3.0b2,<=3.4.7 depends
      on mcp>=1.24.0,<2.0 and fastmcp==3.3.0b2 depends on
      fastmcp-slim[client]==3.3.0b2, we can conclude that fastmcp==3.3.0b2
      depends on mcp>=1.24.0,<2.0.
      And because we know from (1) that fastmcp==3.3.0b1 depends on
      mcp>=1.24.0,<2.0, we can conclude that fastmcp>=3.3.0b1,<=3.3.0b2
      depends on mcp>=1.24.0,<2.0.
      And because fastmcp>=3.0.0,<=3.2.4 depends on mcp>=1.24.0,<2.0, we can
      conclude that fastmcp>=3.0.0,<=3.3.0b2 depends on mcp>=1.24.0,<2.0. (2)

      Because fastmcp-slim[client]>=3.3.0,<=3.4.7 depends on mcp>=1.24.0,<2.0
      and fastmcp==3.4.0b1 depends on fastmcp-slim[client]==3.4.0b1, we can
      conclude that fastmcp==3.4.0b1 depends on mcp>=1.24.0,<2.0.
      And because we know from (2) that fastmcp>=3.0.0,<=3.3.0b2 depends on
      mcp>=1.24.0,<2.0, we can conclude that all of:
          fastmcp>=3.0.0,<=3.3.0b2
          fastmcp==3.4.0b1
      depend on mcp>=1.24.0,<2.0. (3)

      Because all of:
          fastmcp-slim[client]>=3.3.0,<=3.3.1
          fastmcp-slim[client]>=3.4.0,<=3.4.7
      depend on mcp>=1.24.0,<2.0 and fastmcp==3.3.0 depends on
      fastmcp-slim[client]==3.3.0, we can conclude that fastmcp==3.3.0 depends
      on mcp>=1.24.0,<2.0.
      And because we know from (3) that all of:
          fastmcp>=3.0.0,<=3.3.0b2
          fastmcp==3.4.0b1
      depend on mcp>=1.24.0,<2.0, we can conclude that all of:
          fastmcp>=3.0.0,<=3.3.0
          fastmcp==3.4.0b1
      depend on mcp>=1.24.0,<2.0. (4)

      Because all of:
          fastmcp-slim[client]==3.3.1
          fastmcp-slim[client]>=3.4.0,<=3.4.7
      depend on mcp>=1.24.0,<2.0 and fastmcp==3.3.1 depends on
      fastmcp-slim[client]==3.3.1, we can conclude that fastmcp==3.3.1 depends
      on mcp>=1.24.0,<2.0.
      And because we know from (4) that all of:
          fastmcp>=3.0.0,<=3.3.0
          fastmcp==3.4.0b1
      depend on mcp>=1.24.0,<2.0, we can conclude that
      fastmcp>=3.0.0,<=3.4.0b1 depends on mcp>=1.24.0,<2.0. (5)

      Because fastmcp-slim[client]>=3.4.0,<=3.4.7 depends on mcp>=1.24.0,<2.0
      and fastmcp==3.4.0 depends on fastmcp-slim[client]==3.4.0, we can
      conclude that fastmcp==3.4.0 depends on mcp>=1.24.0,<2.0.
      And because we know from (5) that fastmcp>=3.0.0,<=3.4.0b1 depends on
      mcp>=1.24.0,<2.0, we can conclude that fastmcp>=3.0.0,<=3.4.0 depends on
      mcp>=1.24.0,<2.0. (6)

      Because fastmcp-slim[client]>=3.4.1,<=3.4.7 depends on mcp>=1.24.0,<2.0
      and fastmcp==3.4.1 depends on fastmcp-slim[client]==3.4.1, we can
      conclude that fastmcp==3.4.1 depends on mcp>=1.24.0,<2.0.
      And because we know from (6) that fastmcp>=3.0.0,<=3.4.0 depends on
      mcp>=1.24.0,<2.0, we can conclude that fastmcp>=3.0.0,<=3.4.1 depends on
      mcp>=1.24.0,<2.0. (7)

      Because fastmcp-slim[client]>=3.4.2,<=3.4.7 depends on mcp>=1.24.0,<2.0
      and fastmcp==3.4.2 depends on fastmcp-slim[client]==3.4.2, we can
      conclude that fastmcp==3.4.2 depends on mcp>=1.24.0,<2.0.
      And because we know from (7) that fastmcp>=3.0.0,<=3.4.1 depends on
      mcp>=1.24.0,<2.0, we can conclude that fastmcp>=3.0.0,<=3.4.2 depends on
      mcp>=1.24.0,<2.0. (8)

      Because fastmcp-slim[client]>=3.4.3,<=3.4.7 depends on mcp>=1.24.0,<2.0
      and fastmcp==3.4.3 depends on fastmcp-slim[client]==3.4.3, we can
      conclude that fastmcp==3.4.3 depends on mcp>=1.24.0,<2.0.
      And because we know from (8) that fastmcp>=3.0.0,<=3.4.2 depends on
      mcp>=1.24.0,<2.0, we can conclude that fastmcp>=3.0.0,<=3.4.3 depends on
      mcp>=1.24.0,<2.0. (9)

      Because fastmcp-slim[client]>=3.4.4,<=3.4.7 depends on mcp>=1.24.0,<2.0
      and fastmcp==3.4.4 depends on fastmcp-slim[client]==3.4.4, we can
      conclude that fastmcp==3.4.4 depends on mcp>=1.24.0,<2.0.
      And because we know from (9) that fastmcp>=3.0.0,<=3.4.3 depends on
      mcp>=1.24.0,<2.0, we can conclude that fastmcp>=3.0.0,<=3.4.4 depends on
      mcp>=1.24.0,<2.0. (10)

      Because fastmcp-slim[client]>=3.4.5,<=3.4.7 depends on mcp>=1.24.0,<2.0
      and fastmcp==3.4.6 depends on fastmcp-slim[client]==3.4.6, we can
      conclude that fastmcp==3.4.6 depends on mcp>=1.24.0,<2.0.
      And because we know from (10) that fastmcp>=3.0.0,<=3.4.4 depends on
      mcp>=1.24.0,<2.0, we can conclude that all of:
          fastmcp>=3.0.0,<=3.4.4
          fastmcp==3.4.6
      depend on mcp>=1.24.0,<2.0. (11)

      Because all of:
          fastmcp-slim[client]==3.4.5
          fastmcp-slim[client]==3.4.7
      depend on mcp>=1.24.0,<2.0 and fastmcp==3.4.7 depends on
      fastmcp-slim[client]==3.4.7, we can conclude that fastmcp==3.4.7 depends
      on mcp>=1.24.0,<2.0.
      And because we know from (11) that all of:
          fastmcp>=3.0.0,<=3.4.4
          fastmcp==3.4.6
      depend on mcp>=1.24.0,<2.0, we can conclude that all of:
          fastmcp>=3.0.0,<=3.4.4
          fastmcp>=3.4.6,<=3.4.7
      depend on mcp>=1.24.0,<2.0. (12)

      Because fastmcp-slim[client]==3.4.5 depends on mcp>=1.24.0,<2.0 and
      fastmcp==3.4.5 depends on fastmcp-slim[client]==3.4.5, we can conclude
      that fastmcp==3.4.5 depends on mcp>=1.24.0,<2.0.
      And because we know from (12) that all of:
          fastmcp>=3.0.0,<=3.4.4
          fastmcp>=3.4.6,<=3.4.7
      depend on mcp>=1.24.0,<2.0, we can conclude that fastmcp>=3.0.0,<=3.4.7
      depends on mcp>=1.24.0,<2.0.
      And because your project depends on fastmcp>=3.0.0,<4.0.0 and
      mcp>=2.1.1,<2.2.0, we can conclude that your project's requirements
      are unsatisfiable.

hint: The resolution failed for an environment that is not the current one, consider limiting the environments with `tool.uv.environments`.

@renovate
renovate Bot force-pushed the renovate/mcp-2.x branch 2 times, most recently from 45d3eb6 to 98d4450 Compare August 4, 2026 06:09
@renovate
renovate Bot force-pushed the renovate/mcp-2.x branch from 98d4450 to 6c59dc2 Compare August 17, 2026 12:27
@renovate
renovate Bot force-pushed the renovate/mcp-2.x branch 2 times, most recently from 9c4d0e5 to 22024c4 Compare August 26, 2026 22:49
@renovate renovate Bot changed the title chore(deps): update dependency mcp to v2 chore(deps): update dependency mcp to v2 - autoclosed Aug 30, 2026
@renovate renovate Bot closed this Aug 30, 2026
@renovate
renovate Bot deleted the renovate/mcp-2.x branch August 30, 2026 15:40
@renovate renovate Bot changed the title chore(deps): update dependency mcp to v2 - autoclosed chore(deps): update dependency mcp to v2 Aug 31, 2026
@renovate renovate Bot reopened this Aug 31, 2026
@renovate
renovate Bot force-pushed the renovate/mcp-2.x branch 3 times, most recently from 7dfbaad to d2ee912 Compare September 3, 2026 12:24
@renovate renovate Bot changed the title chore(deps): update dependency mcp to v2 chore(deps): update dependency mcp to v2 - autoclosed Sep 3, 2026
@renovate renovate Bot closed this Sep 3, 2026
@renovate renovate Bot changed the title chore(deps): update dependency mcp to v2 - autoclosed chore(deps): update dependency mcp to v2 Sep 4, 2026
@renovate renovate Bot reopened this Sep 4, 2026
@renovate
renovate Bot force-pushed the renovate/mcp-2.x branch 2 times, most recently from d2ee912 to 0d07418 Compare September 4, 2026 23:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@l2ysho l2ysho Awaiting requested review from l2ysho l2ysho is a code owner
@DaveHanns DaveHanns Awaiting requested review from DaveHanns DaveHanns is a code owner

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@apify-service-account