fix(deps): cap mcp below 2.0 — it removed mcp.server.fastmcp
CI & Build / Python lint (push) Successful in 3s
CI & Build / integration (push) Successful in 14s
CI & Build / TypeScript typecheck (push) Successful in 35s
CI & Build / Python tests (push) Successful in 54s
CI & Build / Build & push image (push) Successful in 1m10s

`main` went red on the PR #79 merge (run 2999) with
`ModuleNotFoundError: No module named 'mcp.server.fastmcp'` across every MCP
test module. Not the merged code: the identical tree passed on `dev` an hour
earlier (run 2997). mcp 2.0.0 was published between the two runs.

`src/scribe/mcp/server.py` imports `mcp.server.fastmcp.FastMCP` to build the
entire tool surface, so 2.x is a genuine incompatibility, not a precaution.
Capped at `<2`; lift it in the same change that ports server.py.

Note what this exposes: `uv.lock` already pinned mcp 1.27.2 and CI installed
2.0.0 anyway, because the workflow uses `uv pip install -e ".[dev]"`, which
resolves from pyproject and ignores the lockfile. Every dependency is
therefore floating in CI regardless of what the lock says — this cap fixes
today's break, not that. Filed separately.
This commit is contained in:
2026-07-28 10:15:46 -04:00
parent e0328f2b1c
commit aa850ac1e1
+5 -1
View File
@@ -19,7 +19,11 @@ dependencies = [
"caldav>=1.3",
"icalendar>=5.0",
"APScheduler>=3.10,<4.0",
"mcp[cli]>=1.0",
# Capped below 2.0: that release removed `mcp.server.fastmcp`, which
# src/scribe/mcp/server.py imports to build the whole tool surface. The
# ceiling is a real incompatibility, not caution — lift it in the same
# change that ports server.py to the 2.x API.
"mcp[cli]>=1.0,<2",
"fastembed>=0.4",
"pgvector>=0.3",
]