MCP vs CLI: qué debe utilizar un agente para actuar

Cuando un agente deja de responder y empieza a actuar en tu producto, la pregunta deja de ser "¿usamos MCP?" y pasa a ser qué superficie va a tocar el sistema. Puede ser un comando acotado en un entorno controlado, o un catálogo de acciones que el programa descubre y llama con un contrato. Las APIs siguen existiendo debajo. Casi siempre son lo que el comando envuelve o lo que el servidor MCP publica. Aquí comparamos esas dos formas de llamar, no una diapositiva con tres siglas.

En las demos todo parece una API: el modelo llama a una dirección, devuelve datos y el comité aplaude. En un entorno de verdad, meter el esquema entero en cada turno sale caro, mete ruido en lo que el modelo lee y hace difícil auditar qué verbo se ejecutó. Eso empuja a otras formas de exponer la misma acción. Un comando bien diseñado comprime la acción en pocas palabras y devuelve una salida con forma fija. MCP pone un contrato común para que un cliente de agente descubra esas acciones sin que cada integración sea un proyecto a medida. Las dos cosas conviven. El error es elegir por moda en lugar de por contrato, permisos y dónde corre el código.

Este artículo no repite el mapa de capas ni sustituye identidad y permisos. Da por hecho que una acción necesita nombre, datos estrechos y un tope. Aquí enseñamos a leer dos envoltorios distintos para esa misma acción.

La pregunta no es el protocolo, es la superficie

Durante años la integración era "documenta tu API y el agente improvisará". Funciona en una prueba con tres direcciones. Con veinte recursos, versiones y varias cuentas de cliente, el modelo empieza a elegir mal el verbo, a rellenar campos que no tocaban y a gastar contexto en un esquema que nadie leyó entero. No es que la API sea mala. Es que el agente no necesita ver el mapa completo para hacer una acción concreta.

La superficie es la forma en que el programa invoca esa acción. Puede ser una llamada estrecha, un comando con opciones o un servidor que publica un catálogo. Debajo, en los tres casos, suele haber la misma API de producto. La decisión no es "¿tiramos la API?". Es "¿cómo la envolvemos para que un agente la use sin quemar contexto ni perder la auditoría?".

Anthropic insiste en tratar la puerta entre el agente y la herramienta con el mismo rigor que una pantalla para una persona: nombres claros, datos que no den pie a errores y una salida predecible. En muchos equipos ese rigor se materializa como comandos pequeños, no como volcados de esquema en cada turno. En otros, como un protocolo común para que Cursor, Claude Desktop y vuestro propio programa lean el mismo catálogo sin reescribir conectores. Por eso el artículo se queda en MCP frente a la línea de comandos.

Qué es un comando cuando quien actúa es un agente

CLI quiere decir interfaz de línea de comandos. No es nostalgia de terminal. Para un agente es un contrato comprimido: una línea que dice qué puede pasar, sobre qué recurso y con qué forma de respuesta.

Imagina soporte con un copiloto que busca tickets. En lugar de darle cien rutas, registras un comando de una lista cerrada:

support search --tenant acme --q "factura duplicada" --limit 5 --format json

Esa línea fija la cuenta del cliente, acota la búsqueda, limita filas y obliga a devolver datos con forma fija. El agente no navega un menú de direcciones. Ejecuta un verbo que tú definiste. Si el comando siempre devuelve la misma forma, el modelo no interpreta HTML ni páginas de error genéricas, y después puedes reconstruir la ejecución leyendo el comando, los datos y el código de salida.

El comando gana cuando la acción es acotada, repetible y debe costar pocas palabras por llamada. Encaja bien con procesos, opciones y topes (--dry-run, --max-rows) dentro de un recinto: sin red libre, con un tiempo máximo y con una lista cerrada de programas. Es el patrón de "intérprete de código" hecho bien, porque no es el modelo ejecutando lo que quiera, sino un programa que solo puede invocar comandos que registraste. También encaja con operaciones que ya teníais como scripts (migraciones, exportaciones, informes pesados): el agente dispara el script y el script llama a vuestra API con credenciales de servicio, no al revés.

