Your team wants Claude to open pages in a real browser to check that a fix renders correctly, and someone proposes running the browser tool as a hosted server so nobody has to install anything. A second person points at the documentation's preference for HTTP as support for that plan. What is wrong with the reasoning, and what should the team do?

The principle — Two separate questions get confused here. Which transport is preferred is a question about remote servers. Whether a server can be remote at all is a question about what the tool has to touch, and it is answered first.

Why the key is correct — The documentation recommends HTTP for connecting to remote MCP servers, which is a statement about servers that are already remote. It says nothing about whether a given tool should be remote. Driving a browser on a particular laptop is work that has to happen on that laptop, and stdio servers run as local processes on your machine, which is the property the job requires. The second speaker has taken advice about how to reach a remote server and read it as advice to make this server remote.

Why the others are wrong — Hosting the tool puts the process somewhere that cannot see the browser under test, no matter how sound the transport choice is. Outbound connectivity determines whether the session can talk to a server, not what that server can observe. And no configuration entry grants a remote process access to a local machine, because access follows the location of the process rather than the contents of a file.

Remember this — Decide where the work has to happen before you decide how to reach it. The transport question only opens once the location question is settled, and taking them in the other order is what produces an architecture nobody can debug.

Sources — Anthropic's Claude Code MCP reference.