fix(deps): cap mcp below 2.0 — un-reds main #80

Merged

bvandeusen merged 1 commits from dev into main 2026-07-28 10:18:24 -04:00

Conversation 0 Commits 1 Files Changed 1

+5 -1

bvandeusen commented 2026-07-28 10:18:17 -04:00

Owner

Copy Link

Copy Source

Follows PR #79. main went red on that merge (run 2999) through no fault of the merged code.

What happened

ModuleNotFoundError: No module named 'mcp.server.fastmcp'

across all 12 MCP test modules. The identical tree passed on dev an hour earlier (run 2997). mcp 2.0.0 was published between the two runs and removed mcp.server.fastmcp, which src/scribe/mcp/server.py:4 imports to build the whole tool surface.

Capped mcp[cli]>=1.0,<2. Green on dev at aa850ac (run 3000). Lift the ceiling in the same change that ports server.py to the 2.x API.

Why main's build was skipped

CI failure skipped the image job, so :latest was not republished — the new GET /api/plugin/prior-art endpoint stayed unreachable even after #79 merged. This merge is what actually publishes it.

The larger problem this exposed — filed, not fixed here

uv.lock 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. So every dependency floats in CI regardless of the lock: runs aren't reproducible, and the Renovate dashboard-approval discipline is bypassed entirely — upstream can bump this project without a PR at any time. Only APScheduler and now mcp carry upper bounds.

Tracked as issue #2194 (Scribe), with uv sync --locked as the candidate fix and the three complications that make it more than a one-liner.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs

Follows PR #79. `main` went red on that merge (run 2999) through no fault of the merged code. ## What happened ``` ModuleNotFoundError: No module named 'mcp.server.fastmcp' ``` across all 12 MCP test modules. The identical tree passed on `dev` an hour earlier (run 2997). **`mcp` 2.0.0 was published between the two runs** and removed `mcp.server.fastmcp`, which `src/scribe/mcp/server.py:4` imports to build the whole tool surface. Capped `mcp[cli]>=1.0,<2`. Green on `dev` at `aa850ac` (run 3000). Lift the ceiling in the same change that ports `server.py` to the 2.x API. ## Why main's build was skipped CI failure skipped the image job, so `:latest` was not republished — the new `GET /api/plugin/prior-art` endpoint stayed unreachable even after #79 merged. This merge is what actually publishes it. ## The larger problem this exposed — filed, not fixed here `uv.lock` 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**. So every dependency floats in CI regardless of the lock: runs aren't reproducible, and the Renovate dashboard-approval discipline is bypassed entirely — upstream can bump this project without a PR at any time. Only `APScheduler` and now `mcp` carry upper bounds. Tracked as issue #2194 (Scribe), with `uv sync --locked` as the candidate fix and the three complications that make it more than a one-liner. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs

bvandeusen added 1 commit 2026-07-28 10:18:17 -04:00

fix(deps): cap mcp below 2.0 — it removed mcp.server.fastmcp ... aa850ac1e1

`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.

bvandeusen merged commit d5d0b012b1 into main 2026-07-28 10:18:24 -04:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

bvandeusen

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bvandeusen/FabledScribe#80