Agentes de IA: cuándo usar MCP y cuándo una CLI

Agentes de IA: ¿cuándo conviene MCP y cuándo una CLI?

Para desarrollar dentro de un repositorio, lo mejor es empezar por la CLI. Una interfaz de línea de comandos es un programa que se maneja mediante comandos. Si el agente ya dispone de un ejecutor de comandos autorizado y la herramienta permite completar la tarea, añadir otra integración puede aumentar el mantenimiento sin mejorar el resultado.

Para un asistente alojado que atiende a distintos usuarios, es preferible un servicio MCP con permisos limitados a una shell compartida con privilegios elevados. Model Context Protocol es un estándar que permite a una aplicación de IA descubrir y utilizar herramientas. Un servidor remoto puede aceptar la autorización de cada usuario y ofrecer las operaciones que necesita el asistente. Aun así, hay que hacer cumplir esos permisos.

En un equipo de ingeniería, tiene sentido usar ambos si cumplen funciones distintas. El trabajo con el repositorio puede quedarse en el ejecutor de comandos. Las operaciones de negocio compartidas deben pasar por un servicio que compruebe la identidad y los permisos de quien llama.

Lo decisivo es el acceso al entorno de ejecución, la titularidad de las credenciales, las operaciones disponibles y la cantidad de información que recibe el modelo. El nombre del protocolo viene después.

La documentación de los fabricantes utilizada en esta comparación se verificó el 11 de noviembre de 2026. Se presentan flujos de trabajo documentados y valoraciones de arquitectura, no un benchmark ni resultados de pruebas prácticas propias.

CLI y MCP: ¿cómo llegan las operaciones al modelo?

MCP proporciona al agente la descripción de una herramienta; una CLI le proporciona un comando que ejecutar. Ninguno permite que el modelo realice una operación por sí solo. La aplicación que lo rodea recibe la llamada propuesta, aplica sus controles, la ejecuta y devuelve el resultado.

Con MCP, el cliente consulta al servidor qué herramientas están disponibles. Cada herramienta indica su nombre, su propósito y su esquema de entrada: los campos que admite. La aplicación puede mostrar esas definiciones al modelo, que elige una herramienta y aporta argumentos estructurados. La especificación de herramientas de MCP define el descubrimiento y la invocación, pero deja en manos de la aplicación la forma de interactuar con el usuario.

Con una CLI, el agente utiliza una herramienta de ejecución de comandos para iniciar un programa instalado. Puede que ya conozca un comando habitual, pero puede consultar --help para comprobar la sintaxis de la herramienta instalada. La respuesta puede ser texto, JSON estructurado o la ruta de un archivo. «Salida de CLI» no significa «texto sin estructura».

Por ejemplo, «lista mis pull requests abiertos» puede convertirse en una llamada a una herramienta de GitHub con argumentos o en un comando gh pr list. La cuenta utilizada sigue necesitando permiso para leer esos pull requests. Cambiar de interfaz no concede acceso.

Para conocer el papel más amplio del protocolo, consulta qué es MCP.

Coste de contexto: la CLI gana en el caso local sencillo

Una CLI puede evitar que los detalles irrelevantes de las herramientas lleguen al contexto del modelo, pero no elimina el consumo de contexto. El contexto es la información que recibe el modelo para decidir qué hacer a continuación. Las descripciones de las herramientas y sus esquemas de parámetros ocupan tokens cuando la aplicación anfitriona los incluye, igual que el texto de ayuda y la salida de los comandos.

Por eso, un servidor MCP con un catálogo amplio de herramientas puede consumir bastante contexto antes de empezar el trabajo útil. La precisión clave es cuándo incluye la aplicación ese catálogo. No hay que dar por hecho que todas las aplicaciones cargan todas las definiciones disponibles en cada solicitud al modelo. Seleccionar menos herramientas o descubrirlas bajo demanda cambia la comparación.

La vía CLI puede empezar con la definición del ejecutor de comandos y cargar la ayuda de cada herramienta solo cuando haga falta. También permite filtrar los datos antes de devolverlos al modelo. Pedir únicamente los títulos y las URL de los pull requests es mejor que devolver registros completos y esperar que el modelo ignore casi todo.

