AI Agents und Tunnel-Automatisierung: Inside the Pinggy MCP-Server

Entwickler, die Claude Code, Cursor, Claude Desktop oder Windsurf als ihre primäre Schnittstelle verwenden, möchten zunehmend, dass diese Agenten mehr als nur Codegenerierung übernehmen — inklusive dem Aufbau einer öffentlichen URL für einen lokalen Entwicklungsserver. Pinggy ist einer der ersten Anbieter, die dies mit speziellen Agententools formalisiert haben: ein Agent Skill und ein eigenständiger MCP-Server, beide veröffentlicht unter einem Early-Access- und Experimental-Label. Dieser Beitrag erklärt, was genau jede Komponente macht, wie man sie korrekt installiert (die Konfigurationspfade unterscheiden sich mehr, als man erwarten würde, je nach Client), und wie die aktuelle Sicherheitslage aussieht, sobald ein Agent eigenständig einen Tunnel öffnen kann.

Manuelles Tunneln und die damit verbundenen Hürden

Der grundlegende Arbeitsablauf hat sich seit Jahren nicht geändert: ssh -p 443 -R0:localhost:8000 free.pinggy.io (oder das Äquivalent für ngrok, Cloudflare Tunnel oder andere), URL kopieren und an die Stelle einfügen, wo sie gebraucht wird — ein Webhook-Dashboard, eine Slack-Nachricht, eine .env-Datei. Wenn ein KI-Coding-Agent bereits das Terminal steuert, ist das nur eine weitere manuelle Übergabe zwischen Agenten-Kontext und deinem.

Das Model Context Protocol (MCP), das Anthropic Ende 2024 veröffentlicht hat, bietet Agenten eine standardisierte Möglichkeit, externe Tools aufzurufen, anstatt Shell-Befehle zu parsen. Ein MCP-Setup besteht aus drei Teilen: hosts (die Agenten-Anwendungen — Claude Code, Cursor, Claude Desktop, Windsurf), clients (die Protokollverbindung, die jeder Host aufrechterhält) und servers (Prozesse, die eine bestimmte Reihe von Tools, Ressourcen oder Prompts über diese Verbindung bereitstellen). Ein Tunnel-Client in einem MCP-Server bedeutet, dass der Agent direkt einen Befehl wie start_tunnel aufruft, strukturierte Daten (die öffentliche URL, Tunnel-ID, Status) zurückbekommt und nie Shell-Befehle bauen oder parsen muss.

Skill vs. MCP-Server: Zwei unterschiedliche Dinge

Pinggy liefert zwei separate Komponenten für Agententools, und es ist wichtig, den Unterschied zu kennen, da die eigene Dokumentation des Anbieters lautet:

	Skill	MCP-Server
Was es ist	Paketierte Referenzdokumentation (SSH, CLI, SDK, alle Flags und Tunneltypen), die der Agent liest	Ein laufender Prozess, der Tunnel-Operationen als aufrufbare Tools bereitstellt
Was der Agent damit macht	Dokumente lesen, dann Befehle selbst über Terminalzugriff ausführen	Tools direkt aufrufen — keine Befehlszeilenerstellung
Installation	npx skills add https://pinggy.io	uvx-basierte Konfiguration, pro Client

Pinggys eigene Anleitung empfiehlt, mit dem Skill zu starten, wenn der Agent das Tool verstehen soll, und den MCP-Server nur hinzuzufügen, wenn Tunnel autonom betrieben werden sollen. Beide können unabhängig oder gemeinsam installiert werden, und die Skill-Installation funktioniert bei allen Agenten gleich — die CLI erkennt den Client und schreibt die Skill-Dateien in das Skills-Verzeichnis (~/.claude/skills/pinggy/ bei Claude Code beispielsweise).

Der Rest dieses Beitrags konzentriert sich auf den MCP-Server, da dieser das “Tunnel ohne Chat verlassen”-Verhalten ermöglicht, das die meisten mit agentengesteuerter Tunneling meinen.

Was der Pinggy MCP-Server tatsächlich bereitstellt

Der Server ist ein Python-Paket (benötigt Python 3.10+ und uv), veröffentlicht bei github.com/Pinggy-io/pinggy_mcp. Im eigenen README ist explizit als experimentell gekennzeichnet — “Frühfeedback teilen, mit rauen Kanten rechnen” — was man im Hinterkopf behalten sollte, bevor man ihn in kritische Systeme integriert.

Nach der Installation registriert er dreizehn Tools in vier Gruppen:

