chore(deps): update mcp requirement from <2,>=1.28.1 to >=2.1.1,<3

[dependabot]

Updates the requirements on mcp to permit the latest version.

Release notes

Sourced from mcp's releases.

v2.1.1

What's Changed

• Point imports of mcp.server.fastmcp at the migration guide by @​maxisbey in modelcontextprotocol/python-sdk#3388

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

Commits

• 0921d94 Point imports of mcp.server.fastmcp at the migration guide (#3388)
• 4d6f87e Build releases with the pinned hatchling and a publish action that accepts Me...
• c5d7d0b docs: refresh translations for recent English changes (#3379)
• d8b6383 Give recursive tool return types an object-rooted output schema (#3376)
• 56af447 Log MCPServer handler exceptions by kind and keep crash details off the wire ...
• f1c40b0 Accept boolean sub-schemas in 2025-11-25 tool schema properties (#3354)
• 57394b0 Apply the request body limit to the SSE and OAuth endpoints (#3336)
• 0cee624 Hand TypedDict tool results to pydantic natively (#3331)
• 0d92192 Shorten stdio test comments (#3329)
• b2025ab Acknowledge notification POSTs with 202 on the 2026-07-28 HTTP entry (#3326)
• Additional commits viewable in compare view

[claude]

Review

This PR (dependabot) bumps mcp in requirements/base.txt from >=1.28.1,<2 to >=2.1.1,<3. This conflicts with a documented constraint already in the same file and should not be merged as-is.

Bug: contradicts the pin's own explanatory comment (requirements/base.txt:83-92)

The diff only changes line 85:

-mcp>=1.28.1,<2  # https://github.com/modelcontextprotocol/python-sdk
+mcp>=2.1.1,<3  # https://github.com/modelcontextprotocol/python-sdk

but leaves the comment directly below it (lines 86-92) untouched:

# ^ 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 comment was clearly added deliberately to prevent exactly this bump. Two concrete problems result:

1. Likely dependency resolution failure. requirements/base.txt:59 still has pydantic-ai-slim[openai,anthropic,google,mcp]>=1.107.1,<2, whose [mcp] extra pulls in fastmcp-slim, which — per the comment — caps mcp<2.0 across its published range. Requiring mcp>=2.1.1 in the same install alongside that transitive mcp<2.0 cap is very likely to produce a pip ResolutionImpossible error (or, if a lenient resolver is used, an inconsistent environment where the installed mcp and fastmcp-slim's expectations diverge).
2. Even if resolution somehow succeeds, the code isn't ready. opencontractserver/mcp/server.py still uses the pre-2.0 decorator-based handler registration API in multiple places (@mcp_server.list_tools() at line 797, @scoped_server.list_tools() / @scoped_server.call_tool() at lines 1412/1417 against Server(...) instances at lines 755/1378). Per the comment, mcp 2.0 removed this pattern in favor of on_*= constructor kwargs, so upgrading past <2 without migrating server.py would break the MCP server at runtime even if the package installed cleanly.

Recommendation

Close/skip this dependabot PR (or configure dependabot ignore rules for mcp major-version bumps) until:

• fastmcp-slim ships mcp 2.x support (removing the transitive <2.0 cap on pydantic-ai-slim[mcp]), or fastmcp-slim/mcp usage is dropped in favor of calling the v2 API directly, and
• opencontractserver/mcp/server.py's decorator-based handler registration is migrated to the on_*= constructor-kwarg API.

That migration should be a deliberate, tracked PR (updating both the pin and the comment and server.py together), not an automated dependency bump.

No other files are touched in this PR, so there's nothing else to flag on code quality/tests/security — the sole issue is that this specific version bump is unsafe given the current state of opencontractserver/mcp/server.py.

[claude]

Automated review

This is a Dependabot bump of mcp from >=1.28.1,<2 to >=2.1.1,<3. I'd recommend not merging this as-is — the pin was deliberately capped, and the reasoning is spelled out directly above the line this PR changes (requirements/base.txt:86-92):

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).

I confirmed both halves of that concern are still true on this branch:

1. opencontractserver/mcp/server.py still uses the removed decorator API — @mcp_server.list_tools() (line 797) and @scoped_server.list_tools() / @scoped_server.call_tool() (lines 1412/1417). Per the pin comment, these decorators are gone in mcp 2.0 in favor of on_*= constructor kwargs, so this file would fail at import/registration time against mcp>=2.1.1.
2. pydantic-ai-slim[mcp] (pinned >=1.107.5,<2 at requirements/base.txt:59) resolves fastmcp-slim, which itself caps mcp<2.0 — so this PR would very likely produce an unresolvable/conflicting pin set with the existing pydantic-ai-slim[...,mcp] requirement, independent of the server.py breakage.

Given the diff is just the version bump (the comment block explaining the constraint wasn't updated/removed), this looks like it hasn't accounted for that guardrail yet. Suggest closing/blocking until:

• opencontractserver/mcp/server.py is migrated off the decorator-based list_tools()/call_tool() registration to the on_*= constructor kwargs API, and
• pydantic-ai-slim/fastmcp-slim has a released version supporting mcp 2.x (or the fastmcp-slim dependency is dropped in favor of calling the v2 API directly).

No other files are touched by this PR, so there's nothing else to review code-quality/test-coverage-wise — the only concern is that merging it breaks the app per the codebase's own documented constraint.

[JSv4]

Investigation notes

The pip-resolution blocker documented in requirements/base.txt has cleared. The comment above the mcp pin warns that pydantic-ai-slim[mcp] -> fastmcp-slim caps mcp<2.0 across its whole published range as of 2026-08. A dry-run resolve today (pip install --dry-run "mcp>=2.1.1,<3" "pydantic-ai-slim[openai,anthropic,google,mcp]>=1.56.0,<2") resolves cleanly to fastmcp-slim 4.0.3 + mcp 2.1.1 + pydantic-ai-slim 1.107.5 — fastmcp-slim has since shipped v2 support, satisfying the comment's stated precondition.

But the actual code migration is substantial, not a rename. mcp 2.x's mcp.server.lowlevel.Server dropped every decorator (list_tools(), list_resources(), list_resource_templates(), read_resource(), call_tool(), ...) entirely — confirmed via inspect.signature(Server.__init__) on the installed 2.1.1 package. Handlers now register as on_list_tools=, on_call_tool=, on_read_resource=, etc. constructor kwargs, and each handler's signature changes shape: from () -> list[X] to (ctx: ServerRequestContext[LifespanResultT], params: ...) -> TypedResult (e.g. list_tools now returns types.ListToolsResult, not a bare list[Tool]; call_tool returns CallToolResult | InputRequiredResult, not bare content).

opencontractserver/mcp/server.py is 2255 lines with two Server(...) instances (create_mcp_server() at line 755 and a corpus-scoped one at line 1378), both built entirely on the removed decorator API, plus ~30 call sites passing now-renamed camelCase kwargs (inputSchema→input_schema, uriTemplate→uri_template, mimeType→mime_type) to Tool/Resource/ResourceTemplate.

This is a full API-surface migration of the MCP server, not a mechanical bump. Holding this PR open pending a dedicated migration effort (tracked separately) rather than merging as part of a routine dependabot pass. Whoever picks it up: also bump the .pre-commit-config.yaml mypy hook's mcp pin from >=1.28.1,<2 (see #2302) to >=2.1.1,<3 in the same PR, or the hook will mismatch runtime again in the other direction.