Scope
Remote MCP server deployment checklist
The topology decision comes first: stdio is the right default when the AI client and server share one machine and touch only local resources, while anything shared, multi-user, or enterprise-managed belongs on remote Streamable HTTP — accepting roughly 5-25ms of added latency per call in the same datacenter, or 50-200ms cross-region (p50-p95 estimates in TrueFoundry's May 2026 stdio-vs-Streamable-HTTP analysis), in exchange for centralized credentials, one-place updates, and gateway-enforced auth. The risk on the remote path is concrete, not theoretical: CVE-2025-6514 in the mcp-remote npm package (437,000+ downloads, CVSS 9.6, versions 0.0.5 through 0.1.15) let a malicious MCP server achieve remote code execution on the client by returning a crafted authorization_endpoint URL during OAuth discovery — discovered by JFrog Security Research and fixed in 0.1.16. The 2026-07-28 spec release candidate (blog.modelcontextprotocol.io) responds by hardening exactly this surface: MCP servers become OAuth 2.1 resource servers, PKCE (S256) is required, clients must validate the issuer, and the protocol layer goes stateless — the Mcp-Session-Id header and initialize handshake are removed entirely. Every remote-MCP guide written before that RC is stale; this checklist is what a production deployment must pass now.
Topology Decision: stdio vs Remote
3 checksKeep stdio only when the user controls the machine and the server touches only local resources
stdio has no network hop and is the fastest and simplest transport, but it assumes a local single-user launch model with no shared auth boundary. The moment a server is shared with teammates, customers, or containers, stdio's credential story collapses into secrets scattered across laptops.
Move to remote Streamable HTTP when the server touches shared systems (databases, internal APIs, SaaS)
Shared-system access needs centralized auth, RBAC, rate limiting, and structured logging that only a hosted deployment behind a gateway can enforce. The cost versus warm-process stdio is roughly 5-25ms per call in the same datacenter and 50-200ms cross-region (TrueFoundry's benchmark estimates) — measurable, but usually irrelevant next to the hundreds of milliseconds of the surrounding LLM call.
Price in update distribution before choosing local for a team
Local servers must be updated per-host, per-user — operationally painful for fleets and dangerous when the update is a security fix. A remote server ships the fix once, server-side, for every client simultaneously. CVE-2025-6514's fix (mcp-remote 0.1.16) had to propagate to every one of 437,000+ downloads individually.
Authorization: What the 2026-07-28 Spec Requires
4 checksImplement the server as an OAuth 2.1 resource server with PKCE (S256) required
The 2026-07-28 release candidate makes the OAuth 2.1 resource-server framing explicit, with PKCE using S256 required for clients. Bearer-token-in-a-config-file and homegrown API-key schemes no longer meet the spec for remote servers.
Publish Protected Resource Metadata (RFC 9728) and require resource indicators (RFC 8707)
Clients discover the correct authorization server through the server's published metadata, and resource indicators bind each token to the specific MCP server it was issued for — preventing a token issued for one server from being redeemed at another. Both are mandatory parts of the flow in the 2026 RC.
Validate the issuer (iss) on the authorization response
Issuer validation per RFC 9207 is newly required in the 2026 RC specifically to stop issuer mix-up attacks — the class where a malicious server steers the OAuth flow toward an endpoint it controls. That is exactly the mechanism CVE-2025-6514 abused: a crafted authorization_endpoint from a hostile server, passed unvalidated into the client's URL handling, yielded OS command injection via the URL's userinfo fields.
Audit client-side OAuth handling too, not just the server
CVE-2025-6514 lived in the client-side proxy (mcp-remote), not in any server. If you ship or mandate a connector for your users, pin it at or above the patched version (0.1.16 for mcp-remote) and treat every URL received from a server as untrusted input.
Session Handling and Statelessness
3 checksRemove dependence on Mcp-Session-Id and the initialize/initialized handshake
The 2026-07-28 RC deletes protocol sessions entirely: any server instance can process any request, client/server metadata moves into _meta on each request, and server/discover replaces handshake-based discovery. Deployments built around sticky sessions or a shared session store are running deprecated architecture the week the spec lands.
Design handlers to run on any replica behind a load balancer
Statelessness is the payoff, not just the requirement: no sticky routing, no session-store failure domain, horizontal scaling with plain HTTP load balancing. Keep workflow continuity in request/response state or your own datastore keyed by the authenticated principal — never in server-instance memory.
Rate-limit and log per authenticated principal, not per connection
With no protocol session to anchor on, the OAuth-authenticated identity is your unit of accounting. Per-principal rate limits and structured tool-call logs are what let you detect one credential misbehaving across many stateless requests.
Credential Hygiene and Operations
3 checksReplace static long-lived secrets with short-lived, identity-bound credentials
Astrix Security's MCP-ecosystem research found 53% of MCP servers rely on static long-lived secrets like API keys or PATs, and only around 8.5% use OAuth — the dominant misconfiguration pattern, because static secrets are hard to rotate, scope, and revoke. Remote deployment is your chance to broker credentials centrally via SSO or workload identity instead.
Put the server behind a gateway with origin validation and private-network placement where possible
Enterprise MCP guidance converges on gateway enforcement: origin checks, TLS termination, request-size limits, and IP allowlisting for internal-only servers. A remote MCP server exposed directly to the public internet with tool access to internal systems is the highest-value target you can build.
Pin and verify the spec revision your clients and server negotiate
During the 2025-06-18 to 2026-07-28 transition, mixed fleets are inevitable. Log the negotiated protocol revision per client and alarm on downgrades — an attacker-controlled client requesting the older, session-based flow against a server that still supports both is a real downgrade surface.
Common Mistakes
- Choosing remote hosting for latency-irrelevant single-user tools while leaving genuinely shared servers on stdio with secrets on laptops.
- Treating OAuth as a server-only concern — the worst MCP CVE to date (CVE-2025-6514, CVSS 9.6) was client-side, triggered by trusting a server-supplied authorization_endpoint.
- Building session affinity around Mcp-Session-Id in 2026, right as the release candidate removes protocol sessions entirely.
- Issuing one long-lived API key per integration — the 53% static-secret pattern that turns a leak into a permanent compromise.
- Skipping resource indicators, allowing a token issued for one MCP server to be replayed against another.
- Following pre-RC tutorials: most remote-MCP guides written before July 2026 describe the session-based handshake flow the spec has now deleted.