Description:
When an MCP backend sends a ping request with a numeric JSON-RPC ID, Envoy AI Gateway forwards the request to the client without applying its backend-aware request-ID encoding. The client's response therefore returns the original numeric ID and is rejected with HTTP 400:
Playwright is an example that expects this behavior and is used to cleanup sessions
invalid response ID type: 1
mcpRequestContext.maybeServerToClientRequestModify recognizes other server-to-client request methods before applying the common ID rewrite, but ping currently falls through the default case and returns early.
Expected behavior:
- A backend
ping with numeric ID 1 is exposed to the client as a backend-qualified string ID such as 1__i__mcp-playwright.
- The client response is routed only to the backend that originated the ping.
- The backend receives its original numeric response ID
1.
- Different backends can reuse the same original ping ID without collision.
ping is recorded as a recognized server-to-client method rather than unsupported.
This is protocol routing only. It does not enable, schedule, or otherwise change heartbeat behavior.
Protocol version scope:
Envoy AI Gateway v1.1.0 negotiates MCP protocol version 2025-06-18. In that version, the Ping specification states that either the client or server can initiate a ping request and requires the receiver to respond with the same request ID.1
MCP protocol version 2026-07-28 removes ping from the protocol.2 This issue is therefore limited to the legacy 2025-06-18 MCP path and does not propose adding ping handling to the modern 2026-07-28 path.
Repro steps:
- Check out
v1.1.0 (c217da8a539570ba3f6014a60c2687c29a945f1f).
- Pass a JSON-RPC request with method
ping and numeric ID 1 through maybeServerToClientRequestModify for backend mcp-playwright.
- Observe that the ID remains numeric
1 instead of becoming 1__i__mcp-playwright.
- Return a client response with numeric ID
1 and observe HTTP 400 from handleClientToServerResponse.
A focused regression test on the unpatched source reports:
expected: string("1__i__backend")
actual : int64(1)
Environment:
- Envoy AI Gateway v1.1.0
- Linux amd64
- Go 1.26.4 (selected by the repository toolchain directive)
Logs:
invalid response ID type: 1
Description:
When an MCP backend sends a
pingrequest with a numeric JSON-RPC ID, Envoy AI Gateway forwards the request to the client without applying its backend-aware request-ID encoding. The client's response therefore returns the original numeric ID and is rejected with HTTP 400:Playwright is an example that expects this behavior and is used to cleanup sessions
mcpRequestContext.maybeServerToClientRequestModifyrecognizes other server-to-client request methods before applying the common ID rewrite, butpingcurrently falls through the default case and returns early.Expected behavior:
pingwith numeric ID1is exposed to the client as a backend-qualified string ID such as1__i__mcp-playwright.1.pingis recorded as a recognized server-to-client method rather than unsupported.This is protocol routing only. It does not enable, schedule, or otherwise change heartbeat behavior.
Protocol version scope:
Envoy AI Gateway v1.1.0 negotiates MCP protocol version
2025-06-18. In that version, the Ping specification states that either the client or server can initiate apingrequest and requires the receiver to respond with the same request ID.1MCP protocol version
2026-07-28removespingfrom the protocol.2 This issue is therefore limited to the legacy2025-06-18MCP path and does not propose adding ping handling to the modern2026-07-28path.Repro steps:
v1.1.0(c217da8a539570ba3f6014a60c2687c29a945f1f).pingand numeric ID1throughmaybeServerToClientRequestModifyfor backendmcp-playwright.1instead of becoming1__i__mcp-playwright.1and observe HTTP 400 fromhandleClientToServerResponse.A focused regression test on the unpatched source reports:
Environment:
Logs: