fix: bind client to localhost to match server

[felixweinberger]

Bind client to localhost instead of all interfaces to match server

Motivation and Context

Complete the security hardening started in e8e9909 by also binding the client to localhost only.
Previously only the server was protected while the client remained exposed to the network,
allowing attackers to access the server through the client as a proxy.

Changes:

• Add HOST environment variable support to client (prod mode)
• Configure Vite dev server to bind to localhost by default
• Update browser auto-open URLs to use actual host instead of hardcoded 127.0.0.1
• Fix missing cancelled parameter in startProdClient function

Before	After

How Has This Been Tested?

prod: npm run build && npm run start - works
dev: npm run dev - works
test: npm test - works

Breaking Changes

There may be instances where clients were inadvertently relying on clients binding to *:6274 in their setup - e.g. if accessing the inspector UI via a remotely hosted machine or similar.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[cliffhall]

Suggested a simple refactor of some duplicated lines.

Also... can we align the way we refer to the loopback, either make the link with the token be 127.0.0.1 instead of localhost (or make the host in the client and start script be localhost instead of 127.0.0.1).

Previously we were using 127.0.0.1 since it refers directly to the loopback and doesn't require DNS lookup, thus being slightly safer. However 127.0.0.1 is an IPv4 specific address and in IPv6 environments the loopback is ::1 and so could possibly lead to ECONNREFUSED. So localhost is arguably better for that purpose. An attacker would have to edit your hosts file to redirect 127.0.0.1 to an evil address, so you'd already have to have some compromise.

[cliffhall]

These lines could be extract/refactored into a function and called from line 117 and line 156.

[cliffhall]

Added suggestions to fix a couple of PORT remnants from before we codified SERVER_PORT and CLIENT_PORT env vars. Below is how we want to control ports:

---

NOTE: Another (prior) issue exists where the client looks only for DEFAULT_MCP_PROXY_LISTEN_PORT unless MCP_PROXY_FULL_ADDRESS is set in config. A bit of a chicken/egg problem anyway since the config is fetched from the proxy's /config address. Thus if the proxy server is started on a port other than default, the client won't be able to find it.

Clearly that part needs to be revisited, since we now have a MCP_PROXY_TOKEN on the querystring, but that's for another PR, unless you feel like tackling it in this one. If SERVER_PORT was set in the environment (i.e., is not the default), we need to add it to the querystring and used in place of DEFAULT_MCP_PROXY_LISTEN_PORT in the client.

[cliffhall]

Suggested change

	const PORT = parseInt(process.env.PORT || "6277", 10);
	const PORT = parseInt(process.env.SERVER_PORT || "6277", 10);

We're using CLIENT_PORT and SERVER_PORT everywhere except here and . Thus you get a mismatch of the actual port the server is started on and what is reported on the terminal console if you just set PORT.

[cliffhall]

Suggested change

	const port = process.env.PORT || 6274;
	const port = parseInt(process.env.CLIENT_PORT || "6274", 10);

We're using CLIENT_PORT and SERVER_PORT everywhere except here and server/src/index.ts. Thus you get a mismatch of what's reported on the command line if you just set PORT