Agentes de IA y Automatización de Túneles: Dentro del Servidor MCP de Pinggy

Los desarrolladores que usan Claude Code, Cursor, Claude Desktop o Windsurf como su interfaz principal cada vez más desean que esos agentes manejen más que solo generación de código — incluyendo establecer una URL pública para un servidor local de desarrollo. Pinggy es uno de los primeros proveedores de túneles en formalizar esto con herramientas de agente dedicadas: un Agent Skill y un servidor MCP independiente, ambos publicados bajo una etiqueta de acceso temprano y experimental. Este artículo explica qué hace cada uno, cómo instalarlos correctamente (las rutas de configuración difieren más de lo que esperarías entre clientes), y cómo luce el panorama de seguridad actual una vez que un agente puede abrir un túnel por sí mismo.

Túneles manuales y dónde está la fricción

El flujo de trabajo básico no ha cambiado en años: ejecutar ssh -p 443 -R0:localhost:8000 free.pinggy.io (o el equivalente para ngrok, Cloudflare Tunnel, o lo que uses), copiar la URL resultante y pegarla donde sea necesario — un panel de webhooks, un mensaje en Slack, un archivo .env. Cuando un agente de IA ya controla la terminal, esto es una transferencia manual más entre el contexto del agente y el tuyo.

El Protocolo de Contexto de Modelo (MCP), que Anthropic lanzó a finales de 2024, ofrece a los agentes una forma estandarizada de llamar a herramientas externas en lugar de lanzar comandos en shell y analizar la salida. Una configuración MCP tiene tres partes: hosts (las aplicaciones del agente — Claude Code, Cursor, Claude Desktop, Windsurf), clientes (la conexión del protocolo que mantiene cada host), y servidores (procesos que exponen un conjunto específico de herramientas, recursos o prompts a través de esa conexión). Envolver un cliente de túneles en un servidor MCP significa que el agente llama a una herramienta como start_tunnel directamente, recibe datos estructurados (la URL pública, ID del túnel, estado), y nunca tiene que construir o analizar un comando shell.

Skill vs. servidor MCP: dos cosas diferentes

Pinggy distribuye dos piezas separadas de herramientas para agentes, y vale la pena ser preciso sobre la diferencia, porque la documentación del proveedor es:

	Skill	Servidor MCP
Qué es	Documentación de referencia empaquetada (SSH, CLI, SDK, cada bandera y tipo de túnel) que lee el agente	Un proceso en ejecución que expone operaciones de túnel como herramientas llamables
Qué hace el agente con ello	Lee la documentación y ejecuta comandos por sí mismo vía acceso terminal ordinario	Llama a herramientas directamente — sin construir comandos
Instalación	npx skills add https://pinggy.io	Configuración basada en uvx, por cliente

La propia guía de Pinggy recomienda comenzar con la skill si quieres que el agente entienda la herramienta, y añadir el servidor MCP solo cuando desees que opere túneles de forma autónoma. Ambos pueden instalarse independientemente o juntos, y la instalación de la skill funciona igual en todos los agentes — el CLI detecta el cliente y escribe los archivos de skill en su directorio (~/.claude/skills/pinggy/ por ejemplo para Claude Code).

El resto de este artículo se centra en el servidor MCP, ya que es lo que permite el comportamiento de “túnel sin salir del chat” que la mayoría de la gente asocia con el tunneling impulsado por agentes.

Qué expone realmente el servidor MCP de Pinggy

El servidor es un paquete en Python (requiere Python 3.10+ y uv) publicado en github.com/Pinggy-io/pinggy_mcp. Está explícitamente marcado en su README como experimental — “compartido para retroalimentación temprana, espera bordes ásperos” — lo cual es importante tener en cuenta antes de integrarlo en algo en lo que dependas.

Una vez instalado, registra trece herramientas en cuatro grupos:

Autenticación - authenticate — inicia el flujo OAuth2 de dispositivo y devuelve una URL de login - check_authentication — estado del login, email de la cuenta, expiración del token - get_profile — obtiene tu perfil de cuenta Pinggy - logout — borra la sesión almacenada

