Support mcp 2.x (Python SDK): pin blocks mcp 2.0.0

[ProgrammerPlus1998]

Summary

chainlit currently pins the MCP Python SDK to the 1.x line and cannot be installed alongside mcp 2.0.0 (released 2026-07-28). This issue tracks the breaking changes in mcp 2.0 that affect the backend.

Current constraint

mcp>=1.11.0,<2.0.0 — backend/pyproject.toml:45.

Breaking changes in mcp 2.0 that affect chainlit

All in backend/chainlit/server.py, verified against the installed mcp==2.0.0 SDK:

1. streamablehttp_client renamed → streamable_http_client.

   • server.py:1306 — from mcp.client.streamable_http import streamablehttp_client. In 2.0 the function is streamable_http_client.

2. streamable_http_client / sse_client dropped the headers kwarg.

   • server.py:1434-1437 — streamablehttp_client(url=..., headers=mcp_connection.headers). In 2.0 headers is removed; it must be set on an httpx2.AsyncClient passed as http_client=.
   • server.py:1418-1421 — sse_client(url=..., headers=mcp_connection.headers), same change.

Notes

• The tuple-arity change is already handled: server.py:1442 does read, write = transport[:2], which works for both the old 3-tuple and the new 2-tuple, so no change needed there. server.py:1445-1449 constructs ClientSession without read_timeout_seconds, so the timedelta→float change does not apply. The main work is the import rename and moving headers into an httpx/httpx2 client.
• Dependency-floor updates. mcp 2.0 requires pydantic>=2.12, anyio>=4.9, typing-extensions>=4.13, and adds required deps opentelemetry-api and mcp-types (exact-pinned to the SDK version); the SDK's HTTP layer moved from httpx/httpx-sse to httpx2>=2.5.0.

Happy to help with a PR if the maintainers are open to it.

[qye-inf]

We hit this from the downstream side: chainlit is now the only thing in our dependency graph holding mcp below 2.0.

Two data points that might be useful here:

• claude-agent-sdk relaxed its own mcp<2.0.0 to <3.0.0 in 0.2.140 and now supports 1.x and 2.x side by side. Of the packages we depend on that touch mcp, every other one is floor-only or capped at <3 — this is the last <2.0.0 we're carrying.
• Verified by resolution rather than by reading metadata: with a whole-graph mcp>=2.0.0 constraint, the resolve fails through chainlit alone, and chainlit==2.11.1 + mcp>=2.0.0 reports the conflict directly. Worth flagging for anyone else testing this — an unpinned chainlit>=1.0.0 resolves "successfully" by walking back to a version predating the mcp dependency, which looks like a pass but means you've lost chainlit.

The analysis above matches what we see, the three changes look small, and we'd be glad to send a PR.

One practical question first: would a release be likely to follow a merge? The last release was 2.11.1 (2026-04-22) while PRs have kept merging, so a merged fix wouldn't reach consumers via PyPI on its own. Knowing whether to expect a release or to plan on pinning a main SHA would help us — and probably others landing on this issue.