Der AI-Agent-Workflow: Native MCP-Unterstützung in lokalen Tunneln

Das Jahr 2026 hat eine hochspezifische, aber zunehmend verbreitete Anforderung in Entwickler-Workflows eingeführt: KI-Agenten, die lokale Netzwerktunnel öffnen, verwalten und abbauen können, ohne dass ein Mensch URLs zwischen einem Terminalfenster und einer Chat-Oberfläche kopiert. Da Coding-Assistenten wie Claude Code, Cursor und Windsurf zunehmend Terminal- und Umgebungszugriff übernehmen, wird ihre Fähigkeit, direkt mit lokaler Infrastruktur zu interagieren, zu einem echten Engpass für alle, die Webhooks testen oder einen Entwickler-Server teilen.

Anstatt auf herkömmliche Port-Forwarding-Methoden zu setzen, die für menschliche Operatoren gedacht sind, liefern einige Tunneling-Dienste — rustunnel und Pinggy vor allem — jetzt spezielle Model Context Protocol (MCP)-Server, die es einem Agenten erlauben, Tunnel direkt zu steuern. Anthropic hat ebenfalls ein eigenes Produkt unter dem Namen “MCP tunnels” veröffentlicht, das jedoch ein anderes Problem löst als das hier behandelte — mehr dazu weiter unten.

Dieses Handbuch erklärt, was ein MCP-Tunnel eigentlich ist (es gibt jetzt zwei unterschiedliche Bedeutungen dieses Begriffs), was rustunnel’s und Pinggy’s Agententools wirklich offenlegen, wie sich die Installationsanweisungen je nach Client unterscheiden und wo MCP-Gateways wie Bifrost passen, wenn man mehr als ein paar Server betreibt.

---

1. Die Entwicklung des AI-Agent-Workflows

Der alte Ablauf ist nach wie vor gültig: einen Reverse-Tunnel über die CLI starten, auf die Verbindung warten, die generierte öffentliche URL kopieren und in ein Dashboard sowie ein Chat-Fenster einfügen. Für einmalige Zwecke ist das okay, aber es unterbricht den autonomen Fluss eines Agents, der bereits das Terminal steuert — wenn Claude Code einen Webhook-Endpunkt implementiert und testet, sollte er nicht anhalten und einen Menschen nach einer öffentlichen URL fragen müssen.

Das Model Context Protocol, das Anthropic am 25. November 2024 open-sourcte, hat das geändert. MCP definiert drei Rollen: einen Host (die KI-Anwendung — Claude Code, Cursor, Claude Desktop, Windsurf, inzwischen auch ChatGPT und GitHub Copilot), einen Client (die Protokollverbindung, die der Host zu einem Server hält) und einen Server (ein Prozess, der eine bestimmte Reihe von Tools, Ressourcen oder Prompts bereitstellt). Vor der Einführung eines gemeinsamen Protokolls war die Verbindung von M verschiedenen KI-Anwendungen zu N verschiedenen Tools fast eine M×N-Angelegenheit; MCP reduziert das auf ungefähr M+N, da jede Seite nur einmal das Protokoll implementieren muss. Die Akzeptanz war schnell — Microsoft und GitHub traten dem MCP-Steering-Committee auf der Build 2025 bei, und OpenAI fügte MCP-Unterstützung in sein Agents SDK und Responses API im selben Jahr hinzu.

Speziell beim Tunneln bedeutet das, dass ein Agent direkt ein Tool wie create_tunnel aufrufen kann und strukturierte Daten zurückbekommt (z. B. eine öffentliche URL, eine Tunnel-ID, einen Status), anstatt eine Shell zu verwenden und stdout zu parsen.

---

2. Das “MCP Tunnel” — Zwei unterschiedliche Dinge im Jahr 2026

Hier war eine Überarbeitung notwendig: “MCP tunnel” bezieht sich jetzt auf zwei wirklich unterschiedliche Architekturen, und eine Verwechslung führt dazu, dass Nutzer das falsche Tool verwenden.

2a. Agenten-gesteuerte Tunnel (der Großteil dieses Artikels)

Dieses Muster bauen rustunnel und Pinggy: Ein Client eines Tunneling-Anbieters läuft neben einem lokalen Dienst und wählt outbound über TLS zu einem öffentlichen Edge-Server. Der Agent ruft ein MCP-Tool auf, um diese Tunnel zu öffnen, aufzulisten und zu schließen. Traffic-Fluss: lokaler Rechner → öffentliches Internet, der KI-Agent ist der Operator.

