Skip to content

Raise the fastmcp floor to 4.0 and bound it below 5 - #374

Merged
lesnik512 merged 1 commit into
mainfrom
fastmcp-floor-4
Oct 29, 2026
Merged

lesnik512 merged 1 commit into
mainfrom
fastmcp-floor-4

Conversation

@lesnik512

Copy link
Copy Markdown
Member

Closes #330.

The fastmcp extra is now fastmcp>=4.0,<5, up from >=3.0 with no upper bound. Until now, pytest ran 4.x after uv lock --upgrade and floors ran 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: the fastmcp comment gives the new reason for the floor and for <5. 4.0 still has Provider and add_provider(), so ADR 0001 is unaffected. The typing-extensions>=4.15 line stays because fastmcp 4.0 pulls py-key-value-aio 0.4.4, which still requires it. The fastmcp-metrics comment now says 4.0 instead of 3.0.
  • docs/integrations/fastmcp.md documents the 4.x access log. It records every message a client sends, including notifications, the server/discover request of a modern connection, and requests that fail before reaching a handler. The middleware needed no change.

Tests

test_fastmcp_access_log_records_notifications connects a Client in mode="legacy" with the access log on. It asserts that initialize, notifications/initialized and tools/list are 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 reached on_message on 3.x.

The full suite passes, 589 tests at 100% coverage (just test-ci). just lint (including ty) and just docs-build pass too.

I ran the floors job's steps locally for the fastmcp target 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 pass scripts/floor_smoke.py. No other target installs fastmcp.

Breaking changes

  • If you're pinned to fastmcp 3.x, you can't install 2.0. fastmcp 4 also raises its own floors to pydantic 2.12 and Starlette 1.0.1. See the upgrade guide.
  • With the access log on, it now has records for notifications and pre-handler failures.
  • 2.0 can't install alongside fastmcp 5 until the bound is lifted.

@lesnik512 lesnik512 added this to the 2.0.0 milestone Oct 29, 2026
@lesnik512
lesnik512 merged commit 7193241 into main Oct 29, 2026
37 checks passed
@lesnik512
lesnik512 deleted the fastmcp-floor-4 branch October 29, 2026 16:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bound fastmcp below 5 and test the newest 3.x or raise the floor to 4.0

1 participant