GitHub Repo
MCP Python SDK Community Reports Large-Response Bottleneck, with Repeated Buffer Copies Causing Quadratic Cost
Community reports from October 13–14 indicate that receiving large tool responses over stdio in the MCP Python SDK can add substantial latency because of repeated buffer copies. Contributors have shared a minimal reproduction and before-and-after test results, but no official fix has been released.
A new report about the MCP Python SDK traces latency for large tool responses to the client’s receive path. An issue opened on October 13 reproduces the problem using the SDK’s own server and client; the following day, another contributor reproduced it on the main branch and added results from existing tests. At the time of review, the issue remained open, with no linked fix proposal listed in the development fields. Issue and test records
The problem occurs as stdout_reader accumulates an incomplete message: each time it receives a chunk of data, it runs (buffer + chunk).split("\n"). When the response is large and no newline has arrived, each loop recopies the content received so far. With fixed-size chunks, the total processing cost therefore grows quadratically with message size. The proposed change stores fragments in a list and joins them only when a newline arrives, reducing repeated data movement. Cause and proposed change
The trigger is directly related to the transport format. The MCP specification requires stdio to use newline-delimited JSON-RPC messages, with no literal newlines inside a message. A large tool result can therefore still be one very long JSON message. Chunked reads at the transport layer do not mean the application has received a complete response; the client must retain incomplete fragments. MCP transport specification
The original reporter measured a 16 MB response on Windows 11, Python 3.14.7, and mcp 2.3.0, with processing time falling from 5.39 seconds to 0.27 seconds. Another contributor also reported that existing stdio tests passed after the change. These are still limited results from community machines and cannot be used to estimate the speedup across all agent applications. Measurements and validation scope
For engineering teams, this points to a source of latency beyond the model itself: if tools return large documents or query results, measure whether receive time grows nonlinearly with response size, then determine whether the same code path is involved. Follow-up should track an official fix, cross-platform validation, and a backport to 1.x. There is currently no evidence that this issue extends to Streamable HTTP.