Update mcp requirement from <2,>=1.28.1 to >=2.0.0,<3

[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

[claude]

Review: mcp >=1.28.1 → >=2.0.0

This is a one-line requirements bump, but it raises the floor to a new major version of mcp, and the codebase's usage doesn't look safe to merge as-is without verification.

Correctness risk: this repo uses the low-level Server API directly, not just FastMCP

opencontractserver/mcp/server.py imports and drives exactly the pieces the v2.0.0 release notes call out as rebuilt:

• from mcp.server import Server (server.py:39) — instantiated at server.py:755 and server.py:1378, driven via mcp_server.run(...) / mcp_server.create_initialization_options() (server.py:1822-1825, 2235-2239)
• from mcp.server.sse import SseServerTransport (server.py:40, used at 1809)
• from mcp.server.stdio import stdio_server (server.py:41, used at 2235)
• from mcp.server.streamable_http_manager import StreamableHTTPSessionManager (server.py:42, constructed at 1709 and 1771)

The release notes state the "decorator API is unchanged" for FastMCP/MCPServer, but separately say "the low-level Server is rebuilt around a shared dispatcher engine" and that stateless HTTP semantics, session handling, and the Client/ClientSession layering all changed. This codebase is a low-level Server + StreamableHTTPSessionManager + SseServerTransport consumer, which is squarely in the rebuilt surface — not the part of the SDK the release notes are reassuring you is stable.

Also worth confirming against get_scoped_session_manager/get_session_manager (server.py:1660-1825): v2 streamable-HTTP servers now reject request bodies over 4 MiB with HTTP 413. If any tool response (e.g. document text/annotation payloads) can exceed that, this would be a new, silent failure mode post-bump.

No upper bound, and a nearby line shows the project already knows why that matters

mcp>=2.0.0 (no <3) means any future major release is auto-accepted too. Two lines away, pydantic-ai-slim[openai,anthropic,google,mcp]>=1.107.1,<2 carries the comment "see issue #1451 before bumping the upper bound" — i.e. this project has already been burned by unpinned/loosely-pinned MCP-adjacent deps interacting with pydantic-ai. pydantic-ai-slim's mcp extra was built against v1 Client/ClientSession semantics; bumping the mcp floor to 2.0.0 without also checking pydantic-ai-slim's compatibility range risks either a resolver conflict or a runtime mismatch between what pydantic-ai's MCP integration expects and what's actually installed. Worth checking whether opencontractserver/llms/ (or wherever pydantic-ai's MCP tooling is wired in) is affected, in addition to opencontractserver/mcp/server.py.

Test coverage / CI signal

The PR's own status checks (changes: SUCCESS, linter/CodeQL/redis-integration with no conclusion yet) don't show evidence that the backend suite — specifically opencontractserver/mcp/tests/test_mcp.py and opencontractserver/tests/test_mcp_extended.py, which exercise this exact Server/session-manager code path — has actually run green against mcp==2.0.0. Given the breaking-change scope described in the release notes, I'd want an explicit CI run of the MCP test suite (and ideally a manual smoke test of the /mcp and /sse endpoints) before merging, not just the automerge-eligible dependabot label.

Suggested path

• Don't automerge this one. Either:
  1. Hold/close and let a follow-up PR update opencontractserver/mcp/server.py per the v1→v2 migration guide, run the full MCP test suite against 2.0.0, then merge the version bump alongside those code changes, or
  2. If v2 turns out to be drop-in for this repo's specific usage, at minimum pin an upper bound (mcp>=2.0.0,<3) to match the caution already applied to pydantic-ai-slim, and add a comment noting what was verified.

No frontend/other backend changes in this diff, so scope is limited to the above.

[claude]

Review: do not merge as-is

This is a dependabot bump of mcp from >=1.28.1,<2 to >=2.0.0,<3, but it should be closed/blocked rather than merged.

Blocking issue: contradicts the guardrail comment right below the changed line

requirements/base.txt:85-91 carries an explicit comment (added deliberately, not boilerplate) explaining exactly why the mcp pin must stay <2:

mcp>=1.28.1,<2  # https://github.com/modelcontextprotocol/python-sdk
# ^ pydantic-ai-slim[mcp] -> fastmcp-slim caps mcp<2.0 across its whole
# published range as of 2026-08; mcp 2.0 is a breaking rewrite (decorator-based
# handler registration on mcp.server.lowlevel.Server removed in favor of
# on_*= constructor kwargs) that opencontractserver/mcp/server.py does not yet
# speak. Bump this pin only alongside a migration of that file, once
# fastmcp-slim ships v2 support (or fastmcp-slim/mcp is dropped in favor of
# calling the v2 API directly).

This PR bumps the pin to >=2.0.0,<3 but leaves the comment (and the underlying opencontractserver/mcp/server.py) untouched — so the diff now directly contradicts its own adjacent documentation.

Confirmed: the code does use the removed decorator API

opencontractserver/mcp/server.py builds its low-level servers exactly the way the comment warns about:

• Server("opencontracts") / Server(f"opencontracts-corpus-{corpus_slug}") (server.py:755, server.py:1378)
• @mcp_server.list_resources(), @mcp_server.list_resource_templates(), @mcp_server.list_tools(), @mcp_server.call_tool() decorators (server.py:757-798, 1396-1418)
• .read_resource()(read_resource_handler) / .call_tool()(call_tool_handler) post-hoc registration (server.py:795, 1024, 1410)

Per the mcp v2.0.0 release notes linked in the PR body, mcp.server.lowlevel.Server was rebuilt around a shared dispatcher engine with on_*= constructor kwargs replacing this decorator-based registration. Bumping the pin without migrating this file will very likely break list_resources/list_tools/call_tool/read_resource registration at import or runtime for all three transports this module wires up (Streamable HTTP /mcp, SSE /sse, and stdio) — i.e. this would break MCP entirely, not just degrade gracefully.

Secondary issue: probable dependency resolution conflict

The comment also states pydantic-ai-slim[mcp] -> fastmcp-slim caps mcp<2.0 across its published range as of 2026-08. requirements/base.txt:59 pins pydantic-ai-slim[openai,anthropic,google,mcp]>=1.107.1,<2. If that cap is still in effect, requiring mcp>=2.0.0,<3 alongside pydantic-ai-slim[mcp] may make pip install itself fail to resolve, independent of the runtime breakage above.

Recommendation

Close/skip this dependabot PR (or configure dependabot to ignore major-version bumps for mcp, e.g. via .github/dependabot.yml's ignore rules) until opencontractserver/mcp/server.py is migrated to the v2 API and fastmcp-slim/pydantic-ai-slim[mcp] supports mcp 2.x. Merging this now would be a silent-until-runtime break of the MCP integration with no code changes to catch it in review.

Other

• Scope is minimal (single line, single file) — no other code-quality, security, or test-coverage concerns beyond the above, since no source code changed.