Servidores MCP vs CLI: Cuándo Usar Cada Una

Preludio

Una vez pasamos una semana construyendo un servidor MCP en Rust para proporcionar un conjunto de prompts de revisión de código. El servidor tenía interfaces de herramientas tipadas, gestión de errores adecuada, respuestas JSON estructuradas y una superficie API limpia. Funcionaba a la perfección. Entonces alguien señaló que tres archivos markdown en .claude/commands/ habrían logrado lo mismo en diez minutos.

El error opuesto duele igual. Durante meses ejecutamos consultas de base de datos a través de la herramienta Bash de Claude Code, canalizando SQL sin procesar a través de psql y parseando la salida de texto. Cada consulta volcaba el conjunto de resultados completo en la ventana de contexto. La alineación de columnas se rompía. Los valores NULL se renderizaban como cadenas vacías. Y como la salida de Bash es texto sin estructura, Claude tenía que adivinar dónde terminaba una columna y empezaba la siguiente. Cuando finalmente construimos un servidor MCP con herramientas de consulta tipadas, la mejora fue inmediata: resultados estructurados, manejo adecuado de NULL, pool de conexiones y el uso de la ventana de contexto se redujo un 60%.

Estos no son escenarios hipotéticos. Son el tipo de errores que todo equipo que trabaja con Claude Code cometerá al menos una vez. La cuestión de cuándo usar un servidor MCP frente a una herramienta CLI es una de las decisiones arquitectónicas más comunes en el ecosistema de Claude Code, y hay sorprendentemente poca orientación práctica sobre cómo tomarla bien.

Esta guía es el marco de decisión que nos hubiera gustado construir antes de escribir aquel servidor Rust innecesario.

El Problema

Claude Code viene con dos formas fundamentalmente diferentes de interactuar con sistemas externos. La herramienta Bash da a Claude acceso directo al shell: puede ejecutar cualquier comando, canalizar salida, llamar a APIs con curl, manipular archivos con herramientas Unix estándar y encadenar operaciones con la sintaxis familiar del shell. El Model Context Protocol te permite construir servidores de herramientas dedicados que exponen interfaces tipadas: entradas estructuradas, salidas estructuradas, conexiones persistentes y capacidades descubribles.

Ambos enfoques funcionan. Ambos pueden realizar la mayoría de tareas. Y ese es precisamente el problema. Cuando dos herramientas pueden hacer el mismo trabajo, elegir entre ellas se convierte en una decisión de diseño en lugar de una restricción técnica. Las decisiones de diseño requieren marcos de trabajo, y el ecosistema MCP es demasiado joven para que se haya formado una sabiduría convencional.

El debate en la comunidad es real. En Hacker News y Reddit, los desarrolladores discuten sobre si MCP está sobreingeniado para tareas simples o si el scripting Bash es un riesgo para cualquier cosa más allá de operaciones desechables. CircleCI publicó una comparación teórica a principios de 2026, pero se queda en el nivel arquitectónico sin responder a la pregunta del profesional: dada esta tarea específica, ¿qué enfoque debería elegir?

El coste de elegir mal no es catastrófico. No vas a romper producción. Pero perderás tiempo, ya sea construyendo infraestructura excesiva para una tarea que necesitaba un script de shell, o acumulando patrones Bash frágiles que deberían haber sido herramientas adecuadas desde el principio. Después de un año construyendo tanto servidores MCP como integraciones CLI para la plataforma EntendIA, tenemos un marco claro para tomar esta decisión rápida y correctamente.

El Camino

Lo Que Te Da la Herramienta Bash

La herramienta Bash en Claude Code es la navaja suiza. Claude puede ejecutar cualquier comando del shell, y tanto stdout como stderr completos vuelven como texto en la conversación. Esto significa que toda herramienta CLI de tu sistema está inmediatamente disponible: git, curl, jq, psql, docker, kubectl, aws, gcloud, y miles más.

Las ventajas son significativas:

Cero configuración. No hay servidor que construir, ni configuración que escribir, ni proceso que gestionar. Si el comando existe en tu máquina, Claude puede ejecutarlo. Este es el camino más rápido de la idea a la ejecución.

Capacidades completas del SO. Bash puede hacer cosas que los servidores MCP no pueden replicar fácilmente: cadenas de pipes, gestión de procesos, operaciones del sistema de archivos con patrones glob, manipulación de variables de entorno y manejo de señales. Transformaciones de datos complejas que requerirían docenas de líneas de Rust o Python a menudo son un único pipeline.

