What Are MCP Tunnels? (And Why Vendor-Locked Tunnels Are a Problem)
Published:
Last Updated:
The part of an MCP tunnel rollout that actually takes time isn’t opening the connection. It’s confirming, before anyone signs off, that the vendor providing the tunnel can’t read what passes through it. That question shows up in nearly every enterprise MCP security review once a private server is involved, and the answer depends entirely on which vendor’s tunnel implementation you’re looking at. That’s the actual shape of the decision most platform teams are making right now, not whether to use a tunnel, but which one, and what it costs to depend on it.
What Is an MCP Tunnel? Why It Flips the Usual Connection Direction
An MCP tunnel is a connectivity path that lets a cloud-hosted AI platform reach MCP servers running inside your private network without you opening a single inbound firewall rule. The connection direction is the whole point: your infrastructure initiates an outbound-only connection to the vendor; the vendor never initiates a connection to you, and there is nothing listening on a public IP for anyone to find.
That direction matters because it inverts the default assumption behind most enterprise network exposure. A team that wants Claude Code or a similar coding agent to reach an internal MCP server, a ticketing system, an internal API, a database-backed tool, has historically had two bad options: put the server on the public internet behind its own authentication, or maintain a VPN bridge that every new agent integration has to be manually threaded through. A tunnel replaces both with a managed outbound-only connection that the vendor terminates on their side and routes to your upstream MCP server based on hostname.
Anthropic and OpenAI both shipped versions of this in 2026. They solve the same problem. They do not solve it the same way, and they do not work with each other’s clients, a detail that matters more than either vendor’s documentation emphasizes.
How MCP Tunnels Work: Anthropic’s Cloudflare Stack vs. OpenAI’s Long-Polling Model
The mechanics differ by vendor, but the shape is consistent enough to describe generically before getting specific.
A tunnel stack runs inside your network, usually as a container or a small binary on a host that already has network reachability to your MCP server inside the firewall. That stack opens a persistent or polling outbound-only connection to the vendor’s infrastructure. When an AI agent on the vendor’s side needs to call a tool on your server, the request travels down that existing connection rather than the vendor reaching out to a new address, which is why no inbound ports ever need to open.
Anthropic’s implementation runs on Cloudflare’s tunnel infrastructure. A component called cloudflared opens the outbound connection to a Cloudflare-operated tunnel edge, and Anthropic’s own proxy terminates a second, inner TLS layer on top of that using a certificate only the customer holds, specifically so Cloudflare, sitting in the middle of the transport, cannot read the payloads. Each server you expose gets its own hostname under a tunnel domain, and the proxy performs IP validation against Cloudflare’s published edge ranges before treating a connection as legitimate. As of this writing, Anthropic’s MCP tunnels are in research preview, provided without an uptime or support commitment, and dependent on Cloudflare’s own network with no availability guarantee from that transport provider either.
OpenAI’s implementation skips the persistent-tunnel model entirely and uses long-polling instead. A CLI tool called tunnel-client runs inside your network, repeatedly polls OpenAI’s control plane at api.openai.com for queued work over standard outbound HTTPS, forwards each MCP request to your local server, and posts the response back through the same channel. There’s no equivalent to Cloudflare’s edge in this model. The tunnel token and the runtime API key are what stand between an attacker and your internal tooling, along with an embedded MCP server built into tunnel-client itself, called Harpoon, that OpenAI scopes to a small, explicitly allowlisted set of HTTP targets rather than letting it forward to arbitrary internal hosts.
Both approaches use JSON-RPC as the message format once the connection reaches the private server, consistent with how any MCP client talks to any MCP server. Anthropic’s proxy specifically routes over Streamable HTTP once traffic reaches the upstream server; OpenAI’s tunnel-client forwards to the local server over whichever transport that server actually exposes, stdio or HTTP. The difference that matters is entirely in how the outbound channel itself gets established and secured, not in what travels over it once it’s open.
MCP Tunnels vs. Remote MCP Servers vs. Local MCP Hosting
It’s easy to conflate a tunnel with the two adjacent patterns it sits between, and the distinction is worth being precise about before going further.
A remote MCP server is one you’ve already made reachable on the public internet, typically behind its own authentication and TLS termination; no tunnel is involved because there’s nothing private to bridge. Local MCP hosting is the opposite end: the server runs on the same machine as the client, communicating over stdio, with no network exposure at all because there’s no network in the path. A tunnel exists specifically for the middle case, a server that needs to stay private but still be reachable by a client that isn’t on the same machine or the same network.
Choosing between hosting a server locally, exposing it remotely, or reaching it through a tunnel is a deployment decision with real tradeoffs on each side, covered in full in our comparison of hosted, self-hosted, and local MCP deployment models. The short version relevant here: a tunnel is the right tool exactly when a server has to stay off the public internet and the client calling it isn’t on the same network, which describes most internal mcp servers inside a regulated enterprise.
The Problem With Vendor-Locked Tunnels for Multi-Client AI Agents
Connecting to Claude: Managed Agents and the Messages API
Here’s the part neither vendor’s documentation states directly, because it doesn’t need to from their side of the table. Anthropic’s tunnel infrastructure works with Claude Enterprise and lets a client connect to Claude through managed agents or the Messages API. It does not appear as a connector in claude.ai, and it has no path into ChatGPT, Codex, or any other client. OpenAI’s tunnel-client associates a tunnel with a Platform organization or a ChatGPT workspace. It has no path into Claude Desktop, Claude Cowork, or Claude’s Messages API. Each vendor built a tunnel that solves the private-network problem for their own managed agents and nothing else.
That’s not a bug in either implementation. It’s the predictable outcome of two companies each solving connectivity for their own MCP client ecosystem in isolation. The consequence lands on the team running both.
An organization standardized on a single AI vendor for every tool calls workflow never feels this. An organization running Claude Enterprise and agentic coding tools alongside ChatGPT-based workflows, which describes most platform teams four months into a serious multi-agent rollout, ends up provisioning two separate tunnel stacks for the same internal MCP servers: two sets of credentials to rotate, two audit trails that don’t correlate, two vendor-specific failure modes to diagnose when a tunnel drops mid-incident. None of this is complicated individually. Together, across a fleet of internal servers and two or more AI clients, it’s a maintenance burden that scales with vendor count instead of server count.
In practice, running a tunnel per vendor works fine until a second AI client shows up on the roadmap, and by then nobody remembers which tunnel maps to which internal service without checking a spreadsheet. That’s a pattern, not a statistical outlier. Every enterprise MCP deployment that outlives its first AI client hits the same wall.
The deeper issue is architectural, not operational. A tunnel ID tied to one vendor’s control plane means that vendor’s infrastructure decisions- a research-preview label, a dependency on a specific transport provider, an outage on their side- become your infrastructure’s dependency too, multiplied by however many vendor-specific tunnels your team ends up running in parallel.
How Obot’s MCP Tunnels Are Different
Obot’s MCP tunnel, shipped as part of Obot Platform v0.25.0, runs through the MCP gateway rather than through any single AI vendor’s control plane. That’s not a marginal implementation detail. It’s the structural difference that determines whether the tunnel serves one client or every client your organization actually runs.
Because the tunnel lives at the gateway layer, the same outbound-only connection that reaches an internal MCP server is available to any MCP-compatible client connecting through Obot, Claude Code, Cursor, Codex, or an internal agent framework, without provisioning a separate vendor-specific tunnel stack for each one. The gateway is what enforces access policy and holds the audit trail regardless of which client made the call, which means the audit trail actually correlates across clients instead of living in two or three vendor-specific logs that a security team has to reconcile by hand during an incident review.
Obot MCP Gateway is open source under the MIT license, self-hostable on Kubernetes or Docker, and available as a managed service. Same product either way. The tunnel capability sits alongside the platform’s existing mcp proxy and hosting model rather than as a bolt-on feature tied to one vendor’s roadmap, which is the direct answer to the problem the previous section describes: infrastructure that doesn’t inherit a single vendor’s dependency chain because it was never built around one.
When You Actually Need an MCP Tunnel for Internal Systems
Not every private MCP server needs one. A tunnel earns its complexity in a specific, recognizable set of situations.
Internal databases and internal APIs that can never be public. A server that queries a production database directly, or wraps an internal API with no public-facing equivalent, is exactly the case a tunnel exists for. Exposing it remotely means accepting public attack surface for a service that was never designed to face the internet. Hosting it locally only works if every client that needs it happens to run on the same machine, which stops being true the moment more than one person needs access.
Self-hosted tools behind a VPN or firewall in regulated environments. Financial services, healthcare, and government teams frequently run internal tooling that compliance requirements keep off the public internet entirely. A tunnel lets an approved AI client reach that tooling without the compliance team having to approve a new public endpoint, which is often the difference between a project shipping this quarter and a project stuck in a security review queue for the next two.
Ticketing systems, internal wikis, and other line-of-business tools an agent needs read or write access to. These are rarely worth exposing publicly even with strong authentication, since the cost of a misconfiguration is high and the benefit of public reachability is close to zero. A tunnel gives an agent exactly the access it needs without expanding the network reachability of the underlying system at all.
If none of those describe your situation, and the MCP server in question is either already fine being public or only ever called from the same machine it runs on, a tunnel is solving a problem you don’t have. Add the complexity when the constraint is real, not because the capability exists.
The Question Isn’t Whether to Tunnel
The question is not whether an MCP tunnel belongs in your architecture. It is whether the tunnel you pick still works the day a second AI client shows up on your team’s roadmap. Policies enforced at the gateway layer are infrastructure-level guarantees that hold regardless of which client is calling. Policies that only exist inside one vendor’s tunnel implementation are a bet on that vendor remaining your only client, indefinitely.
FAQ
What is an MCP tunnel?
An MCP tunnel is an outbound-only connection that lets a cloud-hosted AI platform reach private MCP servers behind a corporate firewall without opening inbound ports or exposing those servers to the public internet.
Do MCP tunnels require opening firewall ports?
No. The entire mechanism depends on the connection being outbound-only. Your infrastructure initiates the connection to the vendor; the vendor never initiates a connection back to you, so no inbound firewall rule is ever required.
Are Anthropic’s and OpenAI’s MCP tunnels compatible with each other?
No. Anthropic’s tunnel infrastructure works with Claude’s Managed Agents and Messages API and does not appear as a connector in claude.ai. OpenAI’s tunnel-client associates with a Platform organization or ChatGPT workspace and has no path into Claude’s products. A tunnel built for one vendor’s client does not work with the other’s.
Is an MCP tunnel the same as a remote MCP server?
No. A remote MCP server is already reachable on the public internet, typically behind its own authentication. A tunnel exists for the opposite case: a server that must stay private but still needs to be reached by a client that isn’t on the same network.
Can a compromised tunnel expose my internal MCP server?
The tunnel transport itself is generally encrypted end-to-end so the transport provider cannot read payloads, but the tunnel token and any TLS credentials used to establish the connection are high-value secrets. If both are compromised, an attacker could potentially impersonate the tunnel endpoint. Treat tunnel credentials with the same rigor as any other production secret.
Do I need a separate MCP tunnel for every AI client my organization uses?
With vendor-native tunnels, yes, since each vendor’s tunnel only serves their own client ecosystem. A gateway-based tunnel that isn’t tied to a single vendor’s control plane can serve every MCP-compatible client through one connection instead.
What is the difference between an MCP tunnel and an MCP proxy?
A tunnel solves connectivity: how a remote client reaches a private server without exposing it publicly. A proxy sits in front of one or more MCP servers to enforce policy, broker credentials, and log activity regardless of how the connection was established. The two are complementary; a mature deployment typically uses both.
Is Obot’s MCP tunnel open source?
Yes. Obot MCP Gateway, including the tunnel capability introduced in v0.25.0, is MIT licensed and can be self-hosted on Kubernetes or Docker, or consumed as a managed service running the same codebase.
