Repository navigation
fix(mcp): raise the fastmcp floor to the oldest release that works - #807
vishal-bala wants to merge 3 commits into
Conversation
The mcp extra declared fastmcp>=2.0.0, but RedisVL's MCP server does not work below 2.12.1. 2.0 to 2.3 lack fastmcp.server.auth and fastmcp.server.dependencies, 2.4 to 2.11.1 fail to import with pydantic 2.13, and 2.11.2 to 2.12.0 reject the base_url the JWT verifier is built with. The MCP unit tests pass on 2.12.1 through 3.4.11 apart from tests that patch FastMCP 3.1+ settings. The floor is functional, not a security floor, so users can still choose any working release.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 390b1381de
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| # The floor is the oldest release RedisVL works with, not a security floor: | ||
| # earlier 2.x releases lack fastmcp.server.auth, fail to import with | ||
| # pydantic 2.13, or reject the base_url the JWT verifier is built with. | ||
| "fastmcp>=2.12.1,<4", |
There was a problem hiding this comment.
When resolution selects FastMCP 2.12.1–2.12.5 and a user starts the documented --transport sse server, an upstream routing regression causes clients such as Claude and OpenAI to hang while fetching tools. FastMCP confirmed the regression remained in 2.12.5, and the fix first shipped in 2.13.0, so 2.12.1 is not a functional floor for RedisVL's advertised transports; raise the minimum to at least 2.13.0.
Useful? React with 👍 / 👎.
| # and only its membership is behavior. `fastmcp` is allowed anywhere in | ||
| # `>=2.12.1,<4`, so a minor bump must not break this on presentation alone. |
There was a problem hiding this comment.
When the integration suite runs with an allowed FastMCP version such as 2.12.1, 2.14.7, or 3.0.0, those releases omit additionalProperties from this generated schema, so the unchanged schema["additionalProperties"] assertion fails with KeyError. The new comment now explicitly treats the entire range as allowed, but lower-bound and dependency-matrix testing cannot pass; either relax the assertion for versions where runtime argument rejection still provides the boundary or raise the dependency floor to a release that emits this key.
Useful? React with 👍 / 👎.
…tion on 3.x FastMCP 2.12.1 to 2.12.5 leave SSE clients hanging while they list tools (PrefectHQ/fastmcp#1903, fixed in 2.13.0), so 2.12.1 was not a working floor for the documented --transport sse server. FastMCP 2.x omits additionalProperties from tool schemas but still refuses extra arguments at call time, so assert the key only on 3.x.
Motivation
The
mcpextra declaredfastmcp>=2.0.0,<4, but RedisVL's MCP server does not work with any FastMCP release below 2.12.1. A user who pins an older FastMCP, or whose resolver picks one to satisfy another package, gets an install that resolves cleanly and then fails at import or when JWT auth is configured. This PR raises the floor to the oldest release that works, so the declared range says what is actually supported.Changes
FastMCP floor moves from 2.0.0 to 2.12.1
Each part of the 2.x line below 2.12.1 fails for a different reason. The table comes from running the MCP unit tests (
tests/unit/test_mcpandtests/unit/test_cli_mcp.py, 483 tests) on Python 3.13 with only FastMCP swapped, and from an import check of the two auth modules on every third 2.x release:fastmcp.server.authandfastmcp.server.dependenciesdo not exist, so the auth provider and the tools that read the caller's token fail to importcannot specify both default and default_factory)JWTVerifierrejects thebase_urlargument the server builds it with, so JWT auth fails (2.12.1 to 2.12.5 accept it)fastmcp.settings.transport(added in 3.1) or assert theadditionalProperties: falseschema key, which these releases omitThe comment above the constraint now records that this is a functional floor, not a security one, and the MCP how-to guide states the supported range for users who pin FastMCP themselves.
Minor changes
uv.lockrecords the new specifier; no locked version changes.tests/integration/test_mcp/test_profiles.pyclaimed FastMCP had no upper bound; it now quotes the current range.Notes
On these older releases the server still refuses a call that passes a tenant-locked argument; it only stops advertising
additionalProperties: falsein the tool schema. This was checked on 2.12.1 and 2.14.7 by runningtest_a_client_cannot_pass_the_injected_field_over_the_wirewithout its schema assertion. Before 3.1,FASTMCP_TRANSPORTis ignored and the server falls back to stdio, as the comment inredisvl/mcp/server.pyalready says; thervl mcpCLI always passes--transport, so only programmatic callers that rely on the environment variable are affected.Reviewer Brief
Start here:
pyproject.toml, thefastmcpconstraint in themcpextra. Everything else in the diff only describes it.Where it could fail
pyproject.toml:49: a user or downstream package pinned to FastMCP between 2.0 and 2.12.0 will now fail to resolve rather than fail at runtime; check that is the intended trade.Not verified: the MCP integration tests against FastMCP 2.x, which need Redis; Python versions other than 3.13 for the version sweep; FastMCP 2.x with pydantic releases older than 2.13.4.
Beyond CI: the MCP unit tests ran on FastMCP 2.0.0, 2.11.2, 2.12.0, 2.12.1, 2.13.0, 2.14.7, 3.0.0 and 3.4.11 with the results in the table; CI only exercises the locked 3.4.11.
Reviewed
390b138· Claude Code (claude-opus-5-5) · lenses: correctness, design, docsNote
Low Risk
Packaging and test expectations only; installs that previously resolved to FastMCP below 2.13.0 will fail at resolve time instead of at runtime, with no change to RedisVL MCP server logic.
Overview
The
redisvl[mcp]extra now requiresfastmcp>=2.13.0,<4instead of>=2.0.0, so dependency resolution matches releases RedisVL can actually run (auth imports, pydantic 2.13 compatibility, JWTbase_url, and SSE tool-list hangs on some 2.12.x builds).pyproject.tomldocuments those failure modes; the MCP how-to tells users who pin FastMCP themselves to stay in that range.Tests no longer assume
additionalProperties: falseappears in tool schemas on every FastMCP version—2.x omits the key but still rejects extra arguments at call time; the assertion runs only on FastMCP 3+.uv.lockreflects the new specifier.Reviewed by Cursor Bugbot for commit 9271c34. Bugbot is set up for automated code reviews on this repo. Configure here.