Remote MCP servers, explained.

A remote MCP server is the same Model Context Protocol program as a local one. The difference is the transport. Local servers speak stdio: the host launches a subprocess and talks over stdin and stdout. Remote MCP servers speak Streamable HTTP: the host posts JSON-RPC to a URL such as https://example.com/mcp. Protocol semantics stay identical. A transport is a binding, not a second protocol.

That distinction is the whole category. If you have been pasting npx commands into claude_desktop_config.json, you have been using local servers. If you paste a URL into Claude's Connectors settings, Cursor's mcp.json, or VS Code's .vscode/mcp.json, you are using a remote MCP server. This page is the explainer. The companion walkthrough, how to build an MCP server, covers SDKs and code.

What "remote" actually means

The official architecture overview is blunt about it. An MCP server is the program that serves context, wherever it runs. Claude Desktop launching the filesystem server on your laptop is a local MCP server because it uses stdio. The official Sentry MCP server running on Sentry's platform is a remote MCP server because it uses Streamable HTTP.

Three roles, unchanged:

• Hosts are the AI apps: Claude Desktop, Claude Code, VS Code, Cursor, ChatGPT connectors, Codex.
• Clients live inside the host. One host creates one client per server.
• Servers expose tools, resources, and prompts.

Local stdio servers typically serve a single client: the process that spawned them. Remote Streamable HTTP servers typically serve many clients. That is the operational fork. It is not a branding fork.

The data layer is still JSON-RPC 2.0. Tools are still tools/list and tools/call. Resources and prompts still exist. You do not get a different primitive set by putting the process on the public internet. You get a different failure mode, a different auth story, and a different place the bytes actually go.

Local vs remote, side by side

Two traps sit in that table.

First: "remote" does not mean "the server runs in another city." A Streamable HTTP server bound to 127.0.0.1:8000 is still the remote transport. It is just not a useful remote deployment. Claude's custom connector docs make this concrete. When you add a custom connector, Claude connects from Anthropic's cloud infrastructure, including Claude Desktop and Cowork. A server on localhost or behind a VPN will not connect as a custom connector, even if you can curl it from the same machine. Local MCP servers in claude_desktop_config.json are a separate mechanism and do use your local network. Those are not available in Cowork or claude.ai.

Second: a stdio bridge is not a second product. Clients that only spawn local processes can run a small proxy that speaks stdio to the host and Streamable HTTP to the hosted server. DialMCP's install path has one (npx dialmcp-connector). The calling service still lives at https://mcp.dialmcp.com/mcp. The bridge is a transport shim.

Streamable HTTP is the current remote transport

Streamable HTTP shipped in protocol version 2025-03-26 as the replacement for HTTP+SSE (2024-11-05). Spec 2026-07-28 changed it again. If you are copying samples from a 2025 blog post, check the date on the spec they cite.

What a 2026-07-28 remote server looks like:

• One MCP endpoint that accepts POST, for example https://example.com/mcp.
• Every client message is its own HTTP POST. The body is one JSON-RPC request or notification. Clients do not send JSON-RPC responses.
• The server answers a request with either application/json (one object) or text/event-stream (an SSE stream scoped to that request). Clients must support both.
• Required headers include MCP-Protocol-Version and Mcp-Method. For tools/call, resources/read, and prompts/get, also send Mcp-Name. The header values must match the body. A mismatch is 400 plus JSON-RPC error -32020 (HeaderMismatch).
• Validate Origin. If the header is present and invalid, respond 403. Bind local HTTP servers to 127.0.0.1, not 0.0.0.0.

What 2026-07-28 removed from earlier Streamable HTTP:

• Protocol-level sessions and the Mcp-Session-Id header. List endpoints no longer vary per connection. Cross-call state is a server-minted handle passed as a normal tool argument.
• The GET stream endpoint. Long-lived change notifications now go through subscriptions/listen. Request-scoped progress still rides the original request's response stream.
• SSE resumability (Last-Event-ID). A broken stream loses the in-flight request. Clients re-issue it with a new request ID.

