The AI Agent Workflow: Native MCP Support in Local Tunnels

The year 2026 has introduced a highly specific, yet increasingly common need in developer workflows: AI agents that can open, manage, and tear down local network tunnels without a human pasting URLs between a terminal window and a chat interface. As coding assistants like Claude Code, Cursor, and Windsurf have taken on more terminal and environment access, their ability to interface directly with local infrastructure has become a real bottleneck for anyone testing webhooks or sharing a dev server.

Rather than relying on traditional port-forwarding methods designed for human operators, a handful of tunneling services — rustunnel and Pinggy chief among them — now ship dedicated Model Context Protocol (MCP) servers that let an agent operate tunnels directly. Anthropic has also shipped its own product under the literal name “MCP tunnels,” though it solves a different problem than the one this piece is mostly about — more on that below.

This guide covers what an MCP tunnel actually is (there are now two distinct meanings of that phrase), what rustunnel’s and Pinggy’s agent tooling really exposes, how the installation instructions differ by client, and where MCP gateways like Bifrost fit once you’re running more than a couple of servers.

---

1. The Evolution of the AI Agent Workflow

The old loop hasn’t gone away: spin up a reverse tunnel from the CLI, wait for the connection, copy the generated public URL, and paste it into both a third-party dashboard and a chat window. That’s fine for a one-off, but it breaks the autonomous flow of an agent that’s already driving the terminal — if Claude Code is implementing and testing a webhook endpoint, it shouldn’t have to stop and ask a human for a public URL.

The Model Context Protocol, which Anthropic open-sourced on November 25, 2024, is what changed this. MCP defines three roles: a host (the AI application — Claude Code, Cursor, Claude Desktop, Windsurf, and by now ChatGPT and GitHub Copilot too), a client (the protocol connection the host maintains with a given server), and a server (a process exposing a specific set of tools, resources, or prompts). Before a shared protocol existed, connecting M different AI applications to N different tools meant something close to M×N custom integrations; MCP collapses that to roughly M+N, since each side only has to implement the protocol once. Adoption moved quickly — Microsoft and GitHub joined MCP’s steering committee at Build 2025, and OpenAI added MCP support to its Agents SDK and Responses API the same year.

For tunneling specifically, this means an agent can call a tool like create_tunnel directly and get back structured data (a public URL, a tunnel ID, a status) instead of shelling out to a CLI and parsing whatever comes back on stdout.

---

2. Demystifying the “MCP Tunnel” — Two Different Things in 2026

Here’s where a draft of this piece needed the biggest structural fix: “MCP tunnel” now refers to two genuinely different architectures, and conflating them will send readers to the wrong tool.

2a. Agent-managed tunnels (the subject of most of this piece)

This is the pattern rustunnel and Pinggy build for: a tunneling vendor’s client runs next to a local service and dials out over TLS to a public edge server. The agent calls an MCP tool to open, list, and close these tunnels. Traffic direction: local machine → public internet, with the AI agent as the operator.

• No inbound rules. Nothing is exposed until the client dials out; corporate firewalls that permit outbound HTTPS don’t need to change.
• Scoped exposure. Unlike a VPN, a tunnel exposes one service instance, not the whole network.
• Encrypted transport, usually with the tunnel vendor’s own auth (OAuth, bearer tokens, or an account-scoped API token) layered on top.

2b. Anthropic’s own “MCP tunnels” (a different product, opposite direction)

Anthropic ships a research-preview feature on Claude Platform (formerly the Claude Developer Platform / Console) that is literally named MCP tunnels, and it solves the reverse problem: connecting Claude to an MCP server that lives inside a private network, without opening inbound ports on that network. Traffic direction: Claude → your private network.

The architecture: a lightweight tunnel stack (a proxy plus a cloudflared container) runs inside your network and opens an outbound connection to Cloudflare, which Anthropic uses as a subprocessor for this feature. You deploy it with Helm (Kubernetes) or Docker Compose, register a CA certificate through the Claude Console, and your private MCP server becomes reachable at something like https://<subdomain>.<your-tunnel-domain>/mcp — visible only to Claude Managed Agents and the Messages API, never to the public internet. The proxy is deliberately conservative: by default it only dials upstream addresses in the RFC 1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).

As of this writing, MCP tunnels are in research preview, available to organizations on the Claude Enterprise plan by request, and explicitly shipped “as-is” — no uptime, support, or continuity commitment, and dependent on Cloudflare’s own availability. If you’re building the kind of “agent reaches into our private database” architecture this feature targets, it’s worth requesting access before reaching for a third-party workaround; if you’re building the “agent exposes my laptop to the internet for a demo or webhook test” workflow, that’s section 2a, and the rest of this article.

---

3. rustunnel and the Rise of the Agent-Operator

Most tunneling services still assume a human is at the terminal. rustunnel — a self-hosted, AGPLv3-licensed tunnel server written in Rust, with an optional pay-as-you-go managed service — was built with the agent as the primary operator in mind. It’s a genuinely small project (635 GitHub stars as of writing) but its MCP integration is unusually well documented for something this size.

How it actually ships

One correction worth flagging up front: rustunnel’s MCP server (rustunnel-mcp) is not an npm package you run with npx. It’s a native Rust binary, distributed the same way as the rustunnel CLI client itself — via Homebrew (brew tap joaoh82/rustunnel && brew install rustunnel, which installs both binaries together) or built from source with cargo build --release -p rustunnel-mcp. It speaks MCP over stdio.

The tool surface covers the full tunnel lifecycle — six tools, not four:

Tool	Description
create_tunnel	Open a tunnel and return the public URL — HTTP/TCP/UDP, P2P, and load-balanced pools with health checks
list_tunnels	List all active tunnels
close_tunnel	Force-close a tunnel by ID
list_regions	List available server regions
get_connection_info	Return the CLI command for cloud/sandbox agents
get_tunnel_history	Retrieve past tunnel activity

The hosted service runs three regions — eu (Helsinki), us (Hillsboro, OR), and ap (Singapore) — and the client auto-selects the nearest one unless you pin it. Pricing: free up to 3 tunnels with no custom subdomains, pay-as-you-go at a $3/month minimum plus $0.10/GB (unlimited tunnels, custom subdomains), or self-host for free. Self-hosted deployments optionally expose Prometheus metrics and a JSON-lines audit log — both are configuration options on the server you run, not something baked into the hosted plan’s default behavior, so don’t assume the managed service logs your payloads by default without checking its current terms.

The autonomous loop, corrected

The scenario a draft of this piece described — prompting Claude Code to implement a Stripe webhook handler, expose it, and update a dashboard script — is real and roughly how it works, with two corrections: the tunnel URL pattern is region-scoped (https://abc123.eu.edge.rustunnel.com, not a bare .rustunnel.net domain), and get_connection_info doesn’t return “latency, region data, and request logs” — per rustunnel’s own docs it returns the CLI command a cloud or sandboxed agent would need to reconnect, which is a narrower and more specific job than the draft implied.

Installing it

Three documented paths, in ascending order of manual effort:

Claude Code plugin (simplest, per rustunnel’s own README):

/plugin install rustunnel

The plugin prompts for your server address and API token once, stores them, and starts the MCP server in the background — no .mcp.json editing. One caveat: this differs from the two-step pattern most Claude Code plugins use (/plugin marketplace add <owner>/<repo> followed by /plugin install <name>@<marketplace>). If the one-liner doesn’t resolve on your Claude Code version, fall back to /plugin marketplace add joaoh82/rustunnel and check plugins/claude-code/ in the repo for the exact plugin name to install.

Manual stdio registration:

claude mcp add --transport stdio rustunnel \
  --env RUSTUNNEL_TOKEN=YOUR_TOKEN \
  -- rustunnel-mcp --server edge.rustunnel.com:4040 --api https://edge.rustunnel.com:8443

Claude Desktop (or Windsurf, Cline — same JSON shape), edited directly:

{
  "mcpServers": {
    "rustunnel": {
      "command": "rustunnel-mcp",
      "args": ["--server", "edge.rustunnel.com:4040", "--api", "https://edge.rustunnel.com:8443"],
      "env": { "RUSTUNNEL_TOKEN": "<your-token>" }
    }
  }
}

For Cursor, rustunnel also ships a one-click “Add to Cursor” deep link on its README that pre-fills this config — you only need to paste in your API token afterward.

---

4. Comparing the Tunneling Ecosystem in 2026

ngrok

ngrok’s own first-party MCP story is not agent-managed tunnel creation — it’s the reverse. ngrok’s documented pattern is using ngrok as an MCP gateway: you run the ngrok agent next to your own locally-hosted MCP server, declare an internal Agent Endpoint, and use ngrok’s Traffic Policy engine to authenticate and restrict which clients (e.g., only Anthropic’s published IP ranges) can reach it. That’s a security/observability layer in front of an MCP server you already run, closer in spirit to Kong’s or Bifrost’s role (section 7) than to what rustunnel does. If you want an agent to operate your ngrok account — creating and tearing down tunnels the way rustunnel’s tools do — that exists too, but only through community-built servers (e.g., ngrok-mcp on GitHub, or Composio’s ngrok toolkit), not first-party ngrok tooling.

Pinggy

A draft of this piece described Pinggy as “highly effective for exposing tools, but less focused on the agent managing the tunnel itself.” That undersold Pinggy’s current agent story: it ships two separate pieces of tooling — an Agent Skill (npx skills add https://pinggy.io, reference docs the agent reads before running its own commands) and a standalone, early-access MCP server (pinggy_mcp, a Python/uv-based package) that registers thirteen tools across authentication, tunnel management (start_tunnel, stop_tunnel, list_tunnels, get_tunnel_info — HTTP/TCP/TLS/UDP), WebDAV directory sharing, and token management. Authentication runs over OAuth 2.0 Device Authorization Grant (RFC 8628) rather than a pasted API key. It’s explicitly labeled experimental by its maintainer, and tunnels are tied to the MCP server process — they don’t survive a host-app restart, which is arguably a feature: no lingering background daemon holding a stale public subdomain open.

For the narrower “expose an already-running local MCP server to a remote cloud agent” pattern (not tunnel management, just tunnel creation for one specific server), the plain SSH workflow still works exactly as it always has:

ssh -p 443 -R0:localhost:5000 a.pinggy.io

claude mcp add --transport http MyLocalDB https://rndm-string.pinggy.link/mcp

Cloudflare Tunnel

Missing from earlier drafts entirely, and worth including: Cloudflare bundles agent tooling for its whole developer platform — not tunnel-specific — through a Skills plugin (/plugin marketplace add cloudflare/skills then /plugin install cloudflare@cloudflare). The bundled cloudflare skill covers Workers, storage, AI, and networking including Tunnel and Spectrum, alongside Cloudflare’s own managed remote MCP servers for account operations (DNS, WAF rules, and so on) over OAuth. There’s no dedicated create_tunnel-style tool the way rustunnel or Pinggy ship — an agent using Cloudflare Tunnel today is still largely driving cloudflared via ordinary CLI knowledge the skill teaches it, not calling a purpose-built tunnel-management tool.

LocalCan, LocalXpose, frp, Playit.gg, and localhost.run

These remain accurate to the original framing. LocalCan (native macOS, .local domain integration) and LocalXpose (cross-platform GUI/CLI, with an official node-localxpose client) are strong for human developers but have no confirmed first-party MCP server as of this writing — wiring either into an agent means building a wrapper around their CLI or REST API yourself. frp remains the self-hosted standard for UDP-heavy and gaming workloads, and Playit.gg’s anycast routing serves the same niche without port forwarding; both are lower-level infrastructure that would need a custom MCP server to map natural-language requests onto config-file edits. localhost.run still fills the same SSH-based, zero-install niche as Pinggy for quickly exposing an existing MCP gateway (like Bifrost, covered below) to a remote client.

---

5. Integrating MCP Tunnels with Claude Code

Claude Code supports three MCP transports: stdio (default, for local processes), HTTP (recommended for remote/cloud-hosted servers), and SSE, which is being phased out in favor of HTTP. All three are registered through claude mcp add, or by hand-editing .mcp.json / ~/.claude.json.

Self-signed certificates and TLS during local development

If you’re pointing Claude Code at a locally-hosted tunnel proxy with a self-signed certificate, you’ll hit unable to verify the first certificate — Node.js-based MCP clients (Claude Code included) reject self-signed certs by default. The documented workaround is exactly what a draft of this piece showed:

{
  "env": {
    "NODE_TLS_REJECT_UNAUTHORIZED": "0"
  }
}

in ~/.claude/settings.json. One thing worth adding: this disables certificate verification for all of Claude Code’s outbound connections for that session — including api.anthropic.com and the MCP registry, not just your local tunnel. Anthropic’s own engineering community has flagged this scope as broader than most people expect; treat it strictly as a temporary local-dev flag, run it as NODE_TLS_REJECT_UNAUTHORIZED=0 claude for a single session where possible instead of writing it into global settings, and use NODE_EXTRA_CA_CERTS pointing at your actual CA certificate if you can, since that scopes trust to one certificate rather than disabling verification outright.

---

6. Integrating with Cursor and Windsurf

Cursor and Windsurf both configure MCP through JSON files rather than a CLI. The paths are not as interchangeable as they look:

• Cursor — global: ~/.cursor/mcp.json; per-project: .cursor/mcp.json in the project root.
• Windsurf — ~/.codeium/windsurf/mcp_config.json.

Both use the same mcpServers JSON shape as Claude Desktop:

{
  "mcpServers": {
    "rustunnel": {
      "command": "rustunnel-mcp",
      "args": ["--server", "edge.rustunnel.com:4040", "--api", "https://edge.rustunnel.com:8443"],
      "env": { "RUSTUNNEL_TOKEN": "your_api_token_here" }
    }
  }
}

Worth flagging since it trips people up elsewhere in this space: VS Code uses a different schema (servers, not mcpServers, plus an explicit "type": "stdio" field) at ~/.vscode/mcp.json or .vscode/mcp.json. Don’t reuse a Cursor config verbatim for VS Code — it won’t be read correctly.

Once saved, Cursor’s or Windsurf’s agent detects the new server automatically. Ask it to “expose the Next.js frontend to the internet” and it calls create_tunnel (or Pinggy’s start_tunnel) on its own.

---

7. Scaling with MCP Gateways: Bifrost and Kong

Connecting an agent to a tunneling MCP server, a database server, and a search server individually is trivial at first — it stops being trivial once a team is running ten or fifteen MCP servers. Each server typically exposes 10 to 30 tool definitions, and Claude Code loads every connected server’s full tool catalog into context before it processes a single token of your prompt. That’s where MCP gateways come in.

Bifrost

Bifrost is an open-source, Go-based AI gateway from Maxim AI that acts as both an MCP client (connecting outward to your tunneling server, database tools, and so on) and an MCP server (exposing one aggregated /mcp endpoint inward to Claude Code). Wiring it in is one command — note the corrected scheme, http rather than https for a local instance:

claude mcp add --transport http bifrost http://localhost:8080/mcp

Bifrost adds roughly 11 microseconds of gateway overhead per request at 5,000 requests/second, and its “Code Mode” — where the model writes code against tool definitions instead of having every tool schema injected into context — has been measured to cut input tokens by up to 92% in Bifrost’s own benchmarks while holding task pass rate steady. It also handles virtual-key governance (per-team rate limits and budgets) and multi-provider LLM routing (Anthropic, OpenAI, Bedrock, Vertex AI, and others) through the same deployment.

Kong AI Gateway

Kong shipped native MCP support in Kong Gateway 3.12 (October 2025) as part of its AI Gateway: the AI MCP Proxy plugin, which can either convert an existing REST API into MCP tools or proxy requests straight through to an existing MCP server, and the AI MCP OAuth2 plugin, which implements OAuth 2.0 for MCP server authentication. It’s a natural fit if you’re already running Kong for API management and want AI/MCP traffic under the same governance umbrella; it carries more operational weight than Bifrost if tunneling and MCP traffic are your only concern, since it’s a full API gateway with AI capabilities layered on rather than infrastructure purpose-built for agent traffic.

---

8. Permission Modes: What “Autonomous” Actually Means Right Now

One thing worth being precise about, since it changes what “the agent doesn’t halt” actually means in practice: Claude Code’s default behavior is not to silently run every MCP tool call, including create_tunnel. Most MCP clients — Cursor included — gate tool execution behind an approval prompt by default. Claude Code supports a full-bypass mode (--dangerously-skip-permissions, or --permission-mode bypassPermissions) that skips interactive approval for file edits, bash commands, and MCP tool calls for a session; Anthropic’s own documentation describes that mode as intended for isolated environments — containers, VMs, sandboxes without broader network access — where a compromised action can’t reach anything that matters, and the CLI shows a one-time warning before it will run.

Separately, as of August 14, 2026, Anthropic made a middle-ground “auto mode” the default permission behavior for Pro, Max, and Team plans rather than requiring manual approval for every action — the company’s stated reasoning is that a classifier catches the large majority of a planted dangerous command in testing, versus a much lower catch rate for human reviewers doing the same review. The practical upshot for the “agent opens a tunnel without stopping to ask” workflows described throughout this piece: whether that call runs silently or surfaces an approval prompt now depends on which permission mode a session is in, not just on whether the MCP server technically supports the operation.

---

9. Conclusion

The shift from human-driven CLI tunnel commands to agent-driven MCP tool calls is real and shipping today, but it’s less uniform across vendors than a first pass over this space suggests. rustunnel and Pinggy are the two vendors with genuine, dedicated tunnel-management MCP servers right now, both still labeled early or experimental by their own maintainers. ngrok and Cloudflare have taken the opposite-direction approach — gateway and platform tooling rather than agent-operated tunnel creation — which is a legitimate but different answer to a similar-sounding problem. And Anthropic’s own “MCP tunnels” research preview solves neither of those; it’s a private-network-to-Claude connectivity feature that happens to share a name with the whole category this piece covers, which is exactly the kind of naming collision worth flagging before it causes confusion in someone else’s architecture diagram.

---

Changelog

Corrections and additions made to the original draft, verified against rustunnel’s GitHub README and docs, Pinggy’s own MCP documentation and GitHub repo, Claude Code’s official MCP documentation, ngrok’s documentation, Cloudflare’s agent-setup docs, Kong’s plugin documentation, Maxim AI’s Bifrost documentation, and Anthropic’s Claude Platform documentation:

• Removed metadata scaffolding: the “Target Keywords” SEO line and the placeholder featured-graphic image reference, consistent with house style for this series.
• Biggest structural addition: split “MCP tunnel” into two distinct 2026 meanings — third-party agent-managed tunnels (what the rest of the piece covers) versus Anthropic’s own same-named “MCP tunnels” research-preview feature on Claude Platform, which runs in the opposite direction (connecting Claude to a private-network MCP server via a Cloudflare-backed outbound tunnel, Enterprise-only, research preview). This wasn’t mentioned at all in the original draft.
• rustunnel-mcp distribution corrected: the draft showed npx rustunnel-mcp; rustunnel-mcp is a native Rust binary distributed via Homebrew or built from source, not an npm package. All install examples rewritten to match.
• rustunnel MCP tool table corrected and completed: draft listed four tools (create_tunnel, list_tunnels, close_tunnel, get_connection_info); the documented set is six, adding list_regions and get_tunnel_history. Also corrected get_connection_info’s description — draft said it fetches “latency, region data, and request logs”; it actually returns the CLI command for cloud/sandbox agents to reconnect.
• Fabricated tunnel domain corrected: draft’s example URL (https://random-id.rustunnel.net) replaced with the real, region-scoped pattern (https://abc123.eu.edge.rustunnel.com).
• rustunnel pricing and regions added: free tier (3 tunnels, no custom subdomains), pay-as-you-go ($3/mo minimum + $0.10/GB), self-host (free); three hosted regions (eu/Helsinki, us/Hillsboro OR, ap/Singapore) — none of this was in the draft.
• Claude Code plugin install flagged as non-standard: /plugin install rustunnel is documented as-is by rustunnel’s own README, but it skips the /plugin marketplace add step that most Claude Code plugins require; added that caveat and a fallback path.
• Pinggy’s agent story substantially expanded and corrected: draft characterized Pinggy as “less focused on the agent managing the tunnel itself” — Pinggy in fact ships a dedicated, if experimental, MCP server (pinggy_mcp, 13 tools across auth/tunnels/file-sharing/tokens, OAuth 2.0 Device Authorization Grant) distinct from its separately-installable Agent Skill. Draft’s SSH-exposure example for Pinggy was kept since it’s still accurate for that narrower use case.
• ngrok’s first-party MCP story corrected: draft implied ngrok was adapting toward agent-driven tunnel creation (“API-driven tunnel creation… wrap into an MCP server”); ngrok’s actual documented first-party pattern is the reverse — an MCP gateway in front of a self-hosted MCP server, using Traffic Policy for auth/IP restriction. Agent-operated ngrok tunnel creation exists only via community MCP servers, not first-party tooling.
• Cloudflare Tunnel added: entirely absent from the original draft; added as its own comparison entry, noting Cloudflare’s agent tooling is platform-wide (Skills plugin covering Workers, storage, networking including Tunnel) rather than a dedicated tunnel-management MCP server.
• Bifrost command syntax corrected: draft used https://localhost:8080/mcp; the documented local scheme is http://, not https://.
• Bifrost performance claims sourced: added Bifrost’s own documented ~11 microsecond gateway overhead at 5,000 req/s and up to 92% input-token reduction via Code Mode, replacing the draft’s unsourced “500 tool definitions across 16 servers” framing with the vendor’s actual per-server estimate (10–30 tools/server).
• Kong section corrected and dated: draft said “Kong’s AI Gateway plugins” generically; named the actual plugins (AI MCP Proxy, AI MCP OAuth2) and the release (Kong Gateway 3.12, October 2025).
• NODE_TLS_REJECT_UNAUTHORIZED scope caveat added: draft’s warning note was accurate but incomplete — added that the flag disables TLS verification for all of Claude Code’s outbound traffic for the session (including api.anthropic.com), not just the local tunnel connection, and suggested NODE_EXTRA_CA_CERTS as a narrower-scoped alternative where feasible.
• Cursor vs. VS Code config schemas disambiguated: draft only covered Cursor and Windsurf; added Windsurf’s actual config path (~/.codeium/windsurf/mcp_config.json) and flagged that VS Code uses a different JSON schema (servers + "type": "stdio") at a different path, since reusing a Cursor-style config for VS Code silently fails.
• New section added on Claude Code permission modes: the draft’s “the agent does not halt” framing implied silent, unapproved autonomous execution by default; added context on Claude Code’s approval-gated default, the --dangerously-skip-permissions/bypassPermissions full-bypass mode and its documented isolated-environment intent, and the August 14, 2026 shift to a classifier-driven “auto mode” default for Pro/Max/Team plans.
• MCP protocol history added: exact launch date (November 25, 2024), the host/client/server terminology, the M×N-to-M+N framing, and the Build 2025 steering-committee milestone — none of this context was in the draft.
• Trimmed promotional framing (“massive leap in agentic capabilities,” “seamless infrastructure manipulation”) in line with house style for this series.