Patrones familiares. Todo desarrollador conoce el scripting de shell. Cuando Claude escribe un comando Bash, puedes leerlo, entenderlo y modificarlo. No hay capa de abstracción que aprender.

Composición. Los comandos del shell se componen de forma natural. curl -s https://api.example.com/data | jq '.items[] | .name' | sort | uniq -c | sort -rn es un pipeline de datos válido que Claude puede escribir y ejecutar en una sola llamada a herramienta.

Pero Bash tiene limitaciones reales que aparecen en uso productivo:

Coste de ventana de contexto. Cada llamada a la herramienta Bash devuelve la salida stdout completa como texto en la conversación. Un SELECT * FROM users que devuelve 500 filas vuelca todo ese texto en la ventana de contexto. Un log de compilación verboso consume miles de tokens. No hay forma de filtrar o estructurar la salida antes de que entre en la conversación. A lo largo de una sesión larga, esto agota tu presupuesto de contexto más rápido que cualquier otra herramienta.

Sin seguridad de tipos. La salida de Bash es texto. Si Claude necesita extraer un campo específico de salida JSON, parsea texto. Si un nombre de columna cambia en una consulta de base de datos, el parseo se rompe silenciosamente. No hay validación de esquema, ni comprobaciones en tiempo de compilación, ni gestión de errores estructurada.

Sin estado persistente. Cada llamada a la herramienta Bash es independiente. No hay pool de conexiones, ni estado de sesión, ni autenticación cacheada. Si consultas una base de datos diez veces, abres diez conexiones. Si llamas a una API que requiere OAuth, te reautentificas en cada petición (o gestionas tokens manualmente en variables de entorno).

Sin descubrimiento. Claude no sabe qué herramientas CLI están disponibles en tu sistema hasta que intenta ejecutarlas. Con MCP, Claude recibe una lista de herramientas disponibles y sus esquemas al inicio de la conversación.

Lo Que Te Dan los Servidores MCP

Un servidor MCP es un proceso independiente que expone un conjunto de herramientas a través del Model Context Protocol. Claude se comunica con él por stdio o HTTP, enviando peticiones estructuradas y recibiendo respuestas estructuradas. Tú defines los esquemas de herramientas (nombre, descripción, parámetros de entrada, formato de salida), y Claude los descubre automáticamente.

Las ventajas abordan directamente las debilidades de Bash:

E/S estructurada. Las entradas de herramientas son JSON tipado. Las salidas de herramientas son JSON tipado. Claude no necesita parsear texto, adivinar límites de columna ni manejar problemas de codificación. Una herramienta de consulta de base de datos devuelve filas como objetos JSON con tipos adecuados, no texto separado por tabulaciones.

Eficiencia de contexto. Las herramientas MCP pueden devolver exactamente los datos necesarios, en el formato necesario. Una herramienta de consulta de base de datos puede devolver 10 filas de 3 columnas en lugar de 500 filas de 20 columnas. Una herramienta de búsqueda de logs puede devolver coincidencias estructuradas en lugar de líneas de log sin procesar con contexto circundante. Esta precisión reduce drásticamente el consumo de la ventana de contexto. En nuestra experiencia, cambiar de Bash a MCP para operaciones de base de datos redujo el uso de contexto entre un 40-60% por consulta.

Conexiones persistentes. Un servidor MCP mantiene estado entre llamadas a herramientas. Los pools de conexiones de base de datos permanecen abiertos. Los tokens de autenticación de API se cachean. Las conexiones WebSocket persisten. Esto elimina la sobrecarga por llamada que hace que Bash sea costoso para operaciones con estado.

Descubrimiento. Cuando Claude se conecta a un servidor MCP, recibe un manifiesto de herramientas disponibles con descripciones y esquemas. Claude sabe lo que puede hacer antes de intentarlo. Esto reduce los intentos fallidos y hace que los flujos de trabajo de múltiples pasos sean más fiables.

Distribución en equipo. Los servidores MCP se pueden empaquetar y compartir a través del Anthropic Marketplace o distribuir como configuración de equipo. Un script Bash vive en el entorno de un desarrollador; un servidor MCP puede ser instalado por toda la organización.

Pero MCP tiene sus propios costes:

Tiempo de construcción. Incluso un servidor MCP simple lleva horas construir, probar y desplegar. El protocolo tiene requisitos específicos para el registro de herramientas, gestión de errores y gestión del ciclo de vida. Nuestro servidor MCP más simple (una herramienta basada en Rust para consultas estructuradas) llevó un día completo construirlo y probarlo.

