The MCP python SDK 2.0.0 (released 2026-07-28 alongside the new spec) moved mcp.server.fastmcp.FastMCP to mcp.server.mcpserver.MCPServer, so clikernel-mcp fails at startup with ModuleNotFoundError: No module named 'mcp.server.fastmcp' on any fresh environment that resolves the unpinned mcp dependency to 2.x (hit in the wild on a solveit instance image built after the release).
clikernel's SDK surface is otherwise 2.x-compatible: run_stdio_async, tool(structured_output=...), and the (name, instructions=...) constructor shape are all unchanged in 2.0.0. Fix: import MCPServer as FastMCP with a fallback to the 1.x path, and floor the dependency at mcp>=1.2 (earlier versions predate FastMCP entirely, so they should fail at resolve time rather than import time).
Verified against real mcp 2.0.0 (stdio session: tools list, persistent state across execute calls) and mcp 1.29.0 (fallback branch), plus the full test suite.
The MCP python SDK 2.0.0 (released 2026-07-28 alongside the new spec) moved
mcp.server.fastmcp.FastMCPtomcp.server.mcpserver.MCPServer, soclikernel-mcpfails at startup withModuleNotFoundError: No module named 'mcp.server.fastmcp'on any fresh environment that resolves the unpinnedmcpdependency to 2.x (hit in the wild on a solveit instance image built after the release).clikernel's SDK surface is otherwise 2.x-compatible:
run_stdio_async,tool(structured_output=...), and the(name, instructions=...)constructor shape are all unchanged in 2.0.0. Fix: importMCPServer as FastMCPwith a fallback to the 1.x path, and floor the dependency atmcp>=1.2(earlier versions predate FastMCP entirely, so they should fail at resolve time rather than import time).Verified against real
mcp 2.0.0(stdio session: tools list, persistent state acrossexecutecalls) andmcp 1.29.0(fallback branch), plus the full test suite.