Letting AI Agents Manage Your Local Tunnels

For years, the friction of exposing a local dev server to the internet sat outside the reach of AI coding assistants. You could ask an agent to write a webhook handler, but the moment you needed a public URL — for Stripe, a mobile client, a client demo — you left the chat, opened a second terminal, ran a tunneling command, copied a URL, and pasted it somewhere else. The code got automated years ago. The networking glue did not, until the Model Context Protocol gave agents a tool call that reaches out to the tunnel itself.

This isn’t a finished revolution — most developers still run cloudflared or ssh -p 443 -R0:localhost:3000 a.pinggy.io by hand, and the MCP servers that automate this are, by their own maintainers’ admission, early. But the pieces are real, they’re documented, and they’re worth understanding before you wire one into an agent with terminal access.

The bottleneck this replaces

Testing a webhook integration was never about the code. Stripe, Shopify, or a GitHub App needs a public URL to send events to, and your dev server only listens on localhost. The traditional loop:

1. Start the local server.
2. Open a second terminal.
3. Run a tunneling command and wait for it to connect.
4. Copy the generated URL.
5. Paste it into a third-party dashboard.
6. Send a test event.
7. Repeat steps 3–6 every time the tunnel restarts and the URL changes.

None of that is hard, but it breaks flow state, and it’s exactly the kind of mechanical, multi-step task that a tool-calling agent can absorb — provided the tunnel is reachable as a tool rather than a memorized shell command.

MCP is the standard that makes this possible

Anthropic open-sourced the Model Context Protocol on November 25, 2024, as a standard for connecting AI applications to the systems where data and tools live. Before MCP, wiring a given model to a given external tool meant a bespoke integration for every model–tool pair — the “N×M” problem, where N models each need a custom connector to M tools. MCP collapses that to one server per tool that any MCP-aware client can use.

The architecture has three parts:

• Host — the user-facing application: an IDE, a desktop chat client, a custom agent.
• Client — the piece inside the host that speaks MCP and routes calls to servers.
• Server — the external process exposing tools (executable actions), resources (contextual data), and prompts (reusable templates) to the client.

Messages are exchanged as JSON-RPC 2.0, and the request/response flow borrows ideas from the Language Server Protocol — the same pattern that lets any editor talk to any language’s autocomplete backend without a custom integration per pair.

The transport layer has already changed twice

MCP’s first release (2024-11-05) shipped with two transports: stdio for local, single-client processes, and HTTP+SSE for remote servers. The 2025-03-26 revision replaced HTTP+SSE with Streamable HTTP — a single endpoint that supports stateless deployment behind load balancers and resumable sessions, which the original dual-endpoint SSE design handled poorly. SSE is retained only for backward compatibility, and several vendors have already set shutoff dates for it.

That wasn’t the last word. On July 28, 2026 — a little over a week before this was written — the protocol’s maintainers shipped the 2026-07-28 revision, described by lead maintainer David Soria Parra as the largest change to the spec since it launched. It removes the protocol-level session handshake entirely, making MCP stateless by default: a server no longer needs to track a client across calls, which means any request can be answered by any instance behind ordinary HTTP infrastructure rather than requiring session affinity. It also formalizes an extensions framework (the mechanism behind MCP Apps, which let a tool call render its own UI) and a feature-lifecycle policy guaranteeing at least twelve months between a capability being deprecated and actually removed. Existing 2025-11-25 clients and servers keep working — the new revision is opt-in on upgrade, and a compliant server can answer both revisions from one endpoint.

Adoption moved fast

OpenAI added MCP support to its Agents SDK on March 26, 2025 (“available today,” per Sam Altman, with Responses API and ChatGPT desktop support following). Google DeepMind confirmed Gemini would adopt MCP the following month. By December 9, 2025, Anthropic donated the protocol’s governance to the Agentic AI Foundation, a directed fund under the Linux Foundation, co-founded by Anthropic, Block, and OpenAI, with AWS, Google, Microsoft, Cloudflare, and Bloomberg as platinum founding members. At the time of that handoff, MCP had more than 10,000 active public servers and over 97 million monthly SDK downloads across its Tier 1 SDKs; by the July 2026 spec release, the maintainers reported that figure approaching half a billion monthly downloads, with the TypeScript and Python SDKs each having crossed a billion total downloads. The governance model stayed community-run — membership in the technical process is tied to individuals, not the companies that employ them.

Skills and MCP servers are two different things

The tunneling vendors covered below both use a second, related mechanism worth distinguishing from MCP itself: Agent Skills. A skill is packaged instructions and reference material — CLI flags, SDK usage, example prompts — that an agent reads once and then executes itself using ordinary terminal access. An MCP server, by contrast, is a running process the agent calls directly as a tool, without reconstructing a command from documentation. They’re published under a shared community standard (the skills CLI, distributed via npx skills add <url>) and installed into an agent’s skills directory — for Claude Code, that’s ~/.claude/skills/<name>/. Vendor guidance across the board is the same: start with the skill if you want the agent to understand the tool; add the MCP server once you want the agent operating it autonomously.

Pinggy’s skill and MCP server

Pinggy ships both, and they can be installed independently.

The skill:

npx skills add https://pinggy.io

This pulls the manifest from https://pinggy.io/.well-known/skills/ and writes the skill files into the agent’s skills directory. The only prerequisite is Node.js.

The MCP server — source at github.com/Pinggy-io/pinggy_mcp — requires Python 3.10+ and uv:

curl -LsSf https://astral.sh/uv/install.sh | sh

Nothing installs globally; each client runs pinggy-mcp on demand through uvx. For Claude Code, registration is a CLI command rather than a config file:

claude mcp add pinggy-mcp -- uvx --from git+https://github.com/Pinggy-io/pinggy_mcp.git pinggy-mcp

Claude Desktop, Cursor, and Windsurf use a mcpServers key in a JSON config file (paths differ by client and OS); VS Code is the odd one out, using a top-level servers key instead. Worth noting up front: Pinggy’s own documentation labels the MCP server “early and experimental” and asks for feedback rather than presenting it as production-hardened.

Once connected, Pinggy’s documented example prompts give a sense of the actual surface — not a hypothetical one:

• “Expose my dev server on port 3000.”
• “Open a TCP tunnel to localhost:22.”
• “Share my ~/Downloads folder over the internet.”
• “List my active tunnels.”
• “Only allow traffic from 1.2.3.4 to my tunnel.”
• “Stop the tunnel.”

A detail aimed squarely at agent consumption rather than humans: every Pinggy doc page is also published as plain Markdown at the same path with an index.md suffix, and the whole site is summarized at pinggy.io/llms.txt — letting an agent read the docs directly instead of scraping rendered HTML.

Cloudflare’s MCP surface is broader than “tunnels”

Cloudflare’s own MCP servers don’t center on cloudflared specifically — they cover the entire Cloudflare API. The flagship one, the Cloudflare API MCP server (github.com/cloudflare/mcp, hosted at https://mcp.cloudflare.com/mcp), exposes over 2,500 endpoints across DNS, Workers, R2, and Zero Trust through just two tools: search() and execute(). Rather than loading a schema for every endpoint, the model writes JavaScript against a typed representation of the OpenAPI spec, and that code runs inside an isolated Dynamic Worker sandbox — Cloudflare’s “Code Mode” pattern. The token math is the reason this matters: native MCP exposing all 2,594 endpoints with full schemas would cost roughly 1.17 million tokens just to list the tools; Code Mode’s two-tool approach costs about 1,000 tokens regardless of catalog size.

Beyond that general-purpose server, Cloudflare runs targeted, domain-specific MCP servers — a Documentation server, a Workers Bindings server, an Observability server, a Radar server for internet traffic data, an Audit Logs server, a DNS Analytics server, and others, each at its own subdomain (e.g. docs.mcp.cloudflare.com/mcp). There isn’t a standalone “Tunnel” MCP server in that list; managing a Cloudflare Tunnel — listing active tunnels, checking status, updating ingress rules — happens through the general-purpose API MCP server’s search/execute pattern against the Tunnel and Zero Trust endpoints, the same way any other Cloudflare resource does. If you want an agent to bind a new preview environment to a subdomain, it’s reaching into the same 2,500-endpoint surface, not calling a bespoke tunnel-specific tool.

Cloudflare also bundles its MCP servers with contextual skills and slash commands via a Cloudflare Skills plugin (github.com/cloudflare/skills), installable through the Claude Code plugin marketplace (/plugin marketplace add cloudflare/skills), the Cursor Marketplace, or the same npx skills add CLI used by Pinggy.

MCP Server Portals: the actual enterprise control layer

Cloudflare’s answer to “you can’t hand an LLM your API token unsupervised” is MCP server portals, part of Cloudflare One’s Zero Trust platform (internally, some API paths still carry the product’s earlier name, Agents Gateway). A portal centralizes multiple MCP servers behind a single HTTP endpoint protected by Cloudflare Access. What it actually does, concretely:

• Authentication: users log in to the portal through Cloudflare Access via their identity provider; the portal separately prompts for OAuth against any upstream server that requires it.
• Curated tool exposure: admins can turn off individual tools or prompts per server, or invert the model into an allowlist where only explicitly enabled tools are visible — useful when an upstream server exposes far more than a given team should touch.
• Code Mode by default: every portal collapses all upstream tools into a single code tool that the agent writes JavaScript against, run in an isolated Dynamic Worker — this keeps context-window usage roughly constant no matter how many servers are aggregated behind the portal.
• Logging: per-request logs (time, status, server, tool, duration) are available in the dashboard, with Logpush export to a SIEM available on Enterprise plans.
• Optional Gateway routing: portal traffic can be routed through Cloudflare Gateway for DLP scanning, so a tool call or a tool response containing something like a credential or financial data can be blocked before it reaches the model or the upstream server.

The honest caveat, straight from Cloudflare’s own docs: independent MFA, purpose-justification prompts, and temporary-authentication policies do not apply to MCP servers authorized through a portal, even if those policies are configured elsewhere in the same Access application. So “portal” gets you centralized OAuth, curated tools, and DLP-capable logging — real controls — but it isn’t a drop-in replacement for every Access policy feature you might already rely on for human users.

A grounded webhook-testing example

Stripe is a common target for this workflow, and it’s a useful one to get precisely right, because its MCP server’s capabilities don’t map cleanly onto “the agent does everything.”

Stripe hosts its MCP server at https://mcp.stripe.com. Unusually for a hosted MCP server, it supports both the standard interactive OAuth flow and a restricted API key passed as a bearer token — a documented, supported path for headless or autonomous agents rather than a gap you have to work around. Its tools cover account info, refunds, resource search and fetch, documentation search, and integration planning, plus generic stripe_api_read, stripe_api_write, and API-search tools that reach most of the REST surface without bloating the tool list.

Here’s the boundary that matters for a tunnel-testing workflow: an agent can create or update a webhook endpoint object — including pointing its URL at a fresh tunnel — through the generic write tool. It cannot subscribe to or consume the live webhook event stream through MCP itself; reacting to incoming events is still a REST/webhook infrastructure concern that lives outside the protocol. So a realistic version of the tutorial looks like:

1. Ask the agent to start the local server and expose it with the Pinggy or Cloudflare MCP tool.
2. Ask it to update the Stripe webhook endpoint’s URL to the new tunnel address, via the Stripe MCP write tool.
3. Trigger a test event from the Stripe dashboard or CLI yourself, or have the agent do it if you’re using the Stripe CLI’s own agent tooling.
4. Confirm your local server received and parsed it.

Stripe’s own documentation recommends enabling human confirmation on its write tools and exercising caution when combining the Stripe MCP server with others, specifically flagging prompt-injection risk — sound advice for any MCP server that can move money or reconfigure billing. (Pinggy, for what it’s worth, publishes its own guide for testing Stripe webhooks — useful groundwork whether or not you’re doing it through an agent.)

Where the agentic IDEs actually stand, mid-2026

The three editors most associated with this workflow have all shifted since they were last compared:

• Cursor (built by Anysphere) is in the middle of the largest venture-backed startup acquisition on record. Cursor’s November 2025 Series D valued it at $29.3 billion; SpaceX secured an option to acquire Anysphere in April 2026, and on June 16, 2026 the companies signed a definitive all-stock agreement valuing Anysphere at $60 billion, intended to fold Cursor into SpaceX’s (by then xAI-merged) AI ambitions. As of this writing the deal has not closed — it’s expected to complete in Q3 2026, pending regulatory review — so Cursor continues operating independently for now.
• Windsurf started as Codeium’s agentic IDE. In July 2025, Google DeepMind hired away Windsurf’s CEO, a co-founder, and key researchers in a roughly $2.4 billion non-exclusive licensing-plus-hiring arrangement that left Google with no equity in the company; days later, on July 14, 2025, Cognition AI (maker of the autonomous coding agent Devin) acquired the remaining product, IP, trademark, and roughly 210 employees, reportedly for around $250 million. On June 2, 2026, Cognition rebranded the product Devin Desktop via an over-the-air update — the underlying IDE, plans, and extensions carried over unchanged, with the local agent now branded Devin Local and cloud-agent access folded into the paid tier.
• Claude Code now runs across six surfaces sharing one engine: the original terminal CLI, a VS Code extension, a JetBrains plugin, a standalone desktop app, a web surface at claude.ai/code (launched October 20, 2025), and a Slack integration, with mobile serving as a control surface for remote sessions. Configuration, project memory (CLAUDE.md), and MCP server connections are shared across the local surfaces — a server registered once is available from the terminal, the IDE, or the desktop app.

All three are MCP clients, which is the actual point: the tunnel doesn’t care which of these you’re driving it from, and a Pinggy or Cloudflare MCP server configured once should behave the same way regardless of which editor issued the tool call — modulo each client’s own config-file quirks.

Security considerations

None of the above removes the need for judgment. VS Code’s own MCP documentation is blunt about it: local MCP servers can run arbitrary code on your machine, so only add ones from sources you trust and have actually reviewed. That’s a reasonable default for Pinggy’s server specifically, given its maintainers’ own “early and experimental” label.

There’s a broader failure mode worth knowing about even if it’s not specific to tunneling servers: agents tend to treat MCP tool output as trusted data rather than untrusted input, the same way they’d treat a system prompt rather than a stranger’s message. Security researchers have demonstrated this concretely against other MCP integrations — for example, injecting fake error events into a project’s error-tracking service so that an MCP-connected coding agent “fixes” a bug that doesn’t exist by running attacker-supplied instructions. The lesson generalizes: any MCP server your agent trusts is effectively part of your attack surface, whether or not the vendor calls it experimental. Applying least-privilege scoping — IP allowlisting on the tunnel itself, curated tool exposure through something like a Cloudflare portal, human confirmation on write actions — is the mitigation available today, not a solved problem.

The bottom line

Tunnel management becoming an MCP tool call is a real, working pattern today, not vaporware — Pinggy’s server and skill, Cloudflare’s API MCP server and portals, and Stripe’s MCP server are all live, documented, and independently verifiable against their own docs. But “early and experimental” is the vendor’s own description of the piece doing the actual tunneling, the protocol underneath just went through its biggest breaking change since launch, and the IDEs orchestrating all of it are mid-acquisition or mid-rebrand. If you’re wiring this into a workflow today, treat it the way you’d treat any new piece of infrastructure tooling: read what the server actually does before granting it network access, scope what it can reach, and don’t assume “the agent asked nicely” is the same thing as “this is safe to expose.”

---

Changelog

This piece was rewritten from an earlier draft. Corrections and additions, checked against primary sources:

1. Removed the “obsolete”/“revolution” framing. The original draft presented AI-managed tunnels as an already-completed shift in how all developers work. Reframed as an emerging, genuinely useful pattern that most developers still don’t use day to day — consistent with Pinggy’s own MCP server being labeled “early and experimental” (pinggy.io/docs/ai_agents/) rather than production-ready.

2. Corrected the Pinggy skill install command. The draft used npx skills add pinggy/skills. Pinggy’s own documentation specifies npx skills add https://pinggy.io, installing from the manifest at pinggy.io/.well-known/skills/. (pinggy.io/docs/ai_agents/)

3. Corrected and completed the Pinggy MCP server details. Added the real GitHub source (github.com/Pinggy-io/pinggy_mcp), the Python 3.10+/uv prerequisites, the actual claude mcp add registration command, and the fact that VS Code uses a servers config key while Claude Desktop/Cursor/Windsurf use mcpServers — none of which appeared in the original draft. Replaced the illustrative, unsourced example prompt with Pinggy’s own documented list. (pinggy.io/docs/ai_agents/)

4. Replaced the vague “Cloudflare MCP server” section with verified specifics. Added the actual architecture (search()/execute() Code Mode pattern, 2,500+ endpoints, the ~1,000-vs-1.17M token comparison), the real list of domain-specific servers, and a correction: there is no dedicated “Tunnel” MCP tool as the original draft implied — tunnel and DNS management happens through the general-purpose API MCP server against the same endpoint catalog as everything else. (developers.cloudflare.com/agents/model-context-protocol/cloudflare/servers-for-cloudflare/)

5. Rewrote the “Cloudflare MCP Server Portals” section from an unverified sketch into a sourced one, including the real feature set (Access-based OAuth, tool/prompt allowlisting and aliasing, Code Mode by default, optional Gateway/DLP routing, Logpush on Enterprise) and an important caveat the original omitted entirely: independent MFA, purpose justification, and temporary authentication are not enforced for servers authorized through a portal. (developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/)

6. Corrected the MCP origin and mechanics. Confirmed the November 25, 2024 release date, the N×M framing, and the host/client/server architecture against Anthropic’s own announcement, and added the JSON-RPC 2.0 / LSP-derived message design, which the original omitted. (anthropic.com/news/model-context-protocol)

7. Added the transport history the original draft didn’t mention at all: the 2025-03-26 spec revision deprecating HTTP+SSE in favor of Streamable HTTP, and — new since any comparable prior coverage — the 2026-07-28 revision that makes MCP stateless by default, published one week before this piece. (modelcontextprotocol.io/specification/2026-07-28/changelog; blog.modelcontextprotocol.io/posts/2026-07-28/)

8. Added MCP governance and adoption facts absent from the original: OpenAI Agents SDK support (March 26, 2025), Google DeepMind/Gemini support (April 2025), and Anthropic’s December 9, 2025 donation of MCP to the Agentic AI Foundation under the Linux Foundation, with current adoption figures. (anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation)

9. Rewrote the Stripe webhook tutorial to reflect what the Stripe MCP server actually supports. The original assumed unlimited agent control over Stripe’s webhook system. Corrected: agents can create/update a webhook endpoint’s target URL via the generic write tool, but cannot subscribe to or consume the live event stream through MCP — that remains a REST concern. Added Stripe’s own guidance on human confirmation and prompt-injection caution. (docs.stripe.com/mcp; scalekit.com/blog/stripe-mcp-vs-api)

10. Corrected the IDE landscape entirely, which the original didn’t address. Cursor/Anysphere: added the SpaceX acquisition, corrected to reflect a signed but not-yet-closed $60B deal (signed June 16, 2026, expected close Q3 2026), not a completed transaction. Windsurf: corrected the acquirer and dates — Cognition AI acquired Windsurf’s IP and team on July 14, 2025 for roughly $250M (not “December 2025”), following Google DeepMind’s earlier reverse-acquihire of its CEO and senior team, and the product was rebranded Devin Desktop on June 2, 2026. Claude Code: confirmed the six-surface description (terminal, VS Code, JetBrains, desktop, web at claude.ai/code launched October 20, 2025, and Slack). (techcrunch.com/2026/06/16/spacex-to-acquire-cursor-for-60b-in-stock-days-after-blockbuster-ipo/; digitalapplied.com/blog/windsurf-becomes-devin-desktop-ide-migration-2026)

11. Added a grounded security section in place of a generic reassurance. Cited VS Code’s own MCP security guidance and a documented real-world attack pattern (fake Sentry events used to hijack an MCP-connected coding agent) to illustrate why MCP tool output shouldn’t be treated as automatically trustworthy. (code.visualstudio.com/docs/agent-customization/mcp-servers; pinggy.io/blog/agentjacking_ai_coding_agents_sentry_mcp/)

12. Removed unverifiable or fabricated specifics from the original draft that could not be confirmed against any primary source, including the implied dedicated Cloudflare “Tunnel Management” tool and WAF-audit tool calls, and did not repeat them elsewhere in vaguer form.

13. Removed SEO-style repetition and “junior DevOps engineer living inside your editor” framing, consistent with house style for this blog — replaced with a closing section that states the trade-offs plainly rather than declaring the transition complete.