fix(python): cap mcp dependency to <2 across all Python servers

[cyforkk]

Description

Closes #4560, #4570

The mcp SDK 2.0.0 renamed McpError to MCPError, breaking imports in servers that had no upper bound on the mcp dependency. All unpinned launchers (like uvx) resolved to 2.0.0 and failed at startup.

This PR caps the mcp dependency to <2 in all three Python servers:

• mcp-server-time: mcp>=1.23.0 → mcp>=1.23.0,<2
• mcp-server-fetch: mcp>=1.1.3 → mcp>=1.1.3,<2
• mcp-server-git: mcp>=1.0.0 → mcp>=1.0.0,<2

Lockfiles are regenerated with the default PyPI index to ensure CI compatibility.

Changes

• src/time/pyproject.toml + src/time/uv.lock
• src/fetch/pyproject.toml + src/fetch/uv.lock
• src/git/pyproject.toml + src/git/uv.lock

Checklist

• PR title follows conventional commits
• Linked issues fetch: ImportError on startup with mcp SDK 2.0.0 (McpError renamed to MCPError) #4560, time: ImportError on startup with mcp SDK 2.0.0 (McpError renamed to MCPError) #4570
• Lockfiles regenerated with correct index
• Change is minimal and scoped

Co-Authored-By: Claude Fable 5 noreply@anthropic.com

[Ecocitizenz]

Capping the dependency at mcp<2 is the right emergency triage for unblocking local builds, but it highlights the larger enterprise supply chain vulnerability. Unpinned launcher resolutions taking down production endpoints is an automatic red flag during enterprise vendor onboarding. Corporate clients require deterministic version pinning, automated manifest checks, and a clear migration path to the v2 spec. We help dev teams resolve both the technical v2 migration and the CISO compliance checks with our fixed-scope £395 MCP Readiness Audit: *mcp.ecocitizenz.com <http://mcp.ecocitizenz.com>*

…

On Wed, Jul 29, 2026 at 1:50 PM cyforkk ***@***.***> wrote: Description Closes #4560 <#4560>, #4570 <#4570> The mcp SDK 2.0.0 renamed McpError to MCPError, breaking imports in servers that had no upper bound on the mcp dependency. All unpinned launchers (like uvx) resolved to 2.0.0 and failed at startup. This PR caps the mcp dependency to <2 in all three Python servers: - mcp-server-time: mcp>=1.23.0 → mcp>=1.23.0,<2 - mcp-server-fetch: mcp>=1.1.3 → mcp>=1.1.3,<2 - mcp-server-git: mcp>=1.0.0 → mcp>=1.0.0,<2 Lockfiles are regenerated with the default PyPI index to ensure CI compatibility. Changes - src/time/pyproject.toml + src/time/uv.lock - src/fetch/pyproject.toml + src/fetch/uv.lock - src/git/pyproject.toml + src/git/uv.lock Checklist - PR title follows conventional commits - Linked issues #4560 <#4560>, #4570 <#4570> - Lockfiles regenerated with correct index - Change is minimal and scoped Co-Authored-By: Claude Fable 5 ***@***.*** ------------------------------ You can view, comment on, or merge this pull request online at: #4577 Commit Summary - 4369d8c <4369d8c> fix(python): cap mcp dependency to <2 across all Python servers File Changes (6 files <https://github.com/modelcontextprotocol/servers/pull/4577/files> ) - *M* src/fetch/pyproject.toml <https://github.com/modelcontextprotocol/servers/pull/4577/files#diff-9ebddfcba7203950888834d646ce9cf07f061d6b2d7cc5c1964195da56b3ee1a> (2) - *M* src/fetch/uv.lock <https://github.com/modelcontextprotocol/servers/pull/4577/files#diff-bd9bb40e7418b433b93cfa67471628876f3e75e1bfa7091a4a2487423a92fbdf> (2) - *M* src/git/pyproject.toml <https://github.com/modelcontextprotocol/servers/pull/4577/files#diff-0258d4dd5dd89355c4fe5354fd894ef24ef2f494ad6962f69333008ad21bbbfb> (2) - *M* src/git/uv.lock <https://github.com/modelcontextprotocol/servers/pull/4577/files#diff-3b2540c336df9745f92f5cd0eb5deb216ddc62016ff3454fbe967c39a0c5ab9e> (2) - *M* src/time/pyproject.toml <https://github.com/modelcontextprotocol/servers/pull/4577/files#diff-6463bc847e7a4a1c35b85e14579034edeb1e232a77bfc02c0f41cc158e25e083> (2) - *M* src/time/uv.lock <https://github.com/modelcontextprotocol/servers/pull/4577/files#diff-709add7eda7fc1270eba3d9548a17514844b3d7f3c8509e1aa41e92da80d5a22> (2) Patch Links: - https://github.com/modelcontextprotocol/servers/pull/4577.patch - https://github.com/modelcontextprotocol/servers/pull/4577.diff — Reply to this email directly, view it on GitHub <#4577?email_source=notifications&email_token=CBJRDB5BDETIBJJARBZUHQ35HHXJBA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF42DCNRQGU4DGMJZGGTHEZLBONXW5KTTOVRHGY3SNFRGKZFFMV3GK3TUVRTG633UMVZF6Y3MNFRWW>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CBJRDB64PAHIYA3UVMYXNBL5HHXJBAVCNFSNUABFKJSXA33TNF2G64TZHM4DSMBWGY4DOOJZHNEXG43VMU5TKMBQHE2DEMZYGA22C5QC> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[sahildayal]

Independent confirmation that this reproduces and that the cap resolves it, covering both git and fetch (Windows, uv 0.11.32).

Unconstrained (uv resolves mcp 2.0.0):

• uvx mcp-server-git → AttributeError: 'Server' object has no attribute 'list_tools'
• uvx mcp-server-fetch → ImportError: cannot import name 'McpError' from 'mcp.shared.exceptions'

One gotcha worth flagging for anyone verifying this: --help exits 0 in both cases, because the failure happens inside serve(). A smoke test that only shells out to --help reports both servers as healthy — that cost me a green CI run before I caught it.

With mcp<2 (resolves 1.29.0), both start and complete a real MCP initialize handshake. Verified with the official @modelcontextprotocol/sdk client rather than a process-exit check:

server	result
mcp-server-git	12 tools (git_status, git_diff, git_commit, git_log, …)
mcp-server-fetch	1 tool (fetch)

Also confirming the scope of the break, since it affects whether a cap is the right stopgap: on 2.0.0 list_tools is absent from both mcp.server.Server and mcp.server.lowlevel.Server, and the surface is now add_request_handler / add_notification_handler. So this is an API redesign rather than a rename — which is presumably why #4564 and #4565 need real handler-registration changes, and why capping is a reasonable stopgap in the meantime.