The 2025-06-18 MCP transport spec says Streamable HTTP replaces HTTP+SSE, lets one server handle multiple client connections, and requires Origin validation to prevent DNS rebinding. In production, that is the moment MCP stops being a clever tool demo and becomes a platform engineering problem about identity, isolation, and load control MCP transports spec.
- Remote MCP pushes teams from local subprocess tooling into HTTP, auth discovery, and session management, because the spec separates stdio from HTTP-based authorization flows MCP authorization spec.
- Both Anthropic and OpenAI now support remote MCP connectivity, which means vendor support is no longer the blocker; the blocker is whether your platform can govern who is allowed to expose which tools to which model Anthropic remote MCP docs OpenAI MCP docs.
- Cloudflare’s enterprise guidance is the clearest operational read so far: locally hosted MCP servers create supply-chain and administrative problems, while centrally managed remote servers add auditability, CI/CD, and default-deny write controls Cloudflare enterprise MCP.
Production breaks demos
Anthropic introduced MCP in November 2024 as an open standard for connecting assistants to data sources and tools, alongside local Claude Desktop support and an open-source server repository Anthropic announcement. That launch frame mattered: MCP began life as a developer convenience layer. It was optimized for getting a model connected to GitHub, Postgres, or Slack quickly, not for answering the question every platform team eventually gets: who owns the blast radius when the model can now execute high-value actions?
The authorization draft makes the split explicit. HTTP-based MCP deployments should follow the transport-level authorization spec, while stdio deployments should not and are expected to retrieve credentials from the environment MCP authorization spec. That is fine on one laptop. It is weak as an enterprise operating model. Environment-scoped credentials, ad hoc local installs, and hand-managed server versions are exactly the conditions that turn a promising prototype into security debt and unreliable operations.
Production needs identity
The most underappreciated line in the MCP auth draft is that the design is based on OAuth 2.1, protected resource metadata, and authorization server discovery MCP authorization spec. In plain English, a remote MCP server is not just “a tool endpoint for an LLM.” It is an access-controlled resource server. If your architecture sketch still shows one shared bearer token sitting behind a gateway, you are not building MCP for production. You are replaying the worst habits of early internal API platforms.
Anthropic’s own documentation is blunt that remote MCP servers connected through Claude are third-party services that are not owned, operated, or endorsed by Anthropic, and that users should connect only to servers they trust Anthropic remote MCP docs. OpenAI takes a similarly pragmatic position: its Responses API can work with remote MCP servers, but it does not make your trust model disappear OpenAI MCP docs. The practical implication is boring and non-negotiable: every remote MCP deployment needs mapped identities, scoped tokens, revocation, and auditable ownership before it needs another tool catalog.
Transport changed the problem
The transport update is not cosmetic. The current spec says Streamable HTTP replaces the older HTTP+SSE transport, uses HTTP POST and GET, and allows a server to handle multiple client connections while optionally using SSE to stream server messages MCP transports spec. That means remote MCP inherits the same design questions that already haunt every other stateful HTTP service: connection lifetimes, retries, buffering, fan-out, and whether your server can remain deterministic when several agent runs hit the same tool surface at once.
The same spec also requires Origin validation for incoming connections and recommends binding local deployments to localhost instead of all interfaces to reduce DNS rebinding risk MCP transports spec. This is the tell. Once a protocol specification needs to remind implementers about origin checks and network binding, you are no longer in prompt-engineering land. You are in application security and edge networking. Teams that do not promote MCP ownership from “AI experiments” to platform engineering usually discover this only after a demo becomes an internal dependency.
| Deployment mode | What the spec or vendor docs say | What platform teams should infer |
|---|---|---|
| Local stdio | Client launches the server as a subprocess, and auth for stdio should come from the environment rather than the HTTP auth spec MCP transports spec MCP authorization spec. | Fast to prototype, hard to govern, and easy to let drift across developer machines. |
| Remote Streamable HTTP | Server can handle multiple client connections, uses POST and GET, and may stream with SSE MCP transports spec. | Treat it like a production service with quotas, observability, and incident ownership. |
| Vendor-connected remote MCP | Anthropic warns these servers are third-party, while OpenAI imports tool lists from compatible remote MCP servers Anthropic remote MCP docs OpenAI MCP docs. | Your model provider is not your governance layer; you still need one. |
Isolation beats local trust
Cloudflare’s internal write-up is worth reading because it describes what mature organizations do after the first enthusiasm wave. The company says it concluded that locally hosted MCP servers were a security liability because they rely on unvetted software sources and versions, increase supply-chain and tool-injection risk, and keep administrators out of the control loop Cloudflare enterprise MCP. That diagnosis lines up with what senior engineers already know from CI runners, browser extensions, and internal developer portals: local convenience scales into invisible risk faster than people admit.
Cloudflare’s answer was not to ban MCP. It was to centralize it. The company describes a shared platform where new MCP servers inherit approval workflows, audit logging, auto-generated CI/CD, secrets management, and default-deny write controls Cloudflare enterprise MCP. That is the right instinct. If you already have a paved road for service templates, workload identity, and policy enforcement, MCP should plug into that road. If you let every product team publish remote tool surfaces from scratch, you are volunteering to debug both your permissions model and your incident process in production.
Production needs backpressure
OpenAI’s MCP documentation makes one operational detail easy to miss: when you specify a remote MCP server, the Responses API first attempts to retrieve the list of tools from that server, and successful imports show up as an mcp_list_tools output item. In other words, your serving path is not only model latency plus tool execution. It can also include remote tool discovery and schema transfer. That extra hop is fine for low-frequency workflows and terrible for fleets that pretend every agent can dynamically discover everything on demand.
The transport spec’s support for multiple client connections makes concurrency management your problem too MCP transports spec. Senior teams should be thinking about admission control, cached tool manifests, rate limits per tenant, and explicit timeout budgets before they celebrate “universal tool access.” This is the same lesson behind our coverage of function-calling failures in production workflows and LLM gateways reducing wasted API spend: giving models more edges to call is easy; making those edges cheap and predictable is the real engineering work.
Gateway the sprawl
Cloudflare argues that remote MCP servers provide better visibility and control because the MCP server can sit between the MCP client and the corporate resource boundary Cloudflare enterprise MCP. It also describes Shadow MCP detection through Gateway and an MCP server portal pattern aimed at reducing token costs Cloudflare enterprise MCP. Whether you use Cloudflare or not, the architectural point stands: once MCP adoption reaches more than a few teams, you need a discovery and control plane, not a growing spreadsheet of approved server URLs.
This is where AI platform work starts to look a lot like old platform work. You need inventory, tenancy, approval paths, logging, and regression tests for tool behavior. If you want a good mental model, combine three ideas: treat server definitions like code, test them like agents, and version them like APIs. Our earlier guides on building Claude skills and agent testing before production fit directly into this operating model.
Ship the boring platform
The near-term winner in MCP will not be the team with the longest list of tool integrations. It will be the team that ships the most boring, governable platform around them. The sources now point in the same direction: MCP is open and real Anthropic announcement, remote connectivity is supported by major model vendors Anthropic remote MCP docs OpenAI MCP docs, HTTP transport has serious security requirements MCP transports spec, and mature adopters are already centralizing governance Cloudflare enterprise MCP.
- Standardize on remote MCP only when you can enforce workload identity and scoped authorization MCP authorization spec.
- Cache or pre-approve tool manifests for high-volume paths instead of discovering everything live on every request OpenAI MCP docs.
- Put remote MCP behind the same observability, rollout, and incident processes you use for internal APIs MCP transports spec.
- Prefer centrally managed templates over developer-specific local installs when the tool can touch shared data or write paths Cloudflare enterprise MCP.
- Assume the protocol is the easy part. Ownership is the hard part.
If that sounds less exciting than “agents can now use any tool,” good. Excitement does not keep production systems reliable. Identity, isolation, budgets, and boring control planes do.