AI-Agenten verwalten Ihre lokalen Tunnels automatisiert

Seit Jahren lag die Reibung, einen lokalen Dev-Server ins Internet zu bringen, außerhalb der Reichweite von KI-Coding-Assistenten. Sie konnten einen Agenten bitten, einen Webhook-Handler zu schreiben, aber sobald eine öffentliche URL benötigt wurde — für Stripe, einen mobilen Client, eine Demo für den Kunden — mussten Sie den Chat verlassen, ein zweites Terminal öffnen, einen Tunneling-Befehl ausführen, eine URL kopieren und an einer anderen Stelle einfügen. Der Code wurde vor Jahren automatisiert, aber die Netzwerkverknüpfung nicht, bis das Model Context Protocol (MCP) den Agenten ein Tool-Call gab, das direkt zum Tunnel selbst führt.

Dies ist noch keine vollendete Revolution — die meisten Entwickler laufen noch manuell cloudflared oder ssh -p 443 -R0:localhost:3000 a.pinggy.io, und die MCP-Server, die das automatisieren, sind, nach Aussage ihrer eigenen Maintainer, noch früh. Aber die Komponenten sind vorhanden, dokumentiert und es lohnt sich, sie zu verstehen, bevor man sie in einen Agenten mit Terminalzugang integriert.

Das Flaschenhals-Problem, das hier ersetzt wird

Das Testen einer Webhook-Integration war nie nur eine Frage des Codes. Stripe, Shopify oder eine GitHub App benötigen eine öffentliche URL, um Events zu empfangen, und Ihr Dev-Server hört nur auf localhost. Der traditionelle Ablauf:

1. Starten des lokalen Servers.
2. Öffnen eines zweiten Terminals.
3. Ausführen eines Tunneling-Befehls und Warten auf die Verbindung.
4. Kopieren der generierten URL.
5. Einfügen in ein Dashboard eines Drittanbieters.
6. Senden eines Test-Events.
7. Schritt 3–6 wiederholen, wenn der Tunnel neu startet und sich die URL ändert.

Das ist alles nicht schwer, unterbricht aber den Arbeitsfluss. Genau diese mechanische, mehrstufige Aufgabe kann ein Tool-Call-Agent übernehmen — vorausgesetzt, der Tunnel ist als Tool erreichbar, nicht nur als Shell-Befehl im Kopf.

Das MCP macht das möglich

Anthropic hat das Model Context Protocol am 25.11.2024 als Standard für die Verbindung von KI-Anwendungen mit Systemen, in denen Daten und Tools leben, open-sourced. Vor MCP war die Anbindung eines Modells an ein externes Tool eine individuelle Integration für jedes Modell–Tool-Paar — das “N×M”-Problem, bei dem N Modelle jeweils eine eigene Verbindung zu M Tools benötigen. MCP fasst das auf einen Server pro Tool zusammen, den jeder MCP-fähige Client nutzen kann.

Die Architektur besteht aus drei Teilen:

• Host — die benutzerorientierte Anwendung: eine IDE, ein Desktop-Chat-Client, ein spezieller Agent.
• Client — das Teil im Host, das MCP spricht und Aufrufe an Server weiterleitet.
• Server — der externe Prozess, der Tools (ausführbare Aktionen), Ressourcen (kontextbezogene Daten) und Prompts (wiederverwendbare Vorlagen) an den Client ausliefert.

Nachrichten werden im JSON-RPC 2.0-Format ausgetauscht, und der Request/Response-Fluss basiert auf dem Language Server Protocol — dem gleichen Muster, das es jedem Editor erlaubt, mit jedem Autocomplete-Backend zu sprechen, ohne individuelle Integration.

Der Transportlayer hat sich bereits zweimal verändert

Die erste Version von MCP (2024-11-05) nutzte zwei Transporte: stdio für lokale, einzelne Clients, und HTTP+SSE für entfernte Server. Die Revision vom 26.03.2025 ersetzte HTTP+SSE durch Streamable HTTP — einen einzigen Endpunkt, der stateless Deployment hinter Load Balancern und wiederaufnehmbaren Sessions unterstützt, was bei der ursprünglichen SSE-Dual-Endpunkt-Architektur schlecht funktionierte. SSE bleibt nur für Abwärtskompatibilität, und mehrere Anbieter haben bereits Abschaltdaten dafür festgelegt.

