MCP frente a CLI para agentes de IA: ¿cuál debería usar?

El debate entre MCP y CLI es una de esas discusiones que empieza en Reddit, migra a Hacker News y acaba aterrizando en el documento de arquitectura de su equipo como una decisión a medio terminar que nadie tomó. He visto esto suficientes veces como para tener una postura: CLI es la mejor opción predeterminada para la mayoría de las tareas de agentes, MCP justifica su complejidad solo cuando realmente necesita autenticación centralizada, descubrimiento estructurado de herramientas u orquestación entre varios servicios, y la mayoría de los sistemas de producción que llevan funcionando más de seis meses terminan usando ambos.

Si no está de acuerdo con eso, perfecto. Es el punto de partida adecuado.

Lo que los equipos aprenden tarde

• CLI cuesta entre 4 y 32 veces menos tokens que MCP para tareas comparables; esa diferencia se acumula a escala.
• MCP solo justifica su sobrecarga cuando necesita autenticación centralizada, descubrimiento basado en esquemas u orquestación entre servicios en un flujo de agente de IA.
• La verdadera elección es una decisión de cartera: CLI para el bucle interno, MCP para el bucle externo.
• La mayoría de los debates sobre «MCP vs CLI» omiten las API HTTP directas; a veces esa es la respuesta correcta para ambos.

MCP vs CLI: la comparación que la mayoría de los equipos interpreta al revés

El enfoque habitual trata esto como una cuestión de capacidades. No lo es. Es una cuestión de costes y contexto. Aquí es donde ambos difieren realmente en la práctica.

El debate sobre MCP suele atascarse en si el protocolo MCP es «mejor». Ese es el eje equivocado. La herramienta CLI que ya tiene funciona en la mayoría de los casos de un solo agente y entorno local sin infraestructura adicional. El servidor MCP justifica su existencia cuando el problema de coordinación es real.

Por qué CLI cuesta menos tokens que MCP para la misma tarea

El coste de tokens importa para los agentes de IA de formas que no importa en prompts puntuales. Un agente que realiza docenas de llamadas a herramientas por sesión, en cientos de sesiones al día, consume dinero con cada token adicional en la ventana de contexto. La elección entre herramientas e infraestructura termina siendo una decisión presupuestaria.

El benchmark que fundamentó este debate para mí: el análisis de Shareuhack de una comparación de 75 ejecuciones entre llamadas API sin procesar, servidores MCP y herramientas CLI para agentes de IA concluyó que CLI cuesta entre 4 y 32 veces menos tokens que las llamadas MCP equivalentes a CLI, y que los agentes basados en CLI lograron una tasa de éxito del 100 % en ciertos flujos de automatización, frente al 72 % de sus equivalentes MCP. Ese rango (4-32 veces) es lo bastante amplio como para decir «depende de la tarea», pero el mínimo sigue siendo 4 veces y el máximo resulta caro.

Conviene entender por separado los mecanismos detrás de esa diferencia, porque apuntan a distintos modos de fallo.

Cómo se acumulan los costes de MCP por solicitud

El diseño de MCP basado en esquemas es también su problema de tokens. Antes de que un agente pueda realizar llamadas a herramientas MCP, debe cargar las definiciones de herramientas desde el servidor MCP. Cada herramienta del registro contribuye a esa carga útil inicial de esquemas: el agente necesita saber qué herramientas existen, qué parámetros aceptan y qué salidas debe esperar antes de poder invocar cualquiera de ellas.

En una configuración MCP típica con unas pocas herramientas, esa carga de esquemas puede añadir cientos de tokens a cada solicitud antes de que se ejecute el comando real. Cuando escala a docenas de herramientas en varios servidores, MCP obliga al agente a transportar mucho más contexto por ciclo. Con grandes volúmenes de llamadas, esa sobrecarga no es un error de redondeo. Es una partida presupuestaria.

De dónde proviene la eficiencia de tokens de CLI

Los agentes basados en CLI no transportan esa sobrecarga de esquemas porque no la necesitan. Los LLM han visto enormes cantidades de sintaxis CLI en los datos de entrenamiento —git, curl, kubectl, aws, gh—, lo que significa que los comandos CLI resultan naturales para el modelo. No hace falta cargar ningún esquema en cada llamada. El modelo ya sabe qué devuelve git status y qué espera aws s3 cp.

