feat(MCP): [4/5] add RedisVL MCP CLI

[vishal-bala]

Builds on top of #540

Summary

• The repo did not have an end-to-end MCP entrypoint, which made the MCP design in spec/MCP.md incomplete in practice and left users without a supported way to run RedisVL as an MCP server.
• That gap creates friction for local agent integrations: the server contract, config, filters, and tools existed as design and implementation work, but there was no polished CLI path and no clear packaging/runtime story for using it.
• This change completes the MCP implementation by adding the rvl mcp command, wiring in lazy optional-dependency handling, and rounding out the MCP server/config/tooling surface with tests and documentation updates.
• It also adds task-oriented help text for the new subcommand and keeps the base CLI usable without MCP extras installed.

Testing

• uv run python -m pytest tests/unit/test_cli_mcp.py -q
• uv run python -m pytest tests/unit/test_mcp -q
• uv run rvl
• uv run rvl mcp --help
• Manual smoke check: started uv run rvl mcp --config /tmp/redisvl_mcp_smoke/config.yaml against a live Redis container
• uvx --from 'redisvl[mcp]' rvl mcp --config ... currently resolves the published package, which does not yet include the new extra/CLI path, so that install-path check is not green until a release is cut

---

Note

Medium Risk
Adds a new async CLI entrypoint that loads optional MCP dependencies at runtime and manages server startup/run/shutdown; failures here affect how users launch MCP but do not change core indexing logic.

Overview
Adds a new rvl mcp subcommand that runs the RedisVL MCP server over stdio, including --config (required) and optional --read-only handling.

The new CLI path lazily imports redisvl.mcp (so the base CLI works without MCP extras), validates Python >= 3.10, and provides clearer error messaging and shutdown behavior for async server lifecycles.

Introduces unit tests covering dispatch, help text, version/dependency failures, read-only flag propagation, and startup/run error handling.

^{Written by Cursor Bugbot for commit e705fbb. This will update automatically on new commits. Configure here.}

[jit-ci]

🛡️ Jit Security Scan Results

✅ No security findings were detected in this PR

---

^{Security scan by Jit}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9441c1d942

ℹ️ 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".

[rbs333]

LGTM! figure this goes after the other stuff

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

[cursor]

Double startup causes "already running" error at runtime

High Severity

_serve explicitly calls server.startup() before run_async(transport="stdio"), but FastMCP's run_async will invoke the _server_lifespan context manager passed during construction, which also calls self.startup(). The guard in _begin_startup raises RuntimeError("MCP server is already running") when lifecycle state is already RUNNING, so the server immediately errors out and never actually serves. All tests use fake servers that lack run_async, so they always exercise the else branch and never trigger the lifespan-mediated double-startup path that production code follows.