Pero una CLI que imprime un registro enorme, o una skill que carga un manual extenso, puede anular esa ventaja. Del mismo modo, una herramienta MCP que devuelve una respuesta concisa puede ser más eficiente que explorar repetidamente desde la shell. Hay que medir la tarea completa: definiciones, ayuda, salidas, reintentos y si el resultado fue correcto. Que el comando sea corto demuestra poco por sí solo.

Ganador de esta categoría: CLI para tareas locales habituales con salida selectiva. MCP sigue siendo competitivo cuando el conjunto de herramientas y sus resultados son pequeños. Aquí no hay fundamento para afirmar un multiplicador universal de tokens.

Autenticación y permisos: MCP gana si el servicio hace cumplir los límites

La autorización por usuario importa más que el hecho de que el agente envíe JSON o una cadena de comandos. OAuth es un flujo de acceso delegado: un usuario autoriza a un cliente sin entregarle su contraseña. Una implementación remota de MCP puede utilizar esa identidad para decidir a qué cuenta, registros y acciones puede acceder el cliente.

Pensemos en un asistente de soporte que atiende a distintas organizaciones. Debería recuperar los registros del cliente que ha iniciado sesión sin recibir las credenciales de un ingeniero con acceso a todas las cuentas. Entre un servicio MCP remoto con permisos correctamente acotados y una shell compartida de administrador, conviene elegir el servicio. Es ahí donde MCP puede ser la única opción aceptable entre esas dos implementaciones.

No es la única arquitectura segura posible. Una integración directa con una API puede imponer el mismo límite. Tampoco basta con añadir MCP para crearlo: la especificación de autorización de MCP establece que la autorización es opcional, define el flujo de autorización HTTP y distingue los servidores locales STDIO que obtienen credenciales de su entorno.

Una CLI también puede utilizar el inicio de sesión en el navegador y credenciales con permisos limitados. El riesgo depende de aquello a lo que puede acceder su proceso: credenciales, archivos, destinos de red y otros ejecutables. Un ejecutor de comandos aislado en un sandbox, con credenciales de alcance reducido, plantea una situación distinta al acceso sin restricciones al equipo de un desarrollador.

Ganador de esta categoría: MCP remoto con permisos limitados para el acceso delegado de distintos usuarios. En cualquiera de las dos vías, hay que aplicar en código la autorización sobre cuentas y objetos, evitar que las credenciales aparezcan en las salidas visibles para el modelo y registrar qué usuario autorizó cada acción.

GitHub CLI o GitHub MCP: ¿trabajo en el repositorio o acceso a un servicio compartido?

GitHub CLI, el cliente de línea de comandos gh, es la opción directa para un agente de programación que ya trabaja en una copia local del repositorio. Supongamos que se necesita un resumen de los pull requests abiertos propios. Dentro del repositorio, una vez autenticado, este comando utiliza opciones documentadas:

gh pr list --author "@me" --json number,title,url

El comando solicita solo los campos necesarios para el resumen. La CLI también admite --jq para filtrar el JSON antes de que llegue al modelo. Es una técnica concreta para ahorrar contexto, sin atribuirle resultados de un benchmark de tokens.

Los límites de la CLI dependen del ejecutor que la rodea. Que un comando funcione en un portátil no lo convierte automáticamente en una interfaz adecuada para todos los empleados o clientes. Según el manual de inicio de sesión de GitHub CLI, el acceso desde el navegador normalmente guarda un token en el almacén de credenciales del sistema; si este no está disponible, recurre al almacenamiento en texto plano. Conviene revisar cómo se gestionan realmente las credenciales, en lugar de suponer que «local» significa «aislado».

GitHub MCP Server, el servidor oficial de herramientas de GitHub, encaja en un asistente que necesita realizar operaciones sobre repositorios mediante MCP. Para obtener el mismo resumen, se habilitan las herramientas de pull requests pertinentes, se utiliza la autorización del usuario correspondiente y se solicitan sus pull requests abiertos. GitHub aloja un servidor remoto y también ofrece una opción local.

GitHub documenta conjuntos de herramientas y la selección individual de estas, además de un modo de solo lectura que omite las herramientas de escritura. La compatibilidad con OAuth en su servidor remoto también depende de que la aplicación anfitriona configure la aplicación de GitHub u OAuth adecuada; un transporte compatible no resuelve por sí solo la autenticación.

