Claude MCP Tunnels: Private MCP Access for Agents

Anthropic announced MCP tunnels for Claude Managed Agents on May 19, 2026, alongside self-hosted sandboxes. The important idea is narrow but useful: Claude agents can reach Model Context Protocol servers that live inside a private network without requiring those servers to expose public endpoints.

The feature is still a research preview. That matters. This is not a general-availability networking product, and it is not something to describe as production-proven from a small local experiment. Anthropic's docs say access must be requested, the feature is provided without continuity guarantees, and the transport depends on Cloudflare as a third-party provider.

Effloow Lab did run a local sandbox PoC for the part that can be tested safely without credentials: a loopback MCP-like server, a gateway that routes by hostname, and a deny-by-default check for unknown hosts. The evidence note is in data/lab-runs/claude-mcp-tunnels-research-preview-developer-guide-2026.md.

Boundary: Effloow Lab did not create a live Anthropic tunnel, call Claude Managed Agents, use an Anthropic API key, test Cloudflare transport, validate TLS certificates, or measure latency, uptime, cost, or security. The PoC validates the routing shape, not the hosted service.

Why This Matters

MCP made agent integrations easier to standardize, but it also created a deployment problem. A useful internal MCP server often needs to reach private systems: ticketing tools, data warehouses, service catalogs, source repositories, runbooks, billing records, customer notes, or internal APIs. Publishing those servers to the public internet just so a hosted agent can call them is a poor default.

MCP tunnels are Anthropic's answer for that gap. The official announcement says a lightweight gateway runs inside your network and makes a single outbound connection. The agent can then reach private MCP servers through the tunnel without inbound firewall rules or public endpoints.

That changes the deployment conversation. Instead of asking whether every internal tool can be made public enough for an agent, teams can ask which private MCP servers deserve a controlled route, which tools should be enabled, which OAuth scopes should apply, and what logs must exist before a workflow goes live.

This is also why MCP tunnels should be evaluated with self-hosted sandboxes but not confused with them. Self-hosted sandboxes decide where agent tool execution runs. MCP tunnels decide how Claude reaches private MCP servers. Anthropic's docs say these are independent: an Anthropic-hosted session can use a tunnel, and a self-hosted session can use public or tunneled MCP servers.

What Anthropic Actually Shipped

Anthropic's May 19 announcement introduced two enterprise-facing Managed Agents updates:

Self-hosted sandboxes, available in public beta, for running tool execution in infrastructure controlled by the customer or a supported provider.
MCP tunnels, available in research preview, for connecting Managed Agents and the Messages API to private MCP servers.

The MCP tunnel overview says the deployment stack has two components inside the customer's network:

cloudflared, which initiates outbound-only connectivity to the tunnel edge.
An Anthropic proxy component, which validates upstream IPs and routes requests to the right upstream MCP server based on hostname.

Each exposed MCP server gets a hostname under the tunnel domain, such as docs.<your-tunnel-domain>. Once the tunnel has an active certificate and the stack is connected, the routed MCP servers can be used from Claude Managed Agents or from the Messages API through the MCP connector.

The Messages API shape is familiar if you already use remote MCP servers: pass a server URL in mcp_servers, reference it with an mcp_toolset, and include the current MCP connector beta header. The difference is that the host belongs to your tunnel domain rather than a public MCP endpoint.

Effloow Lab Sandbox PoC

The sandbox PoC used Node.js v25.9.0 in /tmp/effloow-claude-mcp-tunnel-poc. It created:

A private MCP-like HTTP server on 127.0.0.1.
A gateway on 127.0.0.1.
One allowed hostname, echo.local-tunnel.test.
One blocked hostname, admin.local-tunnel.test.

The local client called the gateway three times. The allowed host could list tools and call the deterministic hello tool. The blocked host received 403.

tools_list_status=200
tools_list_body={"jsonrpc":"2.0","id":1,"result":{"tools":[{"name":"hello","description":"Return a deterministic greeting"}]}}
tool_call_status=200
tool_call_body={"jsonrpc":"2.0","id":2,"result":{"content":[{"type":"text","text":"hello private-mcp"}]}}
blocked_status=403
blocked_body={"error":"host_not_allowed","host":"admin.local-tunnel.test"}

