← Volver al listado de tecnologías ← Índice de Claude Partner Badge: Claude Code

Capítulo 21 — MCP tunnel: puente con el desarrollo local

10 de octubre de 2026 Por: Artiko

claude-codeanthropicpartner-badgemcprelayred-corporativa

MCP tunnel: puente con el desarrollo local

Módulo 5 · Extensibilidad · Lección 3 de 8

La API interna del cliente no es alcanzable. El relay sí.

Al terminar esta lección sabrás cuándo usar el patrón de relay MCP remoto, cómo configurarlo y cómo explicarlo al equipo de plataforma del cliente sin que se convierta en una escalación de seguridad.

El problema del último tramo

Permitido en la allowlist pero inalcanzable: cuando el relay MCP remoto cierra la brecha

El control de la allowlist decide qué puede aprobarse. El relay decide qué es realmente alcanzable. Resuelven problemas distintos.

El escenario aparece en casi todas las activaciones empresariales: un desarrollador necesita que Claude Code se conecte a una API REST interna, a una base de datos o a un servicio privado. El sistema es legítimo y ya está aprobado para acceso MCP, pero solo acepta conexiones desde dentro de la red corporativa, y Claude Code corre en el portátil de un desarrollador que no puede alcanzarlo directamente.

Sin este túnel MCP, el desarrollador copia manualmente las respuestas de la API en la sesión de Claude Code. Eso funciona para una tarea puntual, pero es insostenible para un equipo y anula el propósito de la conexión MCP.

Qué hace realmente el relay

El relay MCP remoto es un relay entre Claude Code y un servidor MCP que corre dentro de la red del cliente. El portátil del desarrollador habla con el endpoint del relay; el endpoint del relay habla con el sistema interno. El límite de seguridad se mantiene intacto.

El patrón de relay es el mismo concepto que un reverse proxy o un API gateway: el relay se sitúa entre el cliente y el sistema de destino, y solo deja pasar el protocolo definido.

flowchart LR
    subgraph portatil["Portátil del desarrollador"]
        cc["Claude Code"]
    end
    subgraph red["Red corporativa"]
        relay["Servidor MCP (relay remoto)"]
        api["Sistema interno: API, base de datos o servicio privado"]
    end
    cc -->|"VPN: solo tráfico MCP"| relay
    relay --> api

Decisión de arquitectura

Usa el patrón de relay solo cuando la conexión directa no es posible

El relay añade latencia y un punto adicional de fallo. No lo uses si una conexión directa funciona.

Opción	Cuándo aplica	Casos típicos
Conexión MCP directa	El sistema de destino es alcanzable desde el entorno del desarrollador	Herramientas SaaS (GitHub, Linear, Slack), sistemas accesibles por VPN o cualquier cosa que la máquina del desarrollador alcance directamente. Ejecuta `claude mcp add` y la conexión funciona. No hace falta túnel.
Relay MCP remoto	El sistema de destino está detrás de un límite de red que el portátil no puede cruzar	APIs internas que solo aceptan solicitudes de subredes específicas, entornos aislados (air-gapped), o sistemas donde el cliente no abrirá una regla de firewall para los portátiles de los desarrolladores. El relay cierra la brecha sin exponer el sistema interno directamente a cada portátil.

flowchart TD
    q{"¿El sistema es alcanzable desde el entorno del desarrollador?"} -->|"Sí"| direct["Conexión MCP directa (claude mcp add)"]
    q -->|"No: está detrás de un límite de red"| relay["Relay MCP remoto (HTTP o SSE por VPN)"]

Configuración

Conectar a sistemas internos: el patrón de relay y la conversación de seguridad

El Plan de activación de 30 días (30-Day Activation Plan) introduce este patrón de conexión en la Semana 1, como parte de Claude Code 101. Trátalo como configuración estándar para cualquier cliente con sistemas internos, no como un caso excepcional.

El enfoque: despliega un servidor MCP dentro de la red corporativa, donde pueda alcanzar el sistema interno, y exponlo mediante un endpoint HTTP o SSE al que los desarrolladores puedan acceder por VPN. Claude Code se conecta usando el transporte sse o http. Configúralo en .mcp.json para conectar con un servidor MCP que corre dentro de la red corporativa:

{
"mcpServers": {
"internal-api": {
"type": "sse",
"url": "https://mcp.client-internal.com/sse"
}
}
}

O mediante la CLI:

claude mcp add --transport sse internal-api https://mcp.client-internal.com/sse

Lo que debe saber el equipo de plataforma

El servidor MCP transporta solo tráfico del protocolo MCP: solicitudes de llamadas a herramientas y sus respuestas. No le da a Claude Code acceso general a la red interna. El servidor MCP que corre dentro de la red controla exactamente qué herramientas y recursos se exponen. El límite de seguridad está en el servidor MCP.