Veredicto de la comparación: usar gh para el resumen del desarrollador y los scripts del repositorio. Preferir MCP para un asistente compartido cuyo cliente admita el flujo de autenticación necesario. Ninguna opción sustituye los permisos del repositorio, y seleccionar menos herramientas MCP puede mejorar tanto la claridad como el uso del contexto.

Playwright CLI o MCP: ¿programación o exploración del navegador?

Playwright CLI, la interfaz de comandos de Microsoft para acciones en el navegador, es la opción inicial para un agente de programación que comprueba un cambio web. Sus creadores recomiendan CLI junto con skills para estos agentes porque los comandos pueden evitar que se carguen esquemas extensos y datos de páginas en el contexto. Es una recomendación de diseño de sus autores, no una afirmación de velocidad medida en este artículo.

Para comprobar un formulario, el flujo consiste en abrir la página, inspeccionar los elementos pertinentes, interactuar y revisar el resultado. El agente no necesita leer todos los detalles de la página después de cada acción.

Instalación de playwright-cli: empezar por los comandos del fabricante

La instalación documentada y la inspección de una página en modo de solo lectura son:

npm install -g @playwright/cli@latest
playwright-cli --help
playwright-cli open https://playwright.dev
playwright-cli snapshot
playwright-cli close

Estos comandos inspeccionan una página pública; no constituyen una batería de pruebas. La instantánea obtenida sirve para identificar los elementos antes de añadir interacciones con la aplicación propia.

Skill de Playwright CLI: añadir las instrucciones del flujo de trabajo

Una vez instalada la CLI, el comando documentado para sus skills es:

playwright-cli install --skills

La limitación importante está en lo que hay que aportar a su alrededor: un entorno de ejecución, una sesión de navegador adecuada e instrucciones que definan cuándo se ha completado la tarea. Una skill ayuda con el procedimiento; no puede decidir si una transacción real de un cliente está autorizada.

Playwright MCP, el servidor de herramientas de navegador de Microsoft, encaja mejor cuando el cliente MCP se beneficia de una inspección estructurada de la página durante un ciclo de exploración. Utiliza instantáneas de accesibilidad, descripciones estructuradas de los elementos de la página, para facilitar la interacción con el navegador.

Hay dos límites importantes. Primero, la persistencia del estado del navegador no es exclusiva de MCP: Playwright CLI conserva las cookies y el almacenamiento entre llamadas dentro de una sesión y ofrece perfiles persistentes entre reinicios del navegador. Segundo, el repositorio de MCP indica expresamente que el servidor no constituye un límite de seguridad. Sus controles de origen también advierten que no proporcionan ese límite ni afectan a las redirecciones.

Veredicto de la comparación: CLI junto con skills para las comprobaciones habituales dentro del flujo de programación; MCP para un cliente y una tarea que aprovechen su forma de interactuar con las herramientas del navegador. No conviene cambiar solo para obtener persistencia de sesión. La guía de configuración de Playwright MCP y pruebas de navegador explica esa vía con más detalle.

Stripe CLI o Stripe MCP: ¿desarrollo de webhooks u operaciones de la cuenta?

Stripe CLI, la herramienta de terminal de Stripe, gana al desarrollar y depurar una integración de pagos. Una tarea habitual es recibir en una aplicación local eventos webhook, las notificaciones que Stripe envía cuando ocurre algo. La CLI documenta stripe listen para recibir y reenviar esos eventos, y stripe trigger para generar eventos de ejemplo.

Este flujo debe mantenerse en un sandbox. Disparar eventos crea objetos de la API y puede generar eventos adicionales; no se limita a imprimir un payload de ejemplo. La CLI también permite realizar operaciones de API e inspeccionar registros de solicitudes, por lo que su utilidad va más allá del reenvío de webhooks.

La diferencia de autenticación tiene más matices que «CLI significa copiar una clave de API». Stripe documenta el inicio de sesión por usuario en el navegador, el almacenamiento local seguro de credenciales cuando está disponible, la renovación de sesiones y la revocación. Para desarrolladores, puede ser una solución adecuada. Para un asistente alojado, elegir la vía CLI sigue exigiendo una forma de aislar el entorno de ejecución y las credenciales de cada usuario.

