[vishal-bala]

Motivation

The mcp extra declared fastmcp>=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_mcp and tests/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	Result
2.0.0 – 2.3.3	fastmcp.server.auth and fastmcp.server.dependencies do not exist, so the auth provider and the tools that read the caller's token fail to import
2.4.0 – 2.11.1	FastMCP itself fails to import alongside pydantic 2.13.4 (cannot specify both default and default_factory)
2.11.2 – 2.12.0	JWTVerifier rejects the base_url argument the server builds it with, so JWT auth fails (2.12.1 to 2.12.5 accept it)
2.12.1, 2.14.7, 3.0.0	473 pass; the 10 failures are tests that patch fastmcp.settings.transport (added in 3.1) or assert the additionalProperties: false schema key, which these releases omit
3.4.11 (locked)	all 483 pass

The 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.lock records the new specifier; no locked version changes.
• A comment in tests/integration/test_mcp/test_profiles.py claimed 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: false in the tool schema. This was checked on 2.12.1 and 2.14.7 by running test_a_client_cannot_pass_the_injected_field_over_the_wire without its schema assertion. Before 3.1, FASTMCP_TRANSPORT is ignored and the server falls back to stdio, as the comment in redisvl/mcp/server.py already says; the rvl mcp CLI always passes --transport, so only programmatic callers that rely on the environment variable are affected.

Reviewer Brief

Start here: pyproject.toml, the fastmcp constraint in the mcp extra. 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, docs}

---

Note

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 requires fastmcp>=2.13.0,<4 instead of >=2.0.0, so dependency resolution matches releases RedisVL can actually run (auth imports, pydantic 2.13 compatibility, JWT base_url, and SSE tool-list hangs on some 2.12.x builds). pyproject.toml documents those failure modes; the MCP how-to tells users who pin FastMCP themselves to stay in that range.

Tests no longer assume additionalProperties: false appears 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.lock reflects the new specifier.

^{Reviewed by Cursor Bugbot for commit 9271c34. Bugbot is set up for automated code reviews on this repo. Configure here.}

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-30T15:53:20.793955Z	390b138	Draft marked ready

ℹ️ 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" or "@codex security review".

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]

💡 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".