Pin `httpx<1.0` (or similar upper bound) — `pip install --pre` resolves `httpx 1.0.dev3` and breaks `httpx-sse`

[SyncTekLLC]

Problem

mcp 1.27.0's declared dep is httpx>=0.27.1 with no upper bound. When a downstream package is alpha (and so its users pip install --pre), pip's resolver picks httpx 1.0.dev3 — a real published pre-release on PyPI — which breaks httpx-sse and the MCP transport layer.

Reproduction

python -m venv /tmp/repro && source /tmp/repro/bin/activate
pip install --pre 'mcp==1.27.0'
pip show httpx | grep Version
# Version: 1.0.dev3
python -c "from mcp.client.stdio import stdio_client"
# (depending on httpx_sse version, this either raises or silently mis-routes SSE)

The path: --pre makes httpx 1.0.dev* eligible → pip picks the highest matching version → httpx-sse 0.4.x (mcp's own dep at httpx-sse>=0.4) is incompatible with httpx 1.x's API changes.

Evidence

PyPI confirms httpx 1.0.dev1, 1.0.dev2, 1.0.dev3 are real published pre-releases. They show up automatically under --pre.

mcp's pyproject.toml currently declares:

"httpx>=0.27.1",
"httpx-sse>=0.4",

No upper bound on either.

Why this matters for downstream

Anyone shipping an alpha or beta library on top of mcp instructs their users to pip install --pre <library>. That --pre flag propagates through pip's resolution to all transitive deps. So every alpha-stage MCP server hits this in production user environments.

We caught this in the pre-publish smoke for simdrive 1.0.0a4 and shipped a defensive httpx<1.0 pin in our own deps in 1.0.0a5. It works, but every downstream library having to do this independently is the wrong fix.

Proposed fix

Add an upper bound to mcp's own httpx constraint. Two reasonable options:

# Option A — strict, breaks at any 1.x:
"httpx>=0.27.1,<1.0",

# Option B — accommodate when httpx-sse adds 1.x support:
"httpx>=0.27.1,<2.0",

Option A is safer until httpx-sse ships explicit httpx 1.x support; option B is forward-leaning. Either is better than the current unbounded constraint.

Same treatment for httpx-sse>=0.4 would also be defensive (e.g., httpx-sse>=0.4,<1.0).

Removal trigger

Once mcp adds the bound, downstream defensive pins (like simdrive's) can be dropped in a future release.

Happy to send a PR if a maintainer confirms which bound is preferred.