MCP over HTTP explained: how agents actually talk to your machine

An MCP HTTP server is a Model Context Protocol server that clients reach over HTTP at a URL, instead of spawning it as a child process over stdio. The client sends JSON-RPC messages to the endpoint — “list your tools,” “call this tool” — and the server responds, optionally streaming results. It’s the transport that lets one long-running server serve many clients at once.

If you’ve configured an MCP server and wondered what actually happens after you hit save, this post is the wire-level tour.

The two transports, in one minute

MCP defines the messages; the transport just carries them. There are two common options:

• stdio. The client launches the server as a subprocess and exchanges JSON over stdin/stdout. Simple, but the server’s lifetime is tied to the client, and each client gets its own private copy of the server.
• Streamable HTTP. The server runs independently and listens on a port. Clients POST JSON-RPC messages to it; the server can respond directly or stream events back. One server, many clients, a stable address.

HTTP is the right shape when the server is an application with its own life. ReDock is a good example: the app runs your local websites — WordPress, Astro, Next.js, Node.js — whether or not any AI client is attached. Its entire surface is served as MCP tools on localhost:47200. Claude Desktop, Claude Code, and Cursor can all connect to that one endpoint at the same time, and none of them had to launch anything.

What actually goes over the wire

The conversation between client and server is JSON-RPC, and it follows a predictable arc:

1. Initialize. The client introduces itself and negotiates protocol versions and capabilities.
2. Discovery. The client asks for the tool list. Each tool comes back with a name, a human-readable description, and a JSON Schema for its inputs. This is the step that makes MCP different from a plain API — the interface is self-describing, which we unpack in MCP vs plain APIs.
3. Tool calls. When the model decides to act, the client sends a tools/call request with the tool name and arguments. The server does the work and returns structured content.
4. Streaming, when it helps. Long operations can stream progress back rather than making the client wait on a silent request.

From the model’s point of view, none of this is visible. It sees tools; the client handles the plumbing.

Why localhost HTTP is a sweet spot

localhost:47200 looks like a web address, but nothing leaves your machine. That combination — HTTP semantics, local-only reach — buys several things at once:

• One server, every client. Configure Claude Desktop and Cursor against the same endpoint; both see the same sites, same tools, same state.
• A stable address. No per-client process management, no “which copy of the server is this client talking to.”
• No exposure by default. The port binds locally. When you want the outside world to see a site, that’s an explicit, separate act — ReDock does it through Cloudflare tunnels, not by opening the MCP port.

The local-versus-remote question deserves its own treatment, which it gets in Local MCP vs remote MCP.

What a good HTTP server does beyond the spec

The protocol tells a server how to answer; it doesn’t tell it how to be trustworthy. Two habits matter in practice:

Report real state. When a tool says a site is running, that claim should be derived from the actual process, not from “we sent the start command.” ReDock calls this honest state — status in the UI and in tool results is mapped from real process state, never invented. For an agent, this is the difference between recovering from a failure and hallucinating past one.

Return errors the model can act on. “Site not found — valid sites are X, Y, Z” lets the model retry correctly. A bare 500 does not.

If you’d rather see the tools than read about transports, the full surface is documented in the MCP docs.

FAQ

Is an MCP HTTP server exposed to the internet?

Not unless you expose it. A server bound to localhost (like ReDock on localhost:47200) is reachable only from your machine. Remote exposure is a deliberate, separate step.

Which is better, stdio or HTTP?

stdio is fine for small single-client tools. HTTP wins when the server is long-running, serves multiple clients, or is part of an app that exists independently of the AI client.

Do I have to understand JSON-RPC to use MCP?

No. Clients and servers handle the protocol. You only touch this layer if you’re building a server yourself; as a user you point a client at an endpoint and go.

ReDock puts a full local web stack behind one HTTP endpoint your agents can share — download ReDock.