fix(mcp): constrain incompatible SDK versions

[Retengart]

Closes #275.

Summary

• release the fix as forkd-mcp 0.2.1
• constrain the MCP SDK to mcp>=1.2,<2
• add a stdio regression test covering initialize and all 11 tools
• run CI against MCP 1.2.0 and the latest compatible 1.x release
• document the user-visible compatibility fix in CHANGELOG.md

The latest-compatible CI leg is intentionally unpinned as an early-warning signal. anyio is installed explicitly for the test instead of relying on MCP's transitive dependencies.

Validation

• MCP 1.2.0: 1 passed
• latest mcp>=1.2,<2: 1 passed
• ruff check --output-format=json sdk/mcp: []
• built wheel metadata:
  • Version: 0.2.1
  • Requires-Dist: mcp<2,>=1.2
• Gitleaks: one commit scanned, no leaks
• no documentation changes that assume 0.2.1 is already published
• no docs/superpowers/** paths

[WaylandYang]

Thanks for splitting this out — the scope is exactly right now, and every point from the pre-review is addressed.

I reproduced the bug and verified the fix end to end rather than reading the diff alone. From a clean container, using the tree at each ref:

The breakage on main — mcp>=1.0 lets 2.x resolve, and the import dies:

File "sdk/mcp/forkd_mcp/server.py", line 24, in <module>
    from mcp.server.fastmcp import FastMCP
ModuleNotFoundError: No module named 'mcp.server.fastmcp'

With this branch the resolver refuses 2.x outright:

because all versions of forkd-mcp depend on mcp>=1.2,<2 and you require
mcp==2.0.0, we can conclude that your requirements are unsatisfiable.

Both CI legs pass locally — mcp==1.2.0: 1 passed; mcp>=1.2,<2: 1 passed, resolving to mcp 1.29.0. So the floor and the current head of the 1.x line are both genuinely covered, not just nominally.

The test's assumptions hold up too: EXPECTED_TOOLS matches the 11 @mcp.tool registrations in server.py exactly, FastMCP("forkd") matches the serverInfo.name assertion, and server.py has the __main__ block that -m forkd_mcp.server needs.

Adding --with anyio was the right call — it was arriving transitively through MCP, which is precisely the dependency graph this job exists to catch changes in. And thanks for the comment on the unpinned leg; that intent is worth having in the file.

One note for whoever cuts the release: this bumps the source metadata to 0.2.1, but 0.2.0 stays broken on PyPI until 0.2.1 is actually published. Until then the practical workaround for users is pinning mcp<2 alongside forkd-mcp.

Approving.