Twelve Green CI Legs, One Dead SSE Server

Description and use

Implemented a dynamic compatibility layer and expanded CI to cover network transports, eliminating SSE startup failures on MCP 2.x and ensuring reliable operation across SDK versions.

Problem

The MCP Python SDK’s 2.0.0 release removed the fastmcp module without deprecation, breaking downstream packages that relied on it and causing CI failures and runtime errors in production servers.

Outcome

Implemented dynamic compatibility handling and expanded CI to cover network transports, eliminating SSE startup failures on MCP 2.x and ensuring reliable operation across SDK versions.

Workflow

• 1. Pin mcp<2.0.0 in pyproject.toml to avoid import errors.
• 2. Add a compatibility module (_compat.py) that tries to import fastmcp and falls back to mcpserver, setting MCP_MAJOR accordingly.
• 3. Create CI matrix with mcp1 and mcp2 axes, each installing the appropriate SDK pin after package install.
• 4. Add tests that assert the resolved major version and build the ASGI app for both SSE and streamable-http transports.
• 5. Extend tests to cover network configuration differences between MCP 1.x and 2.x, including host and security settings.
• 6. Fix the probe to use importlib.metadata.version('mcp') when both module trees are importable (e.g., MCP 2.1.x).
• 7. Run CI; all tests pass on both SDK lines.
• 8. Deploy updated package; production SSE servers start correctly on MCP 2.x.
• 9. Monitor for future MCP releases and adjust probe if necessary.

Evidence

The official mcp Python SDK went to 2.0.0 and deleted mcp.server.fastmcp outright.

Source

v0.12.0 shipped at 10:39, six and a half hours after the pin.

Source

mcp 2.x refuses to register a static resource whose handler declares a Context parameter, and it refuses at import time, which takes the server down before it answers a single request.

Source