MCP Python SDK、巨大レスポンスの受信ボトルネックをコミュニティが報告　バッファの反復コピーで二次コストが発生

MCP Python SDKに寄せられた新たな報告では、大規模なツールレスポンスの遅延はクライアントの受信処理に起因するとされている。10月13日に作成されたissueでは、SDK付属のサーバーとクライアントを使って問題を再現。翌日には別の参加者がメインブランチでも再現し、既存テストの結果を追加した。確認時点でissueは未解決で、開発欄にも関連する修正提案は掲載されていない。issueとテスト記録

問題は、stdout_readerが未完了のメッセージを蓄積する際、データチャンクを受け取るたびに(buffer + chunk).split("\n")を実行する点にある。レスポンスが大きく、改行がまだ届いていない場合、ループのたびに受信済みの内容全体が再コピーされる。チャンクのサイズが一定なら、処理コストはメッセージサイズに対して二次的に増大する。提案された変更では、断片をリストに一時保存し、改行に達した時点で結合することで、データの反復コピーを減らす。原因と変更案

この問題の発生条件は、トランスポート形式に直結している。MCP仕様では、stdioは改行区切りのJSON-RPCメッセージを使用し、1つのメッセージ内に実際の改行を含めてはならない。そのため、大規模なツール結果も、非常に長い1つのJSONメッセージになる可能性がある。下位層でデータが分割して読み込まれても、それだけでアプリケーション層が完全なレスポンスを受け取ったことにはならず、クライアントは未完了の断片を保持する必要がある。MCPトランスポート仕様

報告者はWindows 11、Python 3.14.7、mcp 2.3.0で、16 MBのレスポンスの処理時間が5.39秒から0.27秒に短縮したと測定した。別の参加者も、変更後に既存のstdioテストが通過したと報告している。ただし、いずれもコミュニティメンバーの環境で得られた限定的な結果であり、あらゆるエージェントアプリケーションで同程度の高速化が得られるとは限らない。測定結果と検証範囲

エンジニアリングチームにとって、この報告はモデル以外にも遅延の原因があることを示している。ツールが大規模な文書やクエリ結果を返す場合、レスポンスサイズと受信時間が非線形に増えていないかを測定し、同じ処理経路に該当するかを確認するとよい。今後は正式な修正、複数プラットフォームでの検証、1.xへのバックポートを追跡する必要がある。現時点では、この問題をStreamable HTTPにまで拡張して考える根拠はない。