Remote MCP Server

A remote MCP server is a Model Context Protocol server that a client reaches over HTTP at a URL, hosted and operated by the provider, rather than launched as a local subprocess. The contrast is with a local stdio server, which the client starts on the user's own machine and talks to over that process's standard input and output.

The 2025-06-18 revision of the MCP specification defines exactly two standard transports: stdio, where the client launches the server as a subprocess and exchanges newline-delimited JSON-RPC over stdin and stdout, and Streamable HTTP, where the server runs as an independent process serving a single endpoint path that accepts both POST and GET. Under Streamable HTTP each client message is a POST; the server answers either with one JSON object or by opening a Server-Sent Events stream, and it may issue an Mcp-Session-Id header at initialization that the client then echoes on every subsequent request. Clients send an MCP-Protocol-Version header so the server can behave correctly across versions. This transport replaced the older HTTP+SSE transport from the 2024-11-05 revision, which is why some tooling still carries an "SSE" mode alongside a newer "HTTP" one.

Authorization is where the two shapes diverge most. The specification says stdio implementations should not follow the OAuth flow at all and should read credentials from the environment, which in practice means an API key in a config file on the user's laptop. An HTTP server that wants to be protected acts as an OAuth 2.1 resource server: it must implement RFC 9728 protected resource metadata, return 401 with a WWW-Authenticate header pointing at that metadata, and validate that every access token was issued specifically for it as the audience. Clients must implement PKCE and must send the RFC 8707 resource parameter naming the server's canonical URI, and both sides should support dynamic client registration so a user can connect to a server nobody hardcoded in advance. Token passthrough to upstream APIs is explicitly forbidden.

The practical consequence for anyone wiring a search or extraction API into an assistant: a hosted client cannot spawn your npm package. If the assistant runs in someone else's cloud, the only thing it can connect to is a URL, so a web-data vendor that wants to be reachable from a hosted chat product has to run a remote server. That turns a thin protocol wrapper into a real service with multi-tenancy, per-user credentials and rate limits, usage attribution, and an audit trail. Firecrawl, Apify, Browserbase and Tavily all ship MCP servers, and the hosted endpoints among them are remote servers in this sense. When evaluating one, the questions that matter are how it authenticates (OAuth with per-user consent, or one shared key you paste into a config), whether it is stateful enough to keep a browser session alive across calls, and how tool results are metered, because an agent that calls a search tool in a loop bills per call, not per session.