Agents IA et automatisation des tunnels : au cœur du serveur MCP de Pinggy

Les développeurs utilisant Claude Code, Cursor, Claude Desktop ou Windsurf comme interface principale souhaitent de plus en plus que ces agents gèrent plus que la simple génération de code — notamment la mise en place d’une URL publique pour un serveur de développement local. Pinggy est l’un des premiers fournisseurs de tunneling à formaliser cela avec des outils dédiés : une Compétence Agent et un serveur MCP autonome, tous deux publiés sous une étiquette d’accès anticipé et expérimental. Cet article explique ce que chaque composant fait réellement, comment les installer correctement (les chemins de configuration diffèrent plus que ce que l’on pourrait attendre entre les clients), et à quoi ressemble la sécurité une fois qu’un agent peut ouvrir un tunnel de façon autonome.

Tunneling manuel, et où se situe la friction

Le flux de travail de base n’a pas changé depuis des années : exécuter ssh -p 443 -R0:localhost:8000 free.pinggy.io (ou l’équivalent pour ngrok, Cloudflare Tunnel, ou autre), copier l’URL générée, et la coller où c’est nécessaire — tableau de bord webhook, message Slack, fichier .env. Lorsqu’un agent de codage IA contrôle déjà le terminal, c’est une étape supplémentaire manuelle entre le contexte de l’agent et le vôtre.

Le protocole Model Context (MCP), publié par Anthropic fin 2024, offre aux agents une méthode standardisée pour appeler des outils externes au lieu d’exécuter une commande shell et d’analyser la sortie. Une configuration MCP comporte trois parties : hôtes (les applications d’agent — Claude Code, Cursor, Claude Desktop, Windsurf), clients (la connexion protocolée que chaque hôte maintient), et serveurs (processus exposant un ensemble d’outils, ressources ou prompts via cette connexion). Envelopper un client de tunneling dans un serveur MCP permet à l’agent d’appeler directement un outil comme start_tunnel, de recevoir des données structurées (URL publique, ID du tunnel, statut), et de ne jamais avoir à construire ou analyser une commande shell.

Compétence vs. serveur MCP : deux choses différentes

Pinggy fournit deux outils distincts pour l’agent, et il est important de bien distinguer, car la documentation du fournisseur est :

	Compétence	Serveur MCP
Quoi	Documentation de référence empaquetée (SSH, CLI, SDK, tous les flags et types de tunnel) que l’agent lit	Processus en cours exposant des opérations de tunnel comme outils appelables
Ce que fait l’agent avec	Lit la doc, puis exécute des commandes lui-même via un accès terminal classique	Appelle directement les outils — pas de construction de commandes
Installation	npx skills add https://pinggy.io	Configuration basée sur uvx, par client

Les recommandations de Pinggy indiquent de commencer par la compétence si vous souhaitez que l’agent comprenne l’outil, et d’ajouter le serveur MCP uniquement si vous souhaitez qu’il opère des tunnels de façon autonome. Les deux peuvent être installés séparément ou ensemble, et l’installation de la compétence fonctionne de la même manière pour tous les agents — le CLI détecte le client et écrit les fichiers de compétence dans son répertoire (~/.claude/skills/pinggy/ pour Claude Code, par exemple).

Le reste de cet article se concentre sur le serveur MCP, car c’est ce qui permet le comportement “tunnel sans quitter le chat” que la plupart des gens associent à l’automatisation par agent.

Ce que le serveur MCP de Pinggy expose réellement

Le serveur est un package Python (nécessite Python 3.10+ et uv) publié sur github.com/Pinggy-io/pinggy_mcp. Il est explicitement marqué dans son README comme expérimental — “partagé pour retours précoces, prévoir des imperfections” — ce qui est important à garder en tête avant de l’intégrer dans des systèmes critiques.

Une fois installé, il enregistre treize outils répartis en quatre groupes :

Authentification - authenticate — lance le flux OAuth2 de type device et retourne une URL de connexion - check_authentication — statut de connexion, email du compte, expiration du token - get_profile — récupère votre profil Pinggy - logout — efface la session stockée

Tunnels - start_tunnel — HTTP, TCP, TLS ou UDP, avec options d’autorisation IP, réécriture d’en-têtes, débogueur web - stop_tunnel, list_tunnels, get_tunnel_info

Partage de fichiers - share_directory — expose un dossier local via WebDAV avec une URL Pinggy publique - stop_file_share, list_file_shares

Gestion des tokens - add_token, remove_token, list_tokens, update_token — pour attacher un token Pinggy spécifique (pour sous-domaines réservés ou domaines personnalisés) à un port donné

Il ne faut pas appeler ces outils directement ; il faut leur demander en langage naturel (« exposer le port 3000 », « lister mes tunnels actifs », « autoriser uniquement le trafic de 1.2.3.4 ») et l’agent choisira le bon outil. La partie initiale de la description était correcte — cela supporte bien les tunnels HTTP/TCP/TLS/UDP et le partage de répertoires via WebDAV, pas seulement HTTP.

Authentification : cette partie est fiable

L’affirmation que Pinggy utilise OAuth 2.0 Device Authorization Grant (RFC 8628) plutôt que des tokens API collés est correcte. Dire « se connecter à Pinggy » déclenche authenticate, qui contacte le backend Pinggy et retourne une URL ; vous l’approuvez dans un navigateur pendant que le serveur MCP interroge en arrière-plan, puis stocke et rafraîchit silencieusement la session. La session est enregistrée dans ~/.config/pinggy-mcp/config.json (Linux/macOS) ou %LOCALAPPDATA%\pinggy-mcp\config.json (Windows), avec chmod 600 sur Unix. Les tokens sauvegardés sont optionnels et ne sont nécessaires que pour des cas que OAuth ne couvre pas, comme l’attachement d’un sous-domaine réservé à un port local précis.

Installation — correction par client

Voici où les instructions initiales comportaient des erreurs importantes, notamment le mauvais chemin de configuration, qui peut faire la différence entre « ça fonctionne » et « rien n’apparaît dans la liste des outils ». Cursor et VS Code utilisent des emplacements et schémas JSON différents (mcpServers vs. servers), et les confondre, comme une version antérieure de ces instructions le faisait, produira une configuration illisible pour le client visé.

Claude Code — la méthode la plus simple ; une seule ligne de CLI, pas de modification manuelle de fichier :

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

Vérifier avec claude mcp list.

Claude Desktop — modifier directement le fichier de configuration : - 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"]
    }
  }
}

Redémarrez l’application ; pinggy devrait apparaître dans l’indicateur MCP sous la zone de saisie.

Cursor — une autre méthode par rapport à VS Code, malgré que ce soient deux éditeurs : - Global : ~/.cursor/mcp.json - Par projet : .cursor/mcp.json à la racine du projet

Même forme JSON que pour Claude Desktop.

VS Code — encore différente, avec un changement de schéma (servers + `