Doc Relay uses the Go MCP SDK with child MCP servers over stdio (CommandTransport). We need a host-side bound on JSON-RPC frame/message size so a buggy or malicious child cannot send one very large newline-delimited JSON frame and force the parent to buffer/decode it before application code can reject it.\n\nCurrent observation in v1.6.0: the framing/read loop is owned inside the SDK transport/JSON-RPC stack, so hosts using CommandTransport do not appear to have a supported seam equivalent to Decoder.MaxBytes, io.LimitReader per frame, or MaxMessageBytes. Replacing the SDK framing locally would conflict with using the SDK as the JSON-RPC/MCP boundary.\n\nRequested API shape could be any of:\n\n- a MaxMessageBytes/MaxFrameBytes option on CommandTransport or Client/Server options,\n- an exported transport wrapper hook that bounds each newline-delimited frame before JSON decoding, or\n- documented guidance for safely enforcing this without reimplementing the SDK framing loop.\n\nThe important behavior is that an oversized child stdout frame is rejected and the connection is closed before unbounded parent heap growth.
Doc Relay uses the Go MCP SDK with child MCP servers over stdio (CommandTransport). We need a host-side bound on JSON-RPC frame/message size so a buggy or malicious child cannot send one very large newline-delimited JSON frame and force the parent to buffer/decode it before application code can reject it.\n\nCurrent observation in v1.6.0: the framing/read loop is owned inside the SDK transport/JSON-RPC stack, so hosts using CommandTransport do not appear to have a supported seam equivalent to Decoder.MaxBytes, io.LimitReader per frame, or MaxMessageBytes. Replacing the SDK framing locally would conflict with using the SDK as the JSON-RPC/MCP boundary.\n\nRequested API shape could be any of:\n\n- a MaxMessageBytes/MaxFrameBytes option on CommandTransport or Client/Server options,\n- an exported transport wrapper hook that bounds each newline-delimited frame before JSON decoding, or\n- documented guidance for safely enforcing this without reimplementing the SDK framing loop.\n\nThe important behavior is that an oversized child stdout frame is rejected and the connection is closed before unbounded parent heap growth.