El flujo de trabajo del agente AI: soporte nativo MCP en túneles locales

El año 2026 ha introducido una necesidad muy específica, pero cada vez más común en los flujos de trabajo de desarrolladores: agentes AI que pueden abrir, gestionar y cerrar túneles de red locales sin que un humano tenga que pegar URLs entre una terminal y una interfaz de chat. A medida que asistentes de codificación como Claude Code, Cursor y Windsurf han asumido más acceso a terminal y entornos, su capacidad para interactuar directamente con infraestructura local se ha convertido en un cuello de botella para quienes prueban webhooks o comparten un servidor de desarrollo.

En lugar de depender de métodos tradicionales de reenvío de puertos diseñados para operadores humanos, algunos servicios de túneles — rustunnel y Pinggy, entre los principales — ahora distribuyen servidores dedicados del Protocolo de Contexto de Modelo (MCP) que permiten a un agente operar túneles directamente. Anthropic también ha lanzado su propio producto bajo el nombre literal “túneles MCP,” aunque resuelve un problema diferente al que trata principalmente este artículo — más abajo se explica.

Esta guía cubre qué es realmente un túnel MCP (hay ahora dos significados distintos de esa frase), qué exponen realmente las herramientas de agentes de rustunnel y Pinggy, cómo difieren las instrucciones de instalación según el cliente, y dónde encajan las puertas de enlace MCP como Bifrost cuando se ejecutan más de un par de servidores.

---

1. La evolución del flujo de trabajo del agente AI

El ciclo anterior no ha desaparecido: iniciar un túnel inverso desde la CLI, esperar la conexión, copiar la URL pública generada y pegarla en un panel de control de terceros y en una ventana de chat. Eso funciona para una sola vez, pero rompe el flujo autónomo de un agente que ya controla la terminal — si Claude Code está implementando y probando un endpoint webhook, no debería tener que detenerse y pedir una URL pública a un humano.

El Protocolo de Contexto de Modelo, que Anthropic publicó como código abierto el 25 de noviembre de 2024, fue lo que cambió esto. MCP define tres roles: un host (la aplicación AI — Claude Code, Cursor, Claude Desktop, Windsurf, y ahora ChatGPT y GitHub Copilot también), un cliente (la conexión del protocolo que mantiene el host con un servidor dado), y un servidor (un proceso que expone un conjunto específico de herramientas, recursos o prompts). Antes de que existiera un protocolo compartido, conectar M aplicaciones AI diferentes con N herramientas distintas requería casi M×N integraciones personalizadas; MCP reduce eso a aproximadamente M+N, ya que cada lado solo tiene que implementar el protocolo una vez. La adopción fue rápida — Microsoft y GitHub se unieron al comité directivo de MCP en Build 2025, y OpenAI añadió soporte MCP a su SDK de Agentes y API de Respuestas ese mismo año.

Para el tunneling específicamente, esto significa que un agente puede llamar a una herramienta como create_tunnel directamente y recibir datos estructurados (una URL pública, un ID de túnel, un estado) en lugar de lanzar un comando CLI y analizar lo que aparece en stdout.

---

2. Desmitificando el “Túnel MCP” — Dos cosas diferentes en 2026

Aquí es donde una versión preliminar de este artículo necesitó la mayor corrección estructural: “túnel MCP” ahora se refiere a dos arquitecturas genuinamente distintas, y confundirlas enviará a los lectores a la herramienta equivocada.

2a. Túneles gestionados por agentes (el tema principal de este artículo)

Este es el patrón que rustunnel y Pinggy construyen: un cliente de un proveedor de túneles corre junto a un servicio local y llama saliente a través de TLS a un servidor de borde público. El agente llama a una herramienta MCP para abrir, listar y cerrar estos túneles. Dirección del tráfico: máquina local → internet público, con el agente AI como operador.

