fix(deps): bump fastmcp from 2.13.0 to >=2.14.5,<3.0.0 - #331
Conversation
fastmcp 2.13.0 was pinned exactly and incompatible with MCP SDK serialization changes introduced in mcp>=1.26.0, causing broken tool responses when proxying servers (output.output.slice error in clients like opencode). Bumps to the latest 2.x release (2.14.7) while capping below 3.0.0 to avoid breaking API changes.
📝 WalkthroughWalkthroughThe ChangesDependency Version Update
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Review Summary by QodoBump fastmcp to resolve MCP serialization incompatibility
WalkthroughsDescription• Bumps fastmcp from exact 2.13.0 to >=2.14.5,<3.0.0 • Resolves broken tool responses from MCP serialization incompatibility • Fixes output.output.slice errors in client proxying Diagramflowchart LR
A["fastmcp==2.13.0<br/>+ mcp>=1.26.0"] -- "serialization mismatch" --> B["broken JSON-RPC<br/>tool responses"]
C["fastmcp>=2.14.5,<3.0.0"] -- "compatible with" --> D["mcp>=1.26.0<br/>serialization"]
D --> E["fixed tool responses"]
File Changes1. pyproject.toml
|
Code Review by Qodo🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)
Great, no issues found!Qodo reviewed your code and found no material issues that require review |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
pyproject.toml (1)
28-29: ⚡ Quick win
mcp>=1.8.0lower bound is now misleadingly loosefastmcp's own dependency declaration requires
"mcp>=1.24.0,<2.0". Since mcpm pulls in fastmcp>=2.14.5, the effective minimum formcpin practice is 1.24.0, not 1.8.0. Themcp>=1.8.0constraint in mcpm won't cause a runtime failure (the resolver enforces the stricter transitive bound), but it gives a misleading picture of what actually resolves. Consider tightening it to reflect reality:🔧 Suggested tightening
- "mcp>=1.8.0", + "mcp>=1.24.0",🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@pyproject.toml` around lines 28 - 29, The pyproject.toml declares "mcp>=1.8.0" which is misleading because fastmcp (pulled in via "fastmcp>=2.14.5,<3.0.0") requires "mcp>=1.24.0,<2.0", so update the mcp constraint to reflect the actual resolved minimum (e.g., change "mcp>=1.8.0" to "mcp>=1.24.0,<2.0" or otherwise align it with fastmcp's declared range) so the dependency bounds for mcp and fastmcp in pyproject.toml are consistent and not misleading.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@pyproject.toml`:
- Around line 27-29: The pydantic version cap ("pydantic>=2.5.1,<2.12.0") in
pyproject.toml unnecessarily narrows resolution with fastmcp>=2.14.5; update the
pydantic constraint to remove the <2.12.0 upper bound (e.g., "pydantic>=2.5.1"
or "pydantic>=2.11.7") so it is compatible with fastmcp's pydantic requirement,
and optionally tighten the mcp constraint from "mcp>=1.8.0" to match fastmcp's
transitive requirement (e.g., "mcp>=1.24.0,<2.0") to avoid misleadingly loose
bounds.
---
Nitpick comments:
In `@pyproject.toml`:
- Around line 28-29: The pyproject.toml declares "mcp>=1.8.0" which is
misleading because fastmcp (pulled in via "fastmcp>=2.14.5,<3.0.0") requires
"mcp>=1.24.0,<2.0", so update the mcp constraint to reflect the actual resolved
minimum (e.g., change "mcp>=1.8.0" to "mcp>=1.24.0,<2.0" or otherwise align it
with fastmcp's declared range) so the dependency bounds for mcp and fastmcp in
pyproject.toml are consistent and not misleading.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: a9300df1-f506-4279-b673-884413732b4d
⛔ Files ignored due to path filters (1)
uv.lockis excluded by!**/*.lock
📒 Files selected for processing (1)
pyproject.toml
| "pydantic>=2.5.1,<2.12.0", | ||
| "mcp>=1.8.0", | ||
| "fastmcp==2.13.0", | ||
| "fastmcp>=2.14.5,<3.0.0", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Confirm pydantic version currently resolved in uv.lock and check for fastmcp's declared pydantic lower bound
rg -n "pydantic" uv.lock | head -40Repository: pathintegral-institute/mcpm.sh
Length of output: 9738
🏁 Script executed:
#!/bin/bash
# Read the current pyproject.toml to see the actual dependency constraints
cat pyproject.tomlRepository: pathintegral-institute/mcpm.sh
Length of output: 1611
🏁 Script executed:
#!/bin/bash
# Search for mcp in uv.lock to see what version is resolved
rg -n "^name = \"mcp\"" uv.lock -A 5Repository: pathintegral-institute/mcpm.sh
Length of output: 245
🌐 Web query:
fastmcp 2.14.5 pyproject.toml dependencies pydantic mcp
💡 Result:
FastMCP 2.14.5 is a Python framework for building MCP (Model Context Protocol) servers and clients. Its pyproject.toml dependencies, consistent across v2.14.x releases (e.g., v2.14.2 listed explicitly), include pydantic[email] >=2.11.7 [1][2] and mcp <2.0,>=1.24.0 [1][2]. Full core dependencies from the series: authlib>=1.6.5, cyclopts>=4.0.0, exceptiongroup>=1.2.2, httpx>=0.28.1, jsonschema-path>=0.3.4, mcp<2.0,>=1.24.0, openapi-pydantic>=0.5.1, platformdirs>=4.0.0, py-key-value-aio[disk,keyring,memory]<0.4.0,>=0.3.0 (updated in later 2.14.x), pydantic[email]>=2.11.7, pydocket>=0.16.3 (updated from 0.15.5 in 2.14.1), pyperclip>=1.9.0, python-dotenv>=1.1.0, rich>=13.9.4, uvicorn>=0.35, websockets>=15.0.1 [1][3][4]. No exact pyproject.toml for precisely 2.14.5 found, but changes between minor versions are minor (e.g., pydocket bump) [5][6][4], and main branch matches [2]. Projects using fastmcp==2.14.5 pin pydantic>=2.12.5,<3.0 and mcp[cli]>=1.26.0,<2.0 [7][8].
Citations:
- 1: https://pypi.org/project/fastmcp/2.14.2/
- 2: https://github.com/PrefectHQ/fastmcp/blob/main/pyproject.toml
- 3: https://pypi.org/project/fastmcp/2.14.1/
- 4: PrefectHQ/fastmcp@v2.14.1...v2.14.2
- 5: https://gofastmcp.com/changelog
- 6: PrefectHQ/fastmcp@v2.14.5...v2.14.6
- 7: https://github.com/vulnersCom/vulners-mcp/blob/main/pyproject.toml
- 8: https://github.com/uyuni-project/mcp-server-uyuni/blob/main/pyproject.toml
Pydantic <2.12.0 creates an unsustainably narrow resolution window with fastmcp>=2.14.5
fastmcp 2.14.5 declares pydantic[email]>=2.11.7 as a requirement. Combined with mcpm's explicit cap pydantic>=2.5.1,<2.12.0, the valid pydantic range narrows to 2.11.7–2.11.x only (currently resolved to 2.11.7). Any future fastmcp 2.x release that bumps its pydantic floor to >=2.12.0 will make the dependency graph unsatisfiable.
The <2.12.0 cap was added to protect against the pydantic 2.12 breaking change that affected older fastmcp (<2.12.4). Since this PR already requires fastmcp>=2.14.5 (which is compatible with pydantic 2.12+), the cap is now unnecessarily constraining. Consider loosening it to match fastmcp's actual requirements:
🔧 Suggested fix
- "pydantic>=2.5.1,<2.12.0",
+ "pydantic>=2.11.7",
"mcp>=1.8.0",
"fastmcp>=2.14.5,<3.0.0",Or, if mcpm code relies on pre-2.11 pydantic APIs, drop just the cap:
- "pydantic>=2.5.1,<2.12.0",
+ "pydantic>=2.5.1",Verify resolution with uv lock --upgrade-package pydantic.
Minor note: mcpm's mcp>=1.8.0 has no upper bound, but fastmcp transitively enforces mcp<2.0,>=1.24.0 (currently resolved to 1.25.0). The loose lower bound in mcpm is misleading; consider tightening it to match fastmcp's actual minimum.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "pydantic>=2.5.1,<2.12.0", | |
| "mcp>=1.8.0", | |
| "fastmcp==2.13.0", | |
| "fastmcp>=2.14.5,<3.0.0", | |
| "pydantic>=2.11.7", | |
| "mcp>=1.8.0", | |
| "fastmcp>=2.14.5,<3.0.0", |
| "pydantic>=2.5.1,<2.12.0", | |
| "mcp>=1.8.0", | |
| "fastmcp==2.13.0", | |
| "fastmcp>=2.14.5,<3.0.0", | |
| "pydantic>=2.5.1", | |
| "mcp>=1.8.0", | |
| "fastmcp>=2.14.5,<3.0.0", |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@pyproject.toml` around lines 27 - 29, The pydantic version cap
("pydantic>=2.5.1,<2.12.0") in pyproject.toml unnecessarily narrows resolution
with fastmcp>=2.14.5; update the pydantic constraint to remove the <2.12.0 upper
bound (e.g., "pydantic>=2.5.1" or "pydantic>=2.11.7") so it is compatible with
fastmcp's pydantic requirement, and optionally tighten the mcp constraint from
"mcp>=1.8.0" to match fastmcp's transitive requirement (e.g.,
"mcp>=1.24.0,<2.0") to avoid misleadingly loose bounds.
There was a problem hiding this comment.
Pull request overview
This PR updates the project’s FastMCP dependency constraint to avoid JSON-RPC/tool-response serialization mismatches when proxying MCP servers via mcpm run, by moving off an exact fastmcp==2.13.0 pin to a compatible 2.x range and regenerating the lockfile accordingly.
Changes:
- Relax
fastmcpfrom an exact pin tofastmcp>=2.14.5,<3.0.0inpyproject.toml. - Regenerate
uv.lockto resolvefastmcpto2.14.7and update transitive dependencies.
Reviewed changes
Copilot reviewed 1 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
pyproject.toml |
Updates the runtime dependency constraint for fastmcp to a compatible 2.x range. |
uv.lock |
Regenerates the lockfile to reflect fastmcp 2.14.7 and its updated dependency graph. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Summary
fastmcp==2.13.0(exact pin) tofastmcp>=2.14.5,<3.0.0mcpm runRoot Cause
fastmcp==2.13.0was pinned exactly whilemcp>=1.8.0was left loose. pip/uv resolvedmcpto 1.25.0+ which introduced serialization changes (tracked in fastmcp's own test snapshot update for MCP 1.26.0). The mismatch caused malformed JSON-RPC tool responses, manifesting asoutput.output.sliceerrors in clients like opencode.Changes
pyproject.toml:fastmcp==2.13.0→fastmcp>=2.14.5,<3.0.0uv.lock: updated to resolve fastmcp 2.14.7 (latest 2.x)Testing
ruff checkcleanSummary by CodeRabbit