Túneles - start_tunnel — HTTP, TCP, TLS, o UDP, con listas blancas de IP opcionales, reescritura de encabezados y depurador web - stop_tunnel, list_tunnels, get_tunnel_info

Compartir archivos - share_directory — expone una carpeta local vía WebDAV a través de una URL pública de Pinggy - stop_file_share, list_file_shares

Gestión de tokens - add_token, remove_token, list_tokens, update_token — para adjuntar un token Pinggy específico (útil para subdominios reservados o dominios personalizados) a un puerto determinado

No llamas a estas directamente; preguntas en lenguaje natural (“exponer puerto 3000,” “listar mis túneles activos,” “solo permitir tráfico desde 1.2.3.4”) y el agente selecciona la herramienta adecuada. Esa parte del marco original era precisa — esto soporta túneles HTTP/TCP/TLS/UDP y compartición de directorios vía WebDAV, no solo HTTP.

Autenticación: esto funciona

La afirmación de que Pinggy usa OAuth 2.0 Device Authorization Grant (RFC 8628) en lugar de tokens API pegados es correcta. Decir “inicia sesión en Pinggy” activa authenticate, que contacta el backend de Pinggy y devuelve una URL; tú la apruebas en un navegador mientras el servidor MCP hace sondeos en segundo plano, y luego guarda y actualiza silenciosamente la sesión en adelante. La sesión se escribe en ~/.config/pinggy-mcp/config.json (Linux/macOS) o %LOCALAPPDATA%\pinggy-mcp\config.json (Windows), con permisos chmod 600 en Unix. Los tokens guardados son opcionales y solo necesarios para cosas que OAuth no cubre, como vincular un subdominio reservado a un puerto local específico.

Instalación — corregido por cliente

Aquí las instrucciones originales tenían errores que vale la pena señalar, ya que una ruta de configuración incorrecta marca la diferencia entre “funciona” y “nada aparece en la lista de herramientas.” Cursor y VS Code usan ubicaciones de configuración diferentes e incluso esquemas JSON distintos (mcpServers vs. servers), y confundirlos, como hacía una versión anterior de estas instrucciones, generará una configuración que el cliente previsto no puede leer.

Claude Code — esta es la vía más sencilla; es un comando CLI de una línea, sin edición manual de archivos:

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

Verifica con claude mcp list.

Claude Desktop — edita el archivo de configuración directamente: - 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"]
    }
  }
}

Reinicia la app; pinggy debería aparecer en el indicador MCP debajo del cuadro de entrada.

Cursor — un camino diferente al de VS Code, a pesar de ser ambos editores: - Global: ~/.cursor/mcp.json - Por proyecto: .cursor/mcp.json en la raíz del proyecto

Tiene la misma estructura JSON que Claude Desktop, arriba.

VS Code — diferente aún, y nota el cambio de esquema (servers, no mcpServers, además de un "type": "stdio" explícito): - macOS/Linux: ~/.vscode/mcp.json - Windows: %APPDATA%\Code\User\mcp.json - O .vscode/mcp.json para configuración a nivel de espacio de trabajo

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

Recarga con Developer: Reload Window desde la paleta de comandos.

Windsurf — edita ~/.codeium/windsurf/mcp_config.json con la misma estructura que la configuración de Claude Desktop, y luego reinicia.

Una inconsistencia en los nombres que vale la pena señalar para quienes navegan por el repositorio: la documentación de Pinggy enlaza a github.com/Pinggy-io/pinggy_mcp como la fuente canónica, pero varios bloques de código en el README del mismo repositorio (las instrucciones para clonación local, en particular) aún hacen referencia a una ruta anterior, github.com/abhimp/pinggy_mcp, antes de que el proyecto se moviera a la organización Pinggy-io. Ambos actualmente se resuelven mediante redirección de GitHub, pero en adelante se debe usar la ruta de la organización Pinggy-io.

Cómo funciona en la práctica el tunneling impulsado por agentes

Un flujo de trabajo ilustrativo (no un caso de estudio documentado del proveedor): estás ejecutando un servidor local de desarrollo y quieres que un cliente lo vea. En lugar de cambiar de terminal, pides a tu agente que inicie el servidor, lo exponga y redacta un mensaje con el enlace. El agente ejecuta el comando de desarrollo, identifica el puerto, llama a start_tunnel, recibe una URL pública, y puede referenciar esa URL — además de lo que sabe sobre tus commits recientes — en la misma ventana de contexto en la que escribió el código. El mecanismo es real (las herramientas existen y hacen esto); cualquier cadena multi-etapa de “y luego envía un email al cliente” es solo un ejemplo de lo que puede lograrse con un agente que también tiene acceso a terminal y archivos, no una función específica de Pinggy.

Las pruebas de webhooks siguen la misma estructura y son probablemente el caso de uso más fuerte: un agente que escribe un manejador de webhooks y además provee el túnel para probarlo contra un servicio de terceros en vivo (Stripe, Shopify, GitHub) no necesita que un humano puente los pasos. Puede llamar a start_tunnel, registrar la URL resultante con el mecanismo de registro de webhooks que tenga (la CLI o API del proveedor, mediante otra llamada a herramienta), y luego disparar un evento de prueba y revisar los logs de la aplicación. La orquestación exacta depende de qué otras herramientas tenga conectadas el agente, no de Pinggy específicamente.

Cómo se compara esto con ngrok y Cloudflare

Pinggy no es el único proveedor de túneles que desarrolla para agentes, y los enfoques difieren en qué buscan optimizar. El principal ángulo de ngrok para agentes es opuesto al de Pinggy: en lugar de un agente operando tu cuenta de ngrok, el patrón documentado de ngrok es usar ngrok como una puerta de enlace que expone un servidor MCP que ejecutas localmente a una plataforma remota de LLM, con controles de identidad y políticas de tráfico en frente — más parecido a una puerta de enlace API para tráfico MCP que a una skill de gestión de túneles. Por separado, existen servidores MCP construidos por la comunidad (a través de Composio y otros) que permiten a un agente gestionar túneles y endpoints de ngrok directamente, similar a lo que Pinggy ofrece de forma nativa, pero estos no son herramientas oficiales de ngrok en el mismo sentido. Cloudflare integra sus servidores MCP con Skills y comandos slash mediante un plugin de Skills de Cloudflare, instalable vía el marketplace de plugins de Claude Code o con la misma CLI npx skills add, pero su soporte abarca toda la plataforma Cloudflare One / Zero Trust en lugar de ser específico para túneles.

Seguridad: qué cubren realmente las salvaguardas integradas y qué no

La presentación original subestimó cuánto riesgo existe en la industria, por lo que vale separar lo que el diseño de Pinggy realmente mitiga del panorama de riesgo general.

Lo que es real en el diseño de Pinggy: - Los túneles viven dentro del proceso del servidor MCP. Cuando la aplicación host (Claude Code, Cursor, Claude Desktop) se reinicia, el servidor también, y todos los túneles en ejecución mueren con él — no hay un demonio en segundo plano persistente. - La autenticación OAuth de flujo de dispositivo significa que el agente nunca maneja un token API en texto plano. - La mayoría de los clientes MCP, incluido Cursor, controlan la ejecución de herramientas tras una aprobación explícita por defecto, por lo que una llamada a start_tunnel suele mostrar un prompt de aprobar/rechazar en lugar de ejecutarse en silencio.

Lo que no cubre: estas son propiedades de un servidor MCP bien construido, no una declaración sobre la seguridad del tunneling MCP en general. Hasta 2026, se ha generado bastante información sobre cómo están las implementaciones MCP en realidad, y no es tan tranquilizador como “la industria ha resuelto esto.” Una auditoría de credenciales de más de 5,200 servidores MCP públicos encontró que aunque el 88% requiere alguna forma de credencial, solo alrededor del 8.5% usa OAuth — la mayoría confía en claves API estáticas o tokens de acceso personal, a menudo pasados vía variables de entorno. La encuesta de Estado de Seguridad en IA 2026 de Cisco encontró que solo el 29% de las organizaciones se sienten preparadas para asegurar despliegues de IA con agentes. Investigaciones separadas en miles de implementaciones MCP en vivo encontraron porcentajes de doble dígito con exposición a traversal de rutas, inyección de código o comandos, en gran parte por cómo el transporte STDIO maneja parámetros entrantes.

El tunneling específicamente introduce un riesgo adicional más allá del MCP genérico: la guía de la Cloud Security Alliance de 2026 sobre MCP agentico señala el secuestro de subdominios como una preocupación activa para servidores MCP expuestos a través de servicios de túneles — si una sesión de túnel termina y su subdominio queda disponible para reasignación, un atacante que lo reclame puede interceptar solicitudes de cualquier cliente que aún tenga la URL antigua en caché. Por eso, en la práctica, se recomienda tratar las URLs de túneles como efímeras, no solo en teoría, y esto apoya la decisión de Pinggy de terminar los túneles al reiniciar el proceso en lugar de mantener un subdominio estable sin supervisión.

Resumen: los túneles con alcance a nivel de proceso y OAuth son mejoras genuinas respecto a pegar un token API de larga duración en el entorno del agente, pero solo abordan una parte de la exposición — no abordan el envenenamiento de herramientas, patrones de deputy confundido donde un servidor MCP sobre-privilegiado actúa sin verificar los permisos reales del solicitante, ni el hecho de que la mayoría del ecosistema aún no ha adoptado OAuth. Aprobar una llamada a start_tunnel es un control razonable; no sustituye tratar cualquier servidor MCP con acceso a archivos o red como algo que requiere la misma atención que la infraestructura de producción.

Limitaciones actuales

• Experimental, según la propia etiqueta del mantenedor. Espera bordes ásperos, cambios en nombres o comportamiento, y reporta problemas en lugar de asumir estabilidad.
• Sin persistencia tras reinicios. Como los túneles dependen del proceso del servidor MCP, no hay “reanudar mi túnel anterior” — debes volver a solicitarlo en cada sesión.
• Esquema de parámetros no documentado. La documentación pública lista nombres y propósitos de herramientas, pero no un referencia completa de parámetros, por lo que las formas exactas de llamada (qué acepta start_tunnel más allá del puerto y protocolo) no son confiables sin revisar el código fuente.

Por dónde va esto

Los servidores MCP de proveedores para infraestructura de desarrollo — túneles, despliegues, acceso a bases de datos — todavía están en una etapa temprana, y “experimental” es la palabra más adecuada que usan la mayoría, incluido Pinggy. La dirección plausible a corto plazo es más del mismo patrón ya visible: un agente llama a una herramienta en lugar de hacer shell, con una URL o recurso público devuelto automáticamente a su contexto. Lo que esto signifique para transferencias multi-agente verdaderamente autónomas — un agente consumiendo directamente el túnel de otro, sin intervención manual — es una extrapolación razonable, pero no está documentado ni en producción aún, y debe considerarse especulación.

---

Registro de cambios

Correcciones y adiciones hechas al borrador original, verificadas contra la documentación en vivo de Pinggy (pinggy.io/docs/ai_agents/) y el repositorio pinggy_mcp en GitHub:

• Ruta del repositorio corregida: el borrador usaba github.com/abhimp/pinggy_mcp; la ruta canónica y documentada actualmente es github.com/Pinggy-io/pinggy_mcp. Se señaló que el README del repositorio aún contiene referencias internas a la ruta antigua.
• Instalación de Claude Code corregida: el borrador solo mostraba edición manual del JSON; el método recomendado es el comando CLI de una línea claude mcp add.
• Rutas en Windows/Linux para Claude Desktop añadidas: el borrador solo implicaba una ruta estilo macOS; se añadieron las rutas correctas en Windows (%APPDATA%\Claude\...) y Linux (~/.config/Claude/...).
• Ruta de configuración de Cursor corregida: el borrador asignaba incorrectamente la ruta de VS Code a Cursor (~/.vscode/mcp.json). Cursor usa ~/.cursor/mcp.json (global) o .cursor/mcp.json (por proyecto).
• VS Code separado como cliente propio con sus rutas correctas y esquema diferente (servers + `