fix(deps): pin the MCP SDK below 2.0

[HackedRico]

Description

requirements.txt asked for an unpinned mcp, so a fresh install now resolves to 2.0.0, which removed mcp.server.fastmcp in favour of MCPServer.

Both MCP servers in this plugin still import the 1.x path:

• mcp_server.py:103 — from mcp.server.fastmcp import FastMCP
• app/mcp_server.py:2 — same

So every stdio subprocess dies on line 2, the pipe closes, and the client surfaces only MCPError: Connection closed wrapped in nested TaskGroup exception groups. The real cause scrolls past above the traceback.

Only the server half of the SDK changed. mcp.client.stdio and mcp.client.session survived, so the parent process imports fine, the plugin enables, and the splash page reads configured. The failure waits until a workflow actually spawns a server, which is why this got through.

1.29.1 is the newest release that still ships fastmcp. Pinning mcp>=1.9,<2 restores both servers with no code change. Migrating to the 2.x MCPServer API is a real port and belongs in its own change.

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Installed the pin into the CALDERA venv and verified the actual failure is gone:

mcp.server.fastmcp: OK
mcp.client.stdio/session: OK          (parent side unaffected)
plugins/mcp/app/mcp_server.py: OK     (imports clean, exits on empty stdin)
plugins/mcp/mcp_server.py: OK

• pip show mcp -> 1.29.1
• Nothing else in the venv depends on mcp (Required-by: is empty), so the downgrade is contained.
• Plugin test suite after the downgrade: 70 passed, 13 skipped.
• flake8 . --select=E9,F63,F7 (the repo's CI hard gate): passes.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have made corresponding changes to the documentation - n/a, one dependency bound
• I have added tests that prove my fix is effective or that my feature works - n/a, a version pin is not unit-testable; verified by installing it and booting both servers