Esa es la dinámica de un «hablante nativo de CLI». Los agentes basados en CLI pueden apoyarse en el vocabulario existente del modelo para las interacciones con el shell, por eso CLI resulta más ligero en la práctica. Las ventajas de CLI en el contexto de agentes proceden en parte del diseño de infraestructura y en parte de los datos de entrenamiento: el modelo ya domina el lenguaje antes de la primera llamada.

📊 En cifras:
En 75 ejecuciones de benchmark que compararon CLI y MCP para tareas de automatización basadas en agentes, los agentes basados en CLI alcanzaron el 100 % de finalización de tareas en determinados casos, mientras que los agentes basados en MCP llegaron al 72 %, junto con una diferencia de coste de tokens de entre 4 y 32 veces. No son cifras fijas: la diferencia se reduce en tareas de datos estructurados donde el acceso directo a API de MCP disminuye el trabajo posterior de análisis. Pero como punto de partida práctico, asuma que CLI es más barato hasta que su flujo demuestre lo contrario.

El problema de MCP del que nadie habla en producción

El coste de tokens es el argumento visible contra MCP. El argumento de producción es más complejo y se comenta menos.

El argumento contra MCP en producción no es filosófico, sino operativo. Cada servidor MCP puede representar un artefacto de despliegue que debe versionarse, supervisarse y actualizarse cuando cambian las capacidades de las herramientas. Muchas implementaciones MCP que funcionan en staging fallan silenciosamente tras la primera actualización de esquema, porque el agente estaba llamando a una definición de herramienta que ya no coincide con lo que el servidor realmente hace. El agente no lo sabe. No hay nada incorrecto en el registro de ejecución hasta que rastrea un fallo posterior hasta una llamada a herramienta obsoleta.

Sigo viendo este patrón en soporte: los equipos ponen en marcha un servidor MCP, funciona, construyen flujos sobre él y, tres meses después, alguien actualiza una herramienta y el agente posterior empieza a generar resultados inútiles. El servidor MCP puede seguir funcionando perfectamente. El esquema que ofrece simplemente está desincronizado con el comportamiento real del servicio subyacente.

La velocidad de iteración de desarrollo también es menor con MCP. Modificar un script CLI lleva segundos. Modificar un esquema MCP, volver a desplegar el servidor y probar de nuevo la interacción del agente lleva bastante más tiempo, y esa fricción se acumula en un equipo que itera rápidamente.

Cuando la configuración del servidor MCP se convierte en el cuello de botella

Cada servidor MCP que despliega es infraestructura que ahora le pertenece. Configuración de transporte, autenticación, observabilidad y actualizaciones. CLI evita todo esto: está envolviendo un comando que ya existe y ejecutándolo en un contexto que ya controla.

La fricción del despliegue en producción es suficientemente real como para que la mayoría de las implementaciones MCP se estanquen antes de llegar a producción. Los equipos descubren el coste de configuración no durante la planificación, sino después de que la primera actualización de esquema rompa una llamada de agente posterior a las 2 de la madrugada. Es entonces cuando se revisa la decisión de «simplemente ejecutaremos un servidor MCP para esto».

Los despliegues remotos de servidores MCP añaden otra capa: fiabilidad de red, seguridad de endpoints y la pregunta de quién lo mantiene cuando la persona que lo construyó está de vacaciones. CLI no plantea estas preguntas. Se ejecuta donde se ejecuta el agente.

Explosión de herramientas y deriva de esquemas con MCP

Añadir una nueva capacidad a un agente CLI significa añadir un comando. Añadirla a un registro de herramientas MCP significa añadir una definición de esquema, actualizar la documentación, volver a desplegar y comprobar que el comportamiento existente del agente no ha cambiado porque la nueva herramienta modificó la lista de herramientas que el agente ve al cargar.

