AI Agents Take the Wheel: MCP Servers and Tunnel Automation in 2026

The way developers interact with their environments has fundamentally changed. In 2026, AI isn’t just autocompleting boilerplate or generating regex strings — developers are handing terminal and environmental access to AI coding assistants outright. Through the Model Context Protocol (MCP), AIs in IDEs like Cursor and Windsurf, or terminal-native tools like Claude Code, can dynamically execute commands, read file systems, and configure networking.

One of the clearest examples of this shift is local network exposure. Historically, sharing a local server or testing a webhook meant context-switching: leaving the editor, wrestling with CLI commands, managing ports, and copying a temporary URL into a third-party dashboard. Today, tools like Pinggy ship dedicated MCP servers and Agent Skills that fold that work into the same conversation you’re already having with your AI assistant. You can tell it, “expose my local payment service and test the Stripe webhook,” and the agent handles the plumbing.

This guide covers how AI agents provision network tunnels through MCP, what Claude Code and Cursor actually do under the hood when they expose localhost, and what to verify before you trust an agent with that kind of access — including a few places where common write-ups (this one’s earlier draft included) get the specifics wrong.

1. The Model Context Protocol: The Universal USB-C for AI

Anthropic open-sourced MCP on November 25, 2024, aiming to solve what’s often called the “N×M integration problem”: without a shared standard, every AI agent needs a bespoke integration for every tool it talks to. MCP replaced that with a client–server architecture — an MCP client (the AI agent, e.g., Claude Code, Cursor, Windsurf) talks to an MCP server (a lightweight local or remote process exposing specific tools, resources, and prompts).

The “adopted across the industry by 2026” framing undersells how quickly that happened. OpenAI adopted MCP in March 2025, adding support first in its Agents SDK and joining MCP’s steering committee, with Responses API and ChatGPT desktop support following soon after. Google DeepMind confirmed MCP support in Gemini the following month. Microsoft and GitHub joined the steering committee at Build 2025, and AWS followed in November 2025. In September 2025, ChatGPT Developer Mode added full read/write MCP support. Then, on December 9, 2025, Anthropic transferred MCP’s governance to a newly formed Agentic AI Foundation under the Linux Foundation, with Anthropic, Block, and OpenAI as founding contributors and Google, Microsoft, AWS, and Cloudflare holding platinum member seats — the kind of neutral-governance move that tends to matter to enterprise procurement teams more than to individual developers, but it’s a real signal of how far the protocol has moved from being a single vendor’s project.

The growth numbers back that up: combined monthly downloads across MCP’s Python and TypeScript SDKs went from roughly 2 million at launch to 97 million by March 2026, and by the protocol’s next major spec release in July 2026, Anthropic reported downloads approaching half a billion a month, with both SDKs individually past a billion downloads all-time.

That July 2026 spec release — dated 2026-07-28 — is the largest revision to MCP since launch, and it changes some of the ground this article’s original draft was standing on. The headline change is that MCP moved from a stateful, connection-oriented protocol to a stateless one: the old initialize/initialized handshake and the Mcp-Session-Id header are gone, replaced by self-contained requests that carry their own protocol version and capabilities. That matters mainly for people building or auditing MCP servers, since it means a request can now be answered by any server instance behind an ordinary load balancer rather than needing sticky sessions. The same release promoted MCP Apps (a way for servers to deliver interactive, server-rendered UI rather than just text) and a Tasks extension (for long-running work) to first-class status, and tightened the protocol’s authorization model around OAuth 2.1 and OpenID Connect patterns — including closing an authorization-server mix-up hole by requiring clients to validate the iss parameter per RFC 9207. None of this changes what using a tunneling MCP server feels like day to day, but if you’re evaluating one, it’s worth knowing that guidance written against the pre-July-2026 protocol may describe session behavior that no longer applies. It’s also worth knowing that adoption hasn’t fully caught up to the security model on offer: industry surveys through mid-2026 put production MCP usage at well under half of organizations experimenting with it, and only a small fraction of public MCP servers currently implement the protocol’s OAuth 2.1 requirements — a gap worth keeping in mind before you point a tunneling MCP server at anything sensitive.

