MCP tunnel
An MCP tunnel is an outbound-only connection that lets an AI agent or platform outside a private network reach a specific Model Context Protocol (MCP) server inside it. A small tunnel client runs next to the server and dials out over TLS to the endpoint that needs to reach it. Tool calls travel back down that connection, and nothing inside the network accepts inbound traffic.
The MCP servers most worth connecting to agents are usually the ones an organization can least afford to expose. Because they remain private, a Postgres MCP tool that queries live data, an admin tool that can edit a user’s plan, or a wrapper for a company API stays hidden. It has no public URL, and its firewall exists to keep it that way.
They run differently. Background agents operate using vendors’ cloud infrastructure or separate VMs, with no access to company systems, while MCP apps like Claude and ChatGPT reach services through URLs. A tool running outside the network cannot access servers that exist only within it.
Before tunnels, fixing that split came down to one of 2 things. The machine gained an open endpoint, the risk the firewall was meant to block, or the software got in through a VPN or peering setup, touching much more than one machine. With MCP, a link lets the app reach only that server and no other, while the server remains hidden.
How does an MCP tunnel work?
A tunnel is a reverse connection. A tunnel client runs on a machine already connected to the MCP server and dials outbound, rather than accepting inbound connections:
- The client opens one outbound connection. It connects over HTTPS or a secure WebSocket to a tunnel endpoint outside the network. Most corporate firewalls already allow outbound traffic on port 443, so a tunnel typically requires no firewall changes and no network team coordination.
- Tool calls travel through that connection. When an agent calls a tool, the request travels down the connection the client opened, the client forwards it locally to the MCP server, and the response returns the same way. Concurrent requests are multiplexed as separate streams over the single connection.
- The server remains hidden inside. There is no inbound firewall rule, no public hostname, and no port forward. The only path to the server is the connection the client chose to open, and stopping the client closes it.
Two details separate a well-built tunnel from an ad hoc one. It should only send data to the nearby IP given when configured on startup; then its endpoint, once it dials, cannot redirect it toward another machine in the LAN. It must authenticate against the endpoint through a secret the team may rotate, so an exposed secret becomes invalid with no host changes.
Where do MCP tunnels connect?
A tunnel connects one private server to one endpoint. That endpoint is the thing trying to contact the server:
- An agent vendor’s platform. Anthropic and OpenAI each ship an MCP tunnel so their hosted products can reach private servers. A Claude tunnel serves Managed Agents and the Messages API, and an OpenAI tunnel serves ChatGPT, Codex, and other OpenAI products.
- An MCP gateway. The tunnel terminates at an MCP gateway, which then serves the private server to every agent surface behind it and applies its identity, permission, and logging controls to tunneled traffic.
- A developer’s own tooling. A developer building an MCP server on a laptop can tunnel it so a hosted client can call it before it is deployed anywhere.
The decision counts because a link provides connectivity, without control. A tunneled host follows rules set at the endpoint it reaches. Setting up one path per vendor means every vendor gets a separate endpoint on the system, so none can see what another dialed. Routing through a gateway means the firm gets a single user on each host, plus one spot logging every request.
When does an organization need an MCP tunnel?
Software on a device within a network can connect directly to a private host. A tunnel becomes necessary when an agent and a host operate across a network boundary. Common scenarios include:
- Hosted agents needing internal systems. A background agent on vendor infrastructure requires access to an issue tracker behind SSO, a staging database, or an internal API that only exist inside the network.
- Internal APIs behind the firewall. APIs built for callers on the corporate network cannot be exposed publicly without inverting the security model they were designed for.
- Development servers on localhost. An MCP server under development has no address outside the developer’s machine. A tunnel is the only way for a hosted agent to call it before deployment.
- VPC-only services. Databases and internal admin platforms are intentionally private, and a tunnel provides access without changing that privacy posture.
- On-premises systems in restricted networks. Where policy prohibits inbound traffic, an outbound-only connection is the only pattern that satisfies security review.
What value do MCP tunnels provide?
An MCP tunnel offers distinct advantages over other connectivity approaches:
- Private servers become usable by agents. The most valuable servers, the ones holding sensitive data or controlling consequential actions, are private for a reason. A tunnel makes them available to agents without forcing organizations to decide whether they are safe to publish.
- No new inbound firewall exposure. No inbound rule or port forward is added, and the private server needs no public hostname. The tunnel still creates a new access path, so the endpoint it connects to needs appropriate authentication and policy.
- The network path is scoped to one server. The client forwards to only one configured local address; it does not put the agent on the network. Access to that server still depends on the controls where the tunnel terminates.
- Deployment is lightweight. The tunnel client is a single process or container running anywhere the server is reachable. Since outbound port 443 is almost universally open, most deployments require no firewall changes or network team coordination.
- Control remains with the organization. The tunnel exists only while the client runs. The authentication key can be rotated, and the local destination address is fixed at launch time. Nothing external can widen the tunnel’s scope.
- Governance placement is a choice. Terminate the tunnel at a policy gateway and the private server gains identity, permissions, and an audit trail without leaving the network. Terminate it at an agent directly and the server becomes reachable but ungoverned, which creates a shadow MCP problem.
MCP tunnel vs VPN: Key differences
An MCP tunnel and a VPN both bridge networks, but serve different purposes and operate at different scopes:
- VPN scope: Gives a client network-layer access to the services permitted by its routes and access rules
- MCP tunnel scope: Connects a single MCP server to a single endpoint; the tunnel client forwards only to one configured local address
- VPN exposure: Depends on routes, access rules, and device policy; a VPN can be tightly scoped
- MCP tunnel exposure: The tunnel forwards only to its configured MCP endpoint; the terminating platform decides who may call it
- VPN setup: Requires VPN client software, credentials, and ongoing session management
- MCP tunnel setup: Single outbound connection on port 443, usually requires no firewall changes
For organizations needing agents to reach a specific private MCP server without giving them a VPN session, a tunnel narrows the application path. It does not replace authentication and authorization at the endpoint.
How does Speakeasy provide MCP tunnels?
In the Speakeasy AI Control Plane, a tunneled server operates as a source type. A lightweight proxy runs alongside your internal host, establishing one outbound WebSocket connection to the platform that multiplexes per-request streams through it. It forwards only to the local MCP endpoint pinned at launch, reconnects automatically with backoff if the link fails, and authenticates with a token displayed once, retained only as a hash, and rotated to revoke all active connections.
The tunnel creates a persistent bridge between your private server and the external platform, with requests and responses flowing through the outbound connection established by your network:
After setup, each tunneled host behaves the same as any other entry in that registry. It receives a cloud URL, runs via the same proxy layer as outside machines, and gains authentication, per-role app permissions, metering, and group entry. Calls appear in tool logs with the Tunneled MCP target type next to everything else the organization runs. One connection leaves it reachable to Claude, ChatGPT, the Responses API, or an organization’s own tools via that governed route, not one per vendor.
It appears as an option inside the dashboard. Create one tunneled MCP server from Sources > Connect; use its Docker, CLI, or Kubernetes setup where it can access that server, and it appears in the registry once it dials outward. The tunneled MCP servers docs cover configuration and monitoring, and the AWS deployment guide walks through EKS, ECS Fargate, and EC2.
To reach isolated hosts from your apps without exposing those, talk with us.