Varios servidores MCP agravan esto. Tres servidores MCP con espacios de nombres de herramientas superpuestos representan el problema de complejidad de composición sobre el que nadie le advierte antes de que esté inmerso en él. El agente empieza a realizar selecciones ambiguas de herramientas porque existen herramientas con nombres similares en diferentes servidores. La deriva de esquemas, donde la definición de una herramienta diverge de su comportamiento real con el tiempo, se vuelve más difícil de detectar y corregir sin romper los flujos dependientes.

No es una preocupación teórica. Ahí es donde empiezan la mayoría de los tickets de «nuestra configuración MCP se volvió complicada».

Use CLI cuando el flujo de su agente se parezca a esto

CLI gana en casos específicos e identificables. Si su flujo encaja con alguno de estos patrones, empiece con CLI y añada MCP solo si realmente alcanza sus límites.

• Operaciones de archivos y directorios en un entorno controlado

  Leer, escribir, mover y transformar archivos dentro de un contexto de servidor local o gestionado es exactamente para lo que se diseñó CLI. El shell lleva haciendo esto de forma fiable durante décadas. Un agente que envuelve find, grep, awk o scripts de Python mediante CLI le proporciona acceso inmediato a un conjunto de herramientas maduro y probado en batalla, sin sobrecarga de esquemas.

• Flujos de Git y gestión de repositorios

  Si su agente se ocupa de crear commits, operar con ramas o preparar merges, GitHub CLI (gh) y git nativo le proporcionan acceso directo al shell para el conjunto completo de comandos con un comportamiento predecible. Un agente que puede ejecutar gh pr create y git log --oneline no necesita una capa MCP para operaciones en un único repositorio.

• Tareas de gestión con CLI de cloud

  AWS CLI, gcloud, kubectl, az: todos ofrecen interfaces de comandos potentes y bien documentadas que los LLM conocen de forma nativa. Un agente que gestiona recursos cloud en un pipeline controlado mediante acceso CLI a estas herramientas es más rápido y barato que enrutar las mismas operaciones a través de un servidor MCP que envuelve las mismas llamadas API.

• Tareas secuenciales de DevOps con resultados claros de aprobado o suspendido

  Pipelines de compilación, scripts de despliegue, comprobaciones de estado, seguimiento de logs: todo esto es nativo de CLI. La ventaja de CLI aquí es que el conjunto de herramientas ya existe, los comandos se conocen bien y la salida (exit codes, stdout, stderr) puede analizarla cualquier agente entrenado en interacción con el shell. CLI es excelente para tareas en las que la pregunta es «¿tuvo éxito o falló?» en lugar de «¿qué datos estructurados debería devolver?».

• Iteración rápida donde la experiencia de desarrollo importa más que la complejidad de autenticación

  CLI le ofrece el camino más rápido desde «necesito que el agente haga X» hasta «el agente está haciendo X». Si está creando prototipos, experimentando o desarrollando herramientas internas para un solo equipo en un servidor controlado, la sobrecarga de una configuración MCP añade fricción sin aportar valor.

Ejemplo concreto: un ingeniero principal en una empresa SaaS mediana necesita un agente que ejecute comprobaciones de calidad de datos cada mañana, capture stdout y publique un resumen en lenguaje sencillo en Slack. Las comprobaciones ya existen como scripts CLI. El agente los llama mediante un nodo de JavaScript, captura la salida, la pasa a un modelo de IA para interpretarla en lenguaje sencillo y publica el resultado. Sin servidor MCP. Sin esquema. Tiempo total de configuración: menos de una hora. En el modelo de facturación por ejecución de Latenode, ese flujo de varios pasos —obtener datos, ejecutar CLI, llamar al modelo de IA y publicar en Slack— cuenta como una ejecución en lugar de cuatro tareas independientes. El agente CLI se encarga del trabajo pesado; el flujo se encarga de la coordinación.

Use MCP cuando el flujo necesite más que acceso al shell

MCP fue diseñado para los casos en los que el modelo de shell de CLI deja de ser suficiente. Son también los casos en los que la sobrecarga de configuración se amortiza.

