Consider a healthCheckEndpoint for inner mcp service

[anyuan95]

First of all, thanks for the great tool.

We are using SuperGateway in docker now(stdio -> sse).
Sometimes we may find a scenario where healthCheckEndpoint is already able to return OK, but in reality, due to network and other reasons, the internal MCP service has not yet started.
eg:

What we hope for is to have an endpoint that can obtain the normal state of the internal MCP (rather than SuperGateway itself).
Based on this, we can easily and quickly ensure that the SuperGateway and MCP services in the container have reached an available state by performing HEALTHCHECK at the container level.

Is this feasible? Or is there a lightweight way to determine the availability of MCP services within SuperGateway?

[Nedomas]

hey @anyuan95 - this is a great idea - would love to do something about it. Was wondering about "monitoring" the MCP a bit deeper. We ourselves run thousands of MCPs in Supercorp and it seems some of the open-source implementations leak memory and just hang eventually.

It a bit unclear to me whats the best way to "monitor" MCPs deeper than /healthz Express endpoint. We thought about possibly hitting the "connect" or "listTools" periodically just to make sure it has not hung (actually something we’re working on in Supermachine atm).

Wonder maybe you could just hit "listTools" manually from the same part as you hit /healthz atm? Not sure if this is the best ergonomics for you guys and also not sure how we could reliably know that underlying service has not hung.

[anyuan95]

Thank you for your reply!

Indeed, as you said, the most accurate detection method currently known may be tools/list. And we are currently doing the same, regularly initiating tools/list requests on the scheduling side for detection.
At the same time, we are considering whether we can make some modifications within the container or on the SuperGateway to add another health check capability mentioned above. A less elegant (but maybe effective) way is to add another HTTP endpoint and perform the above operations (such as tools/list, or simply verifying whether the SSE endpoint returns standard endpoint events) within this HTTP endpoint.

[nullStack65]

Jumping in because we’ve run into a very similar need when using SuperGateway as an MCP proxy.

Right now /healthz only reflects the health of SuperGateway itself. That means we can end up in a state where /healthz is 200 OK while the upstream MCP server is still starting, unreachable, or hung, so container-level HEALTHCHECK sees “healthy” even though end-to-end MCP is not actually usable.

From what I’ve seen, quite a few MCP servers already expose some kind of HTTP health endpoint, so there are (at least) two complementary directions that seem useful:

1. Protocol-level health via tools/list (what you’re suggesting)
   Use tools/list (or connect) as a “deep” health probe to detect cases where the MCP process is up but non-responsive or stuck. This can catch subtle hangs and memory-leak scenarios that a simple /healthz on the MCP wouldn’t.

2. Upstream-aware health endpoint in SuperGateway
   In addition to the current /healthz for SuperGateway itself, expose something like /upstream/healthz that reflects the health of the underlying MCP server. For HTTP-based MCPs this could just call the configured upstream health endpoint and mirror its status. For stdio MCPs it could be a lighter check (e.g. “process alive / last successful probe”), or even reuse the tools/list logic above.

From an ergonomics perspective for Docker/Kubernetes:

• One option is to keep /healthz as it is (SuperGateway-only) and add /upstream/healthz for the MCP itself, so users can choose what to wire into HEALTHCHECK.
• Another option is to make /healthz optionally aggregate both checks (SuperGateway + upstream MCP) under a config flag, and only report healthy when both are OK.

Either way, having a first-class “upstream health” endpoint (or mode) in SuperGateway would make it much easier to express “this container is ready when both the proxy and the MCP are actually usable”, without having to bolt on custom health logic on the side.