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

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

[GusBot69]

Friendly bump on this — it's been ~2 weeks since the mcp SDK 2.0.0 breakage, and this is still the only PR covering all affected Python servers. A few things worth the maintainers' attention:

1. This breaks every uvx install of mcp-server-time/git/fetch when mcp 2.0.0 resolves. Independent confirmation in this thread (Windows, uv 0.11.32): mcp-server-git fails with AttributeError: 'Server' object has no attribute 'list_tools', mcp-server-fetch fails with ImportError: cannot import name 'McpError'. These are fresh-install failures, not edge cases.

2. The single-server alternatives are both stalled. fix(time): cap mcp dependency to <2 to prevent ImportError on SDK 2.0.0 #4571 was closed unmerged by its author after no review, and fix(time): cap mcp dependency below 2.0 #4572 has zero comments. This PR (fix(python): cap mcp dependency to <2 across all Python servers #4577) is the one that fixes all Python servers at once — which is also the fix the maintainers would have to write anyway.

3. Issue time: ImportError on startup with mcp SDK 2.0.0 (McpError renamed to MCPError) #4570 is still open and unassigned with no maintainer activity since Aug 5.

For anyone hitting this today, pip install "mcp<2" is the workaround, but that's a manual pin every user has to know about — a merged cap here unblocks everyone.

cc @olaservo @cliffhall @bryan-anthropic — would appreciate a review when one of you gets a cycle. Happy to rebase or adjust the cap range if there's a preferred approach.