Carga de mantenimiento. Los servidores MCP son software. Tienen dependencias, necesitan actualizaciones, pueden romperse. Un comando Bash que llama a curl funciona mientras curl esté instalado. Un servidor MCP que envuelve la misma API necesita mantenerse como una base de código separada.

Sobrecarga de infraestructura. Los servidores MCP son procesos que necesitan iniciarse, gestionarse y monitorizarse. En despliegues en producción, necesitan comprobaciones de salud, registro y políticas de reinicio. Esto es apropiado para herramientas de todo el equipo pero excesivo para utilidades personales.

Curva de aprendizaje. Construir servidores MCP requiere entender el protocolo, el SDK de tu lenguaje y los patrones de autenticación para despliegues seguros. Es una inversión significativa, especialmente para desarrolladores que solo necesitan una o dos herramientas personalizadas.

El Marco de Decisión

Después de construir docenas de servidores MCP y cientos de integraciones Bash, destilamos la decisión en cinco criterios. Puntúa cada uno para tu tarea específica, y la elección correcta se vuelve obvia.

1. Frecuencia: ¿Con qué frecuencia se ejecutará?

Puntual o infrecuente (menos de una vez por semana): Usa Bash. El coste de configuración de un servidor MCP nunca se justifica para una tarea que ejecutarás un puñado de veces. Incluso si el enfoque Bash es ligeramente menos elegante, el tiempo total invertido es menor.

Regular (diario o más): Considera MCP. La inversión inicial se recupera rápidamente cuando se amortiza entre cientos de ejecuciones. El pool de conexiones, la autenticación cacheada y la salida estructurada ahorran tiempo en cada llamada.

Continuo (siempre en ejecución, basado en eventos): MCP es la elección clara. Las conexiones persistentes, la gestión del ciclo de vida y la gestión de errores estructurada son esenciales para integraciones que están siempre activas.

2. Audiencia: ¿Quién lo usará?

Solo tú: Bash es casi siempre suficiente. Conoces tu entorno, puedes manejar las asperezas y no necesitas documentar la interfaz.

Tu equipo: MCP se vuelve atractivo. Los esquemas tipados de herramientas sirven como documentación. El servidor se puede distribuir a través de archivos de configuración. Todos obtienen el mismo comportamiento independientemente de su entorno local.

La organización o marketplace: MCP es obligatorio. No puedes distribuir un script Bash a través del Anthropic Marketplace. Las herramientas compartidas necesitan la fiabilidad, el descubrimiento y la seguridad que el protocolo proporciona.

3. Estado: ¿La operación necesita persistencia?

Sin estado (cada llamada es independiente): Bash funciona bien. curl, grep, lecturas de archivos, operaciones git y la mayoría de herramientas Unix son inherentemente sin estado.

Con estado (conexiones, sesiones, cachés): MCP es mejor. Los pools de conexiones de base de datos, las sesiones de API con tokens de refresco, las suscripciones WebSocket y las cachés en memoria requieren un proceso persistente. Bash no puede mantener estado entre llamadas a herramientas sin ayudas externas como archivos temporales o variables de entorno, que son frágiles.

4. Complejidad: ¿Cuán estructurada es la E/S?

Texto simple (unas pocas líneas, formato predecible): Bash está bien. git status, ls -la, echo $VARIABLE producen salida que Claude puede parsear de forma fiable.

Datos estructurados (JSON, tablas, objetos anidados): MCP es mejor. En el momento en que te encuentras escribiendo | jq '...' o | awk '{print $3}' para extraer datos de la salida de Bash, estás haciendo trabajo que una herramienta MCP maneja de forma nativa. Si la salida supera las 20 líneas o contiene estructuras anidadas, solo el ahorro en ventana de contexto justifica MCP.

Datos binarios o payloads grandes (imágenes, archivos grandes, streams): MCP es obligatorio. La salida de la herramienta Bash es texto. Los datos binarios no sobreviven al viaje de ida y vuelta. Los payloads grandes consumen demasiado contexto.

5. Distribución: ¿Se compartirá o empaquetará?

Solo local: Bash. Sin necesidad de empaquetado, sin gestión de versiones, sin canal de distribución.

Compartido por configuración: Ambos funcionan, pero MCP es más limpio. Puedes apuntar la configuración de Claude Code de un equipo a un servidor MCP compartido. Los scripts Bash compartidos requieren gestión de PATH y seguimiento de dependencias.

Marketplace o plugin: Solo MCP. El sistema de plugins requiere el protocolo MCP para la distribución de herramientas.

Puntuando el Marco

