Multi-MCP con Hatago Hub: una configuración para conectar todo

Hatago significa posada tradicional japonesa de la era Edo que ofrecía alojamiento a viajeros. En el mundo actual, Hatago MCP Hub actúa como un punto de relevo que conecta herramientas de IA modernas con servidores MCP, simplificando y centralizando la orquestación.

Hatago MCP Hub es un hub MCP ligero que unifica múltiples servidores MCP en un único punto de acceso utilizable por clientes como Claude Code, Cursor, Windsurf y Codex CLI. Está construido como middleware sobre Hono, lo que facilita la integración, el enrutado JSON RPC y la gestión transparente del estado entre clientes y servidores. En este artículo repasamos el contexto, arquitectura, puesta en marcha, operación y limitaciones actuales, con recomendaciones prácticas para equipos.

En Q2BSTUDIO, especialistas en software a medida, aplicaciones a medida, inteligencia artificial, ciberseguridad y servicios cloud, integramos Hatago MCP Hub en flujos de desarrollo reales para acelerar la adopción de MCP en empresas, combinándolo con automatización, observabilidad y políticas de seguridad. Si buscas iniciativas de ia para empresas o la creación de agentes IA, explora cómo impulsamos casos de uso con nuestro equipo en soluciones de inteligencia artificial aplicadas.

Resumen de valor

Inicio sin configuración con npx, sin contaminar tu repositorio. Conectividad rica con STDIO, HTTP, SSE y WebSocket, incluyendo proxy transparente para MCP remotos y arranque dinámico de servidores MCP publicados como paquetes npm. Recarga en caliente con vigilancia de archivo de configuración y actualizaciones dinámicas de catálogo de herramientas, recursos y prompts.

Por qué construir un hub

Cuando aumenta el número de servidores MCP, mantener sincronizados los ajustes por cliente se vuelve tedioso. Cada herramienta tiende a tener su propio formato y su propia forma de declarar servidores. La solución práctica es consolidar detrás de un único servidor MCP que actúe como concentrador y que todos los clientes apunten a ese hub. Así evitamos la proliferación de configuraciones, resolvemos colisiones de nombres, reenviamos progreso y habilitamos la recarga sin reinicios.

Arquitectura de alto nivel

Hatago se organiza en tres capas: núcleo del hub, registro MCP de herramientas recursos y prompts, y capa de transporte. La independencia de transporte es clave, de modo que la lógica superior funciona igual con STDIO o con HTTP en streaming vía SSE y WebSocket. El hub agrega herramientas de cada servidor MCP y compone un catálogo unificado. Para evitar colisiones de nombres, expone los nombres con el formato serverId_toolName hacia el cliente, mientras delega la ejecución con el nombre nativo en el servidor de origen. También reenvía notificaciones de progreso y puentea sampling createMessage, preservando la experiencia del usuario en operaciones largas y generación LLM delegada.

Puesta en marcha rápida

Inicializa con npx y elige modo stdio o http. Declara tus servidores en un archivo de configuración único con expansión de variables de entorno para usar el mismo archivo en dev y prod. Arranca en modo STDIO cuando uses un solo cliente o en modo HTTP si deseas compartir con varios clientes a la vez. Activa el modo watch para recargar cambios de configuración sin parar el proceso. Incluye utilidades internas como _internal_hatago_status para revisar conexiones, _internal_hatago_reload para forzar recarga y _internal_hatago_list_servers para listar servidores hijos.

Perfiles por etiquetas

Etiqueta cada servidor MCP con tags como dev, production o test, y filtra en el arranque con la opción de etiquetas para lanzar solo los que necesites. Esto permite mantener un único archivo de configuración para varios entornos y roles de equipo. Un flujo típico es usar solo local y mock durante el desarrollo, y añadir production para validaciones previas al despliegue.

Configuración por cliente

Claude Code: registra una sola entrada llamada hatago. En STDIO, lanza el comando de servicio con la ruta a tu config. En HTTP, apúntalo a la ruta de tu endpoint mcp. Hatago se encargará del namespacing y de notificar cambios del catálogo si el cliente soporta la notificación de cambio en herramientas.

Codex CLI: debido a su formato TOML, centralizar mediante el hub es especialmente útil. En STDIO, ejecuta npx con serve y stdio. Para HTTP, en el contexto del artículo, se requería un puente como mcp-remote si no existía soporte nativo de HTTP.

Uso multi cliente con HTTP

Si varios usuarios o equipos acceden a una instancia común de Hatago, el modo HTTP es ideal. Todos los clientes se conectan a la misma URL y el catálogo unificado se comparte de forma consistente. Puedes incluso ejecutar varias instancias de Hatago con diferentes filtros de etiquetas en puertos distintos, para que cada grupo consuma solo el subconjunto de herramientas que necesita.

Node y Workers

En Node, Hatago puede conectar con todos los tipos de servidores, incluyendo MCP locales lanzados con npx o node. En Workers o entornos serverless sin capacidad de spawn de procesos, es habitual conectarse a MCP remotos vía HTTP o SSE. Gracias a Hono, es sencillo añadir middlewares de logging, inyección de cabeceras o comprobaciones de autenticación, tanto en Node como en Workers. Si vas a desplegarlo en nubes públicas, te ayudamos a dimensionar y asegurar la arquitectura en servicios cloud AWS y Azure.

Detalles de diseño

Estrategia de colisiones de nombres con namespace serverId_toolName. Reenvío de notificaciones de progreso evitando duplicidad cuando existe progressToken. Puente de sampling para que las solicitudes de generación desde servidores descendentes lleguen al cliente y regresen al servidor original. Recarga en caliente con emisión de notificaciones de cambio de catálogo tras aplicar los ajustes.

Consejos operativos

Usa identificadores de servidor descriptivos como github-api o filesystem-tmp. Centraliza endpoints y tokens con variables de entorno. Si hay timeouts, amplía los valores en la configuración del servidor afectado. En autenticación, el hub no incorpora OAuth de serie. Puedes apoyarte en middleware de Hono o en una capa previa como Zero Trust con tokens portadores o cookies. Estas pautas encajan con prácticas de ciberseguridad y pentesting, fundamentales cuando expones MCP hacia equipos o terceros.

Limitaciones actuales

El hub no incluye autenticación integrada ni flujos OAuth. Si un MCP descendente exige OAuth, será necesario implementar una extensión adaptada al entorno. El núcleo se mantiene simple para facilitar la portabilidad y la adopción.

Uso como librería

La lógica del hub está disponible como paquetes para Node y Workers, lo que permite embebido en aplicaciones HTTP existentes con Hono. Es una forma ligera de crear un punto de agregación MCP en un gateway API o un portal interno, manteniendo una sola fuente de verdad para el catálogo de herramientas.

Conclusión y próximos pasos

A medida que crece la adopción de MCP, la complejidad de la configuración y la carga operativa también aumentan. Hatago MCP Hub concentra esa complejidad tras un único punto, manteniendo fluida la experiencia diaria. Sus pilares prácticos son evitar colisiones de nombres, el reenvío transparente del progreso, la recarga en caliente y herramientas internas de operación. Empieza conectando dos o tres servidores MCP en tu configuración y apunta tu cliente a una sola entrada hatago. Luego itera añadiendo o quitando servidores según tus necesidades, desde equipos pequeños hasta entornos con múltiples perfiles. En Q2BSTUDIO podemos ayudarte a integrar Hatago con pipelines de desarrollo, observabilidad, servicios inteligencia de negocio con power bi, seguridad y despliegues en cloud. Si tu hoja de ruta incluye aplicaciones a medida, software a medida, agentes IA o ia para empresas, estaremos encantados de acompañarte en la implantación end to end.