Das war nicht das letzte Wort. Am 28.07.2026 — knapp eine Woche vor der Veröffentlichung dieses Textes — veröffentlichten die MCP-Maintainer die Revision vom 28.07.2026, die laut Lead-Maintainer David Soria Parra die größte Änderung seit dem Start darstellt. Sie entfernt den Protocol-Handshake komplett und macht MCP standardmäßig stateless: Ein Server muss keinen Client mehr über mehrere Calls verfolgen, was bedeutet, dass jede Anfrage von jeder Instanz hinter einer normalen HTTP-Infrastruktur beantwortet werden kann, ohne Session-Affinität. Außerdem wird ein Erweiterungs-Framework (für MCP-Apps, die ihre eigene UI rendern) sowie eine Policy für den Lebenszyklus von Features eingeführt, die mindestens zwölf Monate zwischen Deaktivierung und Entfernung garantieren. Bestehende Clients und Server vom 25.11.2024 bleiben funktionsfähig — die neue Revision ist beim Upgrade optional, und ein kompatibler Server kann beide Revisionen von einem Endpunkt aus bedienen.

Adoption schreitet schnell voran

OpenAI fügte am 26.03.2025 MCP-Unterstützung in sein Agents SDK ein (“heute verfügbar”, laut Sam Altman, mit Responses API und ChatGPT Desktop-Unterstützung). Google DeepMind kündigte im April 2025 an, Gemini werde MCP übernehmen. Bis zum 09.12.2025 übergab Anthropic die Steuerung des Protokolls an die Agentic AI Foundation, eine von der Linux Foundation geführte Stiftung, mit Mitgründern wie Anthropic, Block und OpenAI, sowie AWS, Google, Microsoft, Cloudflare und Bloomberg als Platin-Mitglieder. Zu diesem Zeitpunkt hatte MCP über 10.000 aktive öffentliche Server und mehr als 97 Millionen SDK-Downloads pro Monat. Bis Juli 2026 stieg die Zahl auf fast eine halbe Milliarde Downloads monatlich, mit den SDKs für TypeScript und Python jeweils über einer Milliarde Gesamtdownloads. Das Governance-Modell bleibt gemeinschaftlich, Mitgliedschaft im technischen Prozess ist an Personen gebunden, nicht an Unternehmen.

Fähigkeiten und MCP-Server sind zwei unterschiedliche Dinge

Die unten genannten Tunneling-Anbieter nutzen beide einen zweiten, verwandten Mechanismus: Agent Skills. Ein Skill ist eine Paket-Anleitung mit Referenzmaterial (CLI-Flags, SDK-Nutzung, Beispiel-Prompts), das ein Agent einmal liest und dann selbstständig mit normalem Terminalzugang ausführt. Ein MCP-Server ist dagegen ein laufender Prozess, den der Agent direkt als Tool aufruft, ohne eine Befehlszeile aus Dokumentation rekonstruieren zu müssen. Sie werden nach einem gemeinsamen Standard (skills CLI, verteilt via npx skills add <url>) veröffentlicht und in das Skills-Verzeichnis des Agents installiert — bei Claude Code z.B. ~/.claude/skills/<name>/. Die Empfehlung der Anbieter ist überall gleich: Beginnen Sie mit dem Skill, wenn der Agent das Tool verstehen soll; fügen Sie den MCP-Server hinzu, wenn der Agent autonom damit arbeiten soll.

Pinggy’s Skill und MCP-Server

Pinggy bietet beides an, und sie können unabhängig voneinander installiert werden.

Der Skill:

npx skills add https://pinggy.io

Dies lädt das Manifest von https://pinggy.io/.well-known/skills/ und schreibt die Skill-Dateien in das Skills-Verzeichnis des Agents. Voraussetzung ist Node.js.

Der MCP-Server — Quellcode bei github.com/Pinggy-io/pinggy_mcp — benötigt Python 3.10+ und uv:

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

Es wird nichts global installiert; jeder Client startet pinggy-mcp bei Bedarf über uvx. Für Claude Code erfolgt die Registrierung per CLI-Befehl, nicht in einer Konfigurationsdatei:

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

Claude Desktop, Cursor und Windsurf verwenden eine mcpServers-Schlüssel in einer JSON-Konfigurationsdatei (Pfad je nach Client und OS unterschiedlich); VS Code nutzt eine oberste servers-Schlüssel. Wichtig vorab: Pinggy beschreibt den MCP-Server selbst als “früh und experimentell” und bittet um Feedback, nicht als produktionsreif.

