MCP over HTTP explained: how agents actually talk to your machine
An MCP HTTP server answers at a URL rather than being launched per client, so one long-running server can serve Claude, Claude Code and Cursor at the same time.
An MCP HTTP server is a Model Context Protocol server that clients reach at a URL instead of launching as a child process. The client posts JSON-RPC messages to the endpoint, asks what tools exist, calls them, and reads results back, sometimes streamed. It is the transport that lets one long-running server serve several clients at once.
If you have configured an MCP server and wondered what happens after you press save, this is the tour.
Two transports, one minute
MCP defines the messages. The transport only carries them, and there are two common ones.
Standard input and output. The client launches the server as a subprocess and passes JSON over its pipes. Simple. The server’s life is tied to the client, and every client gets its own private copy.
Streamable HTTP. The server runs on its own and listens on a port. Clients post to it, and it can answer directly or stream events back. One server, many clients, a stable address.
HTTP is the right shape when the server is an application with a life of its own. ReDock is one: the app runs your local websites whether or not any AI client is attached, and its whole surface answers on 127.0.0.1:47200. Claude Desktop, Claude Code and Cursor can all be connected at once, and none of them launched anything.
What goes over the wire
The conversation is JSON-RPC and it follows a predictable arc.
- Initialise. The client introduces itself and the two sides agree on a protocol version and what each supports.
- Discovery. The client asks for the tool list. Each tool comes back with a name, a description a person can read, and a JSON Schema for its inputs. This is the step that separates MCP from an ordinary API, and MCP vs plain APIs unpacks it.
- Tool calls. When the model decides to act, the client sends the tool name and arguments. The server does the work and returns structured content.
- Streaming, when it earns its keep. A long operation can report progress instead of leaving the client on a silent request.
None of this is visible to the model. It sees tools. The client handles the plumbing. The specification has the full message list if you are building a server.
Copy one line, connect one client
Because the address is stable, connecting is naming it. Claude Code takes a single line.
Cursor and Windsurf take a small JSON block with the same URL in it. Claude Desktop cannot reach a local HTTP endpoint directly, so ReDock ships a connector file that wraps a tiny proxy: one click installs it and Claude Desktop asks you to confirm. If ReDock is not running you get a clear “server unreachable” message rather than a hang.
Why a loopback address is a sweet spot
127.0.0.1:47200 looks like a web address and nothing leaves the machine. That pairing buys three things at once.
- One server, every client. Point Claude Desktop and Cursor at the same endpoint and both see the same sites, the same tools, the same state.
- A stable address. No per-client process management, no wondering which copy of the server a client is talking to.
- Nothing exposed by default. The port is loopback only. When you want the outside world to see a site, that is a separate act, over a Cloudflare tunnel, and it never involves the MCP port.
The same protocol, hosted
The other half of the picture is a server that is genuinely remote because the resource is. ReDock Web serves an MCP door at https://app.redock.xyz/mcp for the live WordPress sites a workspace has connected. The first connection lands on a consent page that names the workspace and the level being asked for, and the approved app is listed afterwards with a Revoke beside it.
Same transport, different reach. Local MCP vs remote MCP is the longer comparison.
What a good server does past the specification
The protocol says how to answer. It does not say how to be trustworthy. Two habits matter.
Report state you checked. When a tool says a site is running, that should come from the process, not from “we sent the start command”. ReDock calls it honest state, and the tool results carry the same truth the window does. For an agent, this is the difference between recovering from a failure and narrating past one.
Return errors a model can act on. “Site not found, the sites here are X, Y and Z” lets the model retry correctly. A bare 500 does not.
The full local surface is in the MCP docs.
FAQ
Is an MCP HTTP server exposed to the internet?
Not unless you expose it. A server bound to loopback, like ReDock on 127.0.0.1:47200, answers only on your own machine. Do not tunnel or port-forward it; reaching a machine from another device is what a separate remote-access setting is for.
Which is better, pipes or HTTP?
Pipes are fine for a small single-client tool. HTTP wins when the server runs for a long time, serves several clients, or is part of an app that exists whether or not an AI client is attached.
Do I have to understand JSON-RPC to use MCP?
No. The clients and servers handle the protocol. You touch this layer only if you are writing a server.
Can I be connected to a local and a hosted MCP server at once?
Yes, and most people who run both end up doing exactly that: the local door for the sites on their own machine, the hosted one for the live sites they look after.
ReDock puts a whole local web stack behind one endpoint your agents can share. Download it for macOS or Windows.