• Keine inbound-Regeln. Es wird nichts offen gelegt, bis der Client outbound verbindet; Firewalls, die HTTPS outbound erlauben, müssen nicht angepasst werden.
• Eingeschränkte Offenlegung. Im Gegensatz zu einem VPN offenbart ein Tunnel nur eine Service-Instanz, nicht das ganze Netzwerk.
• Verschlüsselter Transport, meist mit Authentifizierung des Tunnel-Anbieters (OAuth, Bearer-Tokens oder API-Tokens), die oben aufliegen.

2b. Anthropic-eigene “MCP tunnels” (ein anderes Produkt, in entgegengesetzter Richtung)

Anthropic bietet eine Forschungs-Vorschau-Funktion auf der Claude Platform (ehemals Claude Developer Platform / Console), die wörtlich MCP tunnels heißt, und löst das umgekehrte Problem: Verbindung Claude → internes MCP-Backend, ohne inbound Ports zu öffnen. Traffic-Fluss: Claude → privates Netzwerk.

Architektur: Ein leichter Tunnel-Stack (Proxy plus cloudflared-Container) läuft im Netzwerk und öffnet eine outbound-Verbindung zu Cloudflare, das von Anthropic als Subprozessor genutzt wird. Deployment erfolgt via Helm (Kubernetes) oder Docker Compose, ein CA-Zertifikat wird im Claude Console registriert, und der private MCP-Server ist erreichbar unter https://<subdomain>.<your-tunnel-domain>/mcp — nur für Claude Managed Agents und die Messages API sichtbar, niemals öffentlich im Internet. Der Proxy ist bewusst konservativ: standardmäßig verbindet er nur mit RFC 1918-Adressbereichen (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).

Stand heute ist MCP-Tunnel in der Forschungs-Vorschau, nur auf Anfrage für Organisationen im Claude Enterprise-Plan verfügbar und ohne Garantie auf Betriebszeit oder Support — hängt von Cloudflares Verfügbarkeit ab. Wenn Sie eine Architektur bauen, bei der der Agent in eine private Datenbank eintaucht, lohnt es sich, vor der Nutzung eines Drittanbieter-Workarounds Zugriff anzufragen; wenn Sie den Workflow “Agent öffnet mein Laptop für eine Demo oder Webhook-Test” meinen, ist Abschnitt 2a relevant.

---

3. rustunnel und der Aufstieg des Agenten-Operators

Die meisten Tunneling-Dienste gehen noch immer davon aus, dass ein Mensch am Terminal sitzt. rustunnel — ein selbstgehosteter, unter der AGPLv3 lizenzierter Tunnel-Server in Rust, mit optionalem Pay-as-you-go-Managed-Service — wurde mit dem Agenten als primärem Operator entwickelt. Es ist ein wirklich kleines Projekt (635 GitHub-Sterne), aber die MCP-Integration ist außergewöhnlich gut dokumentiert.

Wie es tatsächlich ausgeliefert wird

Eine Korrektur vorweg: rustunnel’s MCP-Server (rustunnel-mcp) ist kein npm-Paket, das man mit npx ausführt. Es ist eine native Rust-Binary, verteilt wie der rustunnel CLI-Client — via Homebrew (brew tap joaoh82/rustunnel && brew install rustunnel) oder gebaut aus dem Quellcode mit cargo build --release -p rustunnel-mcp. Es spricht MCP über stdio.

Das Tool deckt den gesamten Tunnel-Lifecycle ab — sechs Tools, nicht vier:

Tool	Beschreibung
create_tunnel	Öffnet einen Tunnel und gibt die öffentliche URL zurück — HTTP/TCP/UDP, P2P, Load-Balanced Pools mit Health Checks
list_tunnels	Listet alle aktiven Tunnel auf
close_tunnel	Erzwingt das Schließen eines Tunnels per ID
list_regions	Listet verfügbare Serverregionen
get_connection_info	Gibt den CLI-Befehl für Cloud- oder Sandbox-Agenten zurück
get_tunnel_history	Holt vergangene Tunnel-Aktivitäten

