MCP facilita el salto de “agente” a “agente que toma acción”. La trampa es que el éxito se acumula: cada sistema nuevo se convierte en un servidor nuevo, cada equipo lanza “una herramienta más”, y pronto tu superficie de integración es demasiado grande para razonar, demasiado inconsistente para asegurar y demasiado caótica para operar.
Mientras tanto, el modelo carga con la culpa de fallas que son, en realidad, problemas de diseño de integración. Las definiciones de herramientas se inflan. La precisión de selección cae. El contexto se consume antes de que alguien escriba un prompt. El trabajo de Tool Search de Anthropic reconoce abiertamente esta realidad: las definiciones de herramientas para 50+ herramientas MCP pueden consumir decenas de miles de tokens, y el descubrimiento bajo demanda puede reducir drásticamente ese overhead al tiempo que mejora la precisión.
La búsqueda de herramientas ayuda con economía de contexto. Por sí sola, no resuelve los problemas de gobernanza y operaciones que aparecen cuando MCP impulsa flujos de trabajo reales.
Ahí es donde el patrón MCP gateway marca la diferencia entre una demo que funciona y una plataforma sostenible, una distinción que se vuelve crítica al desplegar flujos de trabajo de AI desatendidos como Claude Code Routines.
Qué es un MCP gateway
Un MCP gateway es un punto de entrada único de MCP que federa herramientas de múltiples servidores MCP en una superficie de herramientas administrada. El valor no está en “un salto más”. El valor está en que el gateway se convierte en el lugar natural para centralizar las preocupaciones transversales: autenticación, políticas, enrutamiento y telemetría.
Una definición concisa (usando el lenguaje de Arcade.dev porque es explícito y actual): los gateways “federan las herramientas de múltiples servidores MCP en una sola colección”, permiten mezclar herramientas entre servidores, y “no todas las herramientas de un servidor MCP tienen que estar disponibles para el mismo LLM”.
Dos implicaciones prácticas:
- Dejas de conectar cada cliente/agente a una malla de servidores en constante crecimiento.
- Obtienes una forma controlada de exponer superficies de herramientas distintas a diferentes agentes, flujos de trabajo, IDEs y usuarios, sin duplicar servidores backend.
Registry vs gateway: el descubrimiento no es gobernanza
Conforme el ecosistema crece, distinguir entre registries, gateways y runtimes de ejecución se vuelve crítico. Como base, necesitas los dos:
- Un registry: una capa de descubrimiento que ayuda a los clientes a encontrar servidores y su metadata (piénsalo como una “app store para servidores MCP”). El proyecto oficial MCP Registry se posiciona explícitamente así.
- Un gateway: un plano de control de runtime que decide qué se expone, a quién, bajo qué política y con qué auditoría.
Confundirlos lleva a sistemas frágiles. Los registries reducen la fragmentación estandarizando la metadata de descubrimiento. Los gateways reducen la fragmentación estandarizando el control de runtime.
Una arquitectura de referencia que aguanta en producción
Una arquitectura duradera es:
Clientes/hosts MCP (IDE, runtime de agentes, copilotos) → Gateway (endpoint único de MCP + política + telemetría) → Servidores MCP backend (capacidades del sistema + orquestación) → Sistemas/APIs upstream
Transporte: usa Streamable HTTP por defecto en despliegues reales
Si construyes algo con acceso remoto o usado por múltiples clientes, Streamable HTTP es el soporte práctico. La especificación de transporte de MCP también hace explícita la postura de seguridad para transportes basados en HTTP; esto no es “higiene” opcional.
Específicamente, al implementar Streamable HTTP, los servidores deben validar el encabezado Origin (DNS rebinding), deberían vincularse a localhost al correr localmente, y deben implementar autenticación.
Por qué “pensar en gateways” es ahora obligatorio: los servidores expuestos ya son un problema
Esto no es teórico. El equipo TRACE de Bitsight reportó encontrar aproximadamente 1,000 servidores MCP expuestos a internet sin autorización y demostró que podían recuperar listas de herramientas y otra metadata de ellos.
Dos conclusiones:
- No expongas endpoints MCP a internet público sin un mecanismo real de autorización.
- Si vas a hacer MCP ampliamente usable entre agentes, IDEs y usuarios, como en tareas con privilegios elevados como flujos de trabajo de AI SRE on-call, necesitas una “puerta de entrada” consistente que aplique seguridad y políticas base.
Un gateway es esa puerta de entrada.
Autorización: sigue el modelo de MCP y evita los dos errores más comunes
La autorización de MCP (para transportes HTTP) se basa en conceptos de OAuth 2.1: el servidor MCP es un servidor de recursos, el cliente MCP es un cliente OAuth, y la emisión de tokens la maneja un servidor de autorización.
Tres puntos de la especificación que importan desproporcionadamente en la práctica:
- La autorización es opcional en las implementaciones de MCP. Eso explica en parte por qué hay tantos despliegues sin seguridad.
- El binding de audiencia es obligatorio al validar tokens: los servidores deben validar que los tokens fueron emitidos para ellos como audiencia prevista.
- El passthrough de tokens está explícitamente prohibido: los servidores no deben aceptar/transitar tokens arbitrarios; las APIs upstream requieren tokens separados emitidos por el servidor de autorización upstream.
Esto se traduce claramente en un principio de diseño de gateway:
Separa la identidad de la puerta de entrada de la autorización downstream
Quieres dos controles distintos:
- Identidad del llamador en el gateway (¿quién está invocando esta superficie MCP?)
- Autorización a nivel de herramienta (¿qué puede invocarse y bajo qué alcances/permisos?)
Esta separación es la diferencia entre “pusimos una clave en un archivo de configuración” y “esto es seguro para producción multiusuario”.
Un ejemplo concreto de cómo un gateway puede soportar entornos multiusuario (sin convertirse en un sistema de auth a medida): la documentación del gateway de Arcade describe un modo de producción donde un servicio se autentica con una API key y pasa un identificador de usuario final por separado (Arcade-User-ID), para que el gateway pueda aplicar políticas por usuario mientras la app que llama sigue siendo el cliente autenticado.
Puedes implementar el mismo concepto sin depender de un proveedor: autentica el workload que llama, propaga un claim de identidad de usuario y aplica políticas de mínimo privilegio para la ejecución de herramientas en nombre de ese usuario.
Superficies de herramientas: tu gateway debe curar, no agregar
La implementación de gateway más fácil es “proxear todo”. También es la forma más rápida de recrear la sobrecarga de herramientas, solo un nivel más arriba.
Un gateway de producción debe soportar superficies de herramientas curadas:
- Herramientas en lista de permitidos (elige explícitamente qué se expone)
- Vistas por agente / por flujo de trabajo (diferentes clientes reciben diferentes subconjuntos)
- Instrucciones de uso para el LLM en la superficie (cómo debe usarse esta colección de herramientas)
Esta es la lección de la era de integraciones: la reutilización viene de bloques de construcción estables, pero la confiabilidad viene de superficies construidas con propósito específico.
Escalar más allá de “unas pocas herramientas”: combina curación con descubrimiento bajo demanda
La sobrecarga de herramientas ya es tan común que los proveedores de modelos están construyendo mecanismos de primera clase para abordarla. El enfoque de Tool Search de Anthropic es explícito: en lugar de cargar todas las definiciones de herramientas al inicio, marcas las herramientas como diferidas (defer_loading: true) y las descubres bajo demanda.
Dos aclaraciones importantes para ser precisos:
- La búsqueda de herramientas es herramienta del modelo/cliente (por ejemplo, Claude), no una función del protocolo MCP central.
- Complementa a los gateways: el gateway reduce lo que es elegible, y el mecanismo del lado del modelo reduce lo que se carga en este momento.
Una regla práctica (respaldada por la documentación de Claude): mantén un conjunto pequeño de herramientas de uso frecuente como no diferidas, y difiere el resto para que solo se carguen mediante búsqueda.
Esto te da un patrón escalable:
- Gateway: política + curación + nombres/contratos estables
- Cliente/modelo: descubrimiento dinámico para preservar contexto y mejorar la precisión de selección
Operaciones y gobernanza: trata MCP como una plataforma de integración, no como una función
Una vez que MCP participa en flujos de trabajo reales, necesitas los mismos controles que hicieron que los programas de API fueran sostenibles:
- Auth centralizada y aplicación de políticas
- Enrutamiento y moldeado de solicitudes (qué servidor/herramienta backend se usa)
- Límite de tasa / throttling para proteger los upstreams y contener el abuso
- Logs de auditoría y trazado para “quién hizo qué, cuándo y por qué”
Esto no es especulativo: son “políticas de gateway” y responsabilidades bien establecidas en la práctica moderna de API gateways (auth, límite de tasa, monitoreo, CORS, etc.).
Un matiz para MCP: ten cuidado con el caché “útil”. Todo lo que esté influenciado por la identidad del llamador o la política (incluyendo “qué herramientas están disponibles”) debe tratarse como con alcance de identidad o no cachearse.
Orden de construcción: el camino más corto hacia un MCP gateway seguro y operable
Si estás implementando este patrón, esta secuencia minimiza el retrabajo:
- Un endpoint Streamable HTTP para clientes.
- Validación de Origin + valores predeterminados seguros de binding (según la guía de transporte de MCP).
- Autenticación en la puerta de entrada en cada solicitud; falla cerrada.
- Listas de herramientas permitidas y superficies de herramientas con nombre (trata los nombres de herramientas como APIs).
- Vistas por agente/por flujo de trabajo (mínimo privilegio por defecto).
- Instrucciones de superficie (haz el contrato de herramienta explícito para el modelo).
- Disciplina de tokens: binding de audiencia, sin passthrough, tokens upstream separados.
- Registro de auditoría estructurado para llamadas a herramientas (entradas, salidas, actor, decisión de política).
- Límite de tasa por llamador y por clase de herramienta.
- Descubrimiento de herramientas bajo demanda donde esté soportado (carga diferida + búsqueda de herramientas).
Cierre
MCP está ganando porque estandariza cómo los agentes se conectan a sistemas reales. Pero la estandarización aumenta la composabilidad más rápido de lo que aumenta la operabilidad. Los registries aceleran el descubrimiento. La búsqueda de herramientas reduce el costo de contexto. Ninguno te da gobernanza.
Un MCP gateway es el plano de control que falta: convierte “un montón de servidores” en una superficie de integración administrada con seguridad consistente y operaciones predecibles, sin sacrificar la interoperabilidad que hizo a MCP atractivo en primer lugar.