Authentifizierung - authenticate — startet den OAuth2-Device-Flow und liefert eine Login-URL - check_authentication — Login-Status, Kontomail, Token-Ablauf - get_profile — ruft dein Pinggy-Profil ab - logout — löscht die Sitzung

Tunnels - start_tunnel — HTTP, TCP, TLS oder UDP, optional mit IP-Allow-List, Header-Umschreibung und Web-Debugger - stop_tunnel, list_tunnels, get_tunnel_info

Dateifreigabe - share_directory — stellt einen lokalen Ordner über WebDAV mit einer öffentlichen Pinggy-URL bereit - stop_file_share, list_file_shares

Token-Management - add_token, remove_token, list_tokens, update_token — um einen bestimmten Pinggy-Token (z.B. für reservierte Subdomains oder eigene Domains) an einen Port zu binden

Diese Tools werden nicht direkt aufgerufen; stattdessen fragst du in einfacher Sprache (z.B. “Port 3000 freigeben”, “meine aktiven Tunnel auflisten”, “nur Traffic von 1.2.3.4 erlauben”) — der Agent wählt das passende Tool aus. Dieser Teil der ursprünglichen Beschreibung war korrekt — es unterstützt tatsächlich HTTP/TCP/TLS/UDP-Tunnel und WebDAV-Dateifreigabe, nicht nur HTTP.

Authentifizierung: Das stimmt

Die Behauptung, Pinggy nutze OAuth 2.0 Device Authorization Grant (RFC 8628) statt API-Tokens, ist korrekt. “Bei Pinggy anmelden” löst authenticate aus, das Kontakt zum Pinggy-Backend aufnimmt und eine URL zurückgibt; im Browser genehmigst du die Anmeldung, während der MCP-Server im Hintergrund pollt, und die Sitzung wird gespeichert und automatisch aktualisiert. Die Sitzung wird in ~/.config/pinggy-mcp/config.json (Linux/macOS) oder %LOCALAPPDATA%\pinggy-mcp\config.json (Windows) gespeichert, chmod 600 auf Unix. Gespeicherte Tokens sind optional und nur für spezielle Anwendungsfälle notwendig, z.B. eine reservierte Subdomain an einen lokalen Port zu binden.

Installation — clientabhängig

Hier gab es im ursprünglichen Text Fehler, die es zu korrigieren gilt, da ein falscher Konfigurationspfad den Unterschied zwischen “funktioniert” und “nichts in der Tool-Liste” ausmacht. Cursor und VS Code verwenden unterschiedliche Speicherorte und sogar unterschiedliche JSON-Schemas (mcpServers vs. servers), und eine Vermischung, wie in früheren Anleitungen, führt dazu, dass der Client die Konfiguration nicht lesen kann.

Claude Code — der einfachste Weg; ein Zeilenbefehl in der CLI:

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

Verifizieren mit claude mcp list.

Claude Desktop — Konfigurationsdatei direkt bearbeiten: - macOS: ~/Library/Application Support/Claude/claude_desktop_config.json - Windows: %APPDATA%\Claude\claude_desktop_config.json - Linux: ~/.config/Claude/claude_desktop_config.json

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

App neu starten; pinggy sollte im MCP-Indikator unter dem Eingabefeld erscheinen.

Cursor — ein anderer Weg als bei VS Code, trotz beider Editoren: - Global: ~/.cursor/mcp.json - Projektbezogen: .cursor/mcp.json im Projektordner

Gleiches JSON-Format wie bei Claude Desktop.

VS Code — wieder anders, mit Schema-Änderung (servers + "type": "stdio"): - macOS/Linux: ~/.vscode/mcp.json - Windows: %APPDATA%\Code\User\mcp.json - Oder .vscode/mcp.json im Workspace

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

Mit Developer: Reload Window aus der Befehlspalette neu laden.

Windsurf — ~/.codeium/windsurf/mcp_config.json bearbeiten, gleiche Form wie bei Claude Desktop, dann neu starten.

Ein Namenskonflikt, den man bei der Durchsicht des Repos beachten sollte: Die eigene Dokumentationsseite von Pinggy verlinkt github.com/Pinggy-io/pinggy_mcp als kanonisch, aber in mehreren Codeblöcken im README (z.B. bei lokalen Entwicklungsanleitungen) wird noch die alte Pfadangabe github.com/abhimp/pinggy_mcp verwendet. Beide funktionieren derzeit via GitHub-Weiterleitung, aber zukünftig sollte die neue Pfadangabe genutzt werden.

