[dependabot]

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

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
agent-middleware-web	Ready	Preview	Aug 18, 2026 1:18am

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Free

Run ID: f4875c6d-d612-4b76-b2fb-0fe0a0842586

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[PetrefiedThunder]

Heads up before this lands: widening the bound to <3 breaks the application import. The existing <2 is load-bearing, exactly as its own inline comment claims.

Verified locally by merging this branch and installing the resolved requirements (mcp==2.0.0 gets selected):

app/routers/mcp_public.py:40: in <module>
    from mcp.shared.exceptions import McpError
E   ImportError: cannot import name 'McpError' from 'mcp.shared.exceptions'

mcp 2.x renamed the symbol McpError → MCPError. mcp.shared.exceptions now exports MCPError, NoBackChannelError, UrlElicitationRequiredError, ErrorData, JSONRPCError. The old name is imported in two places:

• app/routers/mcp_public.py:40
• app/routers/mcp_standard.py:68

With this merged, pytest fails at collection on every module that imports app.main. Without it, the same tree is green (1319 passed).

Suggested resolution: close this in favour of a deliberate 2.x port, which needs the rename plus a re-check of the other 2.x-facing imports — mcp.server.lowlevel.Server, mcp.server.streamable_http.StreamableHTTPServerTransport, mcp.server.streamable_http_manager.RequestBodyLimitMiddleware, mcp.server.fastmcp, mcp.client.streamable_http — and an update to the <2 guards v1 internals comment. Noting that this PR currently carries an approval; that approval predates this evidence.

Context and the full merge plan for the other nine open PRs: #301.

---

Generated by Claude Code

[PetrefiedThunder]

Closing: this widens a constraint that is deliberate, and the code does not support mcp v2.

requirements.txt:30 already pins mcp>=1.29.0,<2 with the reason inline — "<2 guards v1 internals" — and pyproject.toml:8 carries the same bound. This PR relaxes that to <3, and CI shows why that isn't safe yet: 9 jobs failed with real runners, lint reporting 23 mypy errors across 3 files, all of them v2 API breaks in the governed MCP surface:

• Tool(outputSchema=…) → output_schema
• CallToolResult(structuredContent=…) → structured_content
• Server.list_tools — removed
• Server.request_handlers → _request_handlers
• the result union is no longer callable at mcp_public.py:623

That's app/routers/mcp_public.py — the public MCP transport — so merging this would break the core product path, not just typing.

Upgrading to mcp v2 is a deliberate migration task, not a dependency bump. Until someone does that work, the <2 bound stays.

·@·d·ependabot i·gnore t·his major version

---

Generated by Claude Code

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.

[PetrefiedThunder]

This one is genuinely broken, independent of the current CI outage

Flagging because right now every run in this repo is failing for an infrastructure reason (jobs never get a runner — runner_id: 0, no logs, "completed" ~2s after creation), so a red check here is easy to mistake for that outage. It isn't. I reproduced this locally, off CI entirely.

mcp 2.x does not work with this codebase. Relaxing the bound to <3 resolves to mcp 2.0.0, and:

• mypy app/ → 23 errors in 3 files, identical to what this PR's lint job reported before the runners died.
• pytest → the suite cannot even be collected: 90 collection errors, root cause ModuleNotFoundError: No module named 'mcp.server.fastmcp'.

Restoring mcp>=1.29.0,<2 returns both to clean on the same commit (80d4d6c): mypy Success: no issues found in 172 source files, pytest 1660 passed, 25 skipped.

The breakage is the v1→v2 API rename across the governed MCP path — McpError moved out of mcp.shared.exceptions, Server.request_handlers/list_tools/request_context are gone, ToolAnnotations/Tool/CallToolResult switched from camelCase to snake_case (inputSchema → input_schema, structuredContent → structured_content), and streamable_http_client now expects an httpx2 client.

Worth noting this PR contradicts its own line: it changes the constraint to <3 but leaves the trailing comment reading "<2 guards v1 internals" — which is exactly right, and exactly why this cannot be a one-line bump. Moving to v2 is a real migration across app/routers/mcp_public.py, app/routers/mcp_standard.py, and app/services/upstream_mcp.py, and it touches the trust-critical dispatch path, so it wants its own PR with the full gate suite green — not a dependency bump.

Suggest closing this in favour of a tracked v2 migration, and keeping <2 until that lands.

For contrast, the sibling bumps are fine — #290 (greenlet >=3.5.5), #292 (stripe >=15.5.0), #293 (alembic >=1.19.1) are all floor raises on unbounded >= constraints, and those exact versions are what pip already resolves today; the 1660-passing local run above was made with greenlet 3.5.5, stripe 15.5.0, and alembic 1.19.1 installed.

---

Generated by Claude Code

[PetrefiedThunder]

Closing per the analysis above: mcp 2.x renames McpError → MCPError and breaks app/main.py at import, and upstream's own release notes advise keeping the <2 bound unless deliberately migrating. The 1.x line stays in maintenance mode with security fixes, so the current pin remains safe. A move to 2.x should be its own migration PR (rename the imports, re-verify mcp.server.lowlevel, StreamableHTTPServerTransport, RequestBodyLimitMiddleware, FastMCP/MCPServer, and mcp.client.streamable_http against the 2.x API), not a dependency bump.

---

Generated by Claude Code