Cuando construimos el primer servidor MCP en StudioMeyer, tenia tres herramientas. Hoy operamos 58 servidores MCP con mas de 680 herramientas -- un sistema que mapea toda nuestra logica de negocio, desde CRM hasta facturacion, produccion de video y analisis web. Este articulo es la historia tecnica detras: como se construye una infraestructura MCP que escala sin colapsar?
El inicio: Un servidor, tres herramientas
Todo gran sistema comienza pequeno. Nuestro primer servidor MCP era una herramienta CRM con tres funciones: crear contacto, buscar contacto, actualizar contacto. TypeScript, esquemas Zod para validacion de entrada, un handler por herramienta. Simple, funcional, util.
Pero una vez que un sistema funciona, los requisitos crecen. "Puedes tambien crear facturas?" "Necesitamos monitoreo." "Los correos de outreach tambien deberian correr por MCP." Cada requisito significaba: nuevas herramientas, nuevos esquemas, nuevos handlers. Y quedo claro: un unico servidor con 680 herramientas no funcionaria.
La arquitectura de 3 niveles
La solucion fue una arquitectura que separa herramientas por nivel de acceso y responsabilidad. Tres niveles, claramente definidos:
Nivel 1: Servidores internos
Los servidores de Nivel 1 son exclusivamente para nuestra propia infraestructura. Corren localmente, se comunican via stdio y nunca son accesibles publicamente.
Ejemplos:
- Nex Intelligence -- Nuestro sistema de memoria. Almacena decisiones, aprendizajes, patrones. Mas de 300 entradas, buscables por IA.
- Deploy (8 herramientas) -- Gestion de contenedores, deployments, rollbacks.
- Monitor (9 herramientas) -- Salud de servicios, estado de contenedores, monitoreo de recursos.
Nivel 2: Servidores compartidos
Los servidores de Nivel 2 se usan tanto internamente como por nuestros sistemas de agentes. Ofrecen transporte dual: stdio para uso local, HTTP para acceso de agentes.
Ejemplos:
- CRM (25 herramientas) -- Contactos, deals, pipeline, lead scoring, tags, notas, actividades, busqueda. El servidor mas completo del sistema.
- Billing (17 herramientas) -- Facturas, pagos, suscripciones, integracion Stripe.
- Outreach (10 herramientas) -- Secuencias de email, seguimientos, generacion de leads.
- Onboard (5 herramientas) -- Flujos de onboarding de clientes, seguimiento de hitos.
- Audit -- Calidad de codigo, escaneos de seguridad, verificaciones de cumplimiento.
Nivel 3: Servidores para clientes
Los servidores de Nivel 3 estan construidos para funcionar como productos independientes. Tienen APIs limpias, documentacion completa y pueden ser integrados por clientes como servidores MCP en sus propios asistentes.
Ejemplos:
- Media -- Generacion de video e imagen, integracion con flujos n8n.
- Video -- Grabacion de sitios web, captura de scroll, grabacion multi-dispositivo, text-to-speech.
- Effects -- Extraccion de animaciones de sitios web en vivo. Hover states, GSAP timelines, scroll triggers, rutas SVG, animaciones Lottie.
- Generate -- CSS keyframes, animaciones GSAP, efectos de scroll, shaders WebGL, escenas Three.js.
- Website -- Analisis web, capturas de pantalla, extraccion DOM, deteccion de componentes, conversion HTML-a-React.
- Social -- Creacion de contenido para redes sociales, carruseles, stories, gestion de brand kit.
La tecnologia: TypeScript, Zod y transporte dual
Cada servidor MCP sigue el mismo patron. Esto hace la arquitectura predecible y mantenible, sin importar si el servidor tiene 5 o 50 herramientas.
Esquemas Zod para todo
Cada entrada de herramienta se define mediante un esquema Zod. Sin tipos any, sin validaciones opcionales. Si un parametro es incorrecto, el esquema falla -- antes de que el handler se ejecute.
Esto no es solo seguridad de tipos -- es documentacion. El asistente de IA lee el esquema y sabe exactamente que parametros se esperan, cuales son opcionales y que formatos aplican.
Transporte dual: stdio + HTTP
Nuestra libreria compartida (@studio-mcp/shared) proporciona startDualTransport() -- una funcion que hace disponible cada servidor MCP tanto via stdio como HTTP.
Cada servidor de Nivel 2 y 3 tiene un puerto dedicado (CRM: 4001, Billing: 4002, Monitor: 4003, Deploy: 4004, Outreach: 4005, Onboard: 4006, Audit: 4007).
Patron Server Factory
Para sesiones HTTP, usamos un patron factory: createMcpServer() crea una instancia de servidor fresca para cada sesion HTTP. Sin estado compartido entre sesiones, sin fugas de memoria, sin race conditions.
Por que modular?
La tentacion es poner todo en un servidor. Un servidor, todas las herramientas, listo. Pero eso no escala -- por varias razones:
Tool sprawl: Un asistente con 680 herramientas simultaneas se satura. La calidad de seleccion de herramientas cae drasticamente a partir de 30-40 herramientas por contexto.
Responsabilidad: Si el servidor de facturacion tiene un bug, solo la facturacion se ve afectada.
Seguridad: No todo agente necesita acceso a todo. El agente de ventas no tiene acceso a deploy. El agente DevOps no tiene acceso al CRM. Privilegio minimo por diseno.
Escalabilidad: Cada servidor puede escalarse independientemente.
Que puedes aprender de esto
Si quieres construir tus propios servidores MCP, estas son las lecciones de nuestra experiencia:
- Empieza pequeno. Un servidor, tres herramientas, resuelve un problema. Luego expande.
- Esquemas Zod son obligatorios. No opcionales, no "despues." Desde la primera herramienta.
- Piensa modular. Un servidor por dominio, no un servidor para todo.
- Transporte dual desde el inicio. stdio para desarrollo, HTTP para produccion.
- Patron factory para HTTP. Sin estado compartido. Cada sesion obtiene una instancia fresca.
Las herramientas que corren sobre esta arquitectura estan disponibles en nuestra Tienda -- individualmente o como paquetes. Y si quieres construir tu propia infraestructura MCP: nosotros ya lo hicimos. Podemos hacerlo para ti tambien.
