fix: cap mcp below 2.0, which removed the FastMCP this is built on #4

Merged

airaneel merged 1 commit from hotfix-mcp-major-cap into main

2026-08-08 03:07:27 +03:00

airaneel commented

2026-08-08 02:59:51 +03:00

Owner

Hotfix for the crash-loop on babash-remote.

mcp 2.0.0 shipped and removed mcp.server.fastmcp (replaced by a new MCPServer API). The image builds with pip install /app, which ignores uv.lock and resolved the unbounded mcp>=1.23.0 straight to the new major — so local checks kept passing against the locked 1.26 while production could not import at all.

A floor, not a destination: raise the bound as part of porting to the new API, deliberately, rather than silently on the next rebuild.

Verified inside the published image: with mcp<2 (1.29.0), import babash succeeds and the server logs its usual unauthenticated startup.

🤖 Generated with Claude Code

Hotfix for the crash-loop on babash-remote. `mcp` 2.0.0 shipped and removed `mcp.server.fastmcp` (replaced by a new `MCPServer` API). The image builds with `pip install /app`, which ignores `uv.lock` and resolved the unbounded `mcp>=1.23.0` straight to the new major — so local checks kept passing against the locked 1.26 while production could not import at all. A floor, not a destination: raise the bound as part of porting to the new API, deliberately, rather than silently on the next rebuild. Verified inside the published image: with `mcp<2` (1.29.0), `import babash` succeeds and the server logs its usual unauthenticated startup. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

airaneel added 1 commit

2026-08-08 02:59:51 +03:00

fix: cap mcp below 2.0, which removed the FastMCP this is built on d9b7e929bb

The container has been crash-looping on ModuleNotFoundError for
mcp.server.fastmcp since the last image build. Nothing in babash caused
it: mcp 2.0.0 shipped, and it drops mcp.server.fastmcp entirely in
favour of a new MCPServer API.

What let that reach production is the gap between how the two
environments resolve dependencies. Locally uv installs from uv.lock and
pins 1.26, so every test, mypy run and local server kept passing. The
image is built with `pip install /app`, which does not read the lock at
all — it resolves this file, and `mcp>=1.23.0` with no upper bound
happily took the new major. So the constraint here, not the lock, is
what production actually runs, and it was promising something wider than
the code supports.

This is a floor, not a destination: 1.x is where the code is today, and
the bound should be raised deliberately as part of porting to the new
API, not silently by whoever rebuilds next.

Verified inside the published image: with mcp<2 resolved (1.29.0),
`import babash` succeeds and the server logs its usual unauthenticated
startup.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

airaneel merged commit 0b26b2b799 into main

2026-08-08 03:07:27 +03:00

airaneel deleted branch hotfix-mcp-major-cap

2026-08-08 03:07:27 +03:00

airaneel referenced this pull request from a commit

2026-08-08 03:07:28 +03:00

Merge pull request 'fix: cap mcp below 2.0, which removed the FastMCP this is built on' (#4) from hotfix-mcp-major-cap into main

airaneel referenced this pull request

2026-08-08 03:28:38 +03:00

refactor: move to fastmcp, off the SDK's own FastMCP #5