MCP Python SDK 社群回報大型回覆接收瓶頸，重複複製緩衝區造成平方級成本

MCP Python SDK 的一項新回報，將大型工具回覆的延遲指向用戶端接收流程。10 月 13 日開啟的議題使用 SDK 自帶的伺服器與用戶端重現問題；隔日另有參與者在主分支重現，並補充既有測試結果。截至查核時，議題仍開啟，開發欄位未列出關聯修補提案。議題與測試紀錄

問題出在 stdout_reader 累積尚未完成的訊息時，每收到一塊資料便執行 (buffer + chunk).split("\n")。當回覆很大、換行尚未抵達，每次迴圈都會重新複製已收到的內容；在固定大小分塊下，總處理成本因此隨訊息大小呈平方級成長。提案改將片段暫存在串列，遇到換行才合併，減少重複搬移。原因與修改方案

這個觸發條件與傳輸格式直接相關。MCP 規範要求 stdio 使用換行分隔 JSON-RPC 訊息，單則訊息內不得包含實體換行；大型工具結果因此仍可能是一條很長的 JSON 訊息。底層分塊讀取並不代表應用層已取得完整回覆，用戶端需要保留未完成的片段。MCP 傳輸規範

原作者在 Windows 11、Python 3.14.7 與 mcp 2.3.0 上，測得 16 MB 回覆耗時由 5.39 秒降至 0.27 秒。另一名參與者亦回報修改後既有 stdio 測試通過，但這些仍是社群機器上的局部結果，不能直接推算所有代理應用的加速幅度。量測與驗證範圍

對工程團隊而言，這提示了模型之外的延遲來源：若工具會回傳大量文件或查詢結果，可量測回覆大小與接收耗時是否非線性成長，再判斷是否命中同一路徑。後續應追蹤正式修補、跨平台驗證及 1.x 回補；目前也沒有證據可將此問題延伸至 Streamable HTTP。