The best remote MCP servers, and how to check one is remote.

Every list on this query mixes two different things. Half the entries run on your laptop as a subprocess. The other half run on someone else's infrastructure and are reached by URL. If you searched for the second kind, the local npx servers are noise, and the difference matters more than any feature comparison: a remote server needs no runtime on your machine, needs no update cadence, and works from every device you connect from, including ones that cannot launch a process at all.

This is the remote-only list. The best MCP servers for Claude covers servers by job, including the local ones. The protocol difference is on remote MCP servers explained, and DialMCP's own endpoint is documented on hosted MCP server.

Every endpoint and auth model below was checked against the vendor's own documentation on 20 September 2026. None of it is copied from a directory.

What actually makes a server remote

Four checks, in order. A server that fails the first one is local with extra steps.

1. A documented public HTTPS endpoint. Not "deploy this and point a tunnel at it." A vendor-published URL that answers an MCP request from a machine that is not yours. If the only documented install is npx, uvx, or a Docker image, it is a local server, however it is described.
2. The host's cloud can reach it. This is the check people skip. Claude custom connectors connect from Anthropic's cloud, not from your laptop (Anthropic's connector docs). A server that only works on localhost will fail here even though it speaks HTTP.
3. It speaks Streamable HTTP. The 2026-07-28 spec defines two transports for remote work: stdio for local processes, and Streamable HTTP for everything over the network. The older HTTP+SSE transport, introduced in 2024-11-05, is deprecated but still documented. A URL ending in /sse is a weak signal either way, since some vendors keep the path as an alias onto the same modern handler.
4. Auth is discoverable, not pasted. A well-built remote server answers an unauthenticated request with 401 plus a WWW-Authenticate header pointing at its Protected Resource Metadata (RFC 9728), so the client can start the OAuth flow on its own. A server whose only documented auth is "paste a long-lived API key into a config file" is remote in transport and local in spirit.

The OAuth 2.1 myth on this SERP

Several page-one posts in this results set claim the 2026-07-28 specification "made OAuth 2.1 mandatory for every remote MCP server." It did not, and the difference changes how you evaluate a server.

The spec's authorization page says authorization is optional for MCP implementations, and that HTTP transports should follow OAuth 2.1 while stdio transports should not (stdio takes credentials from the environment). What the spec actually establishes is a default shape: when a remote server does authenticate, OAuth 2.1 with Protected Resource Metadata and dynamic client registration is the expected pattern, so any client can negotiate it without a bespoke integration per server. That is a strong convention. It is not a MUST, and a remote server that ships a static bearer token is not automatically non-compliant.

So use it as a quality signal rather than a compliance test. If a hosted server still wants a long-lived key pasted into a file, the practical cost is real: no per-user scoping, no revocation story, and a secret in your shell history. That is a good reason to prefer the OAuth servers below. "The spec forbids it" is not.

The same 2026-07-28 revision also removed protocol-level sessions and the GET SSE stream from Streamable HTTP. A single endpoint now accepts POST, and a reply is either a JSON response or a request-scoped SSE stream. Remote servers that still document a persistent session ID are running the older shape.

The list

Everything here is first-party, hosted by the vendor that makes the product, and reachable from a client that cannot run a local process. Auth is what the vendor documents for the remote path.

Three notes on that table, because the details are where remote servers actually break.

Read the version in the path. Atlassian and Asana both moved to a /v2/mcp endpoint. Aggregator lists that still publish mcp.atlassian.com/v1/sse and mcp.asana.com/sse are describing the previous generation, and Asana's docs treat the legacy path as beta. Copy endpoints from the vendor page, not from a directory.

/sse in a URL does not always mean the deprecated transport. Cloudflare keeps /sse as an alias that routes to the same Streamable HTTP handler, and returns 410 Gone for a genuine legacy GET. DeepWiki still advertises an /sse path that no longer answers. The path string is a weak signal; the vendor's transport documentation is the strong one.

Not every remote server has a local fallback. GitHub, Sentry, Stripe, Context7, and Exa publish a stdio option or a container. Linear, Asana, and Supabase do not, beyond a generic stdio bridge that proxies to the same remote endpoint. If your client can only launch local processes, that distinction decides which of these you can use at all.

Choosing between them

Remote servers are cheap to add and expensive to carry. Tool schemas load into the model's context whether or not you call them, so a connector you installed in March is still costing you tokens in September. Add the one that matches the product you actually use, and remove it when the work finishes.

The other honest constraint is that almost everything on this list is a data connector. GitHub reads your repos, Notion reads your workspace, Stripe reads your payments. They are excellent at letting an agent see a system the vendor already owns. None of them take an action in the physical world.

The one that is not a data connector

DialMCP is the product we run, so here is the plain version, kept to the same standard as the entries above.

Every other server on this page lets an agent read or write data that a vendor already holds. DialMCP is a hosted remote MCP server that lets an agent place an actual outbound phone call from your own SMS-verified US or Canadian mobile number, navigate the phone tree and the hold queue, and return a transcript, a recording link, and a structured outcome. It is free during launch. It is not a voice API you embed in a call center, and it is not a substitute for any of the connectors above.

Endpoint and auth follow the same pattern as the rest of this list:

• Endpoint: https://mcp.dialmcp.com/mcp, Streamable HTTP.
• Auth: OAuth 2.1 with SMS verification of the number. No API key on the remote path.
• Tools: place_call, get_call, end_call, list_calls. The call is asynchronous; place_call returns an ID and the agent polls.
• Enforced server-side, not left to the prompt: AI disclosure on every call, 8:00 to 21:00 destination-local hours, one concurrent call, three per hour and ten per day, at most two per day to the same number, and a permanent platform-wide opt-out list. The safety model has the full set.

Connect it the way you connect any remote server:

claude mcp add --transport http dialmcp https://mcp.dialmcp.com/mcp

On claude.ai or Claude Desktop, paste the URL as a custom connector. If your client can only launch local servers, npx -y dialmcp-connector is a thin stdio bridge to the same hosted endpoint, not a second calling service. Setup is on client setup and configuration examples; the endpoint itself is documented on hosted MCP server.

Other MCP calling products exist, and they occupy the same query space. DialMCP's difference is whose number appears on the call and what the server enforces rather than asks for. That is a product difference, not a ranking claim.

What to skip

A connector you have not used this month. Tool schemas are context. Ten installed servers is a slower, more confused agent, not a better-equipped one. Two or three that match current work is the ceiling for most people.

Anything that only documents a tunnel. "Expose your laptop with ngrok and point the connector at it" gets you a remote endpoint in the transport sense and a local server in every way that matters: it dies when you close the lid, and the vendor does not operate it. The interesting column in the table above is the maintainer, not the URL.

A directory entry with no vendor docs. Directories crawl, deduplicate, and go stale. Both the endpoint and the auth model should come from the vendor's own documentation before you paste anything into a client.

FAQ

What is a remote MCP server?

An MCP server you reach over the network at a URL instead of launching as a local subprocess. The client POSTs JSON-RPC to a Streamable HTTP endpoint such as https://example.com/mcp. Tools, resources, and prompts are the same primitives as a local server; only the transport changes. Remote MCP servers explained has the full comparison.

Is OAuth 2.1 mandatory for remote MCP servers?

No. The spec says authorization is optional and that HTTP transports should follow OAuth 2.1. In practice OAuth is the norm for first-party hosted servers because it lets any client negotiate access without a bespoke integration, but a server using a static key is not violating the spec. Treat a long-lived pasted key as a practical downside, not a compliance failure.

What are the best remote MCP servers in 2026?

For most people: GitHub, Notion, and whichever single vendor server matches the product they already pay for, plus Context7 if they write code. There is no meaningful global ranking, and every server you add costs context. DialMCP is the one to add when the job is a phone call rather than a data lookup.

How do I tell whether an MCP server is actually remote?

Look for a vendor-documented public HTTPS endpoint that works from a machine that is not yours. If the only documented install is npx, uvx, or Docker, it is local. If it needs a tunnel to reach the internet, it is a local server you exposed.

Can I use remote MCP servers in Claude Desktop?

Yes, for many of them. Paste the URL under Settings then Connectors. Claude connects from Anthropic's cloud rather than your laptop, so the server must be publicly reachable. Some vendors document an OAuth limitation for Desktop custom connectors and recommend their local server instead; GitHub is the common example. Client-by-client details are on client setup.

Do remote MCP servers work in every client?

Any host that supports remote Streamable HTTP with OAuth can connect. That covers Claude custom connectors, Claude Code, Cursor, VS Code, and others; see client setup. Hosts restricted to local stdio need a bridge, which is why some servers also publish one.

Further reading

• Remote MCP servers explained: how they differ from local
• The best MCP servers for Claude
• Hosted MCP server: what the URL means
• Client setup for Claude, Codex, Cursor, and VS Code
• MCP authorization, spec 2026-07-28
• MCP transports, spec 2026-07-28