Esto es lo que la mayoría de los diagramas de arquitectura omiten discretamente sobre los proxies MCP: no se da cuenta de que necesita uno hasta que está gestionando seis servidores MCP de backend, tres tipos de transporte diferentes, ninguna aplicación centralizada de autenticación y una creciente sensación de que algo en la cadena va a exponer lo incorrecto al agente equivocado en el momento equivocado.
La guía de ciberseguridad de la NSA sobre MCP de mayo de 2026 lo expresa claramente: el protocolo ya se está ejecutando en producción en entornos empresariales, financieros, jurídicos y de desarrollo de software. Muchas de estas implementaciones omiten por completo la autenticación. Varias carecen de cualquier aplicación basada en roles. La conversación sobre seguridad ha dejado atrás la teoría. Una capa de proxy ya no es una recomendación académica. Es lo que se coloca entre su agente y todo lo que este puede tocar.
Este artículo explica qué es realmente un proxy MCP, dónde fallan las conexiones directas, cómo funcionan los mecanismos de enrutamiento y delegación, y cuándo el proxy deja de ser opcional.
Lo que la mayoría de los equipos aprende después del primer incidente
- Un proxy MCP delega en servidores de backend: no contiene lógica de herramientas ni los sustituye.
- Las incompatibilidades de transporte entre clientes y backends son invisibles hasta el momento de la conexión; un proxy las conecta.
- Sin un proxy, no existe un único punto de aplicación para autenticación, políticas o auditoría en toda su pila de servidores MCP.
Qué es realmente un proxy MCP
Un proxy MCP es un servidor MCP intermediario. Se sitúa entre un cliente y uno o varios servidores MCP de backend, recibe solicitudes de herramientas, recursos y prompts, y reenvía esas solicitudes al backend que realmente posee esa capacidad. Después devuelve el resultado al cliente. El proxy no contiene lógica de herramientas propia.
Esa última frase es la importante. Esto es delegación, no alojamiento.
La distinción importa porque las personas confunden un proxy MCP con un proxy HTTP genérico, como Nginx o HAProxy. Estas herramientas enrutan tráfico HTTP inspeccionando URL y encabezados. No tienen concepto de la semántica del protocolo MCP, no conocen los espacios de nombres de herramientas, no pueden agregar capacidades de varios servidores en una superficie unificada y no pueden conectar transportes MCP entre cliente y backend. Llamarlos lo mismo lleva inmediatamente a decisiones de arquitectura incorrectas.
Un proxy MCP habla de forma nativa el protocolo de contexto de modelo en ambos lados. Para el cliente, parece un único servidor MCP que expone un conjunto completo de capacidades. Para los backends, parece un cliente que realiza solicitudes. El cliente nunca necesita saber cuántos servidores hay detrás del proxy ni qué transportes utilizan. Esa invisibilidad es el objetivo.
Por qué las conexiones directas a servidores MCP fallan con cargas de trabajo reales
Las conexiones directas funcionan bien cuando tiene un cliente, un servidor, transportes compatibles y nadie pregunta quién realizó cada solicitud. Eso describe el portátil de un desarrollador un martes por la tarde. No describe una implementación de IA en producción.
Cuando escala —más clientes, más servidores de backend, entornos heterogéneos— los problemas se multiplican rápidamente. Cada cliente necesita su propia configuración de conexión para cada servidor. Cada servidor expone su transporte directamente, lo que significa que un backend que solo habla stdio de repente debe ser accesible para un cliente web que solo habla HTTP. No existe un único punto donde pueda preguntar: «¿quién tiene permiso para llamar a qué?». Cada implementación de servidor tiene su propia historia de autenticación o, más comúnmente, ninguna historia de autenticación.
El informe de la NSA es específico al respecto: muchas implementaciones MCP omiten por completo el control de acceso basado en roles, y el protocolo actualmente no tiene un mecanismo nativo para intercambiar permisos RBAC durante la instanciación. La vulnerabilidad no es especulativa. Laboratorios públicos han publicado exploits funcionales que demuestran ejecución arbitraria de código y repetición de tokens contra servidores que se ejecutan sin una capa de aplicación delante de ellos.
Ahí es donde suele comenzar el ticket.
El problema de incompatibilidad de transporte: stdio, SSE y HTTP transmitible
MCP admite varios transportes: stdio para la comunicación de procesos locales, SSE para flujos de eventos enviados por servidor y HTTP transmitible para interacciones HTTP sin estado. El problema es que los clientes y los servidores MCP de backend a menudo hablan transportes diferentes, y esta incompatibilidad es totalmente invisible hasta que alguien intenta conectarlos.
Un complemento de IDE podría esperar comunicarse mediante transporte stdio. El servidor MCP de backend al que necesita acceder se ejecuta como un servicio remoto mediante HTTP transmitible. Sin algo en medio, esa conexión no ocurre. No lentamente ni de forma deficiente. Simplemente no ocurre.
Piense en ello como un problema de adaptador de viaje. El enchufe es real. La toma es real. La electricidad existe en ambos lados. Pero sin el adaptador, no fluye nada. Un proxy MCP es ese adaptador para los transportes MCP: acepta una conexión entrante en el transporte que utilice el cliente y la reenvía al backend mediante el transporte que utilice ese servidor. La traducción es invisible para ambos lados.
Qué sucede al reenviar solicitudes a varios servidores de backend
Imagine que su agente necesita herramientas de cuatro servidores MCP de backend diferentes: uno para acceso al calendario, uno para datos de CRM, uno para documentación interna y uno para ejecución de código. Sin un proxy, el cliente necesita cuatro configuraciones de conexión independientes, cuatro configuraciones de autenticación independientes y exposición directa a cuatro direcciones y transportes de servidor diferentes.
Cuando debe reenviar solicitudes entre varios servidores en un entorno de producción, esto se convierte en deuda de configuración que se acumula cada vez que alguien añade una herramienta nueva. Proyectos como mcp-proxy de tbxark abordan exactamente esto: agregan varios servidores detrás de un único punto de entrada HTTP para que el cliente vea un servidor de backend, no cuatro. La configuración del cliente no cambia cuando añade un quinto backend. El proxy absorbe ese cambio.
Este es el problema de distribución hacia múltiples destinos convertido en algo manejable.
Cómo funciona un proxy MCP: enrutamiento de solicitudes y delegación de capacidades
Vale la pena entender los mecanismos con precisión, porque el comportamiento del proxy parece diferente según el lado desde el que se observe.
Desde la perspectiva del cliente, el servidor proxy MCP parece un servidor MCP estándar. El cliente se conecta, negocia capacidades y envía solicitudes con normalidad. No tiene visibilidad de lo que sucede después.
Lo que sucede después es lo siguiente: el proxy recibe la solicitud, determina qué servidor MCP de backend posee la capacidad solicitada —por nombre de herramienta, URI de recurso o identificador de prompt— y reenvía la solicitud a ese backend mediante el transporte adecuado. Cuando el backend responde, el proxy devuelve el resultado al cliente. El proxy no invoca lógica propia. No reescribe la salida de la herramienta. Delega de forma transparente.
El paso de resolución de capacidades es donde el proxy justifica su complejidad. Si un cliente quiere invocar una herramienta llamada «search_docs», el proxy necesita saber qué backend posee esa herramienta. Esto requiere que el proxy mantenga un registro interno de qué herramientas, recursos y prompts se encuentran en cada backend. Construye este registro consultando cada backend durante la inicialización y almacenando los resultados en caché. Cuando llega una nueva solicitud de herramienta, el proxy la resuelve frente al registro y la enruta en consecuencia.
Ese registro también convierte al proxy en algo más que un relé simple. Puede aplicar políticas en el momento de la resolución: rechazar solicitudes de herramientas que no estén en la lista blanca, eliminar capacidades de los backends antes de exponerlas a clientes específicos o añadir contexto de autenticación antes de reenviar. La capa de enrutamiento también es la capa de aplicación.
Agregación de herramientas, prompts y recursos en un único endpoint
Desde la perspectiva del cliente, el proxy presenta una superficie de capacidades unificada. Cuando el cliente pregunta qué herramientas están disponibles, el proxy responde con el conjunto combinado de todos los backends. El cliente ve un punto de conexión de cliente MCP, un endpoint y una lista de capacidades negociadas. No sabe —ni necesita saber— que «search_docs» procede de un servidor de backend y «create_ticket» de otro.
Este patrón de endpoint de proxy único es lo que hace prácticos los IDE y los frameworks de agentes en entornos con múltiples backends. Claude Desktop, Cursor o cualquier agente compatible con MCP solo necesita una conexión configurada. Añade un servidor de backend, actualiza el registro del proxy y cada cliente conectado obtiene acceso inmediato a las nuevas herramientas. Sin reconfiguración de clientes. Sin nuevas credenciales de conexión que distribuir.
El backend aquí es plural e invisible. La superficie que toca el cliente siempre es singular.
Conexión de transportes y aislamiento de sesiones entre cliente y backend
El proxy mantiene un estado de conexión separado para cada lado. Un cliente se conecta mediante HTTP sin estado y el proxy mantiene esa sesión. Cuando el proxy reenvía a un backend que espera una conexión persistente con estado, gestiona esa conexión de forma independiente. La sesión del cliente y la sesión del backend están aisladas entre sí.
El aislamiento de sesiones importa por una razón fácil de pasar por alto: sin él, el estado de la sesión de un cliente puede filtrarse a la de otro. Si dos agentes están conectados al mismo proxy y uno de ellos tiene un estado de ejecución parcial en un backend compartido, ese estado debe ser invisible para el otro. La gestión de sesiones del proxy aplica ese límite.
Un ejemplo concreto: un cliente se conecta mediante SSE, el proxy acepta ese flujo con estado y reenvía solicitudes de herramientas individuales a servidores MCP remotos mediante HTTP sin estado. El backend nunca ve la conexión SSE persistente. El cliente nunca ve la falta de estado por solicitud. El proxy los conecta y mantiene los contextos limpios.
Autenticación, autorización y gobernanza: donde el proxy demuestra su valor
Aquí es donde el argumento de arquitectura se vuelve real.
En un modelo de conexión directa, la autenticación y la autorización se gestionan —o no se gestionan— en cada servidor individual. Si tiene seis backends, tiene seis configuraciones de autenticación, seis problemas de gestión de credenciales y seis lugares donde una configuración incorrecta puede exponer algo que no debería. No existe un único lugar donde preguntar: «¿Este solicitante tiene permiso para invocar esta herramienta?».
Un proxy cambia esto por completo. Cada llamada de herramienta, solicitud de recurso e invocación de prompt pasa por el proxy antes de llegar a cualquier backend. Esto convierte al proxy en el punto de aplicación natural para toda su pila de credenciales y políticas. En lugar de distribuir la lógica de autenticación entre los backends, la centraliza. El proxy valida la identidad, comprueba permisos y solo reenvía las solicitudes que superan la política. Los backends no necesitan saber nada sobre quién es el solicitante. El proxy ya tomó esa decisión.
El resumen de RSAC 2026 de Coalition for Secure AI resume las preguntas que seguían apareciendo en la comunidad: «¿Quién realiza esta solicitud? ¿Cómo puedo saberlo? ¿Qué ocurre cuando un agente actúa en nombre de un usuario a través de varios saltos?». Un proxy que centraliza controles de seguridad de nivel empresarial es la respuesta directa a las tres. Proporciona la visibilidad y el control que las configuraciones de autenticación por servidor no pueden ofrecer estructuralmente.
La evaluación de la NSA sobre la especificación de autorización MCP es igual de directa: el protocolo carece de intercambio RBAC nativo durante la instanciación. Un proxy no corrige esa brecha del protocolo. Pero añade la capa de aplicación por encima, que es lo que las implementaciones de producción necesitan ahora mismo.
💡 Conviene saberlo:
Los equipos a menudo asumen que, puesto que cada servidor MCP tiene su propia autenticación, el sistema es seguro. Pero sin un proxy, no hay ningún punto de aplicación que pueda impedir que un agente llame a un servidor incluido en la lista blanca y a otro que no lo está dentro del mismo ciclo. La autenticación de cada servidor no evita eso. Solo una capa que controle qué servidores pueden coexistir en el mismo contexto de agente puede impedirlo, y un proxy es esa capa. Un servidor MCP malicioso añadido al entorno pasa a poder invocarse en el momento en que no existe una capa que compruebe el registro.
Autenticación y autorización a nivel de protocolo
Un proxy intercepta cada llamada de herramienta antes de que llegue a cualquier backend. Ese punto de intercepción es donde reside la lógica de autenticación y autorización en una implementación MCP bien gobernada. Validación de tokens, aserciones de identidad, flujos OAuth, comprobación de ámbitos de permisos: todo se ejecuta en el proxy antes de que se reenvíe una sola solicitud.
En la práctica, funciona así: un cliente envía una solicitud de herramienta con un token de autenticación. El proxy valida el token, asigna la identidad del solicitante a un conjunto de permisos, comprueba si esa identidad puede invocar la herramienta solicitada y, después, reenvía o rechaza la solicitud. Si el backend necesita una credencial diferente —cuenta de servicio o clave API con ámbito limitado—, el proxy intercambia tokens en ese límite. La credencial del cliente nunca llega directamente al backend.
Se registra cada solicitud reenviada: identidad del solicitante, nombre de herramienta, marca de tiempo y estado del resultado. Ese registro de auditoría es lo que los equipos de seguridad solicitan y rara vez obtienen en arquitecturas de conexión directa porque nadie pensó en añadirlo antes de producción.
Implementación de listas blancas de servidores MCP y aplicación de políticas
Las listas blancas son el patrón de gobernanza más sencillo y el que más vale la pena implementar pronto. El proxy mantiene un registro de servidores MCP de backend aprobados. Las solicitudes destinadas a cualquier servidor que no esté en ese registro se rechazan antes de reenviarse. Un agente no puede llamar a un backend que no aparezca en la lista aprobada, independientemente de las herramientas que anuncie ese backend.
Implementar la gobernanza MCP de esta manera significa que la supervisión organizativa vive en la configuración del proxy, no dispersa entre configuraciones individuales de agentes. Cuando los equipos de seguridad preguntan «¿a qué servidores MCP pueden acceder nuestros agentes?», la respuesta es «a los que estén en la lista blanca del proxy». Esto es auditable. Puede modificarse sin reconfigurar cada agente. Y es el control fundamental para evitar la clase de riesgo en la que un servidor nuevo sin validar entra en el ciclo de herramientas sin revisión.
El patrón de proxy MCP empresarial amplía esto aún más: delimitación de herramientas por usuario o rol, límites de frecuencia para categorías específicas de herramientas y filtrado saliente de respuestas antes de que lleguen al agente. Los riesgos de seguridad en MCP no se concentran solo en el momento de la autenticación. También están en la cadena de salida, y el proxy es donde se intercepta eso. Los controles de autenticación determinan qué se llama. Los filtros de salida controlan qué vuelve.
Cuatro patrones en los que un proxy MCP resuelve un problema de arquitectura real
No se trata de lenguaje de beneficios. Cada uno es un modo de fallo que el proxy evita.
Capa de seguridad y gobernanza empresarial
Un equipo de ingeniería de seguridad que ejecuta flujos de agentes en backends de CRM, documentos internos y ejecución de código no tiene un punto central para auditar qué agente llamó a qué herramienta, con qué identidad y cuándo. Cada backend ejecuta su propia autenticación o ninguna. El proxy se convierte en el único punto de aplicación: cada solicitud pasa por él, se valida la identidad, se comprueba el ámbito y se captura el registro completo de llamadas. Sin él, la respuesta a incidentes tras un evento de envenenamiento de herramientas implica reconstruir el historial de ejecución a partir de los registros de seis servidores distintos, si esos registros existen. Implementar una capa de gobernanza aquí marca la diferencia entre «podemos investigar lo ocurrido» y «no podemos».
Hub de agregación para servidores MCP heterogéneos
Un equipo de RevOps que utiliza Cursor necesita acceso a herramientas de un servidor de calendario, un servidor CRM y una base de conocimiento interna. Sin un proxy, Cursor necesita tres configuraciones de servidor independientes, tres conjuntos de credenciales, y el equipo debe actualizar cada cliente de agente cada vez que cambia un backend. Con un proxy que agrega los tres detrás de un único punto de entrada HTTP, la configuración del cliente se mantiene estable. Añada un cuarto backend al registro del proxy y todos los agentes conectados lo tendrán inmediatamente. En Latenode, esto equivale a utilizar el MCP Server Builder integrado para exponer capacidades controladas como una superficie de servidor MCP local unificada para clientes como Claude Desktop, con las credenciales de gestión automática de OAuth de Latenode para las conexiones subyacentes a servidores de recursos. Configuración de cliente limpia, acceso gobernado y el modelo de precios por ejecución mantiene la contabilidad sencilla a medida que aumenta el número de backends.
Conexión de transportes entre clientes y backends incompatibles
Un servidor MCP de backend creado para ejecutarse localmente como proceso stdio necesita atender a un cliente de agente web que habla HTTP transmitible. Ambas cosas no se pueden conectar directamente. Un proxy acepta la conexión HTTP del cliente y la reenvía al proceso stdio del backend. El backend no se mueve. El cliente no cambia. El proxy absorbe la incompatibilidad. Los equipos que implementan servidores MCP de forma incremental se encuentran con esto constantemente: un servidor creado para desarrollo local de repente debe atender a agentes remotos. El proxy resuelve esto sin requerir que se reescriba el servidor.
Reempaquetado de capacidades con autenticación personalizada, limitación de frecuencia y analítica
Un equipo de plataforma de IA quiere exponer un subconjunto de herramientas MCP internas a desarrolladores externos sin exponer directamente los servidores de backend. Una capa de proxy MCP de producción se sitúa delante, aplica autenticación mediante clave API, limita la frecuencia por solicitante, elimina metadatos internos de las respuestas y registra cada llamada para analítica y facturación. Sin esta capa, implementar capacidades MCP externamente implica exponer directamente la infraestructura de backend. El proxy es donde separa la interfaz pública de la implementación interna. Los equipos que omiten este paso e implementan servidores MCP directamente se arrepienten la primera vez que un solicitante agota la capacidad del backend o extrae más datos de los previstos. La capacidad del proxy para reducir la carga del backend mediante aplicación de límites de frecuencia y almacenamiento en caché es un beneficio operativo real, no teórico.
Proxy MCP frente a API Gateway: por qué la distinción importa a los arquitectos
Los arquitectos que recurren a un API Gateway para resolver problemas de gobernanza MCP descubrirán que cubre aproximadamente el 60 % de lo que necesitan y deja fuera el 40 % específico de MCP. Vale la pena ser preciso sobre la distinción.
| Capacidad | API Gateway | Proxy MCP |
|---|---|---|
| Conocimiento del protocolo | HTTP/REST; enruta por URL y encabezados | Protocolo MCP; enruta por nombre de herramienta, recurso y prompt |
| Agregación de capacidades | No; enruta a un origen ascendente por endpoint | Sí; agrega herramientas de varios backends en una sola superficie |
| Funciones específicas de MCP | Ninguna; sin reenvío de herramientas ni enrutamiento de prompts o recursos | Nativas; delega llamadas de herramientas, recursos y prompts entre backends |
| Conexión de transportes | No; asume HTTP en ambos lados | Sí; conecta stdio, SSE y HTTP transmitible |
| Caso de uso más adecuado | API REST, limitación de frecuencia y autenticación en tráfico HTTP | Implementaciones MCP con varios servidores, transportes mixtos o requisitos de gobernanza |
Un API Gateway puede gestionar autenticación y limitación de frecuencia para el tráfico HTTP, lo que es realmente útil y vale la pena implementar para la capa HTTP de su pila. La brecha es la delegación: un gateway enruta haciendo coincidir URL e invocando un origen ascendente. No tiene un mecanismo para descubrir que una herramienta llamada «search_docs» está en el backend A y «create_ticket» en el backend B, agregarlas en una sola lista de capacidades y presentarlas de forma nativa a un cliente. No es un problema de configuración del gateway. Es una incompatibilidad arquitectónica entre lo que hace el gateway y lo que requiere MCP.
📊 En la práctica:
Un API Gateway configurado para enrutar tráfico MCP puede reenviar una solicitud HTTP a una dirección de servidor proxy: es una capa de transporte válida. Lo que no puede hacer es exponer una superficie de herramientas MCP unificada a un cliente cuando esas herramientas están repartidas entre varios backends. El gateway ve URL. No ve espacios de nombres de herramientas. Un cliente que habla MCP con un API Gateway obtiene enrutamiento. No obtiene agregación ni conexión de transportes. Las dos capas son complementarias, no intercambiables.