Two failures were useful. First, the generated JavaScript script failed because a nested template string was not escaped. Second, Node's fetch client kept the loopback Host header, so the gateway denied every request until the client switched to http.request with an explicit Host header. Both failures are recorded in the lab note because they match the real operational lesson: tunnel routing is not magic; hostnames, headers, and route tables have to line up exactly.

The result is modest but relevant. The local PoC shows why the proxy route table matters, why unknown hostnames should fail closed, and why a developer should test an MCP server with a realistic hostname before blaming Claude or the model.

The Architecture In Practice

For a real MCP tunnel deployment, think in layers:

Claude Managed Agent or Messages API
  -> MCP connector configuration
  -> tunnel hostname
  -> outbound tunnel transport
  -> proxy route table
  -> private MCP server
  -> downstream internal system

The model should not be the security boundary. The tunnel should not be the only security boundary either. Anthropic's security guidance says every MCP server should require OAuth, upstream IP ranges should be narrow, credentials should rotate, logs should be monitored, and MCP servers should expose only the tools and data required for their purpose.

That last point is easy to skip. If an internal MCP server exposes search_docs, create_ticket, delete_customer, and run_sql through one broad endpoint, a tunnel makes it reachable but not automatically safe. A better pattern is to split MCP servers by task and risk:

docs-readonly for knowledge-base retrieval.
tickets-draft for creating draft tickets but not closing incidents.
billing-audit for reading account history but not changing payment state.
deploy-status for deployment metadata without production mutation tools.

The Managed Agents MCP connector docs also support tool configuration. By default, all tools exposed by a server are enabled, but you can disable the default and explicitly enable only specific tools. For production workflows, the allowlist should be the normal path.

Setup Path For Developers

Anthropic's quickstart uses Docker Compose with manual credentials. The documented stack contains a sample MCP server, the tunnel proxy, and the outbound connector. To run the real quickstart you need Docker, Docker Compose, OpenSSL, a Claude Console role that can manage MCP tunnels, a tunnel domain, and a tunnel token.

The real setup sequence is roughly:

Create a tunnel in the Claude Console.
Copy the assigned domain and token.
Generate a CA and server certificate.
Register the CA certificate in the Console.
Write the sample MCP server.
Write the proxy config and Compose file.
Start the stack and confirm routes are configured.
Call the tunneled MCP server from Claude.

For production, Anthropic points developers toward Helm or Docker Compose deployments and recommends programmatic access through Workload Identity Federation when an OIDC identity provider is available. Manual credentials are the shortest path for testing, not the cleanest long-term operating model.

The practical preflight is simple:

# Local-only conceptual checks before touching the real tunnel
node /tmp/effloow-claude-mcp-tunnel-poc/poc.js

# Expected local signals
# tools_list_status=200
# tool_call_status=200
# blocked_status=403

Then test the real stack in order: tunnel edge connectivity, inner TLS, proxy routing, upstream IP validation, MCP server authentication, tool allowlists, and finally a low-risk Claude call.

Security Model And Failure Modes

MCP tunnels reduce one bad option: exposing private MCP servers publicly. They do not remove the need for normal service security.

Anthropic documents three protection layers: outer mTLS between Anthropic and the transport provider with IP validation, inner TLS from Anthropic's backend to the customer proxy, and OAuth on each MCP server. The docs also state that Cloudflare provides the outbound transport and receives connection metadata such as egress IP, host fingerprint, timing, byte volume, and the assigned tunnel subdomain, while request and response payloads are protected by inner TLS.

The strongest implementation pattern is defense in depth:

Require OAuth on every MCP server.
Use narrow upstream.allowed_ips ranges.
Pin and update container images.
Keep cloudflared and the proxy on restricted network paths.
Rotate tunnel tokens and TLS keys.
Alert on proxy warnings, errors, and unusual traffic.
Keep broad mutation tools off the first tunnel deployment.

Troubleshooting should also follow the layers. Anthropic's troubleshooting docs recommend diagnosing outbound connection first, then inner TLS, then upstream routing and IP validation. A common failure is a proxy log like no route for host, which usually means the tunnel domain or proxy route config does not match what Claude is calling. Another is upstream IP validation failure when a hostname resolves outside the allowed private ranges.

