A developer runs a Streamable HTTP MCP server on a laptop for local testing and often works from café Wi-Fi. The server currently listens on 0.0.0.0 with no authentication. Which change does the transport guidance recommend?
Select an answer to reveal the explanation.
Short Explanation
Listening on 0.0.0.0 in a café is like leaving your front door open on a busy street. Bind to 127.0.0.1 so only your own machine can knock, and you should still ask for credentials. Don't lean on the Origin check here; it's built for browsers, not the laptop at the next table.
Full Explanation
The Streamable HTTP security warning gives three measures for local servers: validate the Origin header on all incoming connections, bind only to localhost (127.0.0.1) rather than all network interfaces (0.0.0.0) when running locally, and implement proper authentication for all connections. On a shared network, a server bound to 0.0.0.0 is reachable by every other device on that network, so loopback binding removes that exposure and authentication protects against other local processes. The local-server guidance adds that HTTP servers meant for local use should require an authorization token or use restricted IPC such as Unix domain sockets. Relying on the Origin check fails by concept: Origin validation defends against browsers being steered by hostile pages through DNS rebinding, while a direct client on another device can simply send no Origin, or any value it likes. Relying on read-only annotations fails because annotations are hints from the server, describe behaviour rather than access, and do not stop anyone from calling the tools. Relying on an unusual port fails because obscurity is not access control; ports are easily scanned. Exam caveat: binding to loopback does not protect against other software on the same machine, which is why authentication is still recommended. Operational check: from a second device on the same network, attempt a POST to the MCP endpoint and confirm the connection is refused.