HTTP+SSE from 2024-11-05 is classified as Deprecated. Do not start a new SSE-transport server. Streamable HTTP may still return a request-scoped SSE stream as the response body. That is a reply shape, not the old two-endpoint transport.

Cancellation differs by binding. On stdio the client sends notifications/cancelled. On Streamable HTTP, closing the response stream is cancellation.

The protocol is also stateless in 2026-07-28. There is no initialize handshake. Every request carries protocol version and client capabilities in _meta. Servers must implement server/discover so a client can ask for supported versions, capabilities, and identity up front. Any request can land on any instance behind a round-robin load balancer. If you need a call ID, mint it and hand it back.

Why people moved off local servers

Local MCP was a fine 2024 shape: one developer, one laptop, one config file. It falls over in three places.

Install tax. Every teammate clones the same npx line and pins a different Node. Hosts spawn your command with a thin PATH. A remote MCP server is a URL. Nothing is installed per machine.

The host is not on the laptop. Claude.ai, Claude mobile, Cowork, and Claude custom connectors on Desktop all reach remote servers from Anthropic's cloud. ChatGPT connectors are the same idea. A stdio server cannot answer that traffic.

The capability is not local. Filesystem access belongs on the machine. A phone call, a payment, a CRM write, or a production database does not. Those need a durable process, shared rate limits, an identity provider, and logs that survive the user closing the laptop.

None of that makes local servers obsolete. If the tool reads ~/src or talks to a database on loopback, keep it on stdio. Putting that on the public internet is how you get the next Wiz write-up.

Auth: optional in the spec, required in production

Authorization is optional for MCP. HTTP implementations should follow the OAuth 2.1 framework added in 2025-03-26. Stdio implementations should not. They take credentials from the environment.

The moment a server is on a public URL and touches user data, treat OAuth as required. From 2025-06-18, MCP servers are OAuth Resource Servers: they publish protected-resource metadata and expect RFC 8707 resource indicators. 2026-07-28 deprecates Dynamic Client Registration in favor of Client ID Metadata Documents. Authorization servers should include iss (RFC 9207). Clients must validate it when it is present.

The shape you will see:

1. An unauthenticated request returns 401 plus WWW-Authenticate pointing at /.well-known/oauth-protected-resource.
2. The client fetches Protected Resource Metadata, discovers the authorization server, and completes authorization-code plus PKCE.
3. Later MCP requests send Authorization: Bearer ....

Wiz Research, 28 July 2026: MCP showed up in about 80% of cloud environments they measured. About 1 in 6 of those environments expose at least one MCP server. Of exposed servers, roughly 70% return their full tool catalog to an anonymous caller, and roughly 42% return real data when a tool is called. Nearly all still negotiated protocol version 2024-11-05, from before authentication landed in the spec. Possession of a URL is not authentication. Possession of a call handle is not either. Bind handles to the authenticated user.

How you actually connect one

The URL is the product. For DialMCP it is https://mcp.dialmcp.com/mcp, Streamable HTTP, OAuth 2.1, no API key. The same URL is pasted into five different files because each host invented a slightly different JSON shape. The configuration examples page is the copy-ready sheet. The short version:

• Claude Code: claude mcp add --transport http dialmcp https://mcp.dialmcp.com/mcp. Project .mcp.json needs "type": "http" (or streamable-http). A url with no type is treated as stdio and skipped.
• Claude.ai / Claude Desktop (remote): Settings → Connectors → Add custom connector. Not claude_desktop_config.json. That file is local stdio only.
• Cursor: .cursor/mcp.json, mcpServers → { "url": "https://mcp.dialmcp.com/mcp" }.
• VS Code: .vscode/mcp.json, root key servers, "type": "http". Not settings.json.
• Codex: ~/.codex/config.toml, [mcp_servers.dialmcp] plus url = "...".

Client setup has the same blocks without the file-shape lecture. If the client cannot speak remote HTTP, use the stdio bridge and keep the hosted endpoint. Document the URL, the transport name the client uses (http vs streamable-http vs serverUrl), and the auth shape. An extra Authorization header on an OAuth server is a good way to break the handshake.

When remote is the wrong default

Stay on stdio when:

