Remote MCP servers: how they work and how to add one

On this page

A remote MCP server is an MCP server you reach at an HTTPS URL, such as https://mcp.notion.com/mcp, instead of a program your AI app starts on your machine. You add the URL to Claude Code, Codex, Cursor or Claude, sign in once in the browser if the server asks, and the app gets the server's tools.

This guide was checked against the MCP transport specification, revision 2026-07-28, and each client's documentation, on 30 October 2026.

Remote vs local MCP servers

MCP defines two standard transports, and they map onto the two kinds of server:

	Local (stdio) server	Remote (Streamable HTTP) server
How it runs	Your client launches it as a subprocess and talks over `stdin` and `stdout`	It runs somewhere else and answers HTTP requests at one URL
Who runs it	You, on every machine that uses it	Usually the vendor of the service
Install	A command such as `npx -y <package>`, plus the runtime it needs	None; you add a URL
Credentials	Environment variables in your client's config	OAuth sign-in in the browser, or an API key in a header
Updates	When you update the package	When the vendor deploys
Reaches	Your files, local tools and private networks	Whatever the vendor's service can reach

A local server is the right choice when the tools need your machine: a filesystem server, a browser you drive locally, a database on your laptop. A remote server fits when the tools front a SaaS product you already sign in to, like an issue tracker, a CRM or an analytics tool. There's nothing to install, and every person and machine signs in with their own account instead of copying a token into a config file.

The specification treats credentials differently for each. Its authorization rules say HTTP servers should use the OAuth flow, while stdio servers should not and instead read credentials from the environment.

Streamable HTTP and the legacy SSE transport

Streamable HTTP

Streamable HTTP is the current remote transport. The server exposes one endpoint, such as https://example.com/mcp. The client sends every JSON-RPC message as its own HTTP POST, and the server answers each request with either a single JSON object or a Server-Sent Events (SSE) stream scoped to that request, which carries progress notifications and then the final response.

Revision 2026-07-28 changed this transport in ways that matter if you run a server:

No sessions. The Mcp-Session-Id header and the initialize handshake are gone. Every request carries its protocol version and client capabilities in _meta, so any server instance can answer any request.
No GET stream. Change notifications, such as a new tool list, arrive on the response stream of a subscriptions/listen request.
No resumable streams. If a response stream breaks, the client sends the request again with a new ID.
Server questions ride in results. When a server needs input from the person, it returns an input_required result and the client retries the call. MCP elicitation walks through that flow.

Older revisions from 2025-03-26 through 2025-11-25 also used Streamable HTTP, with optional sessions and a GET stream. Clients that implement both revision families can probe for modern support and fall back to legacy initialization.

Legacy HTTP+SSE

The original remote transport, from revision 2024-11-05, used two endpoints: a GET that opened an SSE stream and a separate POST endpoint for messages. It has been deprecated since 2025-03-26, and the 2026-07-28 changelog classifies it as Deprecated under the new feature lifecycle, so it can be removed in a future revision. New servers shouldn't adopt it.

Some services still expose only an SSE endpoint, often a URL ending in /sse. Clients that support both try a POST first and fall back to the SSE GET when the server answers 400, 404 or 405 without a modern error body.

Authentication on remote servers

Remote servers either accept anonymous calls, take a static key in a header, or use OAuth. With OAuth, the first request gets a 401 pointing to the server's metadata, the client finds the authorization server, identifies itself, and opens a browser sign-in with PKCE. The token it gets back is issued for that one server.

The details, including Client ID Metadata Documents, token audiences and step-up scopes, are in MCP authentication. The short version for users: prefer OAuth when a server offers it, and keep static API keys for scripts and CI.

Add a remote MCP server to your AI app

The examples use a placeholder URL. Replace it with the endpoint from the server's own documentation.

Claude Code

Claude Code's MCP docs recommend the HTTP transport for remote servers:

Shell

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

For a server that takes an API key instead of OAuth, add a header:

Shell

claude mcp add --transport http secure-api https://api.example.com/mcp \
  --header "Authorization: Bearer your-token"

If the server needs OAuth, run /mcp in a session and choose the server, or run claude mcp login <name> in your shell. Add --scope project to write the server to .mcp.json for the whole repository, or --scope user to load it in all your projects; the default is local, meaning you, in this project. In JSON, a remote entry needs "type": "http" next to its url; an entry with a url and no type is read as stdio and skipped.

For an SSE-only server, the same --transport http command works from v2.1.265, which tries HTTP and switches to SSE. On earlier versions, use --transport sse.

Codex

Codex supports stdio and Streamable HTTP servers, and shares one configuration between the CLI, the IDE extension and the ChatGPT desktop app:

Shell

codex mcp add example --url https://mcp.example.com/mcp
codex mcp login example

codex mcp login runs the OAuth sign-in. To use a token instead, edit ~/.codex/config.toml, or .codex/config.toml in a trusted project:

TOML

