fix(deps): constrain mcp to <2 so fresh installs work - #44
Merged
Conversation
mcp 2.0.0, released 2026-07-28, removed `mcp.server.fastmcp`. The module was
renamed to `mcp.server.mcpserver` and `FastMCP` to `MCPServer`.
`memora/server.py:11` imports the old path:
from mcp.server.fastmcp import FastMCP
Because the dependency was declared as an unbounded `mcp>=1.0.0`, a fresh
install now resolves to the new major:
$ uv pip compile - <<< 'mcp>=1.0.0'
mcp==2.0.0
and the server fails at import:
ModuleNotFoundError: No module named 'mcp.server.fastmcp'
This is quiet from the client side. A dead stdio MCP server looks the same as
one that exposes no tools: the client launches it, the process exits, the
client reports zero tools, and nothing logs an error. I hit this on a fork and
it had been serving zero tools to three MCP clients before I noticed.
Constraining to the 1.x line restores installs. mcp 1.29.0 shipped the same day
as 2.0.0, so 1.x is maintained in parallel and this is not a dead end.
A port to the 2.x API is a larger change than a rename: `_sanitize_tool_schemas`
reaches into FastMCP internals (`server._tool_manager._tools`), and FastMCP 4 /
SDK v2 changes decorator return values, so that helper needs reworking. Worth
doing, but separately from unbreaking installs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
spokV
added a commit
that referenced
this pull request
Aug 10, 2026
Headline is #44 from @BillyBunn: mcp 2.0.0 removed mcp.server.fastmcp and our dependency was unbounded, so every fresh install of 0.3.0/0.3.1 resolved to the new major and the server died at import. Constrained to mcp>=1.0.0,<2. Verified the way 0.3.1 was not: a fresh venv + pip install -e . resolves mcp 1.29.0 and memora.server imports cleanly. Proved the other direction too — installing mcp==2.0.0 in a throwaway venv reproduces the ModuleNotFoundError exactly, and mcp.server.mcpserver.MCPServer exists, confirming the rename. Both version sources moved together. Full suite: 143 passed, 1 skipped. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012sVbdZW7a948sfDPxEqozG
1 task
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
mcp2.0.0 (released 2026-07-28) removedmcp.server.fastmcp— the module was renamed tomcp.server.mcpserver, andFastMCPtoMCPServer.memora/server.py:11imports the old path:The dependency is declared as an unbounded
mcp>=1.0.0, so a fresh install now resolves to the new major:and the server dies at import:
As far as I can tell this means
mainis currently broken for anyone installing from scratch.Why this is worth a hard bound rather than a note in the README
The failure is silent from the client side. A dead stdio MCP server is indistinguishable from one that exposes no tools — the client launches it, the process exits, the client reports zero tools, and nothing surfaces an error. I hit this on a fork, where it had been serving zero tools to three different MCP clients before I noticed, and only then by accident while investigating something unrelated.
Fix
Constrain to the 1.x line.
mcp1.29.0 shipped the same day as 2.0.0, so 1.x is maintained in parallel — this is not a dead end.On porting to 2.x instead
Happy to follow up with that if you'd prefer, but it is more than a rename and seemed worth separating from unbreaking installs:
_sanitize_tool_schemas(memora/server.py:213) reaches into FastMCP internals viaserver._tool_manager._tools.@tool()decorator returns the original function rather than a tool object, so that helper needs reworking around the newer lookup API.host/portmove off the constructor torun().Verified: with the bound applied,
uv pip install -e .resolvesmcp 1.29.0, the server completes aninitialize→tools/listhandshake over stdio, and the test suite passes (51 passed).