Claudes Tool Use ist kein Webhook. Dein Backend schickt eine Nachricht, Claude antwortet — optional mit der Bitte, ein Tool aufzurufen —, dein Code führt das Tool aus und schickt das Ergebnis zurück. Das Ganze läuft über ausgehendes HTTPS von deinem Rechner. Warum geht es hier also um Tunnel?
Weil du in dem Moment, in dem du etwas Echtes mit Claude baust — einen Coding-Agenten, eine Support-Automation, einen MCP-Server, einen langlaufenden Workflow —, eingehende Konnektivität brauchst. Für Browser-Clients. Für MCP-Server, die anderen Apps bereitstehen. Für Webhooks von Drittanbieter-Tools, die das Modell aufruft.
Wo ein Tunnel wirklich hilft
Browser-Frontends für Claude-Apps
Gleiche Struktur wie beim OpenAI-Realtime-Setup. Dein Frontend darf deinen Anthropic-API-Key nicht halten, also spricht es mit deinem Backend, das mit Anthropic spricht. Das Frontend braucht HTTPS, damit Streaming-Antworten sauber rendern (manche Browser verschlechtern SSE über reines HTTP), und dein Backend braucht HTTPS, wenn das Frontend HTTPS ist. Der Tunnel erledigt beides.
Lokal laufende MCP-Server
Das Model Context Protocol lässt Claude (und andere Clients) Tools nutzen, die du als MCP-Server bereitstellst. Bei MCP-Servern mit HTTP-Transport — anders als bei stdio — muss der Client deinen Server erreichen. Wenn du einen MCP-Server prototypisierst und ihn mit Claude Desktop oder einem anderen Remote-Client testen willst, ist der Tunnel der Weg des geringsten Widerstands.
Computer-Use-Callbacks
Nutzt du Claudes Computer-Use-Beta und das Modell interagiert mit einem Dienst, der Webhooks an deinen Rechner zurückschickt, bist du im Webhook-Territorium. Dieselben Muster wie bei jedem Anbieter: erfassen, erneut senden, verifizieren (falls zutreffend).
Was ein Tunnel nicht tut
Du brauchst keinen Tunnel, um Claude aus einem lokalen Skript aufzurufen. curl https://api.anthropic.com/v1/messages funktioniert von jedem Rechner. Die Python- und TypeScript-SDKs laufen problemlos. Tool Use selbst ist eine ausgehende Interaktion — Claude ruft deinen Rechner nicht an, um ein Tool zu nutzen; dein Code ruft auf, basierend auf Claudes Antwort.
Das verwirrt manche beim ersten Mal. Das Muster ist:
- Dein Code schickt eine Nutzernachricht an Claude mit einer Liste verfügbarer Tools.
- Claude antwortet, möglicherweise mit einem
tool_use-Block, der ein aufzurufendes Tool beschreibt. - Dein Code führt das Tool gegen dein lokales System aus.
- Dein Code schickt das Tool-Ergebnis als Folgenachricht an Claude zurück.
- Schleife bis fertig.
Alle fünf Schritte passieren in einem Python- oder TypeScript-Prozess. Kein eingehender Traffic. Kein Tunnel.
Der eigentliche Grund, warum Tunneling bei Claude-Workflows hilft
Der Grund, warum wir bei der Claude-Entwicklung am Ende doch einen Tunnel betreiben, ist nicht das Modell selbst. Es ist alles drumherum: das Dashboard für den Fortschritt des Agenten, das Frontend, das Tool-Ausgaben streamt, der für Tests bereitgestellte MCP-Server, der Webhook eines Drittanbieter-Tools, das der Agent aufgerufen hat („sende eine Slack-Nachricht", „erstelle ein Linear-Issue"). Der Agent löst eine Kettenreaktion aus, und irgendwo in dieser Kette will ein externer Dienst schließlich deinen Rechner erreichen.
Setup für eine MCP-Server-Dev-Schleife
- Implementiere deinen MCP-Server mit HTTP-Transport.
- Lass ihn lokal auf dem von dir gewählten Port laufen.
npx portpreview 3000(oder dein Port).- Konfiguriere in Claude Desktop oder deinem anderen MCP-Client die Remote-Server-URL, die auf deinen Tunnel zeigt.
- Setze Befehle ab. Beobachte die Request-Erfassung im Tunnel und die Antworten deines Servers.
Ist dein MCP-Server ein stdio-Transport, gilt das nicht — stdio-Server kommunizieren über Prozess-Pipes und bleiben per Design lokal.
Streaming-Antworten und Tunnel
Claude streamt Antworten per SSE. Tunnel müssen die langlebige Streaming-Antwort korrekt handhaben — die meisten tun das, aber manche älteren HTTP-Proxys puffern die Antwort und geben sie erst am Ende frei, was Streaming sinnlos macht. PortPreview, Cloudflare und ngrok handhaben SSE ohne Pufferung. Wenn dein Frontend die ganze Antwort nach langer Wartezeit in einem Stück bekommt, puffert dein Tunnel. Das ist ein Tunnel-Problem, kein Claude-Problem.
Die Agenten-Schleife debuggen
Der schwierigste Teil der Claude-Tool-Use-Entwicklung ist nicht die API. Es ist zu verstehen, was das Modell in jedem Schritt entschieden hat. Logge jeden tool_use-Block vor der Ausführung. Logge jedes Tool-Ergebnis vor dem Rücksenden an Claude. Hast du einen Tunnel zwischen Frontend und Backend, liefert die Request-Erfassung auch ein Protokoll der Nutzernachrichten — nützlich, um Agenten-Läufe ohne erneutes Tippen der Prompts zu wiederholen.
Wohin das führt
Anthropics Tool-Use-Ökosystem bewegt sich schnell — MCP, Computer Use, längere Kontextfenster, niedrigere Latenz. Die Webhook-Muster aus Webhooks lokal debuggen und die Signatur-Mathematik aus dem Leitfaden zur Signaturprüfung gelten, sobald ein externes Tool, das der Agent aufruft, einen Callback an deinen Rechner schickt.
Tritt der PortPreview-Warteliste bei für einen Tunnel mit eingebauter Erfassung, Wiederholung und SSE-sicherer Weiterleitung.