Broken after mcp 2.0.0: ModuleNotFoundError: No module named 'mcp.server.fastmcp'

[ssm82]

Summary

minimax-mcp (latest release 0.0.9, 2025-04-15) fails to start with ModuleNotFoundError: No module named 'mcp.server.fastmcp' after the upstream mcp package released version 2.0.0 on 2026-07-28.

Environment

• Package: minimax-mcp==0.0.9 (from PyPI)
• Trigger: mcp 2.0.0 (released 2026-07-28) — the submodule mcp.server.fastmcp was removed/renamed in 2.0.0
• Invocation: uvx minimax-mcp (also reproduced with uvx --from git+https://github.com/MiniMax-AI/minimax-mcp against current main)

Reproduce

uvx minimax-mcp

Actual output

Traceback (most recent call last):
  File ".../bin/minimax-mcp", line 6, in <module>
    from minimax_mcp.server import main
  File ".../site-packages/minimax_mcp/server.py", line 19, in <module>
    from mcp.server.fastmcp import FastMCP
ModuleNotFoundError: No module named 'mcp.server.fastmcp'

Root cause

• In minimax_mcp/server.py the import from mcp.server.fastmcp import FastMCP references a module path that no longer exists in mcp>=2.0.0.
• In mcp>=1.6,<2, the module was available; in mcp==2.0.0 it is gone. The replacement appears to be mcp.server.mcpserver (I confirmed import mcp.server.mcpserver works on 2.0.0, while mcp.server.fastmcp does not).
• Pinning mcp<2 via uvx --with "mcp<2" minimax-mcp restores normal startup (it then fails only because MINIMAX_API_KEY is unset in my test env, which is expected).

Suggested fix

Update the import in minimax_mcp/server.py (and any other affected modules) to the new location, e.g.:

from mcp.server.mcpserver import FastMCP

…and bump the mcp dependency range in pyproject.toml to allow >=1.6,<3 (or whatever new release you target). Please also add a CI matrix entry that runs against mcp==2.0.0 so this kind of breakage is caught at PR time instead of by downstream users.

Impact

Every user installing the package via uvx minimax-mcp (or the latest tag from Git) is affected, because uvx resolves the highest compatible mcp and now picks 2.0.0.

[yinj0012]

Re-confirming this on minimax-coding-plan-mcp (the coding-plan sibling, same minimax_mcp.server import — likely one release bus), recorded 5 days after this issue was filed with the workaround still needed.

Reproduction (uvx 0.10.7, mcp 2.0.0, macOS arm64, 2026-08-03):

$ uvx minimax-coding-plan-mcp
Installed 41 packages in 39ms
Traceback (most recent call last):
  File ".../archive-v0/.../bin/minimax-coding-plan-mcp", line 6, in <module>
    from minimax_mcp.server import main
  File ".../minimax_mcp/server.py", line 17, in <module>
    from mcp.server.fastmcp import FastMCP
ModuleNotFoundError: No module named 'mcp.server.fastmcp'

Same root cause ssm82 described: mcp>=2.0 removed/renamed mcp.server.fastmcp. The replacement symbol is in mcp.server.mcpserver.server (I imported it manually under mcp 2.0.0 to confirm) — from mcp.server.mcpserver import FastMCP works under 2.0.

Two extra bits I think ssm82's report missed:

1. pyproject.toml/setup.py pin no upper bound on mcp:

   Requires-Dist: mcp[cli]>=1.6.0
   

   That's why default uvx resolution picked up 2.0 and immediately broke the released wheel — without a cap this will keep biting users until the import is updated.

2. Workaround that works right now (verified handshake + tools/list succeed, serverInfo returned name=Minimax version=1.29.0):

   uvx --from minimax-coding-plan-mcp --with "mcp<2" minimax-coding-plan-mcp

   Or pin the MCP server entry in ~/.claude.json:

   {
     "command": "uvx",
     "args": ["--from", "minimax-coding-plan-mcp", "--with", "mcp<2", "minimax-coding-plan-mcp"],
     "env": { "MINIMAX_API_KEY": "...", "MINIMAX_API_HOST": "https://api.minimax.io" }
   }

Suggested fix path:

• Short term: add an upper bound to mcp[cli]<2 in pyproject.toml so existing releases stop breaking on fresh installs.
• Long term: bump import in minimax_mcp/server.py:17 to from mcp.server.mcpserver.server import FastMCP (or alias via try/except for both paths), then release.

Happy to open a PR if maintainers want — just point me at the right fork.