• The data must not leave the machine (source trees, local secrets, an air-gapped DB).
• The host is a desktop app that already spawns processes, and there is no hosted host in the mix.
• You are debugging. MCP Inspector against a local command is still the fastest loop.

Go remote when:

• More than one host or more than one person needs the same tools.
• The host itself is hosted (claude.ai, ChatGPT connectors, Cowork).
• The side effect is infrastructure: telephony, payments, identity, anything with a legal disclosure you cannot leave to the model.

An MCP gateway aggregates or routes many servers. That is a different product from a single-purpose hosted server. This page is the transport split.

A hosted remote example, without turning this into a demo

Most "remote MCP" posts stop at weather alerts. A production remote server takes actions that cannot be undone, so the constraints live in the server.

DialMCP is a hosted remote MCP server that lets an MCP-enabled agent place a real outbound phone call from the user's own SMS-verified number. The endpoint is Streamable HTTP plus OAuth 2.1. After phone verification, the verified number is the caller ID. Tools are small: place_call returns an ID immediately, get_call is the poll, end_call cancels, list_calls recovers IDs. That is the 2026-07-28 shape: stateless requests, explicit handles, no protocol session.

The parts that do not belong in a prompt: US and Canada only, 8am to 9pm destination-local time, server-enforced AI disclosure, hard rate limits, a permanent opt-out list. Free during launch. Built by Datawizz Inc., the makers of Gamut. Connect at the install page. If you were about to wrap Twilio yourself, read which voice AI APIs can call a cell phone first.

You do not need telephony to steal the design. Return an ID, then poll. Bind every handle to the authenticated user. Put irreversible policy in code. Log every invocation.

A short decision checklist

1. Does the host spawn a process, or does it POST to a URL? That is local vs remote. Everything else is commentary.
2. If it POSTs, is the URL reachable from the host's network, not yours? Claude custom connectors originate at Anthropic.
3. Are you still shipping HTTP+SSE or minting Mcp-Session-Id? Those are pre-2026-07-28. Migrate.
4. Is the server on the public internet without OAuth? That is the Wiz finding, not a clever MVP.
5. Do you need this capability on every laptop, or once, hosted? If once, do not build another weather server. Point the host at a URL.

FAQ

What is a remote MCP server?

An MCP server that speaks Streamable HTTP on a URL instead of stdio on a subprocess. Same JSON-RPC. Different binding. Typically serves many clients.

What is the difference between a local MCP server and a remote one?

Local: the client launches a process and talks over stdin/stdout. Remote: the client posts to https://.../mcp. Tools, resources, and prompts do not change.

Is Streamable HTTP the same as SSE?

No. HTTP+SSE (2024-11-05) is deprecated. Streamable HTTP (from 2025-03-26, revised 2026-07-28) posts every message to one endpoint. The reply may be a request-scoped SSE stream.

Do remote MCP servers need OAuth?

The spec says authorization is optional. Production servers on the public internet that touch user data should implement OAuth 2.1. Stdio servers should not; they use environment credentials.

Can Claude Desktop use a remote MCP server?

Yes. Add a custom connector with the server URL. Claude still connects from Anthropic's cloud, not from your laptop. claude_desktop_config.json remains the local stdio file.

Why did my localhost MCP URL fail as a Claude connector?

Custom connectors must be reachable from Anthropic's IP ranges. Localhost and VPN-only servers are not. Use stdio config for local servers.

Do I still need initialize / Mcp-Session-Id?

Not on spec 2026-07-28. Discovery is server/discover. Sessions are gone. Handles are tool arguments. Older clients and servers still speak the 2025 handshake; see the spec's backward-compatibility notes.

When should I build a remote server vs use a hosted one?

Build when the system is yours. Use a hosted server when the capability is shared, regulated, or is infrastructure. Phone calls sit in the second bucket.

Further reading

• Official architecture: host, client, server
• Transports: Streamable HTTP and stdio
• Changelog: 2026-07-28
• Authorization: OAuth 2.1 for HTTP transports
• Claude: custom connectors using remote MCP
• DialMCP docs, install, and how to build an MCP server