• Entornos multiinquilino donde los usuarios necesitan acceso limitado a herramientas

  MCP gana cuando su agente necesita actuar en nombre de distintos usuarios con diferentes límites de permisos. CLI hereda las credenciales del shell: todos obtienen el mismo acceso. MCP resuelve de forma nativa el problema de la delegación, con autenticación centralizada que puede limitar los permisos por herramienta y por usuario.

• Flujos entre servicios con requisitos de metadatos estructurados

  Cuando el agente necesita coordinar acciones entre Jira, servicios compatibles con MCP de Atlassian, un CRM y una base de datos, y el procesamiento posterior depende de respuestas JSON estructuradas de cada uno, MCP destaca. La salida CLI de formato libre requiere lógica de análisis que falla cada vez que cambia el formato de salida. Las respuestas estructuradas de MCP son contractualmente estables.

• Descubrimiento de herramientas organizacional entre equipos

  Si necesita que un agente descubra e invoque herramientas que no estaba programado previamente para conocer —porque distintos equipos poseen distintos servicios y quiere una interfaz unificada—, MCP fue diseñado exactamente para ello. Una puerta de enlace MCP compartida permite que los agentes encuentren y usen herramientas publicadas por otros equipos sin programar de forma rígida cada integración.

• GitHub MCP, Jira MCP e integraciones similares de primera parte donde importan los metadatos enriquecidos

  El servidor GitHub MCP ofrece a los agentes acceso a listas de issues, pull requests y operaciones de ramas con autenticación basada en OAuth y respuestas API estructuradas. Para flujos donde el agente necesita correlacionar datos de PR con el contexto de revisión de código y el estado posterior de CI, el formato de respuesta estructurada justifica la complejidad adicional frente a GitHub CLI sin procesar. Use MCP cuando la forma de los datos importe tanto como la acción.

• Situaciones en las que necesita un comportamiento consistente de las herramientas entre varios clientes o bases de código

  Si varios agentes en distintos contextos deben llamar al mismo servicio de la misma manera, el contrato basado en esquemas de MCP impone esa consistencia. CLI deja la consistencia en manos de las convenciones. Las convenciones se degradan. Es más difícil romper esquemas accidentalmente.

Cómo usan los agentes CLI y MCP juntos sin romper ninguno de los dos

El enfoque que hace más clara esta decisión consiste en tratar CLI y MCP como una cartera, no como una elección binaria. El ecosistema de agentes de IA avanza hacia arquitecturas donde ambos conviven en el mismo flujo, no porque los equipos no pudieran decidir, sino porque los dos protocolos resuelven problemas realmente distintos en ámbitos diferentes.

Los profesionales que han trabajado con esto durante suficiente tiempo dejan de discutir sobre cuál es mejor. Empiezan a preguntar «¿qué tipo de tarea es esta?» y enrutan en consecuencia. Conectar sistemas de IA con herramientas no exige un único estándar. Exige el estándar adecuado para el tipo de interacción adecuado.

CLI para el bucle interno, MCP para el bucle externo

El bucle interno es donde el agente realiza su trabajo de iteración ajustada: ediciones de archivos, comandos de shell, manipulación de estado local e intercambios rápidos con el entorno local. Las llamadas CLI dominan aquí. Son rápidas, baratas en tokens y el modelo ya conoce el vocabulario de comandos. Las tareas completadas con CLI en el bucle interno rara vez requieren autenticación estructurada: el agente trabaja dentro de un contexto de permisos ya establecido.

El bucle externo es donde el agente MCP se comunica con el exterior: se autentica frente a servicios externos, llama a API con permisos limitados y devuelve datos estructurados a procesos posteriores. Los agentes en segundo plano que orquestan servicios, gestionan permisos de varios usuarios o necesitan mantener interfaces de herramientas consistentes en toda una organización pertenecen aquí. El uso de CLI a esta escala alcanza rápidamente el límite de permisos del shell: no puede delegar credenciales limitadas mediante un comando de shell de la misma forma en que MCP lo gestiona de manera nativa.

La combinación es práctica, no teórica. Un agente que compila y prueba código utiliza CLI internamente. Cuando necesita abrir un PR en nombre de un usuario específico o actualizar Jira con metadatos estructurados, cruza el límite hacia MCP.

Cuándo las API directas son la mejor tercera opción

