Casi veinte servidores MCP: cuando «más herramientas» se vuelve un problema de diseño

Serie Homelab · Parte 4 · ← MCP: el protocolo que le da manos a la IA · Del agente ReAct a ARIA → · Ver la serie

TL;DR: Agregar un servidor MCP es fácil. Lograr que casi veinte convivan sin confundir a la IA es otra historia. Te cuento cómo los organizo: unos siempre encendidos, otros bajo demanda, un enrutador que decide cuáles conectar y varias lecciones sobre gastar contexto en herramientas.

Más herramientas no es mejor

Cuando descubrí MCP hice lo que hacemos todos con una tecnología nueva: la escalé sin pensar en las consecuencias. «Si uno es bueno, dos son mejores. Si dos son buenos, veinte son… ¿veinte veces mejores?»

No. El problema ya no es «¿cómo hago que esto funcione?» sino «¿cómo hago que funcione bien?», que es otra pregunta.

La razón es simple. Cada herramienta que le muestras al modelo ocupa espacio en su contexto: nombre, descripción y esquema de parámetros. Con pocas, no se nota. Con muchas, gastas ventana de contexto en catálogo y, peor, aumenta la probabilidad de que el modelo elija una herramienta parecida pero equivocada porque la correcta quedó enterrada entre decenas de definiciones. Es un problema conocido, y tarde o temprano te lo encuentras.

Cómo los organizo

No todos los servidores tienen el mismo trabajo ni el mismo apetito:

• Siempre encendidos: los de uso diario. Grafana, Proxmox, Docker, WordPress, WooCommerce, notificaciones, despensa y la tablet de pared.
• Bajo demanda: el navegador (Playwright) y Meta. Pesan más, se usan menos, y solo se prenden cuando un pedido los necesita.
• En otra VM: los de procesos de fondo, que son memoria, transcripciones, video, contenedores y calendario.
• Un navegador propio para ARIA, en una VM aparte que se enciende cuando se lo pido y se apaga sola tras tres horas sin uso.

El enrutador: elegir qué conectar

Aquí está la parte que más me gusta. La plataforma no le muestra a la IA los veinte servidores todo el tiempo: tiene un enrutador de MCP que elige cuáles conectar según lo que le pides.

Si tu pedido necesita un servidor que está apagado, el enrutador lo enciende con el MCP de Docker y espera a que responda. Menos herramientas a la vista significa menos contexto gastado y menos ocasiones de equivocarse.

Pero tiene su trampa. La conexión MCP de Claude se establece una sola vez, al arrancar el proceso. Si el servicio no estaba listo en ese momento, ARIA me avisa «ya lo prendí» y me pide repetir el pedido en un mensaje nuevo. Sí: mi asistente a veces me dice «ya voy, ya voy» y me deja repitiendo la pregunta. Es el precio de no tener todo prendido todo el tiempo.

Otro detalle de diseño: los servidores de destino, como la tablet de pared o las notificaciones, no son fuente de datos. Si el pedido menciona «mándame un aviso», eso no debería hacer que el enrutador se ponga a buscar información en el servidor de notificaciones. Por eso ese tipo de servidores no cuenta como señal de contenido.

Un MCP, varias marcas

Los MCP de WordPress y WooCommerce atienden varias marcas a la vez. Cada herramienta recibe un parámetro brand, y hay una que lista las marcas disponibles. El mismo servidor que publica en este blog atiende también mis otras webs, cada una con sus propias credenciales, que viven fuera del repositorio.

Lo que aprendí

1. Empieza con pocos y úsalos una semana antes de sumar otro. Técnicamente puedes conectar cinco en una tarde. Pero necesitas tiempo para ver cómo cada uno cambia el comportamiento del asistente.
2. La descripción de cada herramienta es parte del prompt. «Obtener información de VM» es mucho peor que «Lista las VMs del clúster con su CPU, RAM y estado». Reescribir descripciones es de lo mejor que hice por mi tiempo.
3. Lo pesado, apagado hasta que se necesite. Un navegador headless prendido las 24 horas es un contenedor haciendo nada con mucho entusiasmo.
4. Separa fuentes de destinos. No todo servidor sirve para recoger datos.
5. Mide qué se usa. Si nunca llamas a un servidor, probablemente sobra. En la parte de Langfuse te cuento cómo lo veo.

Y la lección que se queda conmigo: MCP simplifica la integración de herramientas, pero no la arquitectura del sistema que las usa. Es un sistema distribuido con todo lo que eso implica: fallos parciales, tiempos de espera, observabilidad y contratos entre piezas.