Dejando que los agentes de IA gestionen tus túneles locales

Durante años, la fricción de exponer un servidor de desarrollo local a internet estuvo fuera del alcance de los asistentes de codificación con IA. Podías pedirle a un agente que escribiera un manejador de webhook, pero en el momento en que necesitabas una URL pública — para Stripe, un cliente móvil, una demo para un cliente — salías del chat, abrías una segunda terminal, ejecutabas un comando de tunneling, copiabas una URL y la pegabas en otro lugar. El código se automatizó hace años. El pegamento de red no, hasta que el Model Context Protocol (MCP) proporcionó a los agentes una llamada a herramienta que se conecta directamente al túnel.

Esto no es una revolución terminada — la mayoría de los desarrolladores todavía ejecutan cloudflared o ssh -p 443 -R0:localhost:3000 a.pinggy.io manualmente, y los servidores MCP que automatizan esto, según sus propios mantenedores, están en fase temprana. Pero las piezas son reales, están documentadas y vale la pena entenderlas antes de integrarlas en un agente con acceso a terminal.

El cuello de botella que reemplaza

Probar una integración de webhook nunca fue solo sobre el código. Stripe, Shopify o una App de GitHub necesitan una URL pública para enviar eventos, y tu servidor de desarrollo solo escucha en localhost. El ciclo tradicional:

1. Iniciar el servidor local.
2. Abrir una segunda terminal.
3. Ejecutar un comando de tunneling y esperar a que se conecte.
4. Copiar la URL generada.
5. Pegarla en un panel de control externo.
6. Enviar un evento de prueba.
7. Repetir los pasos 3–6 cada vez que el túnel se reinicia y la URL cambia.

Nada de eso es difícil, pero rompe el flujo de trabajo, y es exactamente el tipo de tarea mecánica y de múltiples pasos que un agente con capacidad de llamada a herramienta puede absorber — siempre que el túnel sea accesible como una herramienta en lugar de un comando de shell memorizado.

MCP es el estándar que hace esto posible

Anthropic liberó el Model Context Protocol como estándar el 25 de noviembre de 2024, para conectar aplicaciones de IA con los sistemas donde viven datos y herramientas. Antes de MCP, conectar un modelo a una herramienta externa requería una integración personalizada para cada par modelo-herramienta — el problema “N×M”, donde N modelos necesitan M conectores. MCP reduce esto a un servidor por herramienta que cualquier cliente compatible puede usar.

La arquitectura tiene tres partes:

• Host — la aplicación para el usuario: un IDE, un cliente de chat de escritorio, un agente personalizado.
• Cliente — la pieza dentro del host que habla MCP y enruta llamadas a servidores.
• Servidor — el proceso externo que expone herramientas (acciones ejecutables), recursos (datos contextuales) y prompts (plantillas reutilizables) al cliente.

Los mensajes se intercambian en JSON-RPC 2.0, y el flujo de solicitudes/respuestas toma ideas del Language Server Protocol — el mismo patrón que permite a cualquier editor comunicarse con cualquier backend de autocompletado de lenguaje sin una integración personalizada por par.

La capa de transporte ya ha cambiado dos veces

La primera versión de MCP (05-11-2024) soportaba dos transportes: stdio para procesos locales con un solo cliente, y HTTP+SSE para servidores remotos. La revisión del 26-03-2025 reemplazó HTTP+SSE por Streamable HTTP — un único endpoint que soporta despliegue sin estado detrás de balanceadores de carga y sesiones reanudables, que el diseño original de doble endpoint SSE manejaba mal. SSE se mantiene solo por compatibilidad, y varios proveedores ya han establecido fechas de desuso.

Pero eso no fue todo. El 28-07-2026 — poco más de una semana antes de escribir esto — los mantenedores del protocolo lanzaron la revisión 2026-07-28, que elimina el apretón de manos de sesión a nivel de protocolo, haciendo a MCP sin estado por defecto: el servidor ya no necesita rastrear un cliente entre llamadas, lo que permite responder a cualquier solicitud desde cualquier instancia detrás de infraestructura HTTP normal, sin necesidad de afinidad de sesión. También formaliza un marco de extensiones (las MCP Apps, que permiten a una herramienta renderizar su propia UI) y una política de ciclo de vida de funciones que garantiza al menos doce meses entre una capacidad siendo deprecada y eliminada. Los clientes y servidores existentes de 25-11-2024 siguen funcionando — la nueva revisión es opcional en la actualización, y un servidor compatible puede responder a ambas versiones desde un mismo endpoint.