• Sin reglas entrantes. Nada se expone hasta que el cliente llama saliente; los firewalls corporativos que permiten HTTPS saliente no necesitan cambiar.
• Exposición limitada. A diferencia de una VPN, un túnel expone una instancia de servicio, no toda la red.
• Transporte cifrado, generalmente con autenticación propia del proveedor del túnel (OAuth, tokens bearer, o un token API por cuenta) en la capa superior.

2b. “Túneles MCP” propios de Anthropic (un producto diferente, en dirección opuesta)

Anthropic lanza una función en Claude Platform (antes Claude Developer Platform / Console) llamada literalmente “túneles MCP,” que resuelve el problema inverso: conectar Claude a un servidor MCP que vive dentro de una red privada, sin abrir puertos entrantes en esa red. Dirección del tráfico: Claude → tu red privada.

La arquitectura: una pila ligera de túnel (un proxy más un contenedor cloudflared) corre dentro de tu red y abre una conexión saliente a Cloudflare, que Anthropic usa como subprocesador para esta función. Se despliega con Helm (Kubernetes) o Docker Compose, se registra un certificado CA a través de la consola de Claude, y tu servidor MCP privado se vuelve accesible en algo como https://<subdominio>.<tu-dominio-túnel>/mcp — visible solo para Agentes Gestionados por Claude y la API de Mensajes, nunca en internet público. El proxy es deliberadamente conservador: por defecto solo llama a direcciones en los rangos privados RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).

Al momento de escribir esto, los túneles MCP están en vista previa de investigación, disponibles para organizaciones en el plan empresarial de Claude bajo solicitud, y se entregan “tal cual” — sin garantías de tiempo de actividad, soporte o continuidad, y dependientes de la disponibilidad de Cloudflare. Si estás construyendo una arquitectura de “el agente accede a nuestra base de datos privada” que esta función apunta, vale la pena solicitar acceso antes de buscar una solución de terceros; si estás construyendo el flujo “el agente expone mi portátil a internet para una demo o prueba webhook,” esa es la sección 2a, y el resto de este artículo.

---

3. rustunnel y el auge del operador-agente

La mayoría de los servicios de túneles aún asumen que un humano está en la terminal. rustunnel — un servidor de túneles autohospedado, con licencia AGPLv3, escrito en Rust, con un servicio gestionado opcional de pago por uso — fue diseñado pensando en que el agente sea el operador principal. Es un proyecto realmente pequeño (635 estrellas en GitHub al momento) pero su integración MCP está inusualmente bien documentada para su tamaño.

Cómo se distribuye realmente

Una corrección importante: el servidor MCP de rustunnel (rustunnel-mcp) no es un paquete npm que se ejecuta con npx. Es un binario nativo en Rust, distribuido igual que el cliente CLI rustunnel — mediante Homebrew (brew tap joaoh82/rustunnel && brew install rustunnel), que instala ambos binarios, o compilado desde fuente con cargo build --release -p rustunnel-mcp. Habla MCP vía stdio.

La interfaz de la herramienta cubre todo el ciclo de vida del túnel — seis herramientas, no cuatro:

Herramienta	Descripción
create_tunnel	Abre un túnel y devuelve la URL pública — HTTP/TCP/UDP, P2P, y pools balanceados con verificaciones de salud
list_tunnels	Lista todos los túneles activos
close_tunnel	Cierra forzosamente un túnel por ID
list_regions	Lista las regiones de servidores disponibles
get_connection_info	Devuelve el comando CLI para agentes en la nube o sandbox
get_tunnel_history	Recupera la actividad pasada del túnel

El servicio alojado opera en tres regiones — eu (Helsinki), us (Hillsboro, OR), y ap (Singapur) — y el cliente selecciona automáticamente la más cercana, a menos que la fijes. Precios: gratis hasta 3 túneles sin subdominios personalizados, pago por uso a $3/mes mínimo más $0.10/GB (túneles ilimitados, subdominios personalizados), o autohospedado gratis. Las implementaciones autohospedadas pueden exponer métricas Prometheus y un registro de auditoría en formato JSON-lines — ambas opciones de configuración en el servidor que ejecutes, no en el plan gestionado por defecto, así que no asumas que el servicio gestionado registra tus cargas útiles sin verificar sus términos actuales.