El riesgo está en el otro lado. Un comando sin recinto es una consola con credenciales. Si el agente puede ejecutar rm, leer /etc o llamar a curl a cualquier sitio, no tienes una integración. Tienes un agente con más poder del que la tarea necesita, que es uno de los riesgos que nombra el artículo del OWASP. El comando enseña bien cuando el recinto existe antes que el comando.

Qué es MCP y qué problema resuelve

MCP (Model Context Protocol) es el contrato entre un cliente de agente y un servidor de acciones. El servidor publica qué acciones existen, con una descripción y la forma de los datos de entrada. El cliente las lista sin que reescribas el conector para cada editor o cada programa. La especificación de MCP no sustituye tu API de producto. Es el enchufe pensado para agentes cuando ese catálogo tiene que poder usarse desde muchos clientes.

Piensa en un SaaS que vende "conecta tus sistemas a agentes". Cada semana aparece un CRM, un drive o un sistema de tickets nuevo. Sin un contrato común, cada programa (el editor de quien desarrolla, el copiloto embebido, el programa con el que evaluáis) pide su propio conector. MCP reduce esa fricción: un servidor por sistema externo, y muchos clientes de agente leyendo el mismo catálogo. Devic usa MCP como capa de integración por ese motivo. El caso de uso y las acciones de vuestro negocio siguen siendo vuestras.

MCP gana cuando necesitas descubrir acciones sobre la marcha y un contrato estándar entre muchos clientes y muchos servidores, no cuando necesitas un único verbo de producto. Si el catálogo cambia (un conector nuevo, una versión nueva), el cliente puede listar de nuevo sin volver a desplegar las instrucciones enteras. Si el agente corre en el portátil de la persona, puede hablar con un MCP en vuestra infraestructura sin que le paséis la clave de esa cuenta dentro de las instrucciones. El servidor aplica permisos de su lado y el cliente solo ve las acciones permitidas.

MCP no gana cuando la acción crítica de tu SaaS ya es una dirección estable y queréis que los mismos datos produzcan siempre el mismo efecto, sin una capa de por medio. Ahí suele bastar una llamada HTTP estrecha o un comando interno. MCP tampoco arregla acciones mal definidas. Si la forma de los datos es vaga, solo habéis estandarizado la confusión.

Cómo leer la elección sin dogma

No hay un ganador universal. Hay combinaciones que se ven en producción cuando el equipo puede nombrar tres cosas: qué acción hace el agente, dónde corre el código y quién audita el efecto.

Figura. Dos ejes, cuatro casillas

La primera tabla responde "¿qué situación es la nuestra?". La segunda añade dónde corre el programa, porque el mismo verbo de producto puede ir por el servidor (permisos centralizados) o por un recinto (ejecución acotada, con una salida que se puede medir). Si una casilla os suena rara, suele ser señal de que falta una pieza del mapa (el recinto, la identidad del agente o un dueño del contrato), no de que "falte más protocolo".

Tres preguntas antes de comprometeros con una superficie:

1. ¿La acción ya existe como verbo estable en el producto? Si sí, envolvedla. No hace falta un catálogo portable para un solo flujo.

2. ¿Cuántos clientes de agente van a consumir la misma integración? Uno: un comando o una llamada HTTP suele bastar. Varios programas distintos: MCP empieza a pagarse.

3. ¿Dónde viven las credenciales? Si el agente corre en el portátil de la persona, las credenciales no van en las instrucciones. Van en un servidor MCP o en un recinto que llama a vuestra API con identidad propia.

Meter cuarenta acciones MCP con una descripción larga en cada turno tiene precio en contexto. Un comando con subcomandos documentados en las instrucciones de ese flujo, o descubiertos en un solo help, suele ser más barato cuando el caso de uso es uno. Eso no es estar en contra de MCP. Es no pagar el descubrimiento dinámico donde no lo necesitas.

