GeezerVison

@nithin42 thanks for picking this up. I verified the fix locally, since the job it repairs can't run here yet: this PR shows 1 check passing and 4 skipped, so mcp-feature-server-runtime hasn't fired. That job only runs on PRs carrying ok-to-test, which is the same reason the breakage went five days unnoticed.

Both halves of the change hold up under mcp==1.29.0 with fastapi-mcp==0.4.0:

The exact call that fails today is accepted. Server.__init__ in 1.29.0 is (self, name, version=None, instructions=None, ...), so Server(self.name, self.description) at fastapi_mcp/server.py:144 binds fine. I also ran the real failing path end to end, constructing FastApiMCP(app, name=..., description=...) against a FastAPI app, and it builds cleanly where it currently raises TypeError.

Dropping mcp-types is right too, not just harmless. mcp==1.29.0 declares no dependency on it and it isn't installed transitively, so it was only ever there because mcp 2.0.0 pulled it in.

One incidental note, no action needed: fastapi_mcp is passing a description into what 1.29.0 names version. That's been true all along and is fastapi-mcp's business, but it's probably why mcp 2.x tightened the signature and why this surfaced as a positional-count error rather than a type error.

@ntkathole @franciscojavierarceo this needs ok-to-test to prove itself, and it unblocks the integration suite for every labelled PR.

@ntkathole @franciscojavierarceo — could you please approve the 16 pending workflow runs on this PR?

The ok-to-test label has been added by @jyejare but since this PR is from a fork, the pull_request_target workflows require explicit maintainer approval to execute. The checks are currently failing instantly at the approval gate — not due to any code issue.

This fix unblocks the mcp-feature-server-runtime and registration integration suite for all labelled PRs. @larrysingleton007 has already verified the fix locally. Would appreciate a quick approve on the workflow runs. 🙏

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 46.81%. Comparing base (b8dfcb0) to head (4362125).
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

@@           Coverage Diff           @@
##           master    #6713   +/-   ##
=======================================
  Coverage   46.81%   46.81%           
=======================================
  Files         415      415           
  Lines       50399    50399           
  Branches     7214     7214           
=======================================
  Hits        23592    23592           
  Misses      25157    25157           
  Partials     1650     1650           

@nithin42 the workflows are running now, and two have already failed for a reason unrelated to the mcp fix. Both integration-test-duckdb-offline and integration-test-ray die about one second in, at the Setup pixi step, before any test runs:

Error:   × lock file not up-to-date with the workspace
##[error]The process '/home/runner/.pixi/bin/pixi' failed with exit code 1

The cause is the psutil==5.9.0 → psutil>=5.9.0 change in pyproject.toml. CI runs pixi install --locked, which hard-fails whenever the manifest and pixi.lock disagree, and the PR doesn't include a regenerated lock. Three more jobs use the same setup step and will fail identically once they run: integration-test-registration-ci, -registration-local, and mcp-feature-server-runtime. That last one is the job this PR is meant to fix, so it can't go green until the lock is regenerated.

Fix is pixi lock, committing pixi.lock alongside pyproject.toml.

Two things that cost me time when I hit this on #6683, in case they save you some:

Nothing local catches it. Unit tests, ruff and mypy all run under uv, not pixi, so a fully green local run tells you nothing about this.

pixi lock --check is not read-only. It rewrites the lock as a side effect before reporting the error, leaving your tree dirty. Use plain pixi lock.

If you don't have pixi installed, this container invocation works:

docker run --rm --platform linux/amd64 \
  -e SETUPTOOLS_SCM_PRETEND_VERSION_FOR_FEAST=<version> \
  -v <repo>:/src -w /src ghcr.io/prefix-dev/pixi:latest pixi lock

--platform linux/amd64 is required on Apple Silicon, since linux-arm64 isn't among the lock's platforms. The SETUPTOOLS_SCM_PRETEND_VERSION_FOR_FEAST value is safe to fake, because the lock records feast as a path dependency with no version of its own.

Worth noting the psutil loosening is what triggers this, and it's incidental to the mcp fix. Dropping it would avoid the lock regeneration entirely, if you'd rather keep this PR narrow and handle the Windows wheels separately.

Thanks @larrysingleton007 — reverted the psutil loosening in 32a3619. It was incidental to the mcp fix and was causing pixi install --locked to fail before tests even ran.

This PR is now narrowly focused on the mcp pin only:

• mcp 2.0.0 → 1.29.0 across all nine requirements lock files
• mcp-types removed (not needed by 1.29.0)
• pyproject.toml unchanged

The psutil Windows-wheel change can follow in a separate PR with a pixi lock regeneration.

@jyejare — force-pushed to revert the incidental psutil change. The PR is now clean and narrowly focused on the mcp pin. Please approve the workflow runs again. Thanks!

@nithin42 Did you run make lock-python-dependencies-all ? if not please run.

@jyejare yes, I successfully ran make lock-python-dependencies-all inside Docker to compile all 15 lock files.

However, doing so required adding a greenlet!=3.5.5 constraint in pyproject.toml (since greenlet==3.5.5 lacks a source distribution on PyPI and crashes pybuild-deps compile).

Because we modified pyproject.toml but did not update pixi.lock, the CI runs are currently failing at the Setup pixi step with:
Error: lock file not up-to-date with the workspace

Would you prefer that we:

1. Revert the pyproject.toml change to keep this PR narrow (since the greenlet compilation failure only affects running dependency lock generation locally, not regular CI/runtime)?
2. Keep the greenlet workaround in pyproject.toml and regenerate/commit the updated pixi.lock alongside it?

I would go for option 2.

Hi @jyejare @ntkathole @franciscojavierarceo @larrysingleton007,

Quick update: I have rebased on the latest master and squashed the branch into a single clean commit.

Key changes included:

• Pinned mcp==1.29.0 across the 9 requirements lockfiles to satisfy the mcp>=1.0,<2 constraint in pyproject.toml (fixing CI requirements pin mcp==2.0.0 while pyproject declares mcp>=1.0,<2, breaking mcp-feature-server-runtime #6706).
• Added httpx-sse==0.4.0 with verified hashes to the lockfiles as required by mcp 1.29.0.
• Isolated RestRegistryServer in test_mcp_server.py to prevent running unmocked gRPC handlers.

All 23 CI checks (unit tests on Python 3.10/3.11/3.12 across Ubuntu & macOS, integration tests, and linters) are now fully green.

The PR is ready for your review and merge if everything looks good to you (LGTM). Thanks!