Nach der Verbindung liefern die dokumentierten Beispiel-Prompts von Pinggy einen Eindruck vom tatsächlichen Anwendungsfeld:

• “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.”

Ein Detail, das direkt an den Agenten gerichtet ist: Jede Pinggy-Dokumentationsseite ist auch als reines Markdown unter demselben Pfad mit index.md veröffentlicht, und die gesamte Seite ist zusammengefasst unter pinggy.io/llms.txt — so kann ein Agent die Dokumentation direkt lesen, ohne HTML zu scrapen.

Cloudflare MCP-Oberfläche ist breiter gefasst als “Tunnels”

Die eigenen MCP-Server von Cloudflare konzentrieren sich nicht nur auf cloudflared — sie decken die gesamte Cloudflare API ab. Der Flaggschiff-Server, der Cloudflare API MCP-Server (github.com/cloudflare/mcp, erreichbar unter https://mcp.cloudflare.com/mcp), bietet über 2.500 Endpunkte in DNS, Workers, R2 und Zero Trust via nur zwei Tools: search() und execute(). Statt für jeden Endpunkt ein Schema zu laden, schreibt das Modell JavaScript gegen eine typisierte Repräsentation der OpenAPI-Spezifikation, die in einer isolierten Dynamic Worker Sandbox läuft — das Cloudflare “Code Mode” Muster. Die Token-Rechnung ist entscheidend: native MCP, das alle 2.594 Endpunkte mit vollständigen Schemas anbietet, würde etwa 1,17 Millionen Tokens kosten, nur um die Tools aufzulisten; Code Mode mit nur zwei Tools kostet etwa 1.000 Tokens, egal wie groß das Verzeichnis ist.

Neben diesem allgemeinen Server betreibt Cloudflare auch spezifische, domänenspezifische MCP-Server — z.B. für Dokumentation, Worker-Bindings, Observability, Radar (Internetverkehrsdaten), Audit-Logs, DNS-Analytics — jeweils auf eigener Subdomain (z.B. docs.mcp.cloudflare.com/mcp). Es gibt keinen dedizierten “Tunnel”-MCP-Server; die Verwaltung eines Cloudflare Tunnels — aktive Tunnels auflisten, Status prüfen, Ingress-Regeln aktualisieren — erfolgt über den allgemeinen API MCP-Server mit search/execute gegen die Tunnel- und Zero Trust-Endpunkte, genau wie bei anderen Cloudflare-Ressourcen. Möchten Sie einen Agenten eine neue Vorschau-Umgebung an eine Subdomain binden lassen, greifen Sie auf die gleichen 2.500 Endpunkte zurück.

Cloudflare bündelt seine MCP-Server außerdem mit kontextbezogenen Skills und Slash-Commands via das Cloudflare Skills Plugin (github.com/cloudflare/skills), das über den Claude Code Plugin Marketplace (/plugin marketplace add cloudflare/skills), den Cursor Marketplace oder den npx skills add CLI installiert werden kann.

MCP-Server-Portale: die eigentliche Enterprise-Steuerung

Die Lösung von Cloudflare für “man kann einem LLM nicht ohne Aufsicht den API-Token geben” sind MCP-Server-Portale, Teil von Cloudflare One’s Zero Trust Plattform (intern tragen einige API-Pfade noch den alten Namen “Agents Gateway”). Ein Portal bündelt mehrere MCP-Server hinter einem einzigen HTTP-Endpunkt, geschützt durch Cloudflare Access. Konkret:

• Authentifizierung: Nutzer loggen sich im Portal über Cloudflare Access mit ihrem Identity Provider ein; das Portal fordert bei Bedarf OAuth bei Upstream-Servern an.
• Gezielte Tool-Exposition: Admins können einzelne Tools oder Prompts pro Server deaktivieren oder eine Allowlist erstellen, bei der nur explizit freigegebene Tools sichtbar sind — nützlich, wenn ein Upstream-Server mehr offenbart, als ein Team sehen sollte.
• Code Mode standardmäßig: Alle Upstream-Tools werden in einem einzigen code-Tool zusammengefasst, gegen das der Agent JavaScript schreibt, in einer isolierten Dynamic Worker-Umgebung — das hält die Nutzung des Kontextfensters konstant, egal wie viele Server hinter dem Portal stehen.
• Logging: Anfragenbezogene Logs (Zeit, Status, Server, Tool, Dauer) sind im Dashboard verfügbar, mit Logpush-Export in ein SIEM auf Enterprise-Plänen.
• Optionale Gateway-Routing: Portal-Verkehr kann durch Cloudflare Gateway für DLP-Scanning geleitet werden, um z.B. Anfragen mit Anmeldeinformationen oder Finanzdaten zu blockieren, bevor sie das Modell oder den Upstream-Server erreichen.

Das ehrliche Wort aus den Cloudflare-Dokumenten: Unabhängige MFA, Zweck- und Rechtfertigungs-Prompts sowie temporäre Authentifizierung gelten nicht für MCP-Server, die über ein Portal autorisiert sind, auch wenn diese Policies anderswo in der gleichen Access-Anwendung konfiguriert sind. Das “Portal” bietet also zentrale OAuth-Authentifizierung, kuratierte Tools und DLP-Logging — echte Kontrollen — ersetzt aber nicht alle Access-Policy-Funktionen, die man für menschliche Nutzer bereits nutzt.

Ein praktisches Beispiel für Webhook-Tests

Stripe ist ein häufig genutztes Beispiel für diesen Workflow, weil seine MCP-Server-Fähigkeiten nicht nahtlos auf “der Agent macht alles” passen.

Stripe hostet seinen MCP-Server unter https://mcp.stripe.com. Anders als bei einem gehosteten MCP-Server unterstützt er sowohl den standardmäßigen OAuth-Flow als auch einen eingeschränkten API-Key als Bearer-Token — eine dokumentierte, unterstützte Methode für headless oder autonome Agenten. Die Tools umfassen Kontoinformationen, Rückerstattungen, Ressourcen-Suche und -Abruf, Dokumentationssuche und Integrationsplanung, sowie generische stripe_api_read, stripe_api_write und API-Such-Tools, die den Großteil der REST-Oberfläche abdecken.

Hier die Grenze für den Tunnel-Test-Workflow: Ein Agent kann einen Webhook-Endpunkt erstellen oder aktualisieren — inklusive Ziel-URL auf einen neuen Tunnel — über das generische Write-Tool. Es kann jedoch nicht, den Live-Webhook-Event-Stream direkt über MCP zu abonnieren oder zu konsumieren; das Reagieren auf eingehende Events bleibt eine REST/webhook-Infrastruktur außerhalb des Protokolls. Ein realistischer Ablauf:

1. Den Agenten den lokalen Server starten und mit Pinggy- oder Cloudflare-MCP-Tool exponieren.
2. Die URL des Stripe-Webhooks auf die neue Tunnel-Adresse aktualisieren, via das Stripe MCP Write-Tool.
3. Einen Test-Event im Stripe-Dashboard oder CLI auslösen, oder den Agenten das selbst machen lassen, falls Sie die Stripe CLI verwenden.
4. Bestätigen, dass der lokale Server das empfangen und verarbeitet hat.

Stripe empfiehlt, bei den Write-Tools eine menschliche Bestätigung zu aktivieren und vorsichtig zu sein, wenn man den Stripe MCP-Server mit anderen kombiniert — insbesondere wegen des Risikos von Prompt-Injection. (Pinggy veröffentlicht eine eigene Anleitung zum Testen von Stripe Webhooks, nützlich, egal ob mit Agent oder manuell.)

Stand der agentischen IDEs Mitte 2026

Die drei wichtigsten Editoren für diesen Workflow haben sich seit der letzten Gegenüberstellung verändert:

• Cursor (von Anysphere) befindet sich mitten in der größten Venture-gestützten Übernahme aller Zeiten. Die Series D im November 2025 bewertete Cursor mit 29,3 Milliarden USD; SpaceX sicherte sich im April 2026 eine Option auf den Kauf von Anysphere, und am 16. Juni 2026 unterschrieben die Unternehmen eine endgültige Aktienvereinbarung im Wert von 60 Milliarden USD, um Cursor in SpaceX’s (bis dahin xAI-verschmolzene) KI-Ambitionen zu integrieren. Das Geschäft ist noch nicht abgeschlossen — voraussichtlich im Q3 2026, abhängig von der Regulierungsprüfung.
• Windsurf begann als agentischer IDE von Codeium. Im Juli 2025 kaufte Google DeepMind Windsurf’s CEO, Mitgründer und Schlüsselmitarbeiter in einem etwa 2,4 Milliarden USD schweren, nicht-exklusiven Lizenz- und Einstellungs-Deal. Wenige Tage später, am 14. Juli 2025, erwarb Cognition AI (Hersteller des autonomen Codierungs-Agenten Devin) die restlichen Produkte, IP, Markenrechte und ca. 210 Mitarbeiter, angeblich für rund 250 Mio. USD. Am 2. Juni 2026 wurde das Produkt in Devin Desktop umbenannt, mit der IDE, den Plänen und Erweiterungen unverändert, der lokale Agent heißt jetzt Devin Local, und Cloud-Agent-Zugriff ist in die Bezahlstufe integriert.
• Claude Code läuft heute auf sechs Oberflächen mit einer Engine: die ursprüngliche Terminal-CLI, eine VS Code Extension, ein JetBrains Plugin, eine eigenständige Desktop-App, eine Web-Oberfläche unter claude.ai/code (gestartet am 20.10.2025), und eine Slack-Integration. Mobile dient als Steuerungsoberfläche für Remote-Sitzungen. Konfiguration, Projekt-Memory (CLAUDE.md) und MCP-Server-Verbindungen sind über alle Oberflächen hinweg geteilt — eine Server-Registrierung reicht für alle.

Alle drei sind MCP-Clients, was der eigentliche Punkt ist: Der Tunnel ist egal, von welcher dieser Oberflächen er gesteuert wird, und ein einmal konfigurierte Pinggy- oder Cloudflare-MCP-Server verhält sich gleich, egal welches Editor-Tool den Aufruf macht — abgesehen von den Eigenheiten der jeweiligen Konfigurationsdateien.

Sicherheitsüberlegungen

Nichts oben genannte ersetzt das Urteilsvermögen. Die MCP-Dokumentation von VS Code ist klar: lokale MCP-Server können beliebigen Code auf Ihrer Maschine ausführen, also nur Server aus vertrauenswürdigen Quellen hinzufügen, die Sie geprüft haben. Das gilt besonders für Pinggy, dessen Maintainer das Label “early and experimental” tragen.

Ein weiteres Risiko, das auch bei Tunneling-Servern besteht: Agenten neigen dazu, MCP-Tool-Ausgaben als vertrauenswürdige Daten zu behandeln, nicht als untrusted input — ähnlich wie bei System-Prompts. Sicherheitsforscher haben gezeigt, dass man das ausnutzen kann, z.B. durch Fake-Fehler-Events, die in einen Fehler-Tracking-Service eingespeist werden, um eine MCP-verbundene Coding-Agenten dazu zu bringen, einen Bug zu “fixen”, der gar nicht existiert, durch Angreifer gesteuerte Anweisungen. Die Lektion: Jedes MCP-Server, dem Ihr Agent vertraut, ist effektiv Teil Ihrer Angriffsfläche. Die Verwendung von Least-Privilege-Scopes — IP-Whitelist, kuratierte Tool-Exposition, menschliche Bestätigung bei Schreibaktionen — ist die derzeit verfügbare Abhilfe.

Fazit

Das Management von Tunneln per MCP-Tool-Call ist heute eine funktionierende Praxis, kein Hirngespinst — Pinggy’s Server und Skill, Cloudflare’s API MCP-Server und Portale, sowie Stripe’s MCP-Server sind alle live, dokumentiert und unabhängig überprüfbar. Aber “early and experimental” beschreibt die eigentliche Tunnel-Komponente, das Protokoll hat die größte Breaking-Change seit dem Start durchlaufen, und die IDEs sind mitten in Übernahmen oder Rebrandings. Wenn Sie das heute in Ihren Workflow integrieren, behandeln Sie es wie jede neue Infrastruktur: Prüfen Sie, was der Server wirklich tut, bevor Sie ihm Netzwerkzugang gewähren, beschränken Sie seine Reichweite, und gehen Sie nicht davon aus, dass “der Agent hat höflich gefragt” automatisch sicher ist.

---

Changelog

Dieses Stück wurde aus einem früheren Entwurf neu geschrieben. Korrekturen und Ergänzungen, geprüft anhand primärer Quellen:

1. Entfernung der “obsolet”/“Revolution”-Formulierung. Der ursprüngliche Entwurf präsentierte KI-gesteuerte Tunnel als bereits vollzogene Veränderung, was nicht stimmt. Es ist ein aufkommendes, tatsächlich nützliches Muster, das die meisten Entwickler noch nicht täglich verwenden — entsprechend ist Pinggy’s MCP-Server als “early and experimental” gekennzeichnet (pinggy.io/docs/ai_agents/) und nicht produktionsreif.

2. Korrektur des Pinggy Skill-Installationsbefehls. Ursprünglich stand npx skills add pinggy/skills. Korrekt ist npx skills add https://pinggy.io, was das Manifest bei pinggy.io/.well-known/skills/ installiert. (pinggy.io/docs/ai_agents/)

3. Korrektur und Ergänzung der Pinggy MCP-Server-Details. Quellen: github.com/Pinggy-io/pinggy_mcp, Python 3.10+ und uv, claude mcp add-Befehl, Konfigurationsunterschiede bei VS Code (servers) und Claude Desktop/Windsurf (mcpServers). Beispiel-Prompts: “Expose my dev server on port 3000.”, “Open a TCP tunnel to localhost:22.”, etc. (pinggy.io/docs/ai_agents/)

4. Ergänzung der Cloudflare MCP-Architektur. Über 2.500 Endpunkte, 2,5k+ APIs, 1,17M vs. 1k Tokens, kein dedizierter “Tunnel”-Server, sondern alles über den allgemeinen API-Server. (developers.cloudflare.com/agents/model-context-protocol/cloudflare/servers-for-cloudflare/)

5. Verifizierung der Portale und deren Funktionen. Zugriff über Cloudflare Access, OAuth, Tool- und Prompt-Allowlisting, Code Mode, Logging, Gateway-DLP-Routing, Einschränkungen bei MFA und Policies. (developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/)

6. Bestätigung der MCP-Architektur und der Nachrichtenformate. Release-Datum 25.11.2024, N×M, JSON-RPC 2.0, LSP, etc. (anthropic.com/news/model-context-protocol)

7. Transport-Änderungen. 2025-03-26: HTTP+SSE durch Streamable HTTP, 2026-07-28: MCP wird standardmäßig stateless. (modelcontextprotocol.io/specification/2026-07-28/changelog; blog.modelcontextprotocol.io/posts/2026-07-28/)

8. Adoption und Governance. OpenAI (2025-03-26), Google DeepMind (April 2025), MCP-Governance an die Agentic AI Foundation (Dez 2025), aktuelle Nutzerzahlen. (anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation)

9. Stripe Webhook-Workflow. Unterstützung für Webhook-Endpoint-Update, keine Event-Stream-Abonnements, Hinweise auf menschliche Bestätigung und Prompt-Injection-Risiko. (docs.stripe.com/mcp; scalekit.com/blog/stripe-mcp-vs-api)

10. IDE-Landschaft. Cursor (Akquisition durch SpaceX, erwartete Abschluss Q3 2026), Windsurf (Kauf durch Cognition AI, Rebranding zu Devin Desktop, 2026), Claude Code (sechs Oberflächen). (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. Sicherheitsüberlegungen. MCP-Server können beliebigen Code ausführen, vertrauenswürdige Quellen, Gefahr von Prompt-Injection, Beispielangriffe. (code.visualstudio.com/docs/agent-customization/mcp-servers; pinggy.io/blog/agentjacking_ai_coding_agents_sentry_mcp/)

12. Entfernung unbestätigter Details. Keine unbelegten Annahmen zu Cloudflare “Tunnel Management” oder WAF-Tools.

13. SEO und Framing. Klare Zusammenfassung der Vor- und Nachteile, keine unnötigen Wiederholungen.

---

Changelog

Dieses Stück wurde überarbeitet, primäre Quellen geprüft:

1. Entfernung der “obsolet”/“Revolution”-Formulierung.
2. Korrektur des Pinggy Skill-Installationsbefehls.
3. Korrekte MCP-Server-Details, Quellen, Befehle, Konfigurationsunterschiede.
4. Verifizierte Cloudflare-Architektur, keine dedizierten “Tunnel”-Tools.
5. Verifizierte Portale, Funktionen, Einschränkungen.
6. Architektur, Nachrichtenformate, Release-Daten.
7. Transport-Änderungen, Spezifikations-Revisionen.
8. Adoption, Governance, Nutzerzahlen.
9. Stripe Webhook-Workflow, Sicherheitswarnungen.
10. IDE-Entwicklungen, Akquisitionen, Rebrandings.
11. Sicherheitsaspekte, Angriffsbeispiele.
12. Entfernung unbelegter Details.
13. SEO-Optimierung, klare Zusammenfassung.