Fix Dependabot alerts round 2: bump pillow and mcp

[ishubhamvashist]

Summary

Resolves the newly disclosed Dependabot alerts that appeared since PR #22 by re-locking two transitive packages via targeted uv lock --upgrade-package calls. Only uv.lock changed — no pyproject.toml constraint changes, no other package versions touched.

What was bumped

Package	Before	After	Alerts fixed
pillow / Pillow	12.2.0	12.3.0	#114-#126 (all pillow/Pillow duplicates, high/medium)
mcp	1.25.0	1.28.1	#103, #104, #105 (high)

Both are pulled in transitively (pillow via vllm/mistral-common/torchvision; mcp via vllm) and both resolved cleanly to their fully-patched versions without requiring any vllm/torch/setuptools version change — verified via uv tree --invert and confirmed the diff only touches these two packages' lock entries.

What was investigated but deliberately NOT changed

vllm (alerts #106-#111, #113, medium/high, fixed_in 0.24.0): A real fix now exists (current: 0.23.0), unlike last round. I attempted the bump (uv lock --upgrade-package vllm resolves cleanly to 0.25.1) but before adopting it I checked how vllm is imported in this repo:

• server/vllm_parsers.py does from vllm.entrypoints.openai.protocol import ChatCompletionRequest, and also imports vllm.reasoning.ReasoningParserManager / vllm.tool_parsers.ToolParserManager.
• server/backends/vllm_backend.py reaches into vllm.__file__'s parent directory to locate a bundled chat template file.

I downloaded the vllm 0.24.0 and 0.25.1 sdists directly from PyPI and inspected them: vllm.entrypoints.openai.protocol no longer exists as of 0.24.0 — it was split into vllm.entrypoints.openai.chat_completion.protocol, .../completion/protocol.py, .../models/protocol.py, etc., with no backward-compat shim re-exporting the old path. This means server/vllm_parsers.py would raise ModuleNotFoundError at import time on every vllm version that satisfies the alert's fixed_in threshold (I checked 0.24.0 specifically, the minimum fixed version — already refactored there).

vllm.reasoning/vllm.tool_parsers (ReasoningParserManager.get_reasoning_parser, ToolParserManager.get_tool_parser) are unaffected — same API in 0.25.1.

Given this is a confirmed, code-breaking import path change and the instruction to touch only lockfile/pyproject and not break functionality, I left vllm at 0.23.0. Bumping vllm is a real fix but requires a source change to server/vllm_parsers.py (updating the import path) plus GPU-based end-to-end testing of the parsing/tool-calling path — out of scope for a lockfile-only PR. Flagging this as the top risk item for follow-up.

setuptools (alert #127, medium, fixed_in 83.0.0) and torch (alert #112, low, fixed_in 2.13.0): Both are transitively pinned tightly by vllm. Confirmed via forced resolution attempts:

• uv lock --upgrade-package torch==2.13.0 fails: vllm (all available versions up to 0.25.1) hard-pins torch==2.11.0.
• uv lock --upgrade-package setuptools==83.0.0 fails: vllm pins setuptools>=77.0.3,<81.0.0 for python>=3.12.

Since torch 2.13.0 doesn't exist for any vllm release yet, and setuptools 83.0.0 conflicts with vllm's own pin, both are blocked upstream by vllm — same category as vllm itself, not independently fixable without the same breaking vllm bump discussed above.

diskcache (alert #8, medium, fixed_in: null): No upstream patch exists yet. Left unchanged, same as PR #22.

Testing

• uv lock --check passes (lock is consistent with pyproject.toml).
• Diff reviewed line-by-line: only pillow and mcp version/hash entries changed in uv.lock; no other package was touched as a side effect.
• uv sync --all-extras fails on this machine with nvidia-cudnn-frontend having no macOS wheel (CUDA-only package) — confirmed this identical failure exists on an unmodified fresh clone of current main, so it's a pre-existing environment limitation, not a regression from this change.
• Functionally exercised both bumped packages in an isolated venv (can't fully uv sync here due to the GPU-only deps above):
  • Installed pillow==12.3.0 standalone: created an image, drew on it, saved/reloaded it — round-trips correctly.
  • Installed mcp==1.28.1 standalone: imported every submodule this repo actually uses — mcp.client.session.ClientSession, mcp.client.streamable_http.streamable_http_client, mcp.client.stdio.stdio_client/StdioServerParameters, mcp.server.Server, mcp.server.streamable_http_manager.StreamableHTTPSessionManager (used in workloads/mcp_support/*.py) — all import cleanly with no API changes.
• No repo test suite or lint config beyond ruff/mypy settings exists to run (checked pyproject.toml, searched for test_*.py — none found).

Risk to flag before merging

vllm/setuptools/torch are still open because the only real fix path (bumping vllm to 0.24.0+) breaks server/vllm_parsers.py's import of vllm.entrypoints.openai.protocol.ChatCompletionRequest (module removed/relocated). This is a source-code change, not a lockfile change, and needs GPU-based testing of the tool-calling/reasoning-parsing path since vllm can't be installed/imported on this (non-CUDA) machine. Recommend a follow-up PR that:

1. Updates the import in server/vllm_parsers.py to the new module path(s).
2. Bumps vllm to >=0.24.0.
3. Is tested on a GPU box exercising actual chat completion + tool-calling + reasoning-parser flows before merge.

This PR itself is low-risk: it only changes two transitive packages (pillow, mcp) that resolved cleanly with no other version changes, and both were spot-checked for basic functional correctness.