Para cualquier nueva integración, puntúa cada criterio en una escala simple: Bash (0) o MCP (1). Si el total es 0-1, usa Bash. Si el total es 2-3, ambos funcionan pero inclínate hacia la mayoría. Si el total es 4-5, MCP es la elección correcta.

En la práctica, el criterio 2 (audiencia) y el criterio 3 (estado) tienen más peso. Una herramienta que solo usas tú y no requiere estado persistente es casi siempre Bash, independientemente de los otros criterios. Una herramienta que el equipo comparte y necesita conexiones persistentes es casi siempre MCP, independientemente de cuán compleja sea la E/S.

La Tabla de Referencia Rápida

Análisis de Coste y Complejidad

El coste oculto de ambos enfoques es el consumo de la ventana de contexto.

Una llamada a la herramienta Bash que ejecuta psql -c "SELECT id, name, email FROM users WHERE active = true" devuelve la salida de texto completa: cabeceras de columna, líneas separadoras, filas de datos y un resumen del recuento de filas. Para 100 filas, esto son aproximadamente 5.000 tokens de contexto consumidos.

Una herramienta MCP que ejecuta la misma consulta devuelve un array JSON de 100 objetos con tres campos cada uno. El formato estructurado es más denso (sin relleno, sin separadores), y el servidor MCP puede limitar el conjunto de resultados, paginar o resumir. Las mismas 100 filas consumen aproximadamente 2.000 tokens.

A lo largo de una sesión con 20 consultas de base de datos, esa diferencia se acumula: 100.000 tokens ahorrados, lo que es aproximadamente el 10% de la ventana de contexto de Claude. En sesiones largas, esta es la diferencia entre alcanzar el límite de contexto y tener margen para trabajar.

Comparación de costes de construcción:

El punto de equilibrio varía según la frecuencia de uso. Para una herramienta usada 5 veces al día por un equipo de 4 personas, un servidor MCP recupera su coste de construcción en una semana mediante la reducción del uso de contexto y la eliminación de errores. Para una herramienta usada una vez a la semana por un desarrollador, Bash nunca pierde su ventaja.

Ejemplos Reales de Producción

Ejemplo 1: Prompts de revisión de código (construimos de más)

Lo que construimos: Un servidor MCP en Rust que servía plantillas de prompts para revisión de código. El servidor tenía herramientas para diferentes tipos de revisión (seguridad, rendimiento, estilo) y aceptaba parámetros como lenguaje, nivel de severidad y área de enfoque.

Lo que deberíamos haber hecho: Tres archivos markdown en .claude/commands/. El sistema de skills gestiona la expansión de prompts de forma nativa. Sin servidor necesario, sin proceso que gestionar, sin paso de compilación. El servidor MCP añadió complejidad para algo que era fundamentalmente una plantilla de texto.

La lección: Si la "herramienta" solo devuelve texto que no depende de estado externo, es una skill o un comando, no un servidor MCP.

Ejemplo 2: Consultas de base de datos (construimos de menos)

Lo que hicimos: Ejecutamos consultas PostgreSQL a través de Bash durante tres meses. psql -h localhost -U app -d production -c "SELECT ..." canalizado a través de jq o awk cuando necesitábamos salida estructurada.

Los problemas que se acumularon: Sobrecarga de conexión (nueva conexión TCP por consulta, ~200ms cada una). Salida sin estructura (la alineación de columnas se rompía con valores largos). Sin manejo de NULL (las cadenas vacías y los NULL eran indistinguibles). Inflado de contexto (cada consulta volcaba resultados completos incluyendo cabeceras y formato).

Lo que construimos en su lugar: Un servidor MCP con herramientas de consulta tipadas. run_query acepta SQL y devuelve filas JSON. describe_table devuelve metadatos de columnas. explain_query devuelve el plan de consulta como datos estructurados. El pool de conexiones redujo la latencia de 200ms a 5ms por consulta. El uso de contexto se redujo un 60%.

La lección: Si estás llamando al mismo servicio externo repetidamente y parseando su salida de texto, eso es un servidor MCP esperando a ser construido.

Ejemplo 3: El enfoque híbrido (nuestro pipeline de analítica)

Nuestro flujo de trabajo diario de monitorización SEO usa ambos enfoques:

Bash para exploración ad-hoc: Al investigar una anomalía de tráfico, usamos curl para extraer datos de varias APIs, jq para filtrar y transformar, y pipelines del shell para combinar fuentes de datos. Son investigaciones puntuales que cambian cada vez. Construir herramientas MCP para ellas sería prematuro.