Stripe MCP, la interfaz de servicios de Stripe para agentes, gana para operar sobre cuentas desde un asistente compatible sin ejecutor de comandos local. Por ejemplo, un operador autorizado puede pedir al asistente que busque y lea los datos pertinentes de la API de Stripe. El servidor proporciona herramientas de búsqueda en la API, descubrimiento de parámetros, lectura y escritura, en lugar de exigir una definición de herramienta distinta para cada operación.

Stripe admite OAuth para acceder en nombre de un usuario y claves de API de agente para el acceso independiente. Su herramienta general stripe_api_write puede abarcar muchas operaciones. Los requisitos de confirmación humana de Stripe dependen de la acción y son independientes de la configuración de aprobación de herramientas del cliente. Aprobar una categoría de herramientas, por tanto, no equivale a aprobar todas las acciones de negocio que puede realizar.

Veredicto de la comparación: CLI para desarrollar webhooks localmente; MCP para el trabajo delegado sobre cuentas desde un asistente. Hay que comparar la operación necesaria, no la cantidad de comandos o herramientas. Una conexión MCP que lee datos de la cuenta no sustituye al receptor local de webhooks del flujo de desarrollo.

MCP y skills: las instrucciones pertenecen a otra capa

Una skill indica al agente cómo trabajar; MCP y CLI le ofrecen formas de actuar. En el formato Agent Skills, un archivo SKILL.md incluye un nombre, una descripción e instrucciones de la tarea, con scripts y archivos de referencia opcionales. Los agentes descubren primero los metadatos y cargan las instrucciones completas cuando las necesitan.

Al comparar «MCP vs CLI vs skills», una combinación útil suele ser CLI más una skill. La CLI realiza la operación; la skill indica qué comandos utilizar, qué entorno elegir, qué evidencias revisar y cuándo detenerse. Una skill también puede orientar a un agente que utilice herramientas MCP.

Para un resumen de pull requests, la skill podría exigir que solo se incluyan las solicitudes abiertas, que se seleccionen campos concisos y que no se publiquen comentarios durante la elaboración del informe. Las credenciales y el entorno de ejecución deben hacer cumplir el límite real de acceso. Las instrucciones escritas ayudan al agente a actuar correctamente, pero no eliminan permisos.

Ganador de esta categoría: las skills para procedimientos repetibles. Complementan cualquiera de las dos interfaces y añaden su propio contexto al cargarse.

MCP vs API vs CLI: mantener unificada la lógica del servicio

Las reglas de negocio deben permanecer en el servicio; después se ofrecen las interfaces que necesitan los usuarios. Una API es la interfaz programática de una aplicación. Una CLI puede llamarla, y un servidor MCP también, como demuestran las interfaces de Stripe.

Si se mantienen ambas, conviene reutilizar la autorización y la validación en vez de crear implementaciones que compitan por decidir «quién puede modificar este registro». La comparación entre MCP y API explica cuándo merece la pena añadir la capa del protocolo.

Un envoltorio que acepta texto de shell arbitrario es una razón débil para migrar. Puede hacer accesible un ejecutor de comandos existente mediante MCP, pero conserva los permisos de ese ejecutor. Un adaptador útil ofrece una operación acotada, valida sus entradas y devuelve solo las evidencias que necesita el agente.

Tabla de decisión: elegir según el despliegue

Conviene elegir la interfaz más sencilla que cubra la tarea sin ampliar los permisos. Estas son configuraciones de partida, no compromisos permanentes.

Cómo pasar de MCP a CLI, o a la inversa

Conviene migrar un flujo de trabajo, no todo el catálogo de herramientas. Lo costoso suele ser conservar los permisos, las salidas y la gestión de fallos, más que convertir el nombre de una herramienta en un comando.

Pasar a CLI exige organizar la instalación, las credenciales, el ejecutor de comandos, el filtrado de las salidas y las instrucciones reproducibles. Pasar a MCP exige elegir o gestionar un servidor, configurar la autenticación del cliente, definir las herramientas disponibles y gestionar los errores mediante esa interfaz. Los flujos con navegador también requieren decidir expresamente a quién pertenecen las sesiones y los perfiles.

No conviene cambiar un flujo CLI que funciona solo para añadir compatibilidad con un protocolo. Tampoco conviene eliminar una integración MCP remota que atiende a personas sin shell solo porque un comando parezca más corto.

Encuentra más guías prácticas para elegir y delimitar flujos de trabajo con agentes en el boletín.

Preguntas frecuentes