Daemon como propietario
Un único proceso supervisa servidores y conserva su estado para evitar instancias duplicadas.
Caso de proyecto
Universal MCP: construir, aprender y saber parar.
Una infraestructura local para centralizar servidores MCP que perdió su razón de producto cuando cambió el contexto.
Contexto
Muchas herramientas, ninguna capa común.
Universal MCP Orchestrator nació al empezar a utilizar MCP y querer ejecutar múltiples servidores desde distintos clientes sin repetir configuración, procesos y credenciales en cada uno.
La hipótesis era que una capa local estable podía centralizar ese trabajo y ofrecer una experiencia consistente.
Problema
Orquestar procesos que hablan un protocolo.
Un lanzador de comandos no era suficiente. El sistema debía conocer la salud de cada proceso, comunicarse mediante JSON-RPC 2.0 sobre entrada y salida estándar, normalizar herramientas, controlar respuestas grandes y separar configuración y credenciales.
Decisiones
Una frontera local y explícita.
Concurrencia asíncrona
La carga dominante era de entrada y salida: procesos, canales y solicitudes concurrentes.
Truncado y paginación
Limitar respuestas era parte de la interfaz para agentes, no un parche posterior.
Credenciales separadas
Los secretos siguen un ciclo distinto a la configuración para reducir exposición accidental.
Arquitectura
Un plano de control local.
Una interfaz de línea de comandos se comunica con un daemon local. El daemon supervisa procesos asíncronos y utiliza JSON-RPC 2.0 sobre entrada y salida estándar para gestionar servidores MCP.
- Daemon local con FastAPI.
- Interfaz de línea de comandos con Typer.
- Supervisión de procesos mediante asyncio.
- Normalización, truncado y paginación de herramientas.
Compromisos
Centralizar simplifica clientes y concentra responsabilidad.
Una sola capa reduce duplicación y permite observabilidad común. A la vez, se convierte en dependencia de todos los clientes y puede ocultar capacidades específicas de un servidor.
La arquitectura local protegía privacidad y latencia, pero añadía instalación, compatibilidad de procesos y mantenimiento.
Resultado
Una primera versión funcional, no un producto consolidado.
El proyecto llegó a ejecutar y gestionar servidores MCP, supervisar procesos, enviar solicitudes JSON-RPC y manejar respuestas mediante truncado y paginación.
No llegó a utilizarse de forma sostenida ni se publicó como producto.
Decisión de producto
Por qué se detuvo.
Mientras se desarrollaba, las principales herramientas empezaron a incorporar soporte MCP directamente. La fricción que justificaba una capa intermedia se redujo.
Parar no invalidó el trabajo; evitó confundir inversión pasada con una razón para seguir.
Aprendizaje
El valor sobrevivió de otra forma.
El proyecto fue el inicio de una metodología basada en agentes especializados. Separar responsabilidades, definir contratos y conservar la validación humana resultó más duradero que la herramienta.
Qué haría diferente hoy
Validaría antes si la coordinación debía ser un producto separado y definiría una condición explícita de parada si los clientes principales empezaban a resolver el problema.