build(deps): bump mcp to 1.28.1 to clear osv-scan High findings

[yassin-berriai]

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

osv-scan on any branch cut from the current litellm_internal_staging tip reports, from uv.lock:

| https://osv.dev/GHSA-hvrp-rf83-w775 | 7.6 | PyPI | mcp | 1.26.0 | 1.27.2 | uv.lock |
| https://osv.dev/GHSA-jpw9-pfvf-9f58 | 7.1 | PyPI | mcp | 1.26.0 | 1.27.2 | uv.lock |
| https://osv.dev/GHSA-vj7q-gjh5-988w | 7.6 | PyPI | mcp | 1.26.0 | 1.28.1 | uv.lock |

After this bump uv lock resolves mcp to 1.28.1, which is at or above every listed fixed release; the osv-scan job on this PR is the proof

Type

🚄 Infrastructure

Changes

Raises the mcp floor in pyproject.toml from 1.26.0 to 1.28.1 and relocks, clearing three known High vulnerabilities that currently fail osv-scan on every branch cut from litellm_internal_staging. No code changes; the lock delta is confined to the mcp entry

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

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[greptile-apps]

Greptile Summary

This PR raises the mcp package floor in pyproject.toml from >=1.26.0 to >=1.28.1 and relocks, with no production code changes.

• pyproject.toml: single-line constraint bump to mcp>=1.28.1,<2.0 under the proxy extras group.
• uv.lock: mcp entry updated to 1.28.1 with new sdist/wheel URLs and SHA-256 hashes; exclude-newer simultaneously changed from a fixed absolute timestamp to the epoch-minimum placeholder 0001-01-01T00:00:00Z, delegating cutoff control to the existing exclude-newer-span = "P3D" setting.

Confidence Score: 4/5

Safe to merge — the only risk is a secondary uv.lock behaviour change that is unrelated to the intended package version bump.

The pyproject.toml change is minimal and correct. The uv.lock change also correctly pins mcp to 1.28.1 with verified hashes, but the simultaneous switch of exclude-newer from a fixed absolute timestamp to a rolling placeholder is a side-effect that changes how future uv lock reruns resolve packages — worth a double-check but not a blocker for the stated goal of this PR.

The exclude-newer modification in uv.lock warrants a quick confirmation that the rolling-window approach is intentional for this repository.

Important Files Changed

Filename	Overview
pyproject.toml	Bumps the mcp minimum version constraint from >=1.26.0 to >=1.28.1 in the proxy extras group — a clean, isolated change.
uv.lock	Locks mcp to 1.28.1 with updated sdist/wheel hashes; also changes exclude-newer from a fixed timestamp to the 0001-01-01T00:00:00Z placeholder, delegating the actual cutoff to the existing exclude-newer-span = "P3D" setting.

_{Reviews (1): Last reviewed commit: "build(deps): bump mcp to 1.28.1 to clear..." | Re-trigger Greptile}

[greptile-apps]

exclude-newer changed to an open-ended placeholder

The exclude-newer field was previously a pinned absolute timestamp (2026-07-13T19:39:19…) and is now 0001-01-01T00:00:00Z with a comment that it "has no effect." Resolution is now driven solely by exclude-newer-span = "P3D", meaning a rolling 3-day window from whenever uv lock is re-run. Existing installs from the lockfile remain deterministic (hashes are pinned), but any future uv lock invocation will consider packages released up to 3 days before that run, rather than being capped at a fixed date. This is a behavioural change worth confirming is intentional — if the intent was only to advance the mcp floor, the previous fixed timestamp approach would have been more conservative.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[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_bump_mcp_1_28_1 (4526d8a) with litellm_internal_staging (669ef38)}