mcp-proxy: support both mcp 1.x and 2.x (drop the <2 cap) (#307)

[sunishsheth2009]

Summary

Fixes #307. A fresh ucode install resolved mcp 2.0.0 off mcp>=1.28.0, and ucode mcp-proxy crashed on import — 2.x renamed streamablehttp_client → streamable_http_client and moved from httpx to httpx2. Every MCP server through the proxy then failed to connect.

PR #311 capped mcp<2 to stop the bad resolution. This PR instead makes the proxy work against both mcp 1.x and 2.x and removes the cap, so a clean install on either major just works.

How one code path covers both majors

The key realization: both mcp 1.28+ and 2.x export the 2.x-native call shape streamable_http_client(url, http_client=<AsyncClient>) (1.x's streamablehttp_client is a deprecated shim over it). Only two things differ across the majors, and both are handled:

	mcp 1.x	mcp 2.x	handling
HTTP lib	httpx	httpx2	_httpx() resolves whichever the SDK uses
client yield	(read, write, get_session_id)	(read, write)	_run takes streams[0], streams[1]
auth	httpx.Auth	httpx2.Auth	_build_token_auth() subclasses the resolved flavor

• _httpx() imports httpx2 (mcp 2.x) else httpx (mcp 1.x), via importlib so the type checker / CI — pinned to mcp 1.x, no httpx2 present — don't choke on a static import httpx2.
• _build_token_auth() builds the per-request bearer Auth from that flavor; auth_flow's generator contract is identical in httpx and httpx2.
• pyproject: mcp>=1.28.0,<2 → mcp>=1.28.0. httpx stays a direct dep (the 1.x path); httpx2 arrives transitively with mcp 2.x, so no direct httpx2 dep is declared.

The fail-fast auth behavior from #201's follow-up is preserved unchanged.

How do you know it works?

Verified in a real venv against both majors (not just the pinned one):

• mcp 1.28.1 (pinned): 21 proxy tests pass; ty check src/ clean; full suite 1788 passed.
• mcp 2.0.0 + httpx2 2.9.1 (installed into the venv, --no-sync): the proxy imports (the [Bug] Fresh ucode install pulls mcp 2.0 and mcp-proxy crashes on a removed API #307 crash point is gone), _httpx() selects httpx2, and httpx2.AsyncClient(auth=…) + streamable_http_client(http_client=…) compose without error; 21 proxy tests pass; ty check src/ clean.
• Confirmed the yield-arity difference empirically (1.28.1 yields a 3-tuple, 2.0.0 a 2-tuple) and that streams[0], streams[1] handles both.
• New/updated tests in tests/test_mcp_proxy.py: mcp dep is uncapped; _httpx() matches the installed SDK; the shared streamable_http_client symbol imports; the token Auth is an instance of the selected flavor's Auth.
• The only 2 suite failures are the pre-existing test_e2e_user_agent live-gateway network tests (fail identically on main). ruff format + ruff check clean.

Not done / caveats

• No live-gateway handshake under mcp 2.x: all my OAuth tokens expired this session (no browser), so I proved transport construction + import + preflight under 2.x, not a real end-to-end tool call. A reviewer with a live workspace and mcp 2.x installed can confirm the round trip.
• The internal pypi mirror currently resolves mcp 1.28.1 (2.x may not be mirrored yet); the uncapped constraint takes whatever is newest available.

This supersedes the earlier "keep the cap + actionable error" revision of this branch.

This pull request and its description were written by Isaac.

[sunishsheth2009]

Reworked per maintainer direction: instead of keeping the mcp<2 cap + surfacing an error, the proxy now supports both mcp 1.x and 2.x and the cap is removed — a clean install on either major works.

One code path handles both because mcp 1.28+ and 2.x both export streamable_http_client(url, http_client=…). The only differences — httpx vs httpx2, and a 3- vs 2-tuple yield — are resolved at runtime (_httpx() picks the flavor the installed SDK uses; _run unpacks positionally).

Verified against both mcp 1.28.1 and mcp 2.0.0 in a real venv: proxy imports, transport composes, 21 proxy tests + ty check clean on each. Details in the updated description.