Docker HEALTHCHECK hardcodes 127.0.0.1 while HOST defaults to 0.0.0.0

Which version line?

v2 — current (@modelcontextprotocol/inspector@latest)

Which client?

All / shared core

Inspector version

2.7.0 (git tag) — static code-review finding, not run locally

Node version

N/A — static code review, no live run performed

Operating system (and browser, for the web client)

N/A — static code review

Transport

Not applicable / never connected

MCP server under inspection

N/A — this is a static code-review finding against the 2.7.0 tag's Dockerfile, not a live reproduction against a running MCP server.

Steps to reproduce

Found via static review of the 2.7.0 tag source, not a live run.

1. Dockerfile line 31 sets ENV HOST=0.0.0.0 as the container's default bind address.
2. Dockerfile lines 65-66 define HEALTHCHECK ... CMD node -e "fetch('http://127.0.0.1:'+(process.env.CLIENT_PORT||6274)+'/')..." — hardcoding 127.0.0.1 rather than reading $HOST.
3. Build and run the image unmodified, or with HOST left at its default of 0.0.0.0: the healthcheck's own probe target (127.0.0.1) happens to still work today because 0.0.0.0 binds all interfaces including loopback.
4. Override HOST to a specific non-loopback interface address (a legitimate config for some deployments) and the healthcheck's hardcoded 127.0.0.1 probe would no longer reach the bound server, flagging a healthy container as unhealthy.
   No live container run was performed; this is based on reading the Dockerfile against the 2.7.0 tag.

Expected behavior

The Dockerfile's HEALTHCHECK probes whatever address the server is actually configured to bind to (respecting $HOST), or the docs/Dockerfile make explicit that HOST must stay loopback-reachable for the healthcheck to remain valid.

Actual behavior

HEALTHCHECK unconditionally curls http://127.0.0.1:$CLIENT_PORT/ while ENV HOST=0.0.0.0 is the image's own default, so the two are only accidentally consistent (0.0.0.0 binds loopback too). Any future change that narrows HOST to a specific non-loopback interface would silently break the healthcheck without any code change to the healthcheck line itself.

Suggested fix: have the healthcheck read $HOST (falling back to 127.0.0.1 when HOST is 0.0.0.0 or unset, since curling 0.0.0.0 directly is not meaningful), e.g. node -e "fetch('http://'+((process.env.HOST&&process.env.HOST!=='0.0.0.0')?process.env.HOST:'127.0.0.1')+':'+(process.env.CLIENT_PORT||6274)+'/')...".

Logs, errors, or screenshots

No response

Already prototyped a fix?

No response

Before you submit

• I searched existing issues and this is not a duplicate.
• This is not a security vulnerability report (those go through the private advisory process).

Start in the Dockerfile at line 31 and lines 65-66, where HOST is set and the Node.js HEALTHCHECK URL is assembled. Trace how HOST and CLIENT_PORT are used, then build and run the image with the default and a specific non-loopback HOST. Done means the healthcheck probes the configured bind address while retaining valid behavior for the default 0.0.0.0 setting.