El ciclo autónomo, corregido

El escenario que describía un borrador — hacer que Claude Code implemente un manejador webhook de Stripe, lo exponga y actualice un script en un panel — es real y funciona aproximadamente así, con dos correcciones: el patrón de URL del túnel está limitado por región (https://abc123.eu.edge.rustunnel.com, no un dominio .rustunnel.net sin más), y get_connection_info no devuelve “latencia, datos de región y registros de solicitudes” — según la propia documentación de rustunnel, devuelve el comando CLI que un agente en la nube o sandbox necesita para reconectarse, que es una tarea más estrecha y específica que la que sugirió el borrador.

Cómo instalarlo

Tres caminos documentados, en orden ascendente de esfuerzo manual:

Plugin de Claude Code (el más simple, según el README de rustunnel):

/plugin install rustunnel

El plugin solicita tu dirección de servidor y token API una vez, los almacena y arranca el servidor MCP en segundo plano — sin editar .mcp.json. Una advertencia: esto difiere del patrón de dos pasos que usan la mayoría de plugins de Claude Code (/plugin marketplace add <propietario>/<repositorio> seguido de /plugin install <nombre>@<marketplace>). Si la línea única no funciona en tu versión de Claude Code, prueba con /plugin marketplace add joaoh82/rustunnel y revisa plugins/claude-code/ en el repositorio para el nombre exacto del plugin.

Registro manual vía stdio:

claude mcp add --transport stdio rustunnel \
  --env RUSTUNNEL_TOKEN=TU_TOKEN \
  -- rustunnel-mcp --server edge.rustunnel.com:4040 --api https://edge.rustunnel.com:8443

Claude Desktop (o Windsurf, Cline — misma estructura JSON), editado directamente:

{
  "mcpServers": {
    "rustunnel": {
      "command": "rustunnel-mcp",
      "args": ["--server", "edge.rustunnel.com:4040", "--api", "https://edge.rustunnel.com:8443"],
      "env": { "RUSTUNNEL_TOKEN": "<tu-token>" }
    }
  }
}

Para Cursor, rustunnel también ofrece un enlace profundo de “Agregar a Cursor” en su README que pre-llena esta configuración — solo necesitas pegar tu token API después.

---

4. Comparando el ecosistema de túneles en 2026

ngrok

La historia de MCP de ngrok propia no es no gestionada por el agente — es al revés. El patrón documentado de ngrok es usar ngrok como un gateway MCP: ejecutas el agente de ngrok junto a tu propio servidor MCP autohospedado, declaras un Endpoint interno del Agente, y usas el motor de Políticas de Tráfico de ngrok para autenticar y restringir qué clientes (por ejemplo, solo rangos IP publicados por Anthropic) pueden acceder. Eso es una capa de seguridad y observabilidad delante de un servidor MCP que ya gestionas, más parecido en espíritu a Kong o Bifrost (sección 7) que a lo que hace rustunnel. Si quieres que un agente opere tu cuenta de ngrok — creando y cerrando túneles como los herramientas de rustunnel — eso también existe, pero solo a través de servidores comunitarios (por ejemplo, ngrok-mcp en GitHub, o la caja de herramientas ngrok de Composio), no con herramientas oficiales de ngrok.

Pinggy

Una versión preliminar de este artículo describió a Pinggy como “muy efectivo para exponer herramientas, pero menos enfocado en que el agente gestione el túnel en sí”. Eso subestimó la historia actual de Pinggy: en realidad, ofrece dos piezas de herramientas — una Skill de Agente (npx skills add https://pinggy.io, documentación que el agente lee antes de ejecutar sus propios comandos) y un servidor MCP independiente, en acceso temprano (pinggy_mcp, un paquete en Python con uv) que registra trece herramientas para autenticación, gestión de túneles (start_tunnel, stop_tunnel, list_tunnels, get_tunnel_info), compartición de directorios WebDAV y gestión de tokens. La autenticación usa OAuth 2.0 Device Authorization Grant (RFC 8628) en lugar de una clave API pegada. Está claramente marcado como experimental por su mantenedor, y los túneles dependen del proceso del servidor MCP — no sobreviven a un reinicio del host, lo cual puede ser una ventaja: no hay un demonio en segundo plano que mantenga un subdominio público abierto.

Para el patrón más estrecho de “exponer un servidor MCP privado ya en ejecución a un agente en la nube remoto” (no gestión del túnel, solo creación para un servidor específico), la simple conexión SSH todavía funciona exactamente igual:

ssh -p 443 -R0:localhost:5000 a.pinggy.io

claude mcp add --transport http MyLocalDB https://rndm-string.pinggy.link/mcp

Cloudflare Tunnel

Faltaba en versiones anteriores, y vale la pena incluir: Cloudflare incluye herramientas para su plataforma de desarrolladores — no solo para túneles — a través de un plugin de Skills (/plugin marketplace add cloudflare/skills y luego /plugin install cloudflare@cloudflare). La skill cloudflare cubre Workers, almacenamiento, IA y redes, incluyendo Tunnel y Spectrum, junto con los servidores MCP gestionados de Cloudflare para operaciones de cuenta (DNS, reglas WAF, etc.) vía OAuth. No hay una herramienta dedicada de create_tunnel como rustunnel o Pinggy — un agente que use Cloudflare Tunnel todavía controla principalmente cloudflared mediante conocimientos de CLI que la skill le enseña, no llamando a una herramienta de gestión de túneles específica.

LocalCan, LocalXpose, frp, Playit.gg y localhost.run

Estas siguen siendo precisas respecto a la estructura original. LocalCan (integración nativa en macOS con dominio .local) y LocalXpose (interfaz gráfica/CLI multiplataforma, con un cliente oficial node-localxpose) son útiles para desarrolladores humanos, pero no tienen un servidor MCP de primera mano confirmado — integrarlos en un agente requiere construir un envoltorio alrededor de su CLI o API REST. frp sigue siendo el estándar autohospedado para cargas de trabajo intensivas en UDP y juegos, y Playit.gg, con enrutamiento anycast, cubre la misma necesidad sin reenvío de puertos; ambos son infraestructura de nivel inferior que necesitaría un servidor MCP personalizado para traducir solicitudes en lenguaje natural a cambios en archivos de configuración. localhost.run sigue llenando el mismo nicho basado en SSH, sin instalación, para exponer rápidamente un gateway MCP existente (como Bifrost, cubierto abajo) a un cliente remoto.

---

5. Integrando túneles MCP con Claude Code

Claude Code soporta tres transportes MCP: stdio (por defecto, para procesos locales), HTTP (recomendado para servidores remotos/en la nube), y SSE, que se está eliminando en favor de HTTP. Los tres se registran mediante claude mcp add, o editando manualmente .mcp.json / ~/.claude.json.

Certificados autofirmados y TLS en desarrollo local

Si apuntas Claude Code a un proxy de túnel local con certificado autofirmado, verás unable to verify the first certificate — los clientes MCP basados en Node.js (incluido Claude Code) rechazan certificados autofirmados por defecto. La solución documentada es exactamente lo que mostró un borrador de este artículo:

{
  "env": {
    "NODE_TLS_REJECT_UNAUTHORIZED": "0"
  }
}

en ~/.claude/settings.json. Un aspecto adicional: esto desactiva la verificación de certificados para todas las conexiones salientes de Claude Code en esa sesión — incluyendo api.anthropic.com y el registro MCP, no solo tu túnel local. La comunidad de ingeniería de Anthropic ha señalado que este alcance es más amplio de lo que la mayoría espera; úsalo solo como una bandera temporal para desarrollo local, ejecutándolo como NODE_TLS_REJECT_UNAUTHORIZED=0 claude en una sola sesión cuando sea posible, en lugar de ponerlo en configuraciones globales, y si puedes, usa NODE_EXTRA_CA_CERTS apuntando a tu certificado CA real, ya que eso limita la confianza a un solo certificado en lugar de desactivar la verificación por completo.

---

6. Integrando con Cursor y Windsurf

Cursor y Windsurf configuran MCP mediante archivos JSON en lugar de CLI. Los caminos no son tan intercambiables como parecen:

• Cursor — global: ~/.cursor/mcp.json; por proyecto: .cursor/mcp.json en la raíz del proyecto.
• Windsurf — ~/.codeium/windsurf/mcp_config.json.

Ambos usan la misma estructura JSON mcpServers que Claude Desktop:

{
  "mcpServers": {
    "rustunnel": {
      "command": "rustunnel-mcp",
      "args": ["--server", "edge.rustunnel.com:4040", "--api", "https://edge.rustunnel.com:8443"],
      "env": { "RUSTUNNEL_TOKEN": "tu_token_api" }
    }
  }
}

Un detalle importante: VS Code usa un esquema diferente (servers, no mcpServers, y un campo explícito "type": "stdio") en ~/.vscode/mcp.json o .vscode/mcp.json. No reutilices la configuración de Cursor para VS Code — no será leída correctamente.

Una vez guardado, el agente de Cursor o Windsurf detecta automáticamente el nuevo servidor. Pídele que “exponga el frontend de Next.js a internet” y llamará a create_tunnel (o start_tunnel de Pinggy) por sí mismo.

---

7. Escalando con puertas de enlace MCP: Bifrost y Kong

Conectar un agente a un servidor MCP de túneles, a un servidor de base de datos y a un servidor de búsqueda individualmente es trivial al principio — deja de serlo cuando un equipo gestiona diez o quince servidores MCP. Cada servidor típicamente expone de 10 a 30 definiciones de herramientas, y Claude Code carga todo el catálogo de herramientas de cada servidor conectado en contexto antes de procesar una sola token de tu prompt. Ahí es donde entran las puertas de enlace MCP.

Bifrost

Bifrost es una puerta de enlace de IA de código abierto, en Go, de Maxim AI, que actúa como cliente MCP (conectando hacia afuera a tu servidor de túneles, herramientas de base de datos, etc.) y como servidor MCP (exponiendo un endpoint /mcp agregado hacia adentro a Claude Code). Configurarlo es un solo comando — nota el esquema corregido, http en lugar de https para una instancia local:

claude mcp add --transport http bifrost http://localhost:8080/mcp

Bifrost añade aproximadamente 11 microsegundos de sobrecarga por solicitud a 5,000 solicitudes/segundo, y su “Modo Código” — donde el modelo escribe código contra definiciones de herramientas en lugar de tener todo el esquema de herramientas inyectado en contexto — ha sido medido para reducir los tokens de entrada hasta en un 92% en sus propias pruebas, manteniendo la tasa de éxito en tareas. También gestiona gobernanza de claves virtuales (límites y presupuestos por equipo) y enrutamiento de modelos multicloud (Anthropic, OpenAI, Bedrock, Vertex AI, y otros) mediante la misma implementación.

Kong AI Gateway

Kong lanzó soporte nativo MCP en Kong Gateway 3.12 (octubre de 2025) como parte de su AI Gateway: el plugin AI MCP Proxy, que puede convertir una API REST existente en herramientas MCP o hacer proxy directo a un servidor MCP, y el plugin AI MCP OAuth2, que implementa OAuth 2.0 para autenticación en servidores MCP. Es una opción natural si ya usas Kong para gestión de API y quieres gestionar tráfico IA/MCP bajo la misma política; tiene más peso operativo que Bifrost si solo te interesa túneles y tráfico MCP, ya que es un gateway completo con capacidades IA integradas, no solo infraestructura para agentes.

---

8. Modos de permiso: qué significa “Autónomo” en realidad ahora

Un aspecto importante, ya que cambia qué significa en la práctica que “el agente no se detiene”: el comportamiento por defecto de Claude Code no es ejecutar silenciosamente cada llamada a herramientas MCP, incluyendo create_tunnel. La mayoría de los clientes MCP — incluido Cursor — requieren aprobación antes de ejecutar herramientas. Claude Code soporta un modo de omisión total (--dangerously-skip-permissions, o --permission-mode bypassPermissions) que salta la aprobación interactiva para ediciones de archivos, comandos bash y llamadas MCP en una sesión; la documentación de Anthropic describe ese modo como destinado a entornos aislados — contenedores, VMs, sandbox sin acceso a red más amplio — donde una acción comprometida no puede llegar a nada importante, y la CLI muestra una advertencia única antes de ejecutarla.

Por separado, a partir del 14 de agosto de 2026, Anthropic hizo que un modo “auto” intermedio fuera el comportamiento predeterminado de permisos para planes Pro, Max y Team, en lugar de requerir aprobación manual para cada acción — la razón oficial es que un clasificador detecta la gran mayoría de comandos peligrosos en pruebas, frente a una tasa de detección mucho menor por revisores humanos. La consecuencia práctica para los flujos “el agente abre un túnel sin detenerse a preguntar” descritos en este artículo: si esa llamada se ejecuta silenciosamente o muestra una solicitud de aprobación ahora depende del modo de permisos en la sesión, no solo de si el servidor MCP soporta la operación.

---

9. Conclusión

La transición de comandos CLI de túneles gestionados por humanos a llamadas de herramientas MCP gestionadas por agentes es real y ya en marcha, aunque no es uniforme entre proveedores. rustunnel y Pinggy son los dos proveedores con servidores MCP dedicados y genuinos para gestión de túneles en este momento, ambos aún etiquetados como experimentales por sus propios mantenedores. ngrok y Cloudflare han tomado un enfoque opuesto — herramientas de plataforma y puertas de enlace en lugar de gestión de túneles por agentes — que es una respuesta legítima pero diferente a un problema similar. Y la vista previa de investigación “túneles MCP” de Anthropic no resuelve ninguno de esos casos; es una función de conectividad a redes privadas para Claude que comparte nombre con toda la categoría que cubre este artículo, y esa colisión de nombres es importante señalarla para evitar confusiones en diagramas arquitectónicos.

---

Historial de cambios

Correcciones y adiciones verificadas contra la documentación oficial de rustunnel, MCP de Pinggy, documentación MCP de Claude Code, documentación de ngrok, documentación de configuración de agentes de Cloudflare, documentación de plugins de Kong, documentación de Bifrost de Maxim AI y documentación de Claude Platform de Anthropic:

• Eliminación de metadatos: la línea SEO “Target Keywords” y la referencia a la imagen de portada de ejemplo, en línea con el estilo de esta serie.
• Mayor corrección estructural: separación de “túnel MCP” en dos significados distintos en 2026 — túneles gestionados por agentes de terceros (lo que cubre el resto del artículo) versus los “túneles MCP” de Anthropic en vista previa de investigación, que conectan Claude con un servidor MCP en red privada mediante un túnel saliente respaldado por Cloudflare, solo para empresas, en vista previa.
• Distribución de rustunnel-mcp corregida: el borrador mostraba npx rustunnel-mcp; rustunnel-mcp es un binario nativo en Rust, distribuido vía Homebrew o compilado desde fuente, no un paquete npm. Todas las instrucciones de instalación reescritas para reflejar esto.
• Tabla de herramientas MCP de rustunnel corregida y completada: el borrador listaba cuatro herramientas (create_tunnel, list_tunnels, close_tunnel, get_connection_info); la documentación oficial indica seis, añadiendo list_regions y get_tunnel_history. También se corrigió la descripción de get_connection_info — el borrador decía que obtiene “latencia, datos de región y registros de solicitudes”; en realidad devuelve el comando CLI que un agente en la nube o sandbox necesita para reconectarse.
• Dominio de ejemplo de túnel corregido: el ejemplo (https://random-id.rustunnel.net) fue reemplazado por el patrón real, con región (https://abc123.eu.edge.rustunnel.com).
• Precios y regiones de rustunnel añadidos: nivel gratuito (3 túneles, sin subdominios personalizados), pago por uso ($3/mes mínimo + $0.10/GB), autohospedado (gratis); tres regiones alojadas (eu/Helsinki, us/Hillsboro OR, ap/Singapur) — nada de esto estaba en el borrador.
• Flag de instalación del plugin de Claude Code señalado como no estándar: /plugin install rustunnel está documentado tal cual en el README de rustunnel, pero omite el paso /plugin marketplace add que la mayoría de plugins de Claude Code requieren; se añadió esa advertencia y una ruta alternativa.
• Historia de Pinggy corregida y ampliada: el borrador caracterizaba a Pinggy como “menos enfocado en que el agente gestione el túnel” — en realidad, ofrece una MCP server propia, experimental (pinggy_mcp, 13 herramientas en autenticación, gestión de túneles, compartición de archivos y tokens, OAuth 2.0 Device Grant). La ejemplo de exposición SSH sigue siendo válido para ese uso.
• Historia de ngrok corregida: el borrador sugería que ngrok se estaba adaptando para crear túneles mediante API y envolverlos en un servidor MCP; en realidad, el patrón documentado es el inverso — un gateway MCP delante de un servidor MCP autohospedado, usando políticas de tráfico para restringir acceso. La creación de túneles gestionados por el agente en ngrok solo existe mediante servidores MCP comunitarios, no con herramientas oficiales.
• Se añadió Cloudflare Tunnel: ausente en el borrador, ahora se incluye, señalando que las herramientas de Cloudflare para desarrolladores (Skills plugin) cubren todo, incluyendo Tunnel y Spectrum, y que controlan cloudflared mediante CLI, no un gestor de túneles dedicado.
• Corrección del comando de Bifrost: el borrador usaba https://localhost:8080/mcp; el esquema correcto para local es http://.
• Citas de rendimiento de Bifrost: se añadió que Bifrost añade unos 11 microsegundos por solicitud a 5,000 req/s, y que su modo Código puede reducir tokens en un 92%, con base en sus propias métricas.
• Corrección y datación de la sección de Kong: se nombraron los plugins reales (AI MCP Proxy, AI MCP OAuth2) y la versión (Kong Gateway 3.12, octubre 2025).
• Advertencia sobre NODE_TLS_REJECT_UNAUTHORIZED: se añadió que desactiva la verificación TLS para todo el tráfico saliente de Claude Code en esa sesión, incluyendo api.anthropic.com, y se sugirió NODE_EXTRA_CA_CERTS como alternativa.
• Discriminación de configuraciones de Cursor y VS Code: se aclaró que VS Code usa un esquema diferente (servers + "type": "stdio") en ~/.vscode/mcp.json, por lo que no se puede reutilizar la configuración de Cursor sin modificaciones.
• Se añadió sección sobre modos de permisos en Claude Code: explicando que por defecto requiere aprobación, que existe un modo completo de omisión, y que desde agosto de 2026, hay un modo “auto” predeterminado para ciertos planes.
• Historia del protocolo MCP: se añadió la fecha de lanzamiento (25 de noviembre de 2024), los roles host/cliente/servidor, la reducción M×N a M+N, y el hito en Build 2025.
• Se eliminó el tono promocional exagerado para ajustarse al estilo de la serie.