Summary
Requests are size-capped (1 MB MaxLineLength), but responses are not. A tool returning 10,000 results, a find_in_file over a giant file, or a maliciously-large search query can produce a multi-GB JSON response that the server allocates entirely in memory and then writes in a single WriteLineAsync to stdout. Server OOM is the failure mode; client stdin-buffer overflow is the runner-up. This is distinct from #1605 (excerpt-only output budget for the excerpt tool) — the cap proposed here is server-wide and applies to every MCP tool's serialized response.
Where
src/CodeIndex/Mcp/McpServer.cs:102-105 (response serialization without size check)- All tool handlers in
src/CodeIndex/Mcp/McpToolHandlers.cs
Suggested approach
(1) Define a MaxResponseBytes constant (e.g., 10 MB; configurable via env / initialize params). (2) Sample serialized size during construction; if the response exceeds the cap, truncate the array result, set truncated: true (paired with #C327), include next_offset (paired with #C328), and emit a data.cap_reason: "max_response_bytes" field. (3) For non-array tools (e.g., a single multi-MB excerpt), return an error -32603 with data: { reason: "response_too_large", limit_bytes, actual_bytes } so the client can refine the query. (4) Cover with a regression test that triggers the cap in both array-truncation and single-blob-rejection cases.
Summary
Requests are size-capped (1 MB MaxLineLength), but responses are not. A tool returning 10,000 results, a
find_in_fileover a giant file, or a maliciously-largesearchquery can produce a multi-GB JSON response that the server allocates entirely in memory and then writes in a singleWriteLineAsyncto stdout. Server OOM is the failure mode; client stdin-buffer overflow is the runner-up. This is distinct from #1605 (excerpt-only output budget for the excerpt tool) — the cap proposed here is server-wide and applies to every MCP tool's serialized response.Where
src/CodeIndex/Mcp/McpServer.cs:102-105(response serialization without size check)src/CodeIndex/Mcp/McpToolHandlers.csSuggested approach
(1) Define a
MaxResponseBytesconstant (e.g., 10 MB; configurable via env / initialize params). (2) Sample serialized size during construction; if the response exceeds the cap, truncate the array result, settruncated: true(paired with #C327), includenext_offset(paired with #C328), and emit adata.cap_reason: "max_response_bytes"field. (3) For non-array tools (e.g., a single multi-MB excerpt), return an error -32603 withdata: { reason: "response_too_large", limit_bytes, actual_bytes }so the client can refine the query. (4) Cover with a regression test that triggers the cap in both array-truncation and single-blob-rejection cases.