time: ImportError on startup with mcp SDK 2.0.0 (McpError renamed to MCPError)

[KarlLeen]

Describe the bug

mcp-server-time fails to start with an ImportError when resolved against mcp SDK 2.0.0 (released 2026-07-28). Same class of failure as #4560 for fetch.

The process exits before any MCP handshake, so clients just report the server as unavailable.

To Reproduce
Steps to reproduce the behavior:

1. Run uvx mcp-server-time (unpinned; resolves mcp==2.0.0 today)
2. Or against current main (d31124c):

uv venv /tmp/mcp2-time --python 3.12
uv pip install --python /tmp/mcp2-time/bin/python -e src/time 'mcp==2.0.0'
/tmp/mcp2-time/bin/python -c 'from mcp_server_time.server import serve'

Expected behavior
The server should import and start successfully (or at least refuse with a clear dependency error), instead of crashing on import of a renamed SDK symbol.

Logs
Traceback (most recent call last): ... File ".../mcp_server_time/init.py", line 1, in from .server import serve File ".../mcp_server_time/server.py", line 12, in from mcp.shared.exceptions import McpError ImportError: cannot import name 'McpError' from 'mcp.shared.exceptions'. Did you mean: 'MCPError'?

Additional context

• Root cause: mcp 2.0.0 renamed McpError → MCPError. src/time/pyproject.toml declares mcp>=1.23.0 with no upper bound, so unpinned launchers (uvx) now pull mcp==2.0.0 and break.
• Verified: uv pip compile <<< mcp-server-time resolves mcp-server-time==2026.7.10 + mcp==2.0.0.
• Control: with mcp==1.29.0, from mcp_server_time.server import serve succeeds.
• A rename-only patch is not enough for a full 2.x port: MCPError now takes code/message (not ErrorData), and @server.list_tools() / @server.call_tool() were removed in favor of constructor callbacks (same shape as fetch/git).
• Suggested fix: short term mcp>=1.23.0,<2; longer term migrate src/time to MCP Python SDK v2 (alongside fetch fix(fetch): port to mcp SDK v2 #4565 / git refactor(git): migrate lowlevel server to MCP Python SDK v2 #4564).
• Workaround: uvx --with "mcp<2" mcp-server-time
• Environment: macOS (darwin 25), uv 0.11.12, Python 3.12.13, src @ d31124c / mcp 2.0.0
• Happy to send a PR for the short-term cap (and/or a v2 port).

[KarlLeen]

I'll take the PR.

[cyforkk]

I'd like to work on this. My plan: add a version cap in as the short-term fix to prevent Provide a command to run with uvx <command>.

See uvx --help for more information. from resolving to 2.0.0 and breaking the import. Will submit a PR shortly.

[KarlLeen]

Following up on my earlier claim: PR is up at #4572 (cap + uv.lock + regression test, matching #4563).

Noting #4571 as well — that one changes only pyproject.toml. Happy for maintainers to compare and take whichever they prefer; no hard feelings either way @cyforkk.