Wie agentengesteuertes Tunneln in der Praxis aussieht

Ein beispielhafter (nicht dokumentierter) Workflow: Du hast einen lokalen Entwicklungsserver laufen und willst, dass ein Client ihn sieht. Statt das Terminal zu wechseln, lässt du den Agenten den Server starten, ihn freigeben und eine Nachricht mit dem Link verfassen. Der Agent führt den Entwicklungsbefehl aus, erkennt den Port, ruft start_tunnel auf, erhält eine öffentliche URL und kann diese im selben Kontext verwenden, in dem er den Code geschrieben hat — plus alle aktuellen Commits. Das ist real (Tools existieren und machen das); alles andere ist eine mögliche Automatisierung, kein spezielles Pinggy-Feature.

Webhook-Tests folgen demselben Muster und sind ein stärkerer Anwendungsfall: Ein Agent, der sowohl einen Webhook-Handler schreibt als auch den Tunnel bereitstellt, um ihn gegen einen Drittanbieterdienst (Stripe, Shopify, GitHub) zu testen, braucht keinen Menschen, der die Schritte verbindet. Er ruft start_tunnel, registriert die URL bei der Webhook-Registrierung (über CLI oder API des Anbieters), löst einen Test aus und prüft die Logs. Die genaue Orchestrierung hängt von den weiteren Tools ab, die der Agent nutzt, nicht von Pinggy.

Vergleich mit ngrok und Cloudflare

Pinggy ist nicht der einzige Anbieter für Tunneling, der für Agenten entwickelt wird, und die Ansätze unterscheiden sich in ihrer Zielsetzung. ngrok fokussiert sich primär auf das Agenten-Frontend: Statt eines Agenten, der dein ngrok-Konto steuert, ist das Pattern von ngrok’s Dokumentation die Nutzung von ngrok als Gateway, das einen MCP-Server, den du lokal betreibst, an eine entfernte LLM-Plattform exposeiert, mit Identitäts- und Traffic-Policies davor — eher eine API-Gateway-ähnliche Lösung. Separat gibt es Community-basierte MCP-Server (z.B. via Composio), die es einem Agenten erlauben, Tunnel und Endpunkte eines ngrok-Kontos direkt zu verwalten, vergleichbar mit Pinggy. Cloudflare integriert MCP-Server mit Skills und Slash-Commands über ein Cloudflare Skills-Plugin, das via npx skills add installiert werden kann, ähnlich wie Pinggy. Es ist jedoch stärker in die Cloudflare One / Zero Trust Plattform eingebunden, weniger rein tunnelbezogen.

Sicherheit: Was die integrierten Schutzmaßnahmen wirklich abdecken

Der ursprüngliche Abschnitt unterschätzte die tatsächliche Exposure-Lage in der Branche. Es ist wichtig, zwischen den Sicherheitsmaßnahmen, die Pinggy tatsächlich umsetzt, und dem allgemeinen Risiko zu unterscheiden.

Was bei Pinggy wirklich relevant ist: - Tunnels laufen im MCP-Serverprozess. Beim Neustart des Hosts (Claude Code, Cursor, Claude Desktop) wird auch der Server neu gestartet, alle Tunnel sterben mit — kein Background-Daemon bleibt bestehen. - OAuth-Device-Flow-Authentifizierung bedeutet, dass der Agent nie einen API-Token im Klartext verarbeitet. - Die meisten MCP-Clients, inklusive Cursor, verlangen eine explizite Zustimmung, bevor Tools ausgeführt werden — start_tunnel löst meist eine Bestätigungsaufforderung aus.

Was nicht abgedeckt ist: Diese Eigenschaften gelten für einen gut entwickelten MCP-Server, nicht für MCP-Tunneling im Allgemeinen. Studien aus 2026 zeigen, dass nur etwa 8.5% der öffentlichen MCP-Server OAuth verwenden, der Großteil arbeitet mit statischen API-Schlüsseln oder Tokens, oft in Environment-Variablen. Die Sicherheitsumfragen zeigen, dass nur 29% der Organisationen sich ausreichend geschützt fühlen. Es gibt auch Berichte über Path-Traversal, Code- und Command-Injection-Exposures, die oft mit der Handhabung inbounder Parameter im STDIO-Transport zusammenhängen.

Das Tunneln bringt zusätzlich Risiken: Das Cloud Security Alliance warnt vor Subdomain-Hijacking bei MCP-Servern, die Tunnel-URLs verwenden. Wenn eine Session endet und die Subdomain wieder frei wird, kann ein Angreifer sie übernehmen und Requests abfangen. Deshalb sollten Tunnel-URLs in der Praxis kurzlebig sein, was auch Pinggy durch das sofortige Beenden von Tunneln bei Prozessneustart unterstützt.

