Over stdio, framing is newline-delimited and there is nothing to route. Streamable HTTP inverts that. But if you assume moving an MCP server from a local subprocess to a URL changes the protocol itself, think again. In the dated MCP specification 2026-07-28, the Transports page makes a sharp claim: protocol semantics are identical on every transport. A transport only defines framing, delivery, request metadata, cancellation, and termination. That distinction is the key to understanding remote MCP servers.
This tutorial unpacks what remote actually means, how stdio compares with Streamable HTTP, and why remote deployments took off after MCP launched in November 2024. You will examine the cost of stateful versus stateless operation, then point a client at a remote MCP server in a hands-on walkthrough. We will also cover authorization, discovery, and the gaps the spec leaves open, followed by a practical framework for choosing local or remote for your own server, and a short list of actions for this week. By the end, you should be able to reason about remote MCP servers as transport bindings, not as a separate protocol, and make informed deployment decisions.
What Remote Actually Means in MCP
The MCP specification, dated 2026-07-28, says it plainly on its Transports page: protocol semantics are identical on every transport. Remote is a transport choice, not a separate protocol.
A binding defines framing, delivery, request metadata, cancellation and termination. It does not define message meaning. So a remote MCP server is an MCP server reached over a network binding, and nothing more exotic than that.
The spec defines two standard bindings:
stdio: newline-delimited messages over the standard streams of a client-launched subprocess.
Streamable HTTP: the network binding, where messages travel to a single MCP endpoint.
Custom transports are permitted, but client and server must agree on one out of band.
Encoding is normative, not convention. Messages are JSON-RPC and MUST be UTF-8. A binding MUST deliver client requests and notifications to the server, and server responses and notifications to the client.
That separation is the payoff. If you already have a working MCP server, making it remote is usually a change at the edge of your code, not a rewrite of tools, prompts or resources. That is an inference from the binding model rather than a spec sentence, but it is what the model buys you.
If the client side is the unknown, What Is an MCP Client? HTTP Transport and Remote Servers covers the handshake from that end. If the terminology has been muddying the picture, What Most Searchers Actually Mean by 'Meta MCP Server' separates the name from the mechanism.
Next, what actually changes between the two bindings.
stdio vs Streamable HTTP: What Actually Changes
Over stdio, framing is newline-delimited and there is nothing to route. Those absences follow as inference from running the process locally, the spec does not state them, but nothing in a subprocess binding creates them. The relevant spec text is in Transports.
Streamable HTTP inverts that. Each message is an HTTP POST; the reply is a JSON object or a request-scoped SSE stream, as defined in the 2026-07-28 spec.
The single endpoint is the operational detail. One URL means one thing behind TLS termination, one route, one rate limit, one trace span. No second channel stays open for server-initiated messages.
Request-scoped means the SSE stream belongs to that request. A server can deliver a notification or a longer answer without holding a session open indefinitely, and without inventing its own correlation scheme.
Teams move because the HTTP binding lands on ingress they already run: TLS termination, WAF, rate limits, tracing. stdio means shipping and running the server process on every client machine, and owning whatever it does there. See stdio vs. Streamable HTTP: Which Should You Use?.
Why Remote MCP Took Off: A Short Timeline
Starting from the local, STDIO-first baseline described above, the community built out remote infrastructure. The protocol's own blog records growing demand for distributed deployments that can operate at scale. Read that as an early-adopter observation from the transport working group, not a surveyed figure. The pivot sentence is the protocol's own: the Streamable HTTP transport was a significant step forward, enabling remote MCP deployments and unlocking new use cases. Everything this page describes follows from it.
Two later dates matter, with one caveat. MCP joined the Agentic AI Foundation on December 9, 2025. That is governance consolidation, not a transport change, so it should not change how you build your server. MCP Apps became official on January 26, 2026, widening the spec surface beyond core transports. The 2026-07-28 release candidate confirms MCP Apps as an extension, adds a Tasks extension, hardens authorization toward OAuth and OpenID Connect, and introduces a formal deprecation policy covering Roots, Sampling and Logging. Transports still decide where your code runs and who can reach it.
Claude Code is one client that takes these endpoints; What Claude Code's Remote MCP Support Actually Does covers what it negotiates.
Sourcing note: every date above traces to modelcontextprotocol.io or the protocol's own blog. No independent or third-party measurement of remote adoption existed when this page was written, so treat adoption percentages you see elsewhere with suspicion.
Stateful vs Stateless: What Running a Remote Server Costs
With remote reach settled, the operational question becomes state.
MCP began stateful, see the timeline above, which is why early remote deployments leaned on session affinity. The transport roadmap names de-statefulising as the direction of travel: server state lives outside the connection, so any instance can answer any request without knowing which instance served the last one.
The difference in practice:
Stateless: one MCP endpoint behind the load balancer you already run. No sticky sessions. No shared session store to keep in sync. Scale by adding instances.
Stateful: session-pinned routing or a shared store for session data. More moving parts at deploy time, and a rolling restart can drop sessions mid-task.
That is the tax for keeping state on the connection.
Honest limit: no sourced, measured, operational comparison of the two exists in public documentation. Vendor cost figures are usually unverifiable. If you want real numbers, measure both of your own deployments and decide from that.
Where I land: I run 22 hosted servers as direct mcp.moltlinestudio.com/<server> endpoints, with 110 of the tools free and no signup required. That is one person running stateless endpoints rather than a vendor lab, so treat it as a worked example, not a benchmark. For the operational trade-offs around running that infrastructure yourself versus using someone else's, see Architecture of Managed vs. Self-Hosted MCP Servers.
Hands-On: Point a Client at a Remote MCP Server
Stateless endpoints are easier to reason about. Connecting to one takes a single string.
Pick any server at mcp.moltlinestudio.com/<server>. That host runs 22 servers and 160 tools; 110 of those tools are free forever, with no account, no API key and no signup. Test the remote path without a card.
Copy the server URL into your client as a remote MCP server. Claude, Claude Code, Cursor, Codex CLI, and any other client supporting Streamable HTTP all take the same URL. Only the config key name differs, so check your client's docs for that string. Adding a remote MCP server in under 60 seconds shows the exact edit.
Call a tool and read the JSON-RPC result. The spec defines replies as a JSON object or a request-scoped SSE stream, as covered in the transport overview.
If nothing comes back, check the transport your client negotiated before blaming the server. A client that only speaks stdio cannot reach an HTTP endpoint without a bridge.
Run the free agent-readiness checker against your client setup before debugging a server. It reports whether the client side can do the remote path you are asking of it.
If you are building rather than consuming, keep one handler and add the Streamable HTTP binding behind it. Run that handler over stdio locally and over HTTP for the hosted version, so your tool code never learns how it was called.
The remaining 50 tools sit behind a $19/month All-Access license, paid in cryptocurrency. That is the only gate on this endpoint set.
Authorization, Discovery and What the Spec Leaves Open
The 2026-07-28 spec treats Authorization as a first-class concern, listed alongside Discovery, Registry, Extensions and SEPs in the specification site navigation (2026-07-28 specification). If you are designing a server rather than consuming one, that list is your reading order.
Honest limit: the public extracts carry no detail on the authorization flow itself. No token lifetime, no revocation semantics, no rejection handling. Treat this as what to check, not what the spec mandates step by step, and read the current spec text before you commit to a design.
For a server you run, the questions to settle are concrete:
Where the token lives.
Who can revoke it.
What a client does when it gets rejected.
How that failure surfaces to the person using the tool.
Write those down before you write auth code. For a worked example of a client-side surface, the browser MCP takeaways are a quick read.
Registry appears in that same list, but the extracts give no behavior or workflow. Registry integration is unproven territory, so verify against the current spec version before you depend on it.
One working pattern for remote access without an account: moltlinestudio.com/api serves a live HTTP 402 x402 challenge, so an agent can discover the price and settle on-chain with no human in the loop. Curl it before you design your own access path:
curl -i https://moltlinestudio.com/api
Local or Remote? How to Decide for Your Own Server
With access settled, the last decision is placement.
Pick stdio when the boundary is the point
stdio still wins if your server touches the user's filesystem, runs commands on their machine, or serves one client per machine. It also wins when you do not want to operate a service. The 2026-07-28 spec says clients SHOULD support stdio whenever possible. Treat it as the baseline, not the fallback. Do not make something remote just because you can.
Pick Streamable HTTP when reach is the point
Remote wins when several clients, teammates or machines need the same tools, when you want one place to update, log and rate limit, or when the client runs somewhere you do not control, such as CI or a hosted agent.
Hybrid is normal and cheap
Keep one handler and add two bindings. Put the transport at the edge so your tools and resources never learn how they were invoked. Choosing between existing servers instead? How to Choose an MCP Server covers that.
Watch the state
If your tools hold per-session state in memory, hosting them statelessly means moving that state to a store or dropping it. This is the first surprise when porting a local server.
Scope: I host my own servers only. There is no third-party hosting here, so look elsewhere if you need someone to run yours.
Conclusion: What to Do This Week
Pick one free endpoint and connect it. Paste mcp.moltlinestudio.com/<server> into Claude, Claude Code, Cursor, or Codex CLI. 110 of the 160 tools there need no account, key, or signup, so the test costs nothing. If the tool call returns nothing, run the free agent-readiness checker before you debug the server. Most first attempts fail on the client side, not the endpoint.
Shipping your own? Keep one handler and add a Streamable HTTP binding behind it. State pinning: apply the same rule from the earlier section, name the state first.
Cite the dated spec version 2026-07-28 in your docs, with a link to the Transports page. Dated citations stay checkable, and they remind you to re-verify when the version date moves.
If your bottleneck is packaging workflows rather than transports, start with the 138 free SKILL.md files at github.com/GarphenGate/moltline-oss. That beats another protocol read.