For local testing only, loopback may be added to allowed ranges. For production, avoid broad ranges like 0.0.0.0/0; that disables the SSRF protection you wanted from the proxy in the first place.

Layer	Primary Job	Developer Risk
MCP connector	Declares the server and enabled tools	Accidentally enabling every tool
MCP tunnel	Routes Claude to a private hostname	Treating transport as authorization
Private MCP server	Implements business tools	Overbroad credentials or mutation scope
Application policy	Approves risky outcomes	Missing human or deterministic gates

When To Use MCP Tunnels

MCP tunnels are most interesting when the MCP server is valuable precisely because it is private. Internal docs, incident systems, inventory services, compliance evidence stores, and source-control analysis services are good early candidates.

Start with read-heavy workflows:

Retrieve internal runbooks for an incident-analysis agent.
Search private documentation from a support-drafting agent.
Read service metadata for a deployment-review agent.
Pull ticket context for a bug-triage agent.
Summarize compliance evidence without changing records.

Delay high-risk workflows:

Production database writes.
Payment or refund actions.
Account deletion.
Legal or regulated decisions without expert approval.
Deployment commands without rollback and audit gates.

The reason is not that Claude cannot call tools. The reason is that a tunnel expands reach. A private endpoint that used to be reachable only from an internal network can now be invoked by a hosted agent path. That is useful only if identity, scope, logs, approval, and incident response are already designed.

Common Mistakes

The first mistake is treating "no public endpoint" as "secure enough." A non-public route is better than a public route, but the upstream MCP server still needs authentication, authorization, logging, and narrow tools.

The second mistake is connecting a broad MCP server too early. If the server wraps an entire internal API, tool allowlists become harder to audit and prompt-injection consequences get larger. Start with one server for one workflow.

The third mistake is skipping route-level tests. The sandbox failure with Host headers is a local version of a real class of problems: a tunnel can be healthy while the proxy route is wrong. Test exact hostnames and paths before debugging the agent prompt.

The fourth mistake is mixing self-hosted sandbox claims with tunnel claims. A self-hosted sandbox controls tool execution location. A tunnel controls private MCP reachability. They can be combined, but each solves a different part of the agent infrastructure problem.

FAQ

Q: Are Claude MCP tunnels generally available?

No. Anthropic describes MCP tunnels as research preview and says access must be requested. Self-hosted sandboxes are public beta, but MCP tunnels are the more limited preview feature as of May 26, 2026.

Q: Do MCP tunnels work with the Messages API?

Yes. Anthropic says tunneled MCP servers are reachable from both Claude Managed Agents and the Messages API once the tunnel is active. For the Messages API, the URL points at a hostname under the tunnel domain and uses the standard MCP connector format.

Q: Does the tunnel authenticate to my MCP server?

No. Anthropic's tunnel overview says the tunnel carries encrypted traffic but does not authenticate to the upstream MCP server. If the upstream server requires OAuth or a bearer token, configure that independently through the same MCP server auth path you would use for any remote MCP server.

Q: Can Claude Desktop use MCP tunnels from the Console?

Anthropic's tunnel overview says MCP tunnels created through the Console are not available as connectors in claude.ai. The documented surfaces are Claude Managed Agents and the Messages API.

Q: What should I test before a production pilot?

Test route matching, TLS, upstream IP validation, OAuth, tool allowlists, logs, credential rotation, and failure behavior. Then start with a read-only MCP server and a workflow that produces inspectable artifacts before any mutation.

Key Takeaways

Claude MCP tunnels are best understood as a private connectivity layer for MCP servers, not as a complete agent security model. They let Managed Agents and the Messages API reach internal MCP servers without public endpoints, but the upstream services still need OAuth, narrow scope, operational logs, and careful tool configuration.

Effloow Lab's local PoC confirmed only the gateway pattern: allowed hostname routes worked, an unknown hostname failed closed, and exact Host routing mattered. That is enough to make the developer lesson concrete, but not enough to claim live tunnel validation.

Bottom Line

MCP tunnels are promising infrastructure for enterprise agents, but they should start as a read-only, allowlisted pilot. Treat the tunnel as transport, keep authorization inside the MCP server, and require evidence before giving agents mutation tools.