Cloudflare has added support for private MCP servers to its MCP server portals, according to a changelog entry on its developer documentation site. The change means a portal can connect to an MCP server that is reachable only inside a private network, rather than requiring that server to be exposed to the public Internet.
Rather than a new hosting product, what Cloudflare outlines here is a routing path. Private hostnames and IP addresses are reached by the portal through Cloudflare Gateway, which means no public endpoint is required for the MCP server itself. Private reachability for the server, mediated by Cloudflare's gateway layer — that is the heart of the announcement.
To make this work, the private server network has to be connected to Cloudflare first. The changelog names Cloudflare Tunnel, Cloudflare Mesh, or another Cloudflare One connector as the options for establishing that connection. Only after that connectivity exists does the portal have a path into the private network.
Configuration then happens in two documented steps. An operator sets up a private hostname or a CIDR route, and when adding the server to the portal, turns on the option to route traffic through Cloudflare Gateway. The changelog frames these as the setup actions required for the private-server case.
There is an important boundary in the design. Cloudflare states that OAuth authorization server endpoints, including the authorization endpoint and the token endpoint, must remain accessible on the public Internet. The private-network treatment applies to the MCP server, not to the OAuth machinery that governs access to it.
A second boundary applies to client registration. If Cloudflare automatically registers the OAuth client through Dynamic Client Registration, the changelog says the registration endpoint must also be reachable from the public Internet. So a fully private deployment is not what is being described; the identity and authorization surface stays public even when the server does not.
For developers and small studios running internal tooling, the practical shape of this is a split architecture. The MCP server can sit behind a private hostname or CIDR route, while the OAuth endpoints it depends on are published. Anyone planning a deployment has to account for both halves, because the private routing does not remove the public requirement on the authorization side.
The connector choice also matters for how the private network is joined to Cloudflare. Tunnel, Mesh and other Cloudflare One connectors are presented as alternatives rather than a single mandated path, which suggests teams can reuse whatever Cloudflare One connectivity they already operate instead of standing up a separate mechanism.
Cloudflare points readers to a setup guide titled Connect a private MCP server for the detailed instructions. The changelog itself is a summary: it states the capability, the routing behavior, the configuration switches and the public-endpoint constraints, but it does not walk through the full procedure.
What the entry does not contain is equally relevant. There is no pricing information, no statement about which plan tiers include private MCP server support, and no indication of regional availability. Those are open questions for anyone evaluating whether this fits an existing Cloudflare One deployment.
There is also no performance or reliability data in the supplied material. Cloudflare does not describe latency, throughput, connection limits or failure behavior for portal traffic routed through Gateway to a private server. The changelog asserts the capability, not measured characteristics of it.
The date of the change is not stated in the extracted text. The source carries a publication timestamp, but the changelog excerpt does not give an explicit event date, so the timing of general availability cannot be pinned down from this evidence alone.
For freelancers and small development teams, the most concrete implication is architectural rather than commercial. If an internal MCP server previously had to be exposed publicly to be usable from a portal, this offers a documented alternative in which the server stays private while authorization endpoints remain public. That reduces the public attack surface for the server itself, but it does not eliminate public exposure entirely, because the OAuth endpoints and, where DCR is used, the registration endpoint must still be internet-reachable.
That distinction is worth stating plainly, because it is easy to read a headline about private MCP servers as meaning nothing is public. Cloudflare's own description contradicts that reading. The private part is the server's network location; the authorization surface is explicitly required to be public.
A second implication concerns setup effort. Adopting this means having a Cloudflare One connector in place, defining a private hostname or CIDR route, and enabling Gateway routing when the server is added. Teams without existing Cloudflare One connectivity would be taking on that layer as part of the work, though the changelog does not quantify the effort involved.
The unresolved items are mostly operational. Without pricing, plan eligibility or regional details, it is not possible to say from this evidence who can use the feature or what it costs. Without any stated limits or performance figures, it is not possible to say how it behaves under load. And without an explicit event date in the text, the rollout timeline remains unclear.
Narrow and specific is what can be stated with confidence: according to Cloudflare's documentation, MCP servers that exist only on a private network can now be connected to by MCP server portals; Cloudflare Gateway is the means by which the portal reaches them; Tunnel, Mesh or another Cloudflare One connector is how connectivity gets established; part of setup are a private hostname or CIDR route plus a Gateway routing toggle; and publicly accessible must remain the OAuth authorization, token and, under DCR, registration endpoints. Anything further finds no support in the supplied material.