2. Pinggy’s AI Agent Tooling: What It Actually Is

Pinggy has established itself as a straightforward way to expose local servers to the internet, using SSH reverse tunneling to hand out temporary public HTTPS URLs without port forwarding or router configuration. A manual tunnel still looks like this:

ssh -p 443 -R0:localhost:3000 free.pinggy.io

-p 443 routes the SSH connection over the HTTPS port so it isn’t blocked by firewalls that only allow standard web traffic; -R0:localhost:3000 asks the Pinggy server to pick a random public port and forward it back to your local port 3000.

Pinggy ships two separate, independently installable pieces of AI-agent tooling on top of that — and this is where the earlier draft of this piece invented details rather than reporting them.

The Agent Skill is a bundle of instructions and reference material (SSH commands, CLI flags, SDK usage) that an agent reads and then executes itself using ordinary terminal access. It installs the same way any Agent Skill does:

npx skills add https://pinggy.io

This writes the skill into the client’s skills directory — ~/.claude/skills/pinggy/ for Claude Code — and needs nothing but Node.js.

The MCP server is a running process that exposes tunnel operations as callable tools, so the agent calls a tool directly instead of reconstructing a CLI command from documentation. This is the piece the original draft got wrong: it isn’t an npm package, and npx -y pinggy-mcp doesn’t install anything real. The actual server, pinggy_mcp, is a Python package published at github.com/Pinggy-io/pinggy_mcp (the project started life at github.com/abhimp/pinggy_mcp before moving to the Pinggy-io organization; both paths currently redirect). It requires Python 3.10+ and uv, and is run through uvx rather than installed globally. Pinggy’s own documentation is upfront that this is early software, describing it as “shared for early feedback, expect rough edges” — worth weighing before wiring it into a workflow you depend on.

Once connected, the server currently registers thirteen tools across four groups:

• Authentication — authenticate (starts an OAuth 2.0 device-flow login and returns a URL), check_authentication, get_profile, logout
• Tunnels — start_tunnel (HTTP, TCP, TLS, or UDP, with optional IP allow-listing, header rewriting, and the web debugger), stop_tunnel, list_tunnels, get_tunnel_info
• File sharing — share_directory, stop_file_share, list_file_shares, which expose a local folder through Pinggy’s existing --serve flag rather than a WebDAV implementation, contrary to what an earlier version of this description claimed
• Token management — for issuing and revoking the tunnel-scoped tokens the other tools use

Pinggy’s documentation gives a sense of the intended surface with example prompts like “expose my dev server on port 3000,” “open a TCP tunnel to localhost:22,” “share my ~/Downloads folder over the internet,” and “only allow traffic from 1.2.3.4 to my tunnel.” Every Pinggy doc page is also published as plain Markdown alongside the rendered HTML, and the whole site is summarized at pinggy.io/llms.txt, aimed squarely at agents reading the docs directly rather than scraping rendered pages.

3. Claude Code Localhost Exposure: Terminal-Native Automation

Because Claude Code runs natively in the shell and speaks MCP, it’s well positioned to handle this kind of environmental task. In practice, you might type:

claude "I need to share this app with the QA team — expose it and summarize the endpoints"

With the Pinggy MCP server registered, Claude Code can read your package.json to find the port, start the dev server, call the start_tunnel tool, and report back the resulting URL along with a summary of the routes it found — collapsing what used to be a multi-terminal chore into one exchange.

