--- title: When should you use Secure MCP Tunnel for an MCP server? url: https://deepthinkingai.org/when-to-use-secure-mcp-tunnel/ published: 2026-09-18 author: Shekhar Singh topic: Agents & Protocols tags: mcp, openai, infrastructure, security site: DeepThinking AI --- # When should you use Secure MCP Tunnel for an MCP server? **Summary:** Secure MCP Tunnel is the right OpenAI MCP path when a server must stay inside your network boundary. A directly reachable remote MCP server is simpler when the endpoint can be public. The implementation split is specific and checkable: public servers use `server_url`, while tunneled ones use `tunnel_id`. ## Key takeaways - Secure MCP Tunnel keeps a private MCP server off the public internet by having tunnel-client poll OpenAI from inside your network. - The Responses API uses `server_url` for a public remote MCP server and `tunnel_id` for a tunneled private server. - Public plugin distribution still requires a stable public HTTPS MCP endpoint, so Secure MCP Tunnel is an infrastructure control rather than a publishing shortcut. - Tunnel operations add organization, workspace, and client health dependencies that a public MCP server does not carry. OpenAI's two MCP connection paths solve different problems, and teams blur them when they talk about "using MCP with Responses" as though the runtime were all that mattered. The durable distinction is network exposure: public servers are for endpoints OpenAI can reach directly, and Secure MCP Tunnel is for private servers that must stay inside your boundary. ## What is the difference between a remote MCP server and Secure MCP Tunnel? A remote MCP server is the straightforward case. You expose a public HTTPS MCP endpoint, pass that endpoint as `server_url`, and OpenAI reaches it directly when the model needs tools. The MCP servers guide shows the path clearly, down to the `mcp_list_tools` output item the Responses API creates before a tool call. That is the same discovery flow the core MCP [tools specification](https://modelcontextprotocol.io/specification/draft/server/tools) expects, where the server returns tool definitions and input schemas to the client. Secure MCP Tunnel changes only the network path. `tunnel-client` runs inside the network that can already reach the private MCP server, long-polls OpenAI for queued work, forwards each JSON-RPC request locally, and returns the response through the same tunnel. That is why I would keep the decision narrow. If the server can be public, a public server is simpler. If the server must stay private, the tunnel is the right shape. **Public remote MCP server path** ```mermaid sequenceDiagram participant OpenAIproduct as OpenAI product participant PublicMCPserver as Public MCP server OpenAIproduct->>PublicMCPserver: tools/list via server_url PublicMCPserver-->>OpenAIproduct: tool list and schemas OpenAIproduct->>PublicMCPserver: tools/call over HTTPS PublicMCPserver-->>OpenAIproduct: tool result ``` - tools/list via server_url: OpenAI reaches the server directly. - tool list and schemas: MCP tools include full input schemas. - tools/call over HTTPS: Approval policy still applies. A public remote MCP server is the direct path. OpenAI calls the server_url itself and receives the normal MCP tool list and tool results. ## When does Secure MCP Tunnel solve a real MCP problem? Secure MCP Tunnel solves a real problem when exposing the MCP server would punch through a boundary you actually care about. OpenAI names the obvious cases: private networks, on-premises systems, developer machines, and services sitting behind existing access controls. In those cases the tunnel lets ChatGPT, Codex, or the Responses API use a normal MCP path without adding inbound internet access to the server itself. The useful correction in the tunnel guide is what it does not solve. It does not turn a private server into a public integration surface. OpenAI says public plugin submission still requires a stable, publicly reachable HTTPS MCP endpoint. So if your goal is partner access, public app distribution, or a general remote endpoint other clients can call, build the public server first and apply [read versus write controls](/agent-controls-read-vs-write/) around it. My opinion is blunt here: teams should use the tunnel to preserve a boundary. They should not treat it as an architectural default for capabilities that were never meant to stay private. ## What does the Responses API expect from Secure MCP Tunnel? The easiest implementation mistake is treating the tunnel like a funny-looking URL. OpenAI's guide says not to do that. A directly reachable remote server goes in `server_url`. A tunneled private server goes in `tunnel_id`. The API surface reflects the underlying transport: one path is a public endpoint OpenAI can call now, and the other is an OpenAI-hosted endpoint bound to a running `tunnel-client` session. **Where Secure MCP Tunnel changes the boundary** 1. OpenAI-hosted tunnel endpoint Public entry point, OpenAI managed 2. tunnel_id selects this endpoint Use tunnel_id for the tunnel connection. 3. tunnel-client in your network Polls outbound HTTPS to OpenAI --- server stays private below --- (No inbound public listener) 4. Private MCP server Reached locally or over private net Secure MCP Tunnel moves the public listener to an OpenAI-managed endpoint and keeps the MCP server behind your existing network boundary. That distinction matters operationally as well as syntactically. A public server fails like any other HTTPS dependency. A tunneled server can fail because the client stopped polling, because the wrong organization or workspace was associated with the tunnel, or because the local path from `tunnel-client` to the MCP server broke. If you have already worked through how [MCP tool discovery behaves](/how-model-context-protocol-works/), this is the same protocol with one more moving part in the middle, and most debugging time will go on that middle part. ## How does Secure MCP Tunnel change trust and approval? Less than people hope. The MCP servers guide warns that developers must trust a remote MCP server because a malicious server can exfiltrate sensitive data from anything that enters model context. Secure MCP Tunnel does not change that sentence. The tunnel changes exposure. It does not change what the server may do once it is connected to the workflow. Approval behaves the same way. OpenAI documents that MCP tool calls can be allowed automatically or require explicit approval from the developer. That is a policy on the tool path. Network placement is a separate choice. A tunneled server can still be mis-scoped, over-privileged, or too broadly approved. The practical rule is to separate the questions. Ask whether the server must stay private. Then ask what a tool call to that server is allowed to read, write, or trigger. This site has made the same point for agent infrastructure more broadly in [why read controls do not govern write paths](/agent-controls-read-vs-write/). The tunnel fits the first question. Tool approval fits the second one. ## What should an AI engineering team standardise for Secure MCP Tunnel? Standardise a decision rule. My preference is simple: default to a public remote MCP server for shared or third-party capabilities, and require a written reason before using Secure MCP Tunnel. That reason should name the boundary being preserved, the operator who owns `tunnel-client`, and the health signal that proves the tunnel is live. From there, keep the runbook mechanical. Public server means `server_url`, normal HTTPS monitoring, and whatever approval setting fits the capability. Tunnel means `tunnel_id`, `tunnel-client doctor`, outbound network checks, and an alert when discovery fails because the client is down rather than because the server logic is wrong. The aim is the same discipline this site argued for in [cacheable MCP tool lists](/mcp-cacheable-tool-lists/): know which layer owns the failure before you start optimising it. A tunnel is valuable when it keeps a real boundary intact. Outside that case, it is extra runtime to explain at 3 a.m. ## Choose between a public MCP server and Secure MCP Tunnel Start with the network boundary, then work outward to distribution, runtime wiring, and operational health. 1. **Decide whether the MCP server must stay private**: If the server can be safely exposed as a stable HTTPS endpoint, start with a direct remote MCP server. Reach for Secure MCP Tunnel only when privacy is a real requirement, such as on-premises systems, internal tools, or a service behind existing controls. 2. **Check whether the capability must be publicly distributed**: OpenAI's tunnel guide excludes public plugin submission and distribution. If partners or customers must connect through a normal public MCP endpoint, use a direct server or a public proxy instead of treating the tunnel as a publishing layer. 3. **Wire the API with the correct identifier**: Public servers use server_url in the MCP tool definition. Tunneled servers use tunnel_id. Mixing the two is the failure mode worth checking first, because the tunnel guide says plainly not to pass the OpenAI-hosted tunnel endpoint as server_url. 4. **Place tunnel-client in the same trust boundary as the server**: Run tunnel-client where it can already reach the private MCP server, then confirm outbound HTTPS to OpenAI and local connectivity to the server. The documented doctor, health, ready, metrics, and UI surfaces exist because this is now part of your runtime. 5. **Review approval and trust separately from exposure**: A tunnel does not make the server trustworthy. Keep approval policy, tool review, and least privilege decisions independent of network placement, because the MCP server can still influence or exfiltrate model context once it is allowed into the workflow. 6. **Monitor discovery failures and client health together**: A public server can fail as a normal HTTPS dependency. A tunneled server can also fail because tunnel-client stops polling or the organization and workspace association is wrong. Alert on both classes so a broken path names the component that failed. ## Frequently asked questions ### Does Secure MCP Tunnel replace server_url? No. The Responses API still uses server_url for a directly reachable remote MCP server. The tunnel path is a different integration: you identify the OpenAI-hosted endpoint with tunnel_id, and tunnel-client forwards the work to the private MCP server from inside your network. ### Can I use Secure MCP Tunnel for public plugin submission? No. OpenAI's tunnel guide says Secure MCP Tunnel does not support public plugin submission or distribution. Public plugins need a stable, publicly reachable HTTPS MCP endpoint, which means a direct remote server or a public proxy in front of a private one. ### Does Secure MCP Tunnel remove approval or trust risk? No. The MCP servers guide says remote MCP tools can be auto-approved or require explicit approval, and the same trust issue remains: a malicious server can exfiltrate sensitive data that enters model context. The tunnel changes exposure at the network boundary. Tool trust remains a separate control question. ### Where should tunnel-client run? Inside the same trust boundary that can already reach the private MCP server. OpenAI documents sidecar, separate Kubernetes deployment, and VM patterns, all built around outbound HTTPS to OpenAI and local reachability to the server. ## Sources - [MCP servers](https://developers.openai.com/api/docs/guides/tools-connectors-mcp). OpenAI, 2026 - [Secure MCP Tunnel](https://developers.openai.com/api/docs/guides/secure-mcp-tunnels). OpenAI, 2026 - [Tools](https://developers.openai.com/api/docs/guides/tools). OpenAI, 2026 - [Tools](https://modelcontextprotocol.io/specification/draft/server/tools). Model Context Protocol, 2026 --- Canonical HTML: https://deepthinkingai.org/when-to-use-secure-mcp-tunnel/