Kurz: Prozessgebundene Tunnel und OAuth sind echte Verbesserungen gegenüber API-Tokens im Environment, adressieren aber nur einen Teil der Risiken. Tool-Poisoning, Confused Deputy-Pattern und andere Sicherheitslücken bleiben bestehen, solange MCP-Server zu viel Privilegien haben oder OAuth nicht flächendeckend genutzt wird. Die Zustimmung zu start_tunnel ist eine sinnvolle Kontrolle, ersetzt aber nicht die generelle Vorsicht bei MCP-Servern mit Dateisystem- oder Netzwerkkonfiguration.

Aktuelle Einschränkungen

• Experimentell, vom Maintainer so gekennzeichnet. Es sind noch rauhe Kanten, Tool-Namen und Verhalten können sich ändern. Melde Issues bei Bedarf.
• Keine Persistenz bei Neustarts. Tunnel sind an den MCP-Server gebunden; bei Neustart muss die Anfrage neu gestellt werden.
• Unvollständige Parameter-Dokumentation. Die öffentlichen Docs listen Tool-Namen und Zwecke, aber keine vollständige Parameterliste. Für genaue Aufrufe muss man den Quellcode prüfen.

Zukunftsausblick

Anbieter von MCP-Servern für Entwickler-Infrastruktur — Tunneling, Deployment, Datenbankzugriff — sind noch in der Frühphase, “experimentell” ist das passende Wort. Die wahrscheinlichste Richtung ist, dass Agenten weiterhin Tools aufrufen, um URLs oder Ressourcen automatisch zurückzugeben. Genaue Multi-Agent-Handoffs, bei denen ein Agent einen Tunnel direkt an einen anderen Agenten weitergibt, sind noch nicht dokumentiert oder im Produkt, sondern eine Spekulation.

---

Changelog

Korrekturen und Ergänzungen basieren auf Pinggys Live-Dokumentation (pinggy.io/docs/ai_agents/) und dem pinggy_mcp GitHub-Repository:

• Repo-Pfad korrigiert: Ursprünglich github.com/abhimp/pinggy_mcp, jetzt github.com/Pinggy-io/pinggy_mcp. Hinweise auf alte Pfade im README wurden angepasst.
• Claude Code-Installation korrigiert: Statt manueller JSON-Konfiguration ist die empfohlene Methode der Ein-Zeilen-Befehl: bash claude mcp add pinggy-mcp -- uvx --from git+https://github.com/Pinggy-io/pinggy_mcp.git pinggy-mcp Verifizieren mit claude mcp list. - Pfade bei Claude Desktop für Windows/Linux ergänzt: Windows: %APPDATA%\Claude\..., Linux: ~/.config/Claude/... - Cursor-Konfigurationspfad korrigiert: ~/.cursor/mcp.json (global) oder .cursor/mcp.json (projektbezogen). - VS Code als eigener Client mit eigenem Schema: servers + "type": "stdio", Pfade: ~/.vscode/mcp.json (macOS/Linux), %APPDATA%\Code\User\mcp.json (Windows), .vscode/mcp.json (Workspace). - Windsurf-Konfigurationsdatei hinzugefügt: ~/.codeium/windsurf/mcp_config.json. - Tools aktualisiert: Die tatsächlichen 13 Tools (Auth, Tunnel, File Sharing, Token Management) ersetzen die vorherigen Annahmen. - Unterscheidung Skill vs. MCP-Server: Klare Trennung der beiden Komponenten. - Status als “experimentell” gekennzeichnet: Das MCP-Server-Feature ist noch in der Testphase. - OAuth 2.0-Behauptung bestätigt: Entspricht RFC 8628. - WebDAV-File-Sharing bestätigt: Funktioniert wie beschrieben. - Sicherheitsabschnitt überarbeitet: Aktuelle Daten zu MCP-Security, OAuth-Adoption, Risiken bei Subdomain-Hijacking. - Vergleich mit ngrok und Cloudflare: Unterschiede in Ansatz und Integration erläutert. - Verschiedene Tool-Call-Beispiele entfernt: Statt konkreter Automatisierung nur illustrative Beschreibungen. - Sprachstil angepasst: Weniger werbend, sachlich. - Zukunftsprognose reduziert: Keine unbegründeten Annahmen, nur bekannte Richtungen.