build(deps): bump mcp lock to 1.28.1 to clear image-scan findings

[yuneng-berri]

Relevant issues

Linear ticket

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

Screenshots / Proof of Fix

Before: the image-scan check currently fails on every PR because the shipped image carries mcp 1.26.0, e.g. this run on #33801

NAME  INSTALLED  FIXED IN  TYPE    VULNERABILITY        SEVERITY  EPSS         RISK
mcp   1.26.0     1.27.2    python  GHSA-jpw9-pfvf-9f58  High      0.3% (16th)  0.2
mcp   1.26.0     1.27.2    python  GHSA-hvrp-rf83-w775  High      0.2% (13th)  0.2
mcp   1.26.0     1.28.1    python  GHSA-vj7q-gjh5-988w  High      0.2% (7th)   0.1
[0038] ERROR discovered vulnerabilities at or above the severity threshold

After, at 52834fc (this PR's lock), building the same image and scanning it with the same grype version and flags the workflow pins (v0.114.0, --only-fixed --fail-on high):

$ docker build -f docker/Dockerfile.non_root -t litellm-image-scan:head .
$ grype litellm-image-scan:head --only-fixed --fail-on high --output table
No vulnerabilities found

The local build and scan ran on arm64; the image-scan check on this PR is the matching amd64 run. The follow-up commit a920ad5 only raises the pyproject floor and re-records it in the lock; the resolved package set, and therefore the image content, is identical to the scanned 52834fc

Type

🚄 Infrastructure

Changes

uv lock --upgrade-package mcp, taking mcp from 1.26.0 to 1.28.1 (the current latest), plus raising the pyproject.toml floor from mcp>=1.26.0,<2.0 to mcp>=1.28.1,<2.0. The floor raise is what makes the bump durable: with the old floor, any future unrelated uv lock --upgrade-package X whose dependency tree conflicts with mcp 1.28.x could legally resolve mcp back down to 1.26.0, and the regression would only surface as a red image-scan check after the fact. With the floor raised the resolver refuses outright, and installs that consume litellm[proxy] from PyPI without our lock get the same guarantee. The Docker images install with uv sync --frozen, so the shipped image picks the version up from the lock. The exclude-newer timestamp churn in the diff is uv refreshing its relative "3 days" snapshot setting, the same churn present in every recent lock update

Between 1.26.0 and 1.28.1 the upstream changes are additive (OAuth resource validation on the client, streamable HTTP stream buffering, stdio robustness fixes) plus two DeprecationWarnings introduced in 1.28.0 for the websocket transport and the experimental tasks API; litellm imports neither deprecated surface, verified by grepping every mcp import in litellm/ and enterprise/

No new tests: this bump is scanner-driven rather than feature-driven, the enforcement that the image stays clean is the image-scan workflow itself, and a static version-floor test would duplicate that gate while going stale on the next advisory. For verification, the mcp-related unit suites (about 2600 tests across the tests/test_litellm mcp directories) were run on 1.28.1, and the five files under tests/test_litellm/proxy/_experimental/mcp_server were additionally run A/B on 1.26.0 and 1.28.1 in the same environment: results are identical on both versions (337 passing, and the same 68 tests failing locally on both for environment reasons that reproduce at the staging tip without this change), so the bump changes no test outcome

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

[greptile-apps]

No reviewable files after applying ignore patterns.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[codspeed-hq]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing litellm_/mcp-version-bumps-669776 (a920ad5) with litellm_internal_staging (f3d2015)¹}

Footnotes

1. No successful run was found on litellm_internal_staging (6a26a3a) during the generation of this report, so f3d2015 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