Repository navigation
Raise the fastmcp floor to 4.0 and bound it below 5 - #374
Merged
Merged
Conversation
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
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.
Closes #330.
The
fastmcpextra is nowfastmcp>=4.0,<5, up from>=3.0with no upper bound. Until now,pytestran 4.x afteruv lock --upgradeandfloorsran 3.0, so nothing tested the newest 3.x. And the access log behaved differently depending on which major resolved. I took the issue's floor option over a pinned 3.x CI leg: lite-bootstrap 2.0 now supports one fastmcp major and documents one behaviour. fastmcp 4.0.0 was released on 2026-08-31.pyproject.toml: thefastmcpcomment gives the new reason for the floor and for<5. 4.0 still hasProviderandadd_provider(), so ADR 0001 is unaffected. Thetyping-extensions>=4.15line stays because fastmcp 4.0 pulls py-key-value-aio 0.4.4, which still requires it. Thefastmcp-metricscomment now says 4.0 instead of 3.0.docs/integrations/fastmcp.mddocuments the 4.x access log. It records every message a client sends, including notifications, theserver/discoverrequest of a modern connection, and requests that fail before reaching a handler. The middleware needed no change.Tests
test_fastmcp_access_log_records_notificationsconnects aClientinmode="legacy"with the access log on. It asserts thatinitialize,notifications/initializedandtools/listare each logged with their type. It passes on 4.x. I couldn't run it against 3.x for a red phase, because the new floor makes 3.x unresolvable. Per the upgrade guide, notifications never reachedon_messageon 3.x.The full suite passes, 589 tests at 100% coverage (
just test-ci).just lint(includingty) andjust docs-buildpass too.I ran the
floorsjob's steps locally for thefastmcptarget on 3.11, 3.12, 3.13 and 3.14. CI excludes 3.15 for this target. All four resolve fastmcp 4.0.0 and passscripts/floor_smoke.py. No other target installs fastmcp.Breaking changes