Remote MCP server

What it is

MCP servers run in one of two places. A local server is a program the client starts on the same machine; it talks over stdio and typically serves one client. A remote server is a web service at a URL. It talks Streamable HTTP and typically serves many clients. The MCP Registry lists remote servers with a remotes entry of type streamable-http and a public URL.

Why it matters

A remote server needs nothing installed. It works from web and mobile AI apps as well as desktop tools, and it keeps vendor credentials off laptops. It also concentrates risk: it is reachable from the internet, it holds many people's access, and it must keep tenants apart. That is why the MCP specification defines an OAuth flow for HTTP transports, while stdio servers take credentials from the environment instead.

How it works

1. The person gives the client one URL, the MCP endpoint.
2. The client sends a request. A protected server answers 401 with a pointer to its protected resource metadata (RFC 9728), which names the authorisation server.
3. The client registers, sends the person to sign in and consent, and receives an access token for that server.
4. Every request carries the token in the Authorization header. The specification forbids putting it in the query string.

Example

claude mcp add --transport http actionlake https://connect.actionlake.com/mcp

That single URL is the whole installation. The first call opens a browser to sign in.

Common pitfalls

• Session IDs as authentication. The MCP security guidance says servers that implement authorisation must verify every inbound request and must not use sessions for authentication.
• The old HTTP+SSE transport. It is deprecated; new remote servers should use Streamable HTTP.
• A local server on all interfaces. A local server bound to 0.0.0.0 becomes an unintended remote server. The specification says local servers should bind to localhost and validate the Origin header.
• No tenant isolation. A remote server serving many organisations must keep each one's data, cache and credentials apart on every query.

How actionlake handles it

The actionlake service runs as a remote MCP server at https://connect.actionlake.com/mcp. The endpoint is POST-only and keeps no session: every request is authenticated on its own, with an OAuth access token or an actionlake API key as a bearer token, and both resolve to the same key and the same policy. A GET or DELETE is answered 405 with Allow: POST. The service runs in one region, Sydney, Australia, where data is stored at rest; traffic passes through Cloudflare's edge in transit. Each query carries the tenant id, and the cache key includes the connection. The full list of what is and is not yet true is on the trust page; setup is in the quickstart.