Remote MCP server

How a remote MCP server works

A remote server uses the Streamable HTTP transport. The server runs as an independent process that can handle many client connections, and it exposes a single HTTP endpoint, the MCP endpoint, that accepts POST 1. The specification gives https://example.com/mcp as the shape of such a URL 1.

Every JSON-RPC message from the client is a new POST to that endpoint 1. For a request, the server answers either with one JSON object or with a Server-Sent Events stream scoped to that request, which carries progress notifications before the final response 1. A client that wants change notifications, such as a new tool list, opens a long-lived stream with a subscriptions/listen request 1.

The July 2026 revision made the transport stateless 1. It removed the GET stream endpoint and protocol-level sessions, so each POST carries its own protocol version and metadata 1. Every request includes an MCP-Protocol-Version header, plus Mcp-Method and Mcp-Name headers that let load balancers and gateways route traffic without parsing the body 1. To cancel a request, the client closes its response stream 1.

Sign-in sits on top of the transport. The MCP authorization specification covers HTTP transports, and a protected server acts as an OAuth 2.1 resource server while the client acts as an OAuth 2.1 client 3. The user signs in through the browser, and the client then sends an access token with every request, which the MCP OAuth entry covers step by step. The architecture guide notes that Streamable HTTP supports bearer tokens, API keys and custom headers, and that MCP recommends OAuth to obtain tokens 2.

For users, setup comes down to a URL. An MCP client needs only the server address and a sign-in, the server updates in one place, and every user sees the same MCP tool list. The server owner takes on hosting, rate limit rules and access control.

Security rules for a remote MCP server

A server on the public internet takes requests from anyone who finds its URL, so the specification sets firm rules for it.

Origin checks. Servers must validate the Origin header on all incoming connections to prevent DNS rebinding attacks, and must answer HTTP 403 when the header is present and invalid 1.

Authentication. Servers should implement proper authentication for all connections 1. For HTTP transports, the MCP authorization specification is the standard route 3.

Token audience. A server must validate that each access token was issued for it, and must not accept or pass on tokens meant for anything else 3.

Tokens in headers. Clients send the token in the Authorization header on every request, and tokens must never appear in the URL query string 3.

Version checks. A server must reject a request with HTTP 400 when the MCP-Protocol-Version header does not match the version in the request body 1.

Usage rules matter too. A remote server that exposes paid data should also cap usage per account, log each call with its cost and state each tool's price in its description, because many users and agents share one deployment.

The stateless design also helps hosting. Each request carries its own protocol version and metadata, and the routing headers let load balancers and gateways inspect traffic without reading message bodies 1.

Example of connecting a remote MCP server

A two-person sales team wants an assistant to check a prospect list's emails before a send, without writing code.

Step 1   Create a RichAPI account
Step 2   Paste https://mcp.richapi.ai/mcp into the MCP client
Step 3   Sign in when the client opens RichAPI, then click Allow
Step 4   Ask the assistant to verify the list and split it by status
Step 5   Read the cost summary when the run finishes

Signup includes 100 free credits with no credit card 4. The same server URL works in any client that supports remote HTTP MCP, so both teammates add the same address 4. Neither teammate handles a key, and the RichAPI MCP page says there is no API key to copy 4.

The request runs as tool calls on the remote server. Email verification costs 2 credits per email, and RichAPI's starter prompts end with a cost summary of what ran and the credits used 4. Nothing runs on either laptop except the client, so a tool added on the server shows up for both teammates the next time their client lists tools.

Behind the scenes each step is a separate POST to the MCP endpoint, with the access token in the Authorization header 3. If one teammate closes the client in the middle of a long verification, the response stream closes and the server treats that request as cancelled 1.

If the team later wants an internal tool, such as a lookup against its own CRM export on a laptop, it can run that as a separate local MCP server next to the remote one. The host application keeps one client connection per server, so both sets of tools appear in the same conversation 2.

Remote MCP server vs local MCP server

Both speak the same protocol and differ in where the server runs and how the client reaches it. The architecture guide describes local servers on stdio as typically serving a single client and remote servers on Streamable HTTP as typically serving many 2.