La autenticación al endpoint MCP puede hacerse mediante OAuth (para servidores HTTP/SSE que lo soporten), cabeceras estáticas (API keys o bearer tokens) o headersHelper para autenticación personalizada, como SSO interno, Kerberos o tokens de corta duración. OAuth es habitual cuando la plataforma de identidad del cliente lo soporta, pero no todos los sistemas internos lo requieren. Configura la autenticación en .mcp.json para que coincida con lo que el servidor MCP espera como credenciales.

Comprueba tu comprensión

Escenario: ¿qué situación requiere el patrón de relay?

Tres situaciones de una semana típica de activación: una necesita el relay y las otras dos no.

Estás configurando conexiones MCP para la cohorte de desarrolladores de un cliente. ¿Cuál de estas situaciones es el caso de uso correcto para el relay MCP remoto?

A · Conectar a GitHub para obtener contexto de código. El equipo quiere que Claude Code acceda al historial de PRs y al contenido de los archivos de sus repositorios de GitHub.
B · Conectar a una instancia interna de Confluence. Un desarrollador necesita que Claude Code llame a una instancia interna de Confluence que solo es alcanzable desde dentro de la red corporativa.
C · Desplegar un servidor MCP aprobado en toda la organización. El CoE quiere que cada desarrollador tenga acceso al servidor MCP de Linear sin pasos de instalación individuales.

Ver respuesta

B es correcta. El patrón de relay encaja exactamente en este caso: un sistema aprobado y legítimo, pero que solo es alcanzable desde dentro de la red corporativa. Despliega un servidor MCP dentro de esa red, exponlo por HTTP o SSE y conecta Claude Code a él por VPN. Confluence detrás de un perímetro solo accesible por VPN es el ejemplo canónico.

A: GitHub es una herramienta SaaS con un endpoint público. Una conexión MCP directa funciona sin relay; añadir uno introduce complejidad y latencia innecesarias.

C: El despliegue a toda la organización es un trabajo de managed-mcp.json, no un escenario de relay. El relay resuelve un problema de alcanzabilidad de red; el despliegue gestionado resuelve un problema de distribución. Son decisiones distintas.

Escenario: el equipo de plataforma se resiste

La objeción del equipo es de arquitectura. Hay tres formas de responder, y solo una funciona.

El líder de seguridad de plataforma del cliente dice: «No podemos permitir que Claude Code haga llamadas a través de un túnel. No sabemos qué tráfico circula por él.» ¿Qué le respondes?

A · Estar de acuerdo y eliminar el túnel. Quita el túnel de la configuración, ya que la preferencia de seguridad del cliente tiene prioridad.
B · Explicar qué transporta el túnel. Explica que el túnel transporta solo tráfico del protocolo MCP: llamadas a herramientas y respuestas. No es una VPN y no abre una ruta de red general hacia el entorno interno.
C · Pedir que levanten una excepción de seguridad. Pídele al equipo de plataforma que levante una excepción de seguridad para revisar los logs del tráfico del túnel tras el despliegue.

Ver respuesta

B es correcta. El relay transporta solo llamadas de herramientas MCP (lo que Claude pide al servidor que haga) y respuestas (lo que devuelve el servidor). No es una VPN, y no le da a Claude Code acceso general de red al entorno interno. Explicar esta distinción resuelve la objeción en la mayoría de los casos.

A: Quitar el relay significa que los desarrolladores no pueden alcanzar en absoluto el sistema interno. Antes de ceder, explica qué transporta realmente el relay. La preocupación suele basarse en un malentendido sobre lo que hace.

C: La revisión de logs no resuelve la preocupación. El equipo de plataforma se preocupa por qué datos fluyen ahora, no por la visibilidad retrospectiva. Resuelve primero la cuestión arquitectónica (qué transporta el relay) antes de hablar de monitoreo.

Si el cliente tiene sistemas internos detrás de un límite de red, la configuración del relay se convierte en una entrada adicional del .mcp.json del plugin, empaquetada junto con las configuraciones estándar de servidores MCP de la lección 5.8 (capítulo 26).

Ideas clave

MCP ya está conectado. Ahora construye lo que corre encima. El relay MCP remoto resuelve un problema concreto: un sistema interno aprobado y legítimo, detrás de un límite de red que Claude Code no puede cruzar directamente. Despliega un servidor MCP dentro de la red, exponlo por HTTP o SSE y conecta a través de él. Transporta solo tráfico del protocolo MCP, no acceso general a la red. Configura la autenticación para que coincida con lo que requiere el servidor MCP: OAuth, cabeceras estáticas o credenciales personalizadas mediante headersHelper.

Usa el relay solo cuando la conexión directa no es posible: añade latencia y un punto adicional de fallo.
El servidor MCP dentro de la red controla exactamente qué herramientas y recursos se exponen; ahí está el límite de seguridad.
Desde la perspectiva del equipo de plataforma, el relay no es una VPN ni una ruta de red general: es un canal que solo transporta el protocolo MCP.

Los estándares del cliente viven en documentos que nadie lee de forma consistente. Las Skills los empaquetan en algo que Claude carga automáticamente: el formato correcto y las restricciones correctas, en cada sesión.

Siguiente: Skills: empaquetar experiencia reutilizable