La adopción fue rápida

OpenAI añadió soporte MCP a su SDK de Agentes el 26-03-2025 (“disponible hoy”, según Sam Altman, con soporte para Responses API y la versión de escritorio de ChatGPT). Google DeepMind confirmó que Gemini adoptaría MCP en abril de 2025. Para diciembre 9, 2025, Anthropic donó la gobernanza del protocolo a la Fundación Agentic AI, un fondo dirigido bajo la Linux Foundation, cofundada por Anthropic, Block y OpenAI, con AWS, Google, Microsoft, Cloudflare y Bloomberg como miembros platino. En ese momento, MCP tenía más de 10,000 servidores públicos activos y más de 97 millones de descargas mensuales del SDK; para la versión de julio de 2026, los mantenedores reportaron casi medio billón de descargas mensuales, con los SDK de TypeScript y Python superando cada uno los mil millones en total. El modelo de gobernanza sigue siendo comunitario — la membresía en el proceso técnico está vinculada a individuos, no a las empresas.

Skills y servidores MCP son cosas distintas

Los proveedores de tunneling que se mencionan usan también un mecanismo relacionado: Skills de Agente. Una skill es un conjunto empaquetado de instrucciones y material de referencia — flags de CLI, uso del SDK, prompts de ejemplo — que un agente lee una sola vez y ejecuta usando acceso terminal normal. Un servidor MCP, en cambio, es un proceso en ejecución que la misma herramienta llama directamente como una herramienta, sin reconstruir un comando desde documentación. Se publican bajo un estándar comunitario compartido (skills CLI, distribuido vía npx skills add <url>) y se instalan en el directorio de skills del agente — para Claude Code, en ~/.claude/skills/<nombre>/. La guía de los proveedores es la misma: empieza con la skill si quieres que el agente entienda la herramienta; añade el servidor MCP cuando quieras que el agente lo opere de forma autónoma.

Skill y servidor MCP de Pinggy

Pinggy ofrece ambos, y pueden instalarse independientemente.

La skill:

npx skills add https://pinggy.io

Esto obtiene el manifiesto desde https://pinggy.io/.well-known/skills/ y escribe los archivos de la skill en el directorio de skills del agente. El único requisito es Node.js.

El servidor MCP — fuente en github.com/Pinggy-io/pinggy_mcp — requiere Python 3.10+ y uv:

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

Nada se instala globalmente; cada cliente ejecuta pinggy-mcp bajo demanda con uvx. Para Claude Code, el registro se hace con un comando CLI en lugar de un archivo de configuración:

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

Claude Desktop, Cursor y Windsurf usan una clave mcpServers en un archivo JSON de configuración (las rutas varían por cliente y sistema operativo); VS Code usa una clave servers en el nivel superior. Es importante notar que la documentación de Pinggy etiqueta su servidor MCP como “temprano y experimental” y pide feedback, no como una solución lista para producción.

Una vez conectado, los prompts de ejemplo documentados de Pinggy muestran la superficie real — no una hipótesis:

• “Exponer mi servidor de desarrollo en el puerto 3000.”
• “Abrir un túnel TCP a localhost:22.”
• “Compartir mi carpeta ~/Downloads por internet.”
• “Listar mis túneles activos.”
• “Permitir solo tráfico desde 1.2.3.4 a mi túnel.”
• “Detener el túnel.”

Un detalle dirigido directamente al consumo por agentes, no humanos: cada página de documentación de Pinggy también se publica en Markdown simple en la misma ruta con sufijo index.md, y todo el sitio se resume en pinggy.io/llms.txt — permitiendo que un agente lea la documentación directamente en lugar de hacer scraping de HTML renderizado.

La superficie MCP de Cloudflare es más amplia que “túneles”

