Problem
WithMCPParse returns early when the parsed message has no method:
// Skip if not a valid JSON-RPC 2.0 request
if mcpReq.JSONRPC != "2.0" || mcpReq.Method == "" {
next.ServeHTTP(w, r)
return
}That is precisely the shape of a JSON-RPC response, including the ping/heartbeat responses clients send back ({"jsonrpc":"2.0","id":42,"result":{}}). For those, MCPMethodInfo is never populated, and a consumer cannot distinguish "not parsed because it was a response" from "not parsed because it was malformed or non-MCP".
Why this matters downstream
In github/github-mcp-server-remote, requestctx.WithHandler needs to know whether a request is a heartbeat (it is used to suppress log noise for pings). Because the parsed metadata cannot express that, it has to read and decode the body itself, independently of WithMCPParse.
That was the root of github/github-mcp-server-remote#938: two middleware each did io.ReadAll on the same body before any size limit applied. We fixed the memory amplification in github/github-mcp-server-remote#939 by enforcing the limit at the edge and bounding heartbeat detection to a 4 KiB prefix, but the duplicate read is still there in reduced form — every POST pays a bounded copy plus a json.Unmarshal that WithMCPParse is about to repeat a moment later.
We deliberately did not work around it downstream. The only in-repo option was a substring pre-filter before the unmarshal, which is not strictly semantics-preserving (a client escaping the key as "\u0072esult" would change the result), so we left the read in place rather than take that risk.
Suggested change
Surface the JSON-RPC envelope even when method is empty, so consumers can classify responses without re-reading the body. For example, keep the existing early return for genuinely non-MCP payloads but still record the envelope when jsonrpc == "2.0":
- add
ID and a Result presence flag (or an IsResponse bool) to MCPMethodInfo, and
- populate
MCPMethodInfo for jsonrpc == "2.0" messages with an empty method, leaving Method empty as it is today.
Existing consumers that switch on Method are unaffected, since the field keeps its current value.
Payoff
requestctx.WithHandler could then move below WithMCPParse and read nothing at all: heartbeat classification would come from already-parsed metadata. That removes the last duplicate body read on the remote hot path (~1,250 RPS on 1 CPU / 1 GiB pods).
Happy to send the PR if the shape sounds right.
References
Problem
WithMCPParsereturns early when the parsed message has nomethod:That is precisely the shape of a JSON-RPC response, including the ping/heartbeat responses clients send back (
{"jsonrpc":"2.0","id":42,"result":{}}). For those,MCPMethodInfois never populated, and a consumer cannot distinguish "not parsed because it was a response" from "not parsed because it was malformed or non-MCP".Why this matters downstream
In
github/github-mcp-server-remote,requestctx.WithHandlerneeds to know whether a request is a heartbeat (it is used to suppress log noise for pings). Because the parsed metadata cannot express that, it has to read and decode the body itself, independently ofWithMCPParse.That was the root of github/github-mcp-server-remote#938: two middleware each did
io.ReadAllon the same body before any size limit applied. We fixed the memory amplification in github/github-mcp-server-remote#939 by enforcing the limit at the edge and bounding heartbeat detection to a 4 KiB prefix, but the duplicate read is still there in reduced form — every POST pays a bounded copy plus ajson.UnmarshalthatWithMCPParseis about to repeat a moment later.We deliberately did not work around it downstream. The only in-repo option was a substring pre-filter before the unmarshal, which is not strictly semantics-preserving (a client escaping the key as
"\u0072esult"would change the result), so we left the read in place rather than take that risk.Suggested change
Surface the JSON-RPC envelope even when
methodis empty, so consumers can classify responses without re-reading the body. For example, keep the existing early return for genuinely non-MCP payloads but still record the envelope whenjsonrpc == "2.0":IDand aResultpresence flag (or anIsResponse bool) toMCPMethodInfo, andMCPMethodInfoforjsonrpc == "2.0"messages with an emptymethod, leavingMethodempty as it is today.Existing consumers that switch on
Methodare unaffected, since the field keeps its current value.Payoff
requestctx.WithHandlercould then move belowWithMCPParseand read nothing at all: heartbeat classification would come from already-parsed metadata. That removes the last duplicate body read on the remote hot path (~1,250 RPS on 1 CPU / 1 GiB pods).Happy to send the PR if the shape sounds right.
References