Experiencia práctica reemplazando el stack de automatización con servidores MCP y LLMs locales

Configuración y hardware

El desarrollador ejecuta una combinación de Qwen 2.5 32B (cuantizado) y Llama 3.3 70B en un equipo dual 3090. Cada tarea de automatización obtiene su propio servidor MCP que expone herramientas que el modelo puede llamar, funcionando como una API que consume un LLM en lugar de un humano.

Lo que funciona bien

• Automatización de revisión de código: Apuntar el modelo a un git diff a través de herramientas MCP detecta problemas reales, incluyendo errores de lógica, manejo de errores faltante y condiciones de carrera. Funciona aproximadamente un 70% tan bien como una revisión de un desarrollador senior.
• Análisis de registros y alertas: El servidor MCP se conecta a la pila ELK, con el modelo monitoreando patrones de anomalías. Ha detectado 3 problemas de producción antes de que se activaran las alertas de Grafana. La clave es dar suficiente contexto sobre cómo se ve lo "normal" para tu sistema.
• Generación de documentación: El modelo lee la base de código a través de herramientas de archivo MCP y genera/actualiza documentación de API, ahorrando horas por semana con una calidad de salida genuinamente buena.

Lo que no funciona (todavía)

• Cadenas de razonamiento de múltiples pasos: Cualquier cosa que requiera más de 3-4 llamadas a herramientas en secuencia comienza a desviarse a medida que el modelo pierde el contexto del objetivo original. Las ventanas de contexto más pequeñas empeoran esto. El prompting de cadena de pensamiento ayuda pero no lo resuelve.
• Toma de decisiones en tiempo real: La latencia en los modelos de 70B significa que esto no se puede usar para tareas sensibles al tiempo. La canalización de revisión de código toma 2-3 minutos por PR, lo que la hace adecuada para flujos de trabajo asíncronos pero inútil para aplicaciones en tiempo real.
• Resolución creativa de problemas: Los modelos locales tienen dificultades con tareas que requieren enfoques no bien representados en los datos de entrenamiento. Los modelos de API (Claude, GPT-4) son notablemente mejores aquí.

Lecciones arquitectónicas clave

• Mantén los servidores MCP sin estado. Deja que el modelo gestione el estado a través de llamadas a herramientas, no mediante sesiones en el servidor.
• Construye lógica de reintento en tu cliente MCP, no en el servidor. Los modelos harán llamadas a herramientas malformadas aproximadamente el 5% de las veces.
• Registra cada llamada a herramienta y respuesta para depurar cuando el modelo haga algo inesperado.
• Usa salida estructurada (modo JSON) para cualquier cosa que consuman los sistemas posteriores. La salida de texto libre es una pesadilla para depurar.