27 Apr 2025 AI Engineering 5 min read

Remote MCP Servers: From stdio to Authenticated Endpoints

The MCP specification revision 2025-03-26 replaced the HTTP+SSE transport with Streamable HTTP and added an OAuth 2.1 authorization framework. We trace the path from local stdio servers to authenticated remote endpoints, review the first vendor offerings from Cloudflare, GitHub and Stripe, and outline integration patterns and open gaps for enterprise deployments.

Why Local MCP Servers Do Not Scale

Anthropic open-sourced the Model Context Protocol (MCP) on 25 November 2024. The first specification revision, 2024-11-05, defines how an AI application connects to external tools: the client launches the server as a child process and exchanges JSON-RPC 2.0 messages over stdin and stdout. This design is deliberate. It requires no network stack, no TLS and no authentication. It also means every server runs on the machine of the person using it.

That constraint does not survive contact with an organization. Every developer installs servers individually via npx or Docker. API keys sit in plaintext JSON configuration files in home directories. There is no central inventory of which servers run where, no policy enforcement, no version control and no audit trail. Support tickets replace deployment pipelines. A protocol designed for a single desktop has to become a protocol for networks before enterprises can adopt it at scale.

An agent reaches its tools over MCP — one standard surface. 1/4

Streamable HTTP Replaces the Dual Endpoint

The 2024-11-05 revision did include a remote option called HTTP+SSE. It required two endpoints: a long-lived server-sent-events stream for messages from server to client and a separate POST endpoint for the opposite direction. In practice the persistent SSE connection broke behind proxies and load balancers with buffering and idle timeouts, and stateless deployment on serverless platforms was impossible.

The revision of 26 March 2025 replaced this model with Streamable HTTP (PR #206). A single endpoint accepts JSON-RPC over POST; the server answers with a plain JSON response or upgrades to an SSE stream when it needs to send multiple messages. Sessions are identified by the Mcp-Session-Id header. Servers can now be fully stateless — but only if they choose to be. Long-running tools and resumable streams still require server-side state.

OAuth 2.1 Becomes Part of the Protocol

The same revision added an authorization framework based on OAuth 2.1 (PR #133). Clients discover authorization endpoints via server metadata (RFC 8414), register themselves via Dynamic Client Registration (RFC 7591) and obtain tokens through an authorization-code flow with mandatory PKCE. For the first time an MCP client can connect to a server it has never seen and negotiate access without anyone exchanging keys manually.

The framework has a known weakness. As specified, the MCP server is both resource server and authorization server. Enterprises do not want a tool endpoint issuing tokens; they want delegation to an existing identity provider. Aaron Parecki published a widely discussed proposal on 3 April 2025 to separate the two roles. As of this writing the specification has not adopted it.

The First Vendor-Hosted Servers

Cloudflare shipped the first hosting substrate on 25 March 2025. workers-oauth-provider wraps a Worker as a spec-compliant OAuth 2.1 provider including RFC 7591 registration. McpAgent handles remote transport on Durable Objects and will track the switch to Streamable HTTP. mcp-remote bridges clients that only speak stdio, and the Workers AI playground serves as a ready-made remote client. GitHub and Stripe ship official servers as well — note the status column: both still run locally at this date.

The pattern is nevertheless visible: vendors take ownership of their integrations — GitHub rewrote Anthropic's reference server in Go together with Anthropic — while platforms take over hosting. Vendor-built does not yet mean vendor-hosted. We expect the status column of this table to look different within months.

Provider	Server	Transport	Authentication	Status (April 2025)
Cloudflare	McpAgent + workers-oauth-provider	SSE (Streamable HTTP announced)	OAuth 2.1 provider with RFC 7591 registration	Available on Workers since 25 Mar 2025
GitHub	github-mcp-server (Go)	stdio via Docker	Personal Access Token	Public preview since 4 Apr 2025
Stripe	@stripe/mcp (agent toolkit)	stdio via npx	Restricted API key	On npm since 19 Feb 2025

Integration Patterns for the Enterprise

The dominant pattern for authenticated endpoints is the OAuth facade. The MCP server acts as an OAuth provider toward MCP clients and as an OAuth client toward the upstream system — GitHub, Google or a corporate identity provider. Tokens issued to clients are scoped to MCP tools; upstream credentials never leave the server. workers-oauth-provider implements exactly this double role.

For internal rollouts we recommend a second pattern: a single MCP gateway as the only egress point. It terminates OAuth, enforces a server allowlist, logs every tool call and bridges stdio-only clients via mcp-remote during the transition. Combine this with least privilege: restricted API keys instead of account-wide secrets, and the tool annotations from the 2025-03-26 revision — readOnlyHint, destructiveHint — surfaced to users for confirmation.

Decide early whose identity a tool call carries. A per-user OAuth flow yields fine-grained accountability but multiplies consent screens; a service identity simplifies rollout but blurs the audit trail. Mixed models are legitimate: user identity for destructive operations, service identity for read-only lookups. The protocol does not make this decision for you.

What Remote MCP Does Not Solve

OAuth authenticates the client. It does not make tool output trustworthy. Tool descriptions are model input, and in early April 2025 security researchers demonstrated tool-poisoning attacks in which a malicious server manipulates the model through its own metadata. Remote deployment widens this surface: a server can change its tool definitions after approval. Pinning and reviewing server versions remain the operator's job.

Two further gaps are operational. The protocol defines no audit or logging format; traceability is whatever the gateway records. Client support is fragmented: in April 2025 most clients still speak the 2024-11-05 transport, which is why serious servers offer both transports in parallel. And Dynamic Client Registration — which the specification leans on — is rarely enabled in corporate identity providers, so manual client onboarding returns through the back door.

Outlook From April 2025

The direction of travel is unambiguous. OpenAI announced MCP support in its Agents SDK on 26 March 2025; Google DeepMind confirmed MCP support for Gemini on 9 April 2025. One wire format for tool access across vendor boundaries is no longer a hypothesis. We expect three developments: the authorization specification will separate resource server from authorization server; large SaaS vendors will host their own endpoints; clients will support remote connections with OAuth natively — and mcp-remote will disappear.

Our advice as of today: treat an MCP endpoint like any other API product. Give it an owner, an identity boundary, scopes, monitoring and a deprecation policy. The protocol will keep changing — the 2025-03-26 revision is five weeks old. These operating disciplines will not.