Guía previa de MCP Gateway: agregar varios servidores MCP y API REST en una superficie fija de herramientas (licencia no comercial)

Si conectas varios servidores MCP y API REST al mismo cliente de IA, pronto descubres que las propias definiciones de herramientas llenan el contexto. El enfoque de MCP Gateway es colocar un único binario de Rust entre el cliente y todas sus herramientas: los backends quedan detrás, y el agente ve una metasuperficie compacta de 14 a 16 herramientas en lugar de la definición completa de cada backend. Cuantas más definiciones de herramientas ocupan el contexto, menos presupuesto queda para la tarea real; condensarlas en una superficie fija y pequeña es exactamente el problema que pretende resolver. Antes de empezar, confirma una premisa: se distribuye por defecto bajo una licencia no comercial; el uso personal y no comercial (incluido ejecutar el gateway completo) es gratuito, y el funcionamiento comercial requiere una licencia comercial.

Para quién es

• Para quienes ya conectan varios servidores MCP y API REST —o planean hacerlo— y quieren que el tamaño de la lista de herramientas se mantenga estable: sin importar cuántos backends queden detrás, el agente se enfrenta a un conjunto pequeño y fijo de meta-herramientas, no a la suma de todas las definiciones de backend.
• Para quienes pueden mantener un servicio residente en su propia máquina: el gateway funciona como un servicio HTTP local y los clientes se conectan a él mediante un endpoint local.
• No apto para uso directo en entornos comerciales: el funcionamiento comercial requiere una licencia comercial, una premisa que hay que resolver antes de adoptarlo; solo un pequeño núcleo MIT de bloques genéricos se ofrece bajo licencia MIT.
• Con pocos backends y una lista de herramientas ya corta, el valor de la agregación es limitado; las evidencias no aportan datos comparativos sobre beneficios concretos a pequeña escala.
• La lista de clientes compatibles, el despliegue remoto y los métodos de autenticación no aparecen en las evidencias: son puntos sin confirmar, no los des por sentado.

Primer intento en 3 minutos

• Requisito previo: un entorno con Homebrew disponible. La vía de instalación oficial es un tap de Homebrew; las evidencias no recogen otros métodos de instalación.
• Ejecuta en orden los tres comandos de la ruta oficial:

brew install MikkoParkkola/tap/mcp-gateway   # 1. install
mcp-gateway setup wizard --configure-client   # 2. import existing servers + wire up clients
mcp-gateway serve                            # 3. run

• El setup wizard del segundo paso importa tus servidores existentes y conecta los clientes. Ojo: esto es una escritura de estado local; reescribe la configuración local del gateway y de los clientes, no es una operación de solo lectura; qué archivos escribe exactamente y cómo los guarda no se detalla en las evidencias.
• Tras arrancar el tercer paso, el gateway funciona como un servicio HTTP local. Del lado del cliente, conéctate según el fragmento de configuración oficial. El fragmento declara un servicio llamado gateway de tipo http, apuntando a la ruta /mcp del puerto local 39400:

{
  "mcpServers": {
    "gateway": {
      "type": "http",
      "url": "http://localhost:39400/mcp"
    }
  }
}

• Señal de éxito: cuando el cliente se conecta a http://localhost:39400/mcp, la lista de herramientas se condensa en un conjunto pequeño y fijo; llama entonces una vez a gateway_search_tools —la descripción oficial lo presenta como el buscador de herramientas de backend— y si la búsqueda devuelve herramientas de los backends que conectaste, el camino del cliente al gateway está abierto. Las evidencias no indican si esta herramienta lleva un readOnlyHint, así que su carácter de solo lectura no está confirmado; limita el primer intento a la búsqueda y no ejecutes acciones de escritura. En este punto, el agente carga un conjunto pequeño y fijo de meta-herramientas, no todas las definiciones de backend.

Casos de uso

• Caso 1: poner a dieta una pila de herramientas multi-servidor. Situación: el cliente ya tiene varios servidores MCP conectados y las definiciones de cada backend consumen contexto. Método: entrega tus servidores existentes al asistente para importarlos y deja en el cliente solo http://localhost:39400/mcp como único endpoint. Resultado esperado: la superficie de herramientas del agente se fija en torno a 14 a 16 herramientas, no la suma de todas las definiciones de backend; cuando necesites una capacidad concreta, localízala primero con gateway_search_tools. Criterio de juicio: si el número de herramientas que muestra el cliente es claramente menor que el total de herramientas de los backends conectados.
• Caso 2: buscar y luego invocar una vez una herramienta real. Situación: quieres ejecutar una capacidad que ofrece un backend conectado (un servidor MCP o una API REST). Método: localiza primero la herramienta objetivo con gateway_search_tools e invócala después con gateway_invoke; el uso descrito oficialmente son precisamente estas dos meta-herramientas, buscar e invocar. Resultado esperado: la llamada se reenvía al backend correspondiente y devuelve su resultado; la salida concreta depende de los backends que hayas conectado, y las evidencias no incluyen una salida de ejemplo fija. Si la búsqueda no encuentra la herramienta esperada, comprueba primero que ese backend se importó con el asistente y reintenta la búsqueda.

Límites de uso

• Licencia y restricciones: el uso personal y no comercial es gratuito, incluido ejecutar el gateway completo; el funcionamiento comercial requiere una licencia comercial; solo un pequeño núcleo MIT de bloques genéricos se ofrece bajo MIT. Este punto decide si puedes usarlo y dentro de qué ámbito, y va antes de cualquier otro juicio.
• Naturaleza de lectura/escritura y efectos secundarios: el gateway en sí es un servicio local residente; el asistente escribe la configuración local; gateway_invoke acciona de verdad las herramientas del backend, y sus efectos dependen del backend invocado; antes de ejecutar, confirma la naturaleza de la operación objetivo y sus puntos de confirmación.
• Dependencias: la instalación depende de Homebrew; conectar los servidores existentes se hace mediante la importación del asistente.
• Puntos sin confirmar: la lista de clientes compatibles, el formato de configuración concreto para conectar API REST, el despliegue más allá de localhost, los mecanismos de autenticación y si cada meta-herramienta lleva un readOnlyHint: nada de esto se explica en las evidencias. Tampoco se explica si el gateway en sí tiene control de acceso ni cómo registra los logs. Que no aparezca documentación no significa que no haya riesgo; antes de adoptarlo, guíate por la documentación actual del repositorio oficial.