Der gehostete Service läuft in drei Regionen — eu (Helsinki), us (Hillsboro, OR) und ap (Singapur) — und der Client wählt automatisch die nächstgelegene, außer man fixiert sie. Preise: kostenlos bis zu 3 Tunnels ohne eigene Subdomains, Pay-as-you-go ab 3 USD/Monat plus 0,10 USD/GB (unbegrenzte Tunnels, eigene Subdomains), oder selbst gehostet kostenlos. Selbstgehostete Deployments können optional Prometheus-Metriken und ein JSON-Lines-Audit-Log bereitstellen — beides Konfigurationsoptionen auf dem Server, nicht standardmäßig aktiviert.

Der autonome Loop, korrigiert

Das Szenario, das in einem Entwurf dieses Artikels beschrieben wurde — Claude Code soll einen Stripe Webhook-Handler implementieren, ihn exponieren und ein Dashboard-Skript aktualisieren — ist real und funktioniert ungefähr so, mit zwei Korrekturen: die Tunnel-URL ist regionspezifisch (https://abc123.eu.edge.rustunnel.com), nicht eine generische .rustunnel.net-Domain, und get_connection_info liefert nicht “Latenz, Region-Daten und Request-Logs” — laut rustunnel-Dokumentation gibt es den CLI-Befehl zurück, den ein Cloud- oder Sandbox-Agent braucht, um sich erneut zu verbinden, was eine engere Aufgabe ist.

Installation

Drei dokumentierte Wege, in aufsteigender manueller Aufwand:

Claude Code Plugin (am einfachsten, laut rustunnel README):

/plugin install rustunnel

Das Plugin fragt einmal nach Serveradresse und API-Token, speichert sie und startet den MCP-Server im Hintergrund — kein .mcp.json-Edit nötig. Achtung: Das unterscheidet sich vom üblichen zweistufigen Pattern der meisten Claude Code Plugins (/plugin marketplace add <owner>/<repo> gefolgt von /plugin install <name>@<marketplace>). Falls der Einzeiler bei Ihrer Version nicht funktioniert, verwenden Sie /plugin marketplace add joaoh82/rustunnel und prüfen Sie plugins/claude-code/ im Repo auf den genauen Plugin-Namen.

Manuelle stdio-Registrierung:

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 (oder Windsurf, Cline — gleiche JSON-Struktur), direkt bearbeitet:

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

Für Cursor liefert rustunnel auch einen “Add to Cursor”-Deep-Link im README, der diese Konfiguration vorausfüllt — du musst nur noch dein API-Token einfügen.

---

4. Vergleich des Tunneling-Ökosystems 2026

ngrok

ngroks eigene MCP-Story ist nicht die eines Agenten-gesteuerten Tunnel-Managements — es ist das Gegenteil. ngrok’s dokumentiertes Muster ist die Nutzung von ngrok als MCP-Gateway: Du betreibst den ngrok-Agenten neben deinem eigenen MCP-Server, deklarierst einen internen Agent-Endpunkt und nutzt ngrok’s Traffic-Policy-Engine, um Clients (z. B. nur die IP-Bereiche von Anthropic) zu authentifizieren und zu beschränken. Das ist eine Sicherheits- und Überwachungsschicht vor einem bereits laufenden MCP-Server, eher vergleichbar mit Kong oder Bifrost (Abschnitt 7) als mit rustunnel. Wenn du einen Agenten willst, der dein ngrok-Konto steuert — Tunnel erstellt und abbaut — gibt es das auch, aber nur über Community-Server (z. B. ngrok-mcp auf GitHub oder Composio’s ngrok-Toolkit), nicht mit erster Party.

Pinggy

Ein Entwurf dieses Artikels beschrieb Pinggy als “sehr effektiv für das Exposen von Tools, aber weniger auf das Agenten-Management des Tunnels fokussiert”. Das unterschlug die aktuelle Agenten-Story von Pinggy: Es liefert zwei separate Tools — eine Agenten-Fähigkeit (npx skills add https://pinggy.io, Referenzdokumente, die der Agent vor dem Ausführen seiner Befehle liest) und einen eigenständigen, Early-Access MCP-Server (pinggy_mcp, Python/uv-basiert), der dreizehn Tools bereitstellt: Authentifizierung, Tunnelmanagement (start_tunnel, stop_tunnel, list_tunnels, get_tunnel_info), WebDAV-Directory-Sharing und Token-Management. Die Authentifizierung erfolgt über OAuth 2.0 Device Authorization Grant (RFC 8628), nicht über einen API-Key. Es ist explizit als experimentell gekennzeichnet, und Tunnels sind an den MCP-Serverprozess gebunden — sie überleben keinen Neustart, was auch eine bewusste Designentscheidung ist.

Für das engere Muster “expose einen bereits laufenden MCP-Server an einen entfernten Agenten” (nicht Tunnel-Management, sondern Tunnel-Erstellung für einen bestimmten Server) funktioniert der klassische SSH-Workflow weiterhin:

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

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

Cloudflare Tunnel

Völlig neu im Vergleich zu früheren Entwürfen: Cloudflare bietet eigene Agententools für die gesamte Entwicklerplattform — nicht nur für Tunnel — via ein Skills-Plugin (/plugin marketplace add cloudflare/skills dann /plugin install cloudflare@cloudflare). Das Bundle cloudflare deckt Workers, Storage, AI und Networking inklusive Tunnel und Spectrum ab, sowie Cloudflares eigene verwaltete MCP-Server für Kontoverwaltung (DNS, WAF-Regeln etc.) via OAuth. Es gibt kein spezielles create_tunnel-Tool wie bei rustunnel oder Pinggy — ein Agent, der Cloudflare Tunnel nutzt, steuert cloudflared meist nur über CLI, das die Skills vermittelt, nicht über ein spezielles Tunnel-Management-Tool.

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

Diese bleiben wie im Original: LocalCan (macOS-native, .local-Domain-Integration), LocalXpose (plattformübergreifend mit GUI/CLI, mit eigenem node-localxpose-Client) sind gut für Entwickler, haben aber kein erstes MCP-Server-Produkt. Für die Integration in einen Agenten müsste man CLI oder REST API selbst bauen. frp ist der Standard für UDP-lastige und Gaming-Workloads, Playit.gg bietet mit Anycast Routing eine Alternative ohne Port-Forwarding; beide sind Low-Level-Infrastruktur, die einen eigenen MCP-Server brauchen, um natürliche Sprachbefehle in Konfigurationsänderungen zu übersetzen. localhost.run ist weiterhin eine SSH-basierte Lösung, um einen MCP-Gateway (wie Bifrost) schnell nach außen freizugeben.

---

5. MCP-Tunnel in Claude Code integrieren

Claude Code unterstützt drei MCP-Transportarten: stdio (Standard, für lokale Prozesse), HTTP (empfohlen für entfernte Server) und SSE (wird zugunsten von HTTP schrittweise eingestellt). Alle drei werden via claude mcp add registriert oder manuell in .mcp.json / ~/.claude.json eingetragen.

Selbstsignierte Zertifikate und TLS bei lokalem Entwickeln

Wenn du Claude Code auf einen lokalen Tunnel-Proxy mit selbstsigniertem Zertifikat zeigst, bekommst du unable to verify the first certificate — Node.js-basierte MCP-Clients (inklusive Claude Code) verweigern standardmäßig selbstsignierte Zertifikate. Der dokumentierte Workaround ist genau das, was im Entwurf gezeigt wurde:

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

in ~/.claude/settings.json. Wichtig: Das deaktiviert die Zertifikatsüberprüfung für alle ausgehenden Verbindungen von Claude Code in dieser Session — inklusive api.anthropic.com und des MCP-Registrierungsservers, nicht nur dein lokaler Tunnel. Die eigene Entwickler-Community von Anthropic hat darauf hingewiesen, dass dieser Scope größer ist als erwartet; benutze es nur vorübergehend, z. B. mit NODE_TLS_REJECT_UNAUTHORIZED=0 claude für eine einzelne Sitzung, und verwende NODE_EXTRA_CA_CERTS, wenn möglich, um nur dein echtes CA-Zertifikat zu vertrauen.

---

6. Integration mit Cursor und Windsurf

Cursor und Windsurf konfigurieren MCP über JSON-Dateien, nicht per CLI. Die Pfade sind nicht austauschbar:

• Cursor — global: ~/.cursor/mcp.json; projektbezogen: .cursor/mcp.json im Projektordner.
• Windsurf — ~/.codeium/windsurf/mcp_config.json.

Beide verwenden die gleiche mcpServers-Struktur wie Claude Desktop:

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

Wichtig: VS Code nutzt eine andere Schema (servers, kein mcpServers, plus ein `