TL;DR:

  • Remote MCP servers run over HTTP/SSE or the newer Streamable HTTP transport, rather than stdio — this is what makes shared, team-accessible tool servers possible
  • Anthropic’s March 2026 update to the MCP specification formalised OAuth 2.1 as the authentication layer for remote servers, closing the main security gap that was blocking enterprise adoption
  • Cloudflare Workers and Fly.io are the two most popular hosting targets for remote MCP servers today, with Cloudflare offering zero-configuration TLS and edge distribution

When MCP launched in late 2024, most developers encountered it as a local protocol: a Claude Desktop plugin running stdio over a subprocess that lived on the same machine. That made for fast prototyping — no auth, no network config, instant feedback — but it also meant every person on a team had to run their own copy of every tool server, configured identically, updated manually.

Remote MCP changes that. A remote MCP server is a network-accessible service that any agent with credentials can call, maintained centrally, authenticated properly. It’s the difference between a developer tool and infrastructure.

How Remote MCP Transport Works

The original MCP specification used stdio — the client spawned a subprocess and communicated over stdin/stdout. Remote MCP replaces this with network transport. There are currently two options in the specification:

HTTP + Server-Sent Events (SSE) — the original remote transport, where the client makes HTTP requests to the server and receives streaming responses over SSE. This has been available since early MCP versions and is the most widely supported option across client implementations.

Streamable HTTP — introduced in the March 2026 MCP spec update, this transport unifies the request/response model with streaming into a single HTTP endpoint. Instead of a separate SSE stream, the server can return either a standard JSON response or a streaming SSE body from the same endpoint depending on whether the tool call generates incremental output. This simplifies infrastructure and fixes compatibility issues with some load balancers and proxies that don’t handle long-lived SSE connections cleanly.

Most production deployments are still on HTTP+SSE because it’s what the existing client ecosystem supports. Streamable HTTP support in Claude Desktop and other clients is landing throughout mid-2026.

Authentication: The Part That Actually Matters

Local MCP servers have no authentication — they run as the current user and the operating system handles isolation. Remote servers need real auth, and this was the gap that made remote MCP awkward to deploy safely for most of 2025.

The March 2026 spec formalised OAuth 2.1 as the authentication standard for remote MCP servers. The flow works as follows:

  1. A client attempts to connect to a remote MCP server
  2. The server returns its OAuth metadata endpoint (the “MCP server metadata” response)
  3. The client redirects to the authorisation server for the user to authenticate
  4. After consent, the client receives an access token and includes it in subsequent MCP requests as a Bearer token
  5. The server validates the token on each request

For enterprise deployments, the OAuth authorisation server is typically your existing identity provider — Okta, Azure AD, Google Workspace. The MCP server acts as an OAuth resource server, validating tokens issued by your IdP. This means access to MCP tool servers inherits your existing user lifecycle management: when someone leaves, their access to every MCP server registered with your IdP is revoked automatically.

For smaller teams or internal tools, lightweight options like Cloudflare Access (which wraps any HTTP endpoint with its own OAuth/OIDC layer) let you add authentication to a remote MCP server without implementing OAuth yourself.

Deploying a Remote MCP Server

The most common pattern for a team MCP server today:

Cloudflare Workers is the simplest deployment target. Cloudflare’s workers-mcp package handles the HTTP+SSE transport boilerplate, and the combination of automatic TLS, global edge distribution, and Durable Objects for session state solves most of the infrastructure concerns out of the box. Cloudflare Access can be layered on for authentication without code changes.

Fly.io suits cases where the MCP server needs to run arbitrary subprocesses or maintain persistent state that doesn’t map cleanly to Workers’ execution model. A Fly machine with a persistent volume and your MCP server running as a long-lived process handles this well, with Fly’s built-in TLS handling the HTTPS requirements.

Self-hosted on your existing infrastructure — if you have internal services that the MCP server needs to reach without going over the public internet (databases, internal APIs), running the MCP server inside your network with a reverse proxy in front is sometimes simpler than VPN tunneling from a cloud function.

A minimal remote MCP server in TypeScript using the official SDK:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";

const server = new McpServer({ name: "team-tools", version: "1.0.0" });

server.tool("get_customer", { customerId: z.string() }, async ({ customerId }) => {
  const customer = await db.customers.findById(customerId);
  return { content: [{ type: "text", text: JSON.stringify(customer) }] };
});

const transport = new StreamableHTTPServerTransport({ path: "/mcp" });
await server.connect(transport);

The key difference from a local server: the transport is StreamableHTTPServerTransport instead of StdioServerTransport. Everything else — tool registration, resource handlers, prompts — is the same.

What to Put in a Shared Remote MCP Server

The tools most worth sharing across a team are the ones with access to systems that every agent needs but that aren’t practical to give each agent individually:

  • Internal APIs and databases — a CRM lookup tool, a product catalogue query, an internal ticket system. These require service accounts with controlled access, which is easier to manage in one place.
  • Third-party services with shared rate limits — if five agents all make API calls to an external service under the same API key, centralising those calls through a shared MCP server lets you implement rate limiting, caching, and monitoring in one place.
  • Long-running or stateful tools — tools that maintain a connection to external systems benefit from running persistently rather than being re-initialised on every agent run.

Tools that are personal-credential-dependent — email, calendar, private file access — typically still belong on per-user local servers or are accessed through the user’s own OAuth token passed through to the remote server.

References