[v2] Expose the SSE max_event_size setting in Streamable HTTP clients
@Kludex đang làm issue này rồi.
Từ ngày 19/8/2026.
Đánh giá
Issue này chưa được đánh giá.
Mô tả
What happened?
MCP Python SDK v2.0.0 constructs httpx2.EventSource(response) directly when parsing a Streamable HTTP POST response. Since HTTPX2 2.10, a single SSE event is limited to 1 MiB by default.
When a valid tools/call result is larger than 1 MiB and is returned as one SSE event, HTTPX2 raises SSEError. The SDK catches that transport error and the caller receives the generic MCP error:
SSE stream ended without a response
There is currently no public Streamable HTTP setting that lets callers raise the SSE event-size limit. The transport also creates SSE readers in multiple places: the POST response path constructs EventSource(response) directly, while the GET and reconnection paths call AsyncClient.sse() without a transport-level event-size setting.
What did you expect?
I expected the Streamable HTTP client/transport to expose an SSE event-size setting and apply it consistently to:
- POST SSE responses;
- the GET stream; and
- reconnection streams.
One possible API shape would be a max_event_size argument on streamable_http_client() and StreamableHTTPTransport, matching HTTPX2 terminology. The exact public API is open for maintainer direction.
If an event exceeds the configured limit, the original JSON-RPC request should receive a clear request-scoped error. The already-sent POST should not be replayed, and sibling requests sharing the session should remain usable.
Reproduction
Use an MCP Streamable HTTP server whose tool returns more than 1 MiB of text in a single SSE event, then call that tool with the v2 client:
result = await client.call_tool("large_result", {})
With a 2 MiB single-event response, the call fails with SSE stream ended without a response. The same response succeeds when the underlying EventSource is constructed with a larger max_event_size.
I can contribute an implementation and exact boundary tests if maintainers agree with exposing this setting.
Environment
- Python 3.11
- MCP Python SDK 2.0.0
- HTTPX2 2.10.0
- Area: Client transports / Streamable HTTP
Reference
- HTTPX2 support and the 1 MiB default: https://github.com/pydantic/httpx2/pull/1071
This issue was prepared with AI assistance and reviewed by the reporter.
- Ngôn ngữ chính
- Python
- Star
- 24.3k
- Fork
- 4k
- Merge trung bình
- 1 ngày 11 giờ
- Pull request đã merge (30 ngày)
- 30
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của modelcontextprotocol/python-sdk
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
modelcontextprotocol/python-sdk#3566 ·
-
Streamable HTTP client logs a WARNING for valid 202 Accepted on session termination (DELETE) Đang mởv1 v2
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
modelcontextprotocol/python-sdk#3546 · 5 bình luận ·
-
v1 v2
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
modelcontextprotocol/python-sdk#3545 · 1 bình luận ·
-
v1 v2
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 91/100
modelcontextprotocol/python-sdk#3508 · 2 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
modelcontextprotocol/python-sdk#3504 ·
Tất cả issue của modelcontextprotocol/python-sdk
Issue tương tự
-
essnmx good first issue
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 95/100
-
[Feature] 奇物选择添加优先级 Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
syfoud/Simulated_Scepter#174 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Giskard-AI/giskard-oss#2840 · 1 bình luận ·
-
A claim comment carrying the issue number is silently declined while the workflow reports success Đang mởarea: repo bug perceived difficulty: 2
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
yeti-platform/yeti#1380 ·