[mcp_servers.example]
url = "https://mcp.example.com/mcp"
bearer_token_env_var = "EXAMPLE_MCP_TOKEN"

Codex then sends the value of that environment variable as a bearer token. http_headers and env_http_headers set other headers, and codex mcp list or /mcp in the TUI shows what's configured. Its documentation doesn't list the legacy SSE transport.

Cursor

Cursor supports stdio, SSE and Streamable HTTP. Add a remote server to .cursor/mcp.json in the project, or ~/.cursor/mcp.json for every project:

JSON

{
  "mcpServers": {
    "example": {
      "url": "https://mcp.example.com/mcp"
    }
  }
}

For a token, add "headers": { "Authorization": "Bearer ${env:EXAMPLE_MCP_TOKEN}" }, which reads it from your environment instead of the file. For OAuth servers, Cursor runs the sign-in itself with PKCE, using dynamic client registration or a static client ID you set under auth. Manage servers from Customize in the sidebar.

Claude

In Claude, remote servers are custom connectors. On Pro and Max, open Customize → Connectors, choose + Add, then Add custom connector, and enter a name and the URL. On Team and Enterprise, an owner adds it under Organization settings → Connectors, and members connect it from Customize → Connectors. As of October 2026, Free accounts are limited to one custom connector.

One difference from the other three: Claude connects to the server from Anthropic's cloud, not from your computer, even in the desktop app. The server has to be reachable on the public internet from Anthropic's IP ranges, so an endpoint on localhost or inside your office network won't work.

Finding official remote MCP servers

Many SaaS vendors now publish a remote MCP server at their own domain. Prefer those to community wrappers: the vendor maintains the tools, the sign-in goes through the vendor's own OAuth, and you don't hand an API key to a third party.

The best remote MCP servers lists official servers by team, with how each one signs in. All integrations shows every server in the Toolstile catalog with its observed tool list and access suggestions. When you evaluate a server you haven't used, check who publishes it, which tools write or delete, and whether it uses OAuth or wants a long-lived key.

Running your own remote MCP server

If you're publishing tools for others, you'll write the server with one of the official MCP SDKs. TypeScript, Python, C#, Go, Rust and Ruby are listed as Tier 1. Build an MCP server in the official documentation walks through a first one. Then deploy it like any other HTTPS service.

The transport specification sets a few requirements for HTTP servers:

Validate the Origin header on every request and answer 403 when it's present and invalid. This stops DNS rebinding attacks from websites against servers on a person's machine.
Bind to 127.0.0.1, not 0.0.0.0, when the server runs locally.
Authenticate connections. For people, follow the OAuth flow in MCP authentication, and validate that each token was issued for your server.
Send X-Accel-Buffering: no when you open an SSE response, so reverse proxies such as nginx pass events through instead of buffering them.

Because revision 2026-07-28 removed sessions, a server that only speaks that revision can run behind an ordinary load balancer without sticky sessions. If you also serve older clients, you need their initialization and transport behavior. Session IDs are optional in those revisions, so routing requirements depend on whether your implementation keeps server-side session state. The specification's backward-compatibility section describes what to support.

Toolstile doesn't host MCP servers. It's a gateway: it connects to servers that are already running at a public HTTPS address and decides which agents can use which tools.

Using several remote servers through a gateway

Each client above keeps its own list of servers, sign-ins and tool settings. With a few people and several servers, that becomes many separate sign-ins and as many places to change a rule. An MCP gateway puts the servers behind one remote endpoint.

In Toolstile, you add a server by entering its URL; Toolstile detects whether it speaks Streamable HTTP or legacy SSE and whether it needs sign-in. Each AI app then adds https://mcp.toolstile.com/mcp as a single remote server and only sees the tools its agent has been granted. Toolstile reaches public HTTPS servers on port 443 only, so local stdio servers stay configured directly in your client. Connect a first MCP server walks through the setup, and connecting a server covers OAuth and token connections.

Frequently asked questions

What is the difference between a remote MCP server and an MCP server?

Nothing in the protocol. "Remote" describes the transport: the client reaches the server over HTTP at a URL instead of starting it as a local process. The tools, resources and prompts work the same way.

Is SSE the same as Streamable HTTP?

No. Streamable HTTP can use SSE to stream one response, but the legacy HTTP+SSE transport is a different, deprecated design with a separate long-lived GET stream. When a server offers both, use the Streamable HTTP URL.

Can a remote MCP server access my local files?

Connecting a remote MCP server doesn't by itself give it access to your local filesystem. The server receives the data your client sends, including tool arguments and form elicitation answers, and can reach whatever systems are reachable from where it runs. When tools need direct access to local files, use a local server.

Where can I host an MCP server?

Anywhere that serves HTTPS: a container platform, a serverless function or your own infrastructure. A server that speaks only the 2026-07-28 revision keeps no protocol session, so you can run several instances without sticky routing. Supporting older clients means supporting their initialization and transport behavior. Session IDs are optional in those revisions; whether you need sticky routing depends on whether your implementation keeps server-side session state.