Expected Behavior

mcp-feature-server-runtime passes on PRs carrying ok-to-test, and the installed mcp respects the bound pyproject.toml declares.

Current Behavior

The job fails and the feature server starts without MCP:

ERROR:feast.infra.mcp_servers.mcp_server:Failed to initialize MCP integration: Server.__init__() takes 2 positional arguments but 3 were given
  File "sdk/python/feast/infra/mcp_servers/mcp_server.py", line 113, in add_mcp_support_to_app
    mcp = FastApiMCP(
  File ".venv/lib/python3.11/site-packages/fastapi_mcp/server.py", line 144, in setup_server
    mcp_server: Server = Server(self.name, self.description)
TypeError: Server.__init__() takes 2 positional arguments but 3 were given
WARNING:fastapi:MCP support was requested but could not be enabled

The server then comes up without MCP and the job's subsequent curl probes against 127.0.0.1:6566 fail.

Steps to reproduce

Any PR with ok-to-test. It is not branch-specific:

Both fail identically, and they are the only two non-skipped runs of pr_integration_tests.yml in the recent list.

Specifications

• Version: master (4efb86c68 and later)
• Platform: ubuntu-latest, Python 3.11, as run by pr_integration_tests.yml

Possible Solution

pyproject.toml:144 declares mcp = ["fastapi_mcp", "mcp>=1.0,<2"], but sdk/python/requirements/py3.10-ci-requirements.txt, py3.11-… and py3.12-… all pin mcp==2.0.0. The manifest forbids what CI installs.

Two commits on 2026-07-31 explain it:

• 4f6b82109 ("chore: Remove upper version bound for uvicorn (chore: Remove upper version bound for uvicorn #6662)") regenerated the requirement sets as a side effect, taking mcp from 1.28.0 to 2.0.0.
• faf85e06f ("fix: Use correct image name in multi-arch imagetools push step") added the mcp>=1.0,<2 bound about five hours later, without regenerating the requirements.

So the guard exists but is not applied. Neither commit title mentions mcp, which is probably why the two were never connected.

The resolver picking 2.0.0 is reasonable on the metadata: fastapi-mcp==0.4.0 requires mcp>=1.12.0 with no upper bound, so mcp 2.x satisfies it while breaking its code. fastapi-mcp 0.4.0 is the latest release, so bumping it is not an option. Feast's own <2 bound is the right defence; it just needs to reach the lock. Latest 1.x is 1.29.0.

Happy to open the PR. One question first, since it changes the diff considerably: would you prefer a minimal change pinning just mcp (plus its hashes) in the three files, or a full make lock-python-dependencies-all regeneration? A full relock will move unrelated packages, which is how this was introduced.

This is separate from #6252, which proposes replacing fastapi_mcp with the MCP Python SDK for unrelated reasons and would also dissolve this. I am not trying to pre-empt that; this is just an interim unblock while CI is red.