MCP para operaciones estructuradas y repetidas: Nuestra CLI de analítica (systemprompt analytics overview, systemprompt analytics content top) está construida sobre un binario Rust que la plataforma proporciona. La integración con Google Search Console usa un flujo de autenticación dedicado con tokens persistentes. Se ejecutan diariamente y se benefician de la salida estructurada, la gestión de conexiones y los esquemas fiables.

El límite: Cuando un patrón Bash se estabiliza (mismo comando, mismo parseo, usado más de 3 veces por semana), evaluamos si promoverlo a una herramienta MCP. La mayoría de los patrones ad-hoc nunca se estabilizan. Los que sí lo hacen se promueven rápidamente.

El Enfoque Híbrido

Las mejores configuraciones de Claude Code usan ambos enfoques. Bash maneja el trabajo exploratorio, ad-hoc y a nivel de SO. MCP maneja el trabajo estructurado, repetido y compartido en equipo. La clave es saber cuándo graduar un patrón Bash a una herramienta MCP.

Empieza con Bash. Siempre. Incluso si sospechas que eventualmente necesitarás MCP, empieza con Bash. Esto te permite descubrir la interfaz real que necesitas (qué entradas, qué salidas, qué casos de error) antes de comprometerte con un esquema tipado. MCP prematuro es el equivalente arquitectónico de la abstracción prematura.

Observa las señales de promoción. Un patrón Bash está listo para MCP cuando:

1. Has ejecutado el mismo comando (o variantes cercanas) más de 10 veces
2. Has añadido | jq, | awk o | grep para parsear la salida al menos 3 veces
3. Alguien más en tu equipo necesita la misma capacidad
4. El comando requiere autenticación o estado que gestionas manualmente
5. La salida supera regularmente las 50 líneas y solo necesitas un subconjunto

Migra incrementalmente. No necesitas reemplazar todo el uso de Bash de una vez. Promueve un patrón a la vez. Mantén Bash para todo lo demás. A lo largo de los meses, la frontera entre Bash y MCP se asentará naturalmente en el lugar correcto para tu flujo de trabajo.

Mantén Bash para lo que hace mejor. Incluso en una configuración madura con muchos servidores MCP, Bash sigue siendo la herramienta correcta para: operaciones del sistema de archivos (find, cp, mv, rm), operaciones git (git status, git diff, git log), gestión de procesos (ps, kill, top) e inspección del entorno (env, which, uname). Estos son primitivos del SO que no se benefician de la estructura de MCP.

Dónde Encajan los Hooks

Hay una tercera opción que se sitúa entre Bash y MCP: los hooks de Claude Code. Los hooks son comandos del shell basados en eventos que se disparan automáticamente en eventos específicos del ciclo de vida (antes/después del uso de herramientas, al enviar un prompt, al iniciar una sesión). Son scripts Bash, pero se ejecutan en respuesta a eventos en lugar de ser llamados explícitamente.

Los hooks son ideales cuando necesitas automatización en la que Claude no debería tener que pensar: registrar cada llamada a herramienta, aplicar estándares de código antes de ediciones, notificar a un canal de Slack cuando una sesión comienza, o ejecutar linting después de cada escritura de archivo. Complementan tanto a Bash como a MCP en lugar de reemplazar a ninguno.

Si te encuentras pidiendo a Claude que "ejecute este comando después de cada edición" o "siempre compruebe esto antes de hacer commit", eso es un hook, no un comando Bash ni una herramienta MCP.

La Conclusión

La decisión entre MCP y Bash no se trata de qué tecnología es mejor. Se trata de emparejar la herramienta con la tarea.

Usa Bash cuando la tarea es ad-hoc, local, sin estado y la salida es texto simple. Usa MCP cuando la tarea es repetida, compartida, con estado o produce datos estructurados. Empieza con Bash, observa las señales de promoción y migra a MCP cuando el patrón se estabilice.

Los cinco criterios (frecuencia, audiencia, estado, complejidad, distribución) te dan una decisión rápida para cualquier nueva integración. Puntúalos honestamente y la respuesta suele ser obvia. Cuando no es obvia, elige Bash por defecto. Siempre puedes promover después, pero no puedes degradar fácilmente un servidor MCP a un script de shell sin que el coste hundido te susurre al oído.

Las mejores configuraciones de Claude Code no son todo Bash ni todo MCP. Son híbridos que usan cada enfoque donde destaca. Construye lo más pequeño que funcione hoy, y deja que la arquitectura evolucione a partir del uso real en lugar de la planificación teórica.