Esta es la parte que el debate entre MCP y CLI suele omitir: para integraciones estables de nivel de producción donde la fiabilidad y la latencia son las principales preocupaciones, ni MCP ni CLI son la respuesta correcta. Lo son las llamadas API HTTP directas mediante un SDK del lenguaje.

Añadir una interfaz mediada por un agente, ya sea CLI o MCP, a un controlador de webhooks de Stripe estable, una sincronización de Salesforce bien probada o un flujo de procesamiento de pagos en producción introduce una fragilidad innecesaria. Los agentes aún necesitan rutas de anulación y vías de escape hacia API directas para cualquier caso en el que las consecuencias de un error de análisis o una llamada a herramienta omitida sean relevantes. El ecosistema MCP ha madurado, pero que haya madurado no significa que deba estar en todas partes.

Si la verdadera pregunta es «¿cómo hago que esta integración sea fiable?», la respuesta a menudo no es ni MCP ni CLI.

🤔 Piénselo:
La mayoría de las conversaciones sobre «MCP vs CLI» en realidad plantean la pregunta equivocada. La pregunta subyacente es: ¿este flujo necesita siquiera una interfaz mediada por un agente? Para integraciones SaaS de nivel de producción donde la fiabilidad importa más que la flexibilidad, las API HTTP directas y los SDK de lenguaje son una elección más defendible. Construya la capa de agente sobre una integración estable, no en lugar de ella.

Cómo decidir entre MCP o CLI para la implementación específica de su agente

Antes de comprometerse con una arquitectura, realice estas comprobaciones. Están ordenadas según la frecuencia con la que realmente son el factor decisivo.

La decisión sobre herramientas de IA también depende de la capacidad de mantenimiento. Las mejores interfaces CLI se degradan de forma controlada cuando cambian los formatos de salida de los comandos, siempre que se actualice la lógica de análisis. Las mejores implementaciones de especificaciones MCP imponen contratos de esquema que detectan la deriva antes de que llegue al agente. Ninguna se mantiene por sí sola. Elija la que su equipo realmente pueda mantener actualizada.

Si desarrolla en Latenode, el nodo de JavaScript permite a los agentes llamar a herramientas CLI directamente en el lienzo, mientras que MCP Server Builder se encarga de los casos en los que necesita exponer capacidades a Claude Desktop o Cursor con autenticación estructurada. Esa combinación cubre tanto los flujos basados en CLI como los mediados por MCP desde un único entorno, algo importante cuando la arquitectura evoluciona. Permita que los agentes usen ambas vías sin reconstruir desde cero cuando cambie el alcance. El modelo de facturación por ejecución también ayuda: un flujo que abarca ejecución CLI, interpretación de IA y llamadas externas controladas por MCP cuenta como una ejecución, no como cinco interfaces CLI independientes.

Las preguntas que merece la pena hacer antes de elegir un enfoque MCP

Antes de elegir MCP de forma predeterminada, responda honestamente a estas preguntas:

• ¿Realmente necesita descubrimiento de herramientas entre servicios o sabe exactamente qué herramientas llamará el agente?
• ¿Necesita autenticación delegada y limitada para varios usuarios o un único conjunto de credenciales cubre su flujo?
• ¿Su equipo tiene capacidad para mantener un registro de esquemas a medida que evolucionan las herramientas o MCP para todo se convertirá en una acumulación de mantenimiento?
• ¿Ya hay un cliente MCP en su stack que convierta un buen MCP en una opción natural, o está introduciendo simultáneamente el cliente y el servidor como infraestructura nueva?
• ¿CLI para todo podría llevarle al mismo resultado con una ruta de mantenimiento más sencilla, al menos durante los primeros seis meses?
• ¿Está recurriendo a MCP porque realmente resuelve un problema que tiene o porque parece más robusto? Que sea compatible con MCP no significa que necesite MCP.

Si no puede responder afirmativamente a las dos primeras preguntas, empiece con CLI. Puede añadir MCP más adelante cuando el problema de coordinación sea real. Es mucho más difícil deshacer una arquitectura MCP cuando descubre que se añadió antes de que existiera el caso de uso.