What is a remote MCP server?

Remote MCP server, explained#

The first MCP servers were mostly local: a client launched them as a subprocess and they read files or called APIs with a key from the environment. That works for a developer, but not for a team using a hosted product, where nobody wants to install and update a server on every laptop or paste an API key into a config file.

A remote server solves both. It lives at a URL such as https://example.com/mcp. Every JSON-RPC message from the client is an HTTP POST to that endpoint, and the server answers either with a single JSON response or with a Server-Sent Events stream when it has several messages to send. Streamable HTTP was introduced in the 2025-03-26 specification revision and replaced the older HTTP+SSE transport.

Authorization is what makes a remote server safe to share. The MCP specification has the server act as an OAuth 2.1 resource server. An unauthenticated request gets 401 with a pointer to the server's protected resource metadata (RFC 9728). The client follows it to the authorization server, registers itself, sends the person to a consent screen in the browser and comes back with an access token scoped to what they approved. The token goes in the Authorization header of every request, never in the URL.

Remote servers also carry duties a local one does not. They must check that each token was issued for them, validate the Origin header to prevent DNS rebinding, keep tenants apart, and rate-limit so one busy client cannot starve the rest.

For example, a designer adds a remote MCP server to ChatGPT by pasting its URL into a custom connector. The browser opens, they pick their workspace and approve read access, and from then on ChatGPT can search that workspace. Nothing was installed and no key was copied.