Los servidores MCP de Cloudflare no se centran solo en cloudflared; cubren toda la API de Cloudflare. El principal, el servidor MCP de la API de Cloudflare (github.com/cloudflare/mcp, alojado en https://mcp.cloudflare.com/mcp), expone más de 2,500 endpoints en DNS, Workers, R2 y Zero Trust mediante solo dos herramientas: search() y execute(). En lugar de cargar un esquema para cada endpoint, el modelo escribe JavaScript contra una representación tipada del OpenAPI, que se ejecuta en un sandbox de Dynamic Worker — el patrón “Code Mode” de Cloudflare. La matemática del token es clave: exponer todos los 2,594 endpoints con esquemas completos costaría aproximadamente 1.17 millones de tokens solo para listar las herramientas; el enfoque de dos herramientas en Code Mode cuesta unos 1,000 tokens sin importar el catálogo.

Además, Cloudflare ejecuta servidores MCP específicos por dominio: un servidor de documentación, uno de enlaces de Workers, uno de observabilidad, un servidor Radar para datos de tráfico, logs de auditoría, análisis DNS, y otros, cada uno en su subdominio (ej. docs.mcp.cloudflare.com/mcp). No hay un servidor “Túnel” dedicado en esa lista; gestionar un Cloudflare Tunnel — listar túneles activos, verificar estado, actualizar reglas de ingreso — se hace a través del servidor MCP general usando search/execute contra los endpoints de Tunnel y Zero Trust, igual que cualquier recurso de Cloudflare. Si quieres que un agente vincule un nuevo entorno de vista previa a un subdominio, está usando la misma superficie de 2,500+ endpoints, no llamando a una herramienta específica de túnel.

Cloudflare también incluye sus servidores MCP con skills contextuales y comandos slash mediante un plugin de Skills de Cloudflare (github.com/cloudflare/skills), instalable desde el marketplace de plugins de Claude Code (/plugin marketplace add cloudflare/skills), desde el Marketplace de Cursor, o usando el mismo CLI npx skills add que Pinggy.

Portales de servidores MCP: la capa de control empresarial real

La respuesta de Cloudflare a “no puedes dar a un LLM tu token API sin supervisión” son los portales de servidores MCP, parte de Cloudflare One Zero Trust. Un portal centraliza múltiples servidores MCP en un único endpoint HTTP protegido por Cloudflare Access. Lo que hace, en concreto:

• Autenticación: los usuarios ingresan al portal mediante Cloudflare Access con su proveedor de identidad; el portal también solicita OAuth si es necesario.
• Exposición selectiva de herramientas: los administradores pueden desactivar herramientas o prompts por servidor, o hacer una lista blanca donde solo las herramientas habilitadas sean visibles — útil cuando un servidor expone más de lo que un equipo debería tocar.
• Code Mode por defecto: todos los recursos se agrupan en una sola herramienta code que el agente escribe en JavaScript, en un Dynamic Worker aislado — esto mantiene el uso del tamaño de ventana de contexto constante, sin importar cuántos servidores se agreguen.
• Logs: registros por solicitud (tiempo, estado, servidor, herramienta, duración) disponibles en el panel, con export Logpush a SIEM en planes Enterprise.
• Enrutamiento Gateway opcional: el tráfico del portal puede enrutarse a través de Cloudflare Gateway para escaneo DLP, bloqueando llamadas a herramientas o respuestas que contengan credenciales o datos financieros antes de llegar al modelo o al servidor upstream.

La advertencia honesta, directamente de la documentación de Cloudflare: MFA independiente, prompts de justificación de propósito y políticas de autenticación temporal no se aplican a servidores MCP autorizados mediante un portal, incluso si esas políticas están configuradas en otra parte de la misma aplicación Access. Así que “portal” te da OAuth centralizado, herramientas curadas y logs DLP — controles reales — pero no reemplaza todas las funciones de políticas de Access que ya uses para usuarios humanos.

Un ejemplo práctico de webhook

Stripe es un objetivo común para este flujo de trabajo, y es importante hacerlo bien, porque sus capacidades MCP no se alinean con “el agente hace todo.”

El servidor MCP de Stripe está en https://mcp.stripe.com. A diferencia de otros MCP, soporta tanto el flujo OAuth interactivo estándar como una clave API restringida pasada como token bearer — un camino documentado y soportado para agentes sin cabeza o autónomos, no solo un hueco a evitar. Sus herramientas cubren info de cuenta, reembolsos, búsqueda y obtención de recursos, búsqueda en documentación y planificación de integración, además de herramientas genéricas stripe_api_read, stripe_api_write y API-search que alcanzan la mayor parte de la superficie REST sin inflar la lista.

El límite importante para un flujo de prueba de túnel: un agente puede crear o actualizar un endpoint de webhook — incluyendo apuntar su URL a un túnel nuevo — usando la herramienta genérica de escritura. Pero no puede suscribirse ni consumir el flujo de eventos en vivo del webhook a través de MCP; reaccionar a eventos entrantes sigue siendo una preocupación de infraestructura REST/webhook fuera del protocolo. Un ejemplo realista sería:

1. Pedirle al agente que inicie el servidor local y lo exponga con la herramienta MCP de Pinggy o Cloudflare.
2. Pedirle que actualice la URL del webhook de Stripe al nuevo túnel, usando la herramienta de escritura MCP de Stripe.
3. Generar un evento de prueba desde el panel o CLI de Stripe, o que el agente lo haga si usas la CLI de Stripe.
4. Confirmar que tu servidor local lo recibió y analizó.

La documentación de Stripe recomienda activar confirmación humana en sus herramientas de escritura y tener precaución al combinar el servidor MCP de Stripe con otros, por el riesgo de inyección de prompts — consejo válido para cualquier servidor MCP que pueda mover dinero o reconfigurar facturación. (Pinggy publica su propia guía para probar webhooks de Stripe — base útil, esté o no usando un agente.)

Cómo están los IDEs con capacidad de agente a mediados de 2026

Los tres editores más asociados con este flujo han cambiado desde la última comparación:

• Cursor (de Anysphere) está en medio de la mayor adquisición respaldada por venture capital en la historia. La Serie D de Cursor en noviembre de 2025 valuó la empresa en $29.3 mil millones; SpaceX aseguró una opción de adquisición en abril de 2026, y el 16 de junio de 2026 firmaron un acuerdo definitivo por acciones que valora a Anysphere en $60 mil millones, con la intención de integrar Cursor en las ambiciones de IA de SpaceX (ya fusionadas con xAI). La operación aún no cierra — se espera que en el Q3 de 2026, pendiente de revisión regulatoria — así que Cursor sigue operando independientemente.
• Windsurf empezó como el IDE agentico de Codeium. En julio de 2025, Google DeepMind contrató a Windsurf’s CEO, cofundador y principales investigadores en un acuerdo de aproximadamente $2.4 mil millones, sin participación accionaria en Google; días después, el 14 de julio de 2025, Cognition AI (creador del agente de codificación autónomo Devin) adquirió el resto del producto, IP, marca y unos 210 empleados, por aproximadamente $250 millones. El 2 de junio de 2026, Cognition renombró el producto Devin Desktop con una actualización OTA — el IDE, planes y extensiones permanecieron iguales, y el agente local ahora se llama Devin Local, con acceso en la nube en la versión de pago.
• Claude Code ahora funciona en seis superficies compartiendo un motor: la terminal original, una extensión de VS Code, un plugin de JetBrains, una app de escritorio independiente, una interfaz web en claude.ai/code (lanzada el 20 de octubre de 2025), y una integración en Slack, con móvil como superficie de control para sesiones remotas. La configuración, memoria de proyectos (CLAUDE.md) y conexiones MCP son compartidas; un servidor registrado una sola vez está disponible desde la terminal, el IDE o la app de escritorio.

Los tres son clientes MCP, que es el punto clave: el túnel no importa desde qué editor se controle, y un servidor MCP de Pinggy o Cloudflare configurado una vez debe comportarse igual sin importar qué editor hizo la llamada a la herramienta — salvo las particularidades de cada archivo de configuración.

Consideraciones de seguridad

Nada de lo anterior elimina la necesidad de juicio. La documentación de MCP en VS Code lo dice claramente: los servidores MCP locales pueden ejecutar código arbitrario en tu máquina, así que solo añade los de fuentes confiables y revisadas. Esto es especialmente importante para Pinggy, dado que sus mantenedores etiquetan su servidor como “temprano y experimental”.

Existe un modo de fallo más amplio, importante de conocer, incluso si no es específico de tunneling: los agentes tienden a tratar la salida de herramientas MCP como datos confiables, no como entrada no confiable, igual que un prompt del sistema en lugar de un mensaje externo. Investigadores de seguridad han demostrado esto con otras integraciones MCP — por ejemplo, inyectando eventos falsos en servicios de seguimiento de errores para que un agente de codificación conectado a MCP “arregle” un bug inexistente ejecutando instrucciones maliciosas. La lección general: cualquier servidor MCP en el que confíes es parte de tu superficie de ataque, aunque el proveedor diga que es experimental. Limitar privilegios — permitir IPs específicas en el túnel, exponer solo herramientas necesarias, confirmar acciones con humanos — es la mitigación actual, no una solución definitiva.

La conclusión

Gestionar túneles mediante una llamada a herramienta MCP es un patrón real y funcional hoy, no solo una promesa — el servidor y skill de Pinggy, los servidores MCP de Cloudflare y Stripe están activos, documentados y verificables. Pero “temprano y experimental” es la etiqueta del proveedor para la pieza que realiza el túnel, el protocolo en sí acaba de pasar su mayor cambio desde su lanzamiento, y los IDEs que lo orquestan están en medio de adquisiciones o rebrandings. Si integras esto en un flujo de trabajo hoy, trátalo como cualquier infraestructura: revisa qué hace realmente el servidor antes de darle acceso a la red, limita lo que puede alcanzar y no asumas que “el agente preguntó amablemente” equivale a “esto es seguro para exponer”.

---

Cambios recientes

Este texto fue reescrito desde un borrador anterior. Correcciones y adiciones, verificadas con fuentes primarias:

1. Se eliminó el marco de “obsoleto”/“revolución”. El borrador original presentaba los túneles gestionados por IA como un cambio ya completo en la forma de trabajar de todos los desarrolladores. Se reformuló como un patrón emergente, útil y en desarrollo, que la mayoría aún no usa a diario — en línea con que el servidor MCP de Pinggy está etiquetado como “temprano y experimental” (pinggy.io/docs/ai_agents/) en lugar de listo para producción.

2. Se corrigió el comando de instalación de skill de Pinggy. El borrador usaba npx skills add pinggy/skills. La documentación de Pinggy especifica npx skills add https://pinggy.io, instalando desde el manifiesto en pinggy.io/.well-known/skills/. (pinggy.io/docs/ai_agents/)

3. Se corrigieron y completaron los detalles del servidor MCP de Pinggy. Se añadió la fuente real en GitHub (github.com/Pinggy-io/pinggy_mcp), los requisitos en Python 3.10+ y uv, el comando de registro correcto:

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

Se aclaró que VS Code usa la clave servers, mientras que Claude Desktop, Cursor y Windsurf usan mcpServers. Se reemplazó el ejemplo de prompts por los prompts documentados de Pinggy:

• “Exponer mi servidor de desarrollo en el puerto 3000.”
• “Abrir un túnel TCP a localhost:22.”
• “Compartir mi carpeta ~/Downloads por internet.”
• “Listar mis túneles activos.”
• “Permitir solo tráfico desde 1.2.3.4 a mi túnel.”
• “Detener el túnel.”

Cada página de docs de Pinggy también se publica en Markdown simple en la misma ruta con index.md, y todo el sitio se resume en pinggy.io/llms.txt para que un agente pueda leer la documentación sin hacer scraping.

1. Se especificó la arquitectura real de los servidores MCP de Cloudflare. Incluyendo el patrón de search()/execute() en Code Mode, los más de 2,500 endpoints, y que no existe un “servidor Túnel” dedicado; la gestión de túneles y DNS se realiza a través del servidor MCP general usando los mismos endpoints.

2. Se documentaron los portales MCP de Cloudflare con sus funciones reales, incluyendo autenticación OAuth, exposición selectiva de herramientas, Code Mode por defecto, logs, enrutamiento Gateway y restricciones, además de la limitación en políticas MFA y autenticación temporal en servidores autorizados mediante portal.

3. Se verificó la historia y arquitectura del MCP, incluyendo la fecha de lanzamiento (25-11-2024), el esquema N×M, y la estructura de host/cliente/servidor, además de la comunicación en JSON-RPC 2.0 y el patrón de mensajes derivado del LSP.

4. Se añadieron los cambios en transporte, incluyendo la deprecación de HTTP+SSE en 26-03-2025 y la introducción de Streamable HTTP, y la actualización en 28-07-2026 que hace MCP sin estado por defecto.

5. Se incluyeron datos de adopción y gobernanza, con soporte en SDKs de OpenAI (marzo 2025), Gemini (abril 2025), y la donación de MCP a la Foundation en diciembre 2025, con cifras de uso y descargas.

6. Se ajustó el tutorial de webhooks de Stripe para reflejar que los agentes pueden crear/actualizar endpoints, pero no consumir eventos en vivo, y se añadió la recomendación de Stripe sobre confirmación humana y precaución contra inyección de prompts.

7. Se actualizó la sección de IDEs con detalles precisos sobre Cursor, Windsurf y Claude Code, incluyendo fechas, adquisiciones, rebranding y características.

8. Se añadió una sección de seguridad concreta, citando la guía de seguridad de MCP en VS Code y ejemplos de ataques reales, para enfatizar que la salida de MCP no debe considerarse automáticamente confiable.

9. Se eliminaron detalles no verificables o fabricados, como herramientas específicas de gestión de túneles o WAF, que no tenían fuentes primarias.

10. Se eliminó el enfoque de SEO y la narrativa de “junior DevOps”, reemplazando por un cierre que explica claramente los riesgos y recomendaciones.