Un SaaS maduro no elige uno: reparte responsabilidades

Lo habitual en un SaaS maduro no es "solo MCP" ni "solo comandos". Es una pila con responsabilidades claras, porque distintas acciones tienen distinto riesgo y distinto coste de contexto.

Vuestra API sigue siendo la fuente de verdad para los efectos en el producto. Sobre ella montáis verbos estrechos: direcciones o comandos que un agente puede llamar sin inventar consultas ni rutas. Las integraciones de terceros van como servidores MCP (o conectores equivalentes) con las credenciales en el servidor, no en las instrucciones. Si el agente necesita ejecutar lógica pesada o transformar datos, eso ocurre en un recinto con comandos registrados. El modelo no escribe código libre hacia producción.

Un ejemplo sin nombres de cliente: soporte quiere que el copiloto busque artículos, proponga una respuesta y, solo tras una aprobación, actualice el ticket. La búsqueda puede ser un MCP a la base de conocimiento o un comando kb search en un recinto, porque leer no tiene el mismo riesgo que escribir. La escritura en el ticket es una llamada HTTP con permiso tickets:write y confirmación de una persona, porque el efecto en el producto tiene que quedar acotado por identidad y por cuenta. El mismo agente usa dos superficies no por indecisión, sino porque dos tareas piden controles distintos.

Antes de añadir un tercer protocolo, preguntad si la acción ya existe como verbo estable. Si es un catálogo externo, MCP. Si es una ejecución acotada con una salida que se puede medir, un comando en un recinto. Si es un efecto crítico en vuestro dominio y ya está resuelto que la misma petición no se ejecute dos veces, una llamada HTTP estrecha sobre vuestra API sigue teniendo sentido.

Permisos y auditoría: el protocolo no cambia las reglas

MCP y la línea de comandos cambian la forma de llamar. No cambian las reglas de quién puede hacer qué. Si el agente actúa sobre datos de cliente, se trata como un servicio con identidad propia, permisos concretos y la puerta cerrada por defecto, igual que si llamara vuestra API a mano.

Con un comando, el registro debe anotar el comando, los datos (sin secretos), la identidad del agente, la cuenta y el código de salida. Con MCP, el nombre de la acción, los datos validados, el servidor que respondió y el enlace con el identificador de la tarea. En los dos casos hace falta el mismo mínimo que en trazabilidad: poder reconstruir la cadena sin abrir el chat.

Un servidor MCP con permisos amplios es una clave de API disfrazada. Un comando en el portátil de la persona, con la sesión de quien administra, es hacerse pasar por ella. El protocolo no arregla eso. Lo arregla la identidad propia del agente, la lista cerrada y poder quitarle el acceso sin echar a la persona.

Lo que ninguna interfaz arregla sola

Si solo tenéis tres acciones internas y un solo cliente de agente, un servidor MCP puede ser capa de más. Empezad con llamadas HTTP o comandos documentados en el flujo. MCP, cuando el catálogo o los clientes justifiquen el estándar. Un comando sin recinto no escala a un producto con muchas cuentas de cliente. Es aceptable en un ensayo local, no en un copiloto que toca datos de cliente.

Ninguno sustituye el contrato de vuestro negocio. "Buscar tickets de la cuenta actual, máximo 5, sin el HTML crudo" vale igual envuelto en MCP, en un comando o en una llamada. Si el contrato es vago, el protocolo solo ordena el caos. MCP y la línea de comandos son envoltorios para agentes, no un reemplazo del diseño de producto.

Si el equipo puede responder qué superficie usa cada acción de la prueba, con qué identidad y qué queda en el registro, la elección deja de ser teológica. Si no puede, el problema no es el protocolo. Es que todavía estáis en la demo. Ese salto lo contamos en una demo no es un agente en producción.