Remote MCP Server: What a Public Address Costs You

A remote MCP server is the only kind a stranger can verify. What that public address costs you, what it buys, and what to check before you publish it.

A remote MCP server is one a client reaches at a URL instead of launching as a subprocess on the user's machine. The protocol is identical either way, so this isn't a technical choice. It's a choice about who can call your server. We called 53 public MCP endpoints between 20 July and 5 August 2026, and 30 of them refused us.

Below is the cost and the benefit of that address set side by side, the four things a public URL exposes that a subprocess never does, and the registry requirement that decides whether anyone can find it.

TL;DR:

Remote is a decision about visibility, not about scale. Published comparisons frame it as collaboration, latency and uptime. The property that actually changes is that strangers can call your server and read its tool list.
A public address publishes your tool surface. Wiz Research reported in July 2026 that around 70% of the exposed MCP servers it saw returned a full tool catalog, and around 42% returned real data when those tools were called [3].
The registry makes reachability a requirement. "A remote server MUST be publicly accessible at its specified URL" [1], and a custom namespace needs a DNS TXT record or a /.well-known file proving you own the domain [2].
30 of the 53 endpoints we called guarded themselves. Going remote means picking an auth posture before launch rather than after.

What is a remote MCP server?

A remote MCP server is an MCP server a client connects to over HTTP at a URL, rather than starting on the local machine as a subprocess. The handshake, tools/list and every message shape are the same. Only the address changes: a local server has none, and a remote one has an address anyone can reach.

The transport that carries it is Streamable HTTP, where the client POSTs JSON-RPC to a single URL. The older two-endpoint HTTP+SSE transport still appears in older listings, and the official registry now says plainly that "The SSE transport is deprecated, so publish an "sse" remote only to support existing clients" [1]. If you're starting now, one Streamable HTTP endpoint is the whole surface.

Should you build a remote or a local MCP server?

Build local if your tools touch the user's own files, processes, or credentials. Build remote if your tools reach a service you operate. The deciding question isn't scale, latency, or team size. It's whose machine holds the thing the tool acts on, and everything else follows from that answer.

	Local (stdio)	Remote (Streamable HTTP)
Who can call it	Whoever can run the process	Anyone who knows the URL
Where credentials live	The user's environment	Your infrastructure
Who owns uptime	Nobody, it starts on demand	You, continuously
How a user installs it	A command in a config file	A URL in a config file
Who can verify it works	Only someone who runs it	Anyone, from anywhere

That last row is the one the existing comparisons leave out, and it's the row that changes the most. Guides from Stainless, CircleCI and Red Gate all frame the decision as collaboration versus control, which is fair and incomplete. A local server is a private artifact. A remote one is a public one, and it's public whether or not you thought of it that way when you deployed it.

The specification treats the two differently for exactly this reason. It tells stdio implementations they SHOULD NOT follow the authorization spec and should read credentials from the environment instead, because the operating system already decided who may launch that process. We covered where that leaves the OAuth question in the post on MCP OAuth.

What does a public address cost you?

Four things, and none of them appear on a pricing page. A URL is an invitation to every caller on the internet, not only to the ones you had in mind. Each cost below is a direct consequence of the address existing, and each one is something a stdio server never has to answer for.

Anyone can call it, and most will start with tools/list. That request needs no credentials to attempt and it's the cheapest way to learn what a server does. Wiz Research, looking across the cloud environments it scans in July 2026, reported that MCP shows up in around 80% of them, roughly 1 in 6 expose at least one server, and of the exposed ones about 70% returned a full tool catalog while about 42% returned real data when a tool was actually called [3].

Your auth posture becomes a public fact. We asked 53 endpoints anonymously and 30 answered with a 401 or 403. That's not a failure, it's a server guarding itself correctly, which is why auth_required is a healthy outcome rather than a broken one. But whichever answer you give, you give it to everyone who asks, and you give it on day one rather than when you get around to it.

Your tool surface becomes documentation you didn't write. Across the 14 servers that answered us on 5 August 2026 we recorded 288 tools, a median of 4.5 per server, and a range from 2 to 213. Every one of those names and descriptions is readable by anyone who connects. A large tool surface is a standing cost in a client's context window rather than a capability score, which is the argument our roundup makes in full.

You own uptime and version negotiation, continuously. A subprocess starts fresh when a client wants it. A URL is either answering or it isn't, and it has to negotiate a protocol revision with clients that may be older than it is. Across the endpoints we connected to, three revisions were live at once: nine on 2025-11-25, three on 2025-03-26 and two on 2025-06-18.

What does a public address buy you?

Verifiability, and it's the only thing on this list that a local server can't have at any price. Everything a third party can truthfully say about your server, they can say only because there's an address to check. Without one, every claim about a server routes back through its README.

A URL is what makes each of these possible:

A client can add it in one line. No install step, no runtime, no npx, no version drift between the user's machine and yours.
A registry can resolve it. The official registry stores the URL directly in server.json and requires it to work.
A directory can check the claim instead of repeating it. We connect once, record what came back, and publish it with its date, which is what a listing on the weekly board carries. You can see the shape of that record on our corpus page, and run the same check against your own endpoint with the connection tester.
A buyer can check it before trusting it. The 40.55% figure from a May 2026 study of 7,973 live remote servers exposing tools without authentication [4] exists only because those servers had addresses to survey.

We measure exactly one thing and it's worth naming the limit: whether a server answered us, and what it returned when it did, on a date. We haven't audited anyone's implementation, and the same study found that all 119 OAuth-enabled servers it could test carried at least one authentication flaw [4]. A connection record is evidence about reachability, not a security rating, and nobody should read it as one.

How do you publish a remote MCP server to the registry?

Through a remotes entry in server.json rather than a packages entry, plus proof that you control the namespace you're claiming. The rest of the publishing flow is identical to a package-based server, which the launch guide walks through step by step. Two requirements are remote-specific.

The first is reachability, stated as a hard requirement: "A remote server MUST be publicly accessible at its specified URL" [1]. The entry itself is short:

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "com.example/acme-analytics",
  "title": "ACME Analytics",
  "description": "Real-time business intelligence and reporting platform",
  "version": "2.0.0",
  "remotes": [
    {
      "type": "streamable-http",
      "url": "https://analytics.example.com/mcp"
    }
  ]
}

The second is namespace ownership. A io.github.username/* name is proved with a GitHub OAuth device flow. A reverse-DNS name like com.example/* needs more: you generate an Ed25519 or ECDSA P-384 keypair, publish the public key either as a DNS TXT record in the form v=MCPv1; k=ed25519; p=<key> or as a file at /.well-known/mcp-registry-auth on the domain, then let mcp-publisher login dns or mcp-publisher login http sign a challenge against it [2].

That's the trade in miniature. A remote server gets to carry your company's name in the registry, and the price is a cryptographic proof that the domain is yours. The registry is still in preview, so treat both the schema URL and the flow as things to re-read rather than memorize.

What should you check before you publish the URL?

Call your own endpoint the way a stranger would, before a client, a registry or a directory does it for you. An anonymous request tells you what the world sees, which is frequently not what you tested against locally with your own credentials in the environment.

Four checks worth running:

What an anonymous caller gets. If the answer is a 401, confirm it carries a WWW-Authenticate header. A guarded server with nothing for the client to parse is the most common way a correct configuration still fails to connect.
Whether tools/list is paginated. A server returning a nextCursor and a client stopping at page one produces an undercount, not an error. Nothing in the response says the number is wrong.
Which revision you actually negotiate. Not the one your SDK version implies. Three were live across our sample at the same time.
What a failure means when you see one. A 400, 404 or 405 doesn't distinguish "wrong path" from "not an MCP server", and the failure taxonomy covers what each response does and doesn't prove.

Our connection tester runs all of these in one pass and takes an optional token if you want to see the authenticated path in the same run. It returns the outcome, the negotiated revision, the tool count following nextCursor, the tool names, and whether descriptions are present.

The address is the decision

Pick local or remote by asking whose machine holds the thing your tools act on, then accept what the answer implies. A local server stays private and stays unverifiable. A remote one becomes a public artifact the day it deploys, with its auth posture, its tool surface and its uptime all readable by anyone who types the URL.

If you've decided on remote, check what your endpoint returns to an anonymous caller first, then put it in a week. A listing carries what your server returned on the date we asked it and nothing we didn't measure, including saying plainly when a server declined us. Thirty of the 53 endpoints above declined us, and that tier is welcome on the board.