The permissions story around this is worth being specific about, since it’s changed since early 2026. By default, Claude Code asks for approval before every file write or shell command. The best-known way to skip that is the --dangerously-skip-permissions flag (often called “YOLO mode”), which disables every check — all allow, deny, and protected-path rules stop applying. It doesn’t protect against prompt injection: with every check off, an instruction hidden in a fetched web page or file executes the same as one you typed yourself, which matters directly for a networking-adjacent task like this, where the agent may be reading content that arrives over a tunnel it just opened. Claude Code also refuses to run with this flag if you’re on root or sudo, since the blast radius is too large. Anthropic’s own guidance is to run it only inside a container or sandboxed VM.

Since March 2026, there’s a middle ground: auto mode, a research-preview feature where a background classifier evaluates each tool call and blocks dangerous actions instead of prompting for every one. Anthropic built it after finding that people approve roughly 93% of permission prompts anyway, which was producing exactly the kind of approval fatigue that leads people to reach for the bypass flag on machines they shouldn’t. For a task like “start a dev server and open a tunnel to it,” auto mode is a more defensible default than disabling every check outright — the earlier draft’s advice to just “use flags to bypass permissions” for this kind of work is dated and worth updating.

4. Cursor Webhook Testing: Agent Mode and MCP Chaining

By 2026, “Agent Mode” — not Composer — is Cursor’s headline autonomous feature. Composer still exists, for tight multi-file edits with diff review, but Agent Mode runs the longer loop: it reads the codebase, edits files, runs terminal commands, watches the output, and iterates until the task is done. It’s this mode that chains MCP tools together for something like webhook testing.

A representative prompt: “write a webhook handler for Stripe’s payment_intent.succeeded event, expose it, configure the endpoint, and trigger a test payment.” With the Pinggy MCP server and Stripe’s official MCP server both connected, the agent can plausibly: write the route handler, start the local server, call start_tunnel to get a public URL, and use a Stripe tool to create or update a webhook endpoint object pointed at that URL. It’s worth being precise about where that workflow’s edges actually are, though: Stripe’s MCP server (hosted at mcp.stripe.com) can create and manage webhook endpoint objects through its generic execute tools, but consuming the live event stream isn’t exposed through MCP itself — triggering and observing a test event still typically goes through the Stripe CLI’s trigger command, which an agent with terminal access can run directly rather than through an MCP tool call. The end-to-end story is close to what a “the AI just does it” pitch implies, but the last mile — actually firing and confirming the test event — usually still runs as a shell command alongside the MCP calls, not purely through MCP.

5. Setting This Up

Claude Code — registered directly through the CLI, no config file to edit:

claude mcp add pinggy-mcp -- uvx --from git+https://github.com/Pinggy-io/pinggy_mcp.git pinggy-mcp
claude mcp list   # confirm it registered

Cursor — add a mcpServers block to ~/.cursor/mcp.json (global) or .cursor/mcp.json in the project root:

{
  "mcpServers": {
    "pinggy-mcp": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/Pinggy-io/pinggy_mcp.git", "pinggy-mcp"]
    }
  }
}

Claude Desktop and Windsurf use the same JSON shape as Cursor, but different file paths — ~/Library/Application Support/Claude/claude_desktop_config.json (macOS), %APPDATA%\Claude\claude_desktop_config.json (Windows), or ~/.config/Claude/claude_desktop_config.json (Linux) for Claude Desktop; ~/.codeium/windsurf/mcp_config.json for Windsurf.

VS Code is the odd one out: the top-level key is servers, not mcpServers, and each entry needs an explicit "type": "stdio":

{
  "servers": {
    "pinggy-mcp": {
      "type": "stdio",
      "command": "uvx",
      "args": ["--from", "git+https://github.com/Pinggy-io/pinggy_mcp.git", "pinggy-mcp"]
    }
  }
}

Conflating these — as the original draft’s single shared config example did — produces a file the intended client simply can’t read.

A few practical guardrails

• Scope the ports. Restrict the agent to a known range (say, 3000–8000) so it can’t accidentally expose something like a local database port.
• Watch the web debugger. Pinggy’s local inspector (typically on port 4300) shows every request and response passing through the tunnel — worth keeping open in a side panel while an agent is driving a webhook test.
• Keep tunnels ephemeral. Ask the agent to close the tunnel once its task passes, and treat the Pinggy MCP server’s “early and experimental” label as a real caveat, not boilerplate.
• Prefer auto mode or a container over a blanket permissions bypass when the task involves opening a network boundary, for the prompt-injection reasons above.

6. Where This Is Heading

The throughline across MCP’s growth curve, its stateless rewrite, and vendors like Pinggy formalizing agent tooling around a previously manual task is the same: AI is moving from generating code to operating the infrastructure that code runs on. That shift is real, but it’s still early — the protocol itself is a little over a year and a half old, the tunneling MCP servers built on it are explicitly labeled experimental by their own maintainers, and enterprise security practice (OAuth 2.1 adoption among public MCP servers, in particular) is visibly lagging the pace of adoption. None of that argues against using this tooling; it argues for verifying, the way this piece tries to, what a given agent-facing integration actually does before letting it run unsupervised.

---

Changelog

Corrections and additions made to the original draft, verified against primary sources (MCP’s official spec and blog, Pinggy’s documentation and GitHub repository, Anthropic’s Claude Code documentation and engineering blog, and Stripe’s MCP documentation):

• MCP launch and adoption timeline — the original text was correct that MCP launched in “late 2024” (November 25, 2024) but the “adopted across the industry by 2026” claim had no specifics. Added the verified sequence: OpenAI (March 2025), Google DeepMind (April 2025), Microsoft/GitHub joining the steering committee (Build 2025), AWS (November 2025), and the December 2025 governance transfer to the Agentic AI Foundation under the Linux Foundation.
• MCP growth and spec update — added the 2026-07-28 specification release, which the original draft didn’t mention at all: the move to a stateless protocol core, the deprecation of the initialize handshake and Mcp-Session-Id header, MCP Apps and the Tasks extension reaching first-class status, and tightened OAuth 2.1/OpenID Connect-aligned authorization. Added verified download figures (97M/month by March 2026, approaching 500M/month by July 2026) in place of no figures at all.
• Pinggy MCP install commands were fabricated. The draft’s claude mcp add pinggy npx -y pinggy-mcp and a matching Cursor JSON snippet using npx -y pinggy-mcp do not match any real package. The actual server, pinggy_mcp, is a Python package requiring Python 3.10+ and uv, run via uvx against its GitHub source, and explicitly labeled experimental by its maintainers. Replaced with verified install commands for Claude Code, Cursor, Claude Desktop, Windsurf, and VS Code, sourced from Pinggy’s own documentation.
• Pinggy tool count and behavior were invented. Added the real tool inventory — 13 tools across authentication, tunnels, file sharing, and token management — and the OAuth 2.0 device-flow login model, since the original description was generic and unverifiable. Also corrected an unrelated but related error from an earlier pass of this piece: file sharing is exposed through Pinggy’s existing --serve flag, not a WebDAV implementation.
• “Bypassing permissions safely” was vague and slightly out of date. Replaced the general “you can use flags to bypass permissions” language with the specifics of --dangerously-skip-permissions (what it disables, that it’s blocked under root/sudo, that it does not protect against prompt injection) and added auto mode, the classifier-based middle ground Anthropic shipped in March 2026, which the original draft predates.
• Cursor’s headline feature was misnamed. The draft called Composer the interface driving autonomous multi-tool workflows; as of 2026 that’s Agent Mode, with Composer now the more tightly scoped multi-file diff-review tool. Corrected throughout Section 4.
• The Stripe webhook example overstated what MCP alone can do. Added the real Stripe MCP server (mcp.stripe.com) and the specific limitation that it can create/manage webhook endpoint objects but doesn’t expose the live event stream — triggering a test event still runs through the Stripe CLI, typically via the agent’s terminal access rather than an MCP tool call.
• Metadata stripped; author/date footer and tracking elements removed for clean republication.