English

Bash o MCP

No toda integración nueva necesita un servidor. Si tu agente ya puede abrir una terminal y ejecutar una herramienta de línea de comandos, montar un servidor MCP para el mismo trabajo es infraestructura extra sin capacidad extra. La pregunta que vale la pena hacerse antes de construir un servidor no es "¿podría MCP hacer esto?", sino "¿el agente ya tiene una forma más simple de entrar?".

El problema: recurrir a un servidor por defecto

Los servidores MCP (Model Context Protocol) le dan al agente acceso estructurado y documentado a un sistema, algo útil cuando ese sistema no tiene otra forma de entrada. Pero es fácil tratar "montar un servidor MCP" como el movimiento por defecto para cualquier integración, incluso cuando el agente ya tiene un camino perfectamente bueno a través de bash.

Pedirle a un agente que "cree un issue de prueba en esta URL" no necesita ningún servidor si la CLI de GitHub ya está instalada y autenticada en la máquina: el agente simplemente ejecuta gh issue create. Sin configuración, sin servidor que mantener, sin una capa de protocolo entre el agente y la herramienta que ya sabe usar.

La regla de decisión

Todo se reduce a una pregunta: ¿es esta una herramienta común que el agente ya conoce, o un sistema desconocido que no tiene forma de descubrir?

• Plataforma común y conocida → bash. GitHub, Jira y plataformas mainstream similares ya tienen herramientas de línea de comandos maduras. Los grandes modelos de lenguaje generalmente han visto suficiente de estas CLIs durante el entrenamiento como para conocer ya los comandos —gh issue create, git push, llamadas estándar de la CLI de Jira— sin ningún andamiaje adicional. Si tú mismo ya usas la CLI, tu agente probablemente también puede manejarla.
• Sistema interno o desconocido → MCP. Aquí es donde MCP realmente vale la pena: servicios internos desconocidos cuya documentación el agente nunca ha visto. Un sistema de diagnóstico interno, un panel propietario, una API específica de la empresa sin documentación pública: nada de eso está en los datos de entrenamiento del modelo, y no hay una CLI a la que el agente pueda recurrir. Un servidor MCP es lo que lo hace descubrible y utilizable en absoluto.

Ejemplo

gh issue create — el agente ejecuta la CLI de GitHub existente y autenticada. Sin configuración. Compáralo con una API interna sin documentación pública: un servidor MCP describe qué operaciones existen y cómo llamarlas, algo que el agente no tiene otra forma de aprender.

Cómo aplicarlo

Antes de recurrir a un servidor, hazte dos preguntas en orden:

1. ¿Es esta una plataforma común (GitHub, Jira o similar) que ya tiene una CLI? Si es así, deja que el agente use bash. Probablemente ya conoce los comandos, y te ahorras un servidor que construir y mantener.
2. ¿Es esto interno, propietario o de otro modo no documentado en ningún lugar donde el modelo pudiera haberlo aprendido? Si es así, ese es un caso real para MCP: el servidor es lo que convierte un sistema interno opaco en algo que el agente realmente puede operar.

El factor de fondo es qué tan simple es la operación. Las operaciones simples y conocidas sobre plataformas conocidas no necesitan una capa de protocolo en medio. Los sistemas complejos o desconocidos se benefician de una porque no hay otra forma de que el agente aprenda la forma de la API.

Trucos avanzados

• No trates MCP como inherentemente más avanzado. Es una herramienta para una brecha específica —la descubribilidad de sistemas desconocidos— no una mejora universal sobre bash.
• Revisa primero qué CLI ya usas tú mismo. Si manejas GitHub, Jira u otra plataforma desde tu propia terminal, esa es una señal fuerte de que tu agente también puede, sin ninguna infraestructura nueva.
• Reserva el esfuerzo de construir servidores para las herramientas que nadie ha documentado. Ahí es donde un servidor MCP convierte a un agente de inútil a genuinamente útil en ese sistema.