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: un comando acotado en un entorno controlado, o un catálogo de herramientas que el runtime descubre y llama por contrato. Las APIs siguen existiendo debajo; casi siempre son lo que el CLI envuelve o lo que el servidor MCP expone. Lo que comparamos aquí es MCP frente a CLI, no una slide con tres acrónimos.

En las demos todo parece API: el modelo llama un endpoint, devuelve JSON y el comité aplaude. En producción el coste de meter el esquema entero en cada turno, el ruido que mete en contexto y la dificultad de auditar "qué verbo ejecutó" empujan hacia otras formas de exponer la misma acción. Un CLI bien diseñado comprime la acción en pocos tokens y devuelve salida estructurada. MCP estandariza cómo un cliente de agente descubre 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. Asume que ya sabes que una tool necesita nombre, argumentos estrechos y límite. Aquí enseñamos a leer dos envoltorios distintos para esa misma tool.

La pregunta no es el protocolo, es la superficie

Durante años la integración era "documenta tu REST y el agente improvisará". Funciona en un piloto con tres endpoints. Con veinte recursos, versiones y tenants (la cuenta de un cliente en tu SaaS), el modelo empieza a elegir mal el verbo, a rellenar campos que no tocaban y a gastar contexto en OpenAPI que nadie leyó entero. No es que la API sea mala: es que el agente no necesita ver tu mapa completo para hacer una acción concreta.

La superficie es la forma en que el runtime invoca esa acción. Puede ser un POST estrecho, un binario con flags o un servidor que publica un catálogo de tools. Debajo, en los tres casos, suele haber la misma API de producto. La decisión no es "¿tiramos la API?" sino "¿cómo la envolvemos para que un agente la use sin quemar contexto ni perder auditoría?".

Anthropic insiste en tratar la interfaz agente-herramienta con el mismo rigor que una UI humana: nombres claros, argumentos que no den pie a errores, salida predecible. En muchos equipos ese rigor se materializa como comandos pequeños, no como dumps de esquema en cada turno. En otros, como un protocolo común para que Cursor, Claude Desktop y vuestro harness lean el mismo catálogo sin reescribir conectores. Por eso acotamos el artículo a MCP frente a CLI.

Qué es un CLI cuando el actor es un agente

CLI (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 REST, registras un comando allowlisted:

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

Esa línea fija el tenant, acota la búsqueda, limita filas y obliga a JSON. El agente no navega un menú de endpoints: ejecuta un verbo que tú definiste. Si el comando siempre devuelve el mismo schema, el modelo no interpreta HTML ni páginas de error genéricas, y después puedes reconstruir la ejecución leyendo comando, argumentos y código de salida.

El CLI gana cuando la acción es acotada, repetible y debe costar pocos tokens por llamada. Encaja bien con pipelines, flags y límites (--dry-run, --max-rows) en un sandbox: sin red libre, con timeout y con una allowlist de binarios. Es el patrón "code interpreter" hecho bien, porque no es el modelo ejecutando lo que quiera, sino un runtime que solo puede invocar comandos que registraste. También encaja con operaciones que ya teníais como scripts (migraciones, exports, 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 CLI sin sandbox es un shell con credenciales. Si el agente puede ejecutar rm, leer /etc o llamar a curl arbitrario, no tienes integración: tienes excessive agency con esteroides. El CLI 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 tools. El servidor publica qué herramientas existen, con descripción y schema de entrada; el cliente las lista sin que reescribas el conector para cada IDE o runtime. La especificación de MCP no sustituye tu API de producto: es el enchufe orientado a agentes cuando ese catálogo tiene que ser portable entre muchos clientes.

Piensa en un SaaS que vende "conecta tus sistemas a agentes". Cada semana aparece un CRM, un drive o un ticketing nuevo. Sin un contrato común, cada runtime (el IDE del desarrollador, el copiloto embebido, el harness de evaluación) pide su propio conector. MCP reduce esa fricción: un servidor por sistema externo, muchos clientes agente leyendo el mismo catálogo. Devic usa MCP como capa de integración por ese motivo; el caso de uso y las tools de dominio siguen siendo vuestros.

MCP gana cuando necesitas descubrimiento dinámico y un contrato estándar entre muchos clientes y muchos servidores, no cuando necesitas un único verbo de producto. Si el catálogo cambia (nuevo conector, nueva versión), el cliente puede listar de nuevo sin redeployar el prompt entero. Si el agente corre en el portátil del usuario, puede hablar con un MCP en vuestra infra sin que le paséis la API key del tenant en el prompt: el servidor aplica permisos y scopes del lado servidor y el cliente solo ve tools permitidas.

MCP no gana cuando la acción crítica de tu SaaS ya es un endpoint estable y queréis determinismo absoluto (mismo input, mismo efecto, sin capa intermedia). Ahí suele bastar una tool HTTP estrecha o un CLI interno. MCP tampoco arregla tools mal definidas: si el schema es vago, solo habéis estandarizado la confusión.

Cómo leer la elección sin dogma

No hay 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 cuadrantes

La primera tabla responde "¿qué situación es la nuestra?". La segunda añade dónde corre el runtime, porque el mismo verbo de producto puede ir por servidor (permisos centralizados) o por sandbox (ejecución acotada con salida medible). Si una celda os suena rara, suele ser señal de que falta una pieza del mapa (sandbox, identidad del agente o un dueño del contrato de la tool), 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 producto? Si sí, envolvedla; no hace falta un catálogo portable para un solo flujo. 2. ¿Cuántos clientes agente van a consumir la misma integración? Uno: CLI o HTTP suele bastar. Varios runtimes distintos: MCP empieza a pagarse. 3. ¿Dónde viven las credenciales? Si el agente corre en el portátil del usuario, las credenciales no van en el prompt; van en un servidor MCP o en un sandbox que llama a vuestra API con identidad propia.

Meter cuarenta herramientas MCP con descripción larga en cada turno tiene precio en contexto. Un CLI con subcomandos documentados en el system prompt de ese flujo, o descubiertos en un solo help, suele ser más barato cuando el caso de uso es uno. Eso no es "anti-MCP": es no pagar descubrimiento dinámico donde no lo necesitas.

Un SaaS maduro no elige uno: apila responsabilidades

Lo habitual en un SaaS maduro no es "solo MCP" ni "solo CLI". 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 efectos en el producto. Sobre ella montáis verbs estrechos: endpoints o comandos que un agente puede llamar sin inventar SQL ni rutas. Las integraciones de terceros van como servidores MCP (o conectores equivalentes) con credenciales en servidor, no en el prompt. Si el agente necesita ejecutar lógica pesada o transformar datos, eso ocurre en un sandbox con CLIs registrados; el modelo no escribe Python libre hacia producción.

Un ejemplo sin nombres de cliente: soporte quiere que el copiloto busque artículos, proponga respuesta y, solo tras aprobación, actualice el ticket. La búsqueda puede ser un MCP a la base de conocimiento o un CLI kb search en sandbox, porque leer no tiene el mismo riesgo que escribir. La escritura en el ticket es una tool HTTP con scope tickets:write y confirmación humana, porque el efecto en el producto tiene que quedar acotado por identidad y por tenant. 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 catálogo externo, MCP. Si es ejecución acotada con salida medible, CLI en recinto. Si es efecto crítico en vuestro dominio con idempotencia ya resuelta, una tool HTTP estrecha sobre vuestra API sigue teniendo sentido.

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

MCP y CLI 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, scopes y default-deny, igual que si llamara vuestra API a mano.

Con CLI, el log debe registrar comando, argumentos (sin secretos), identidad del agente, tenant y código de salida. Con MCP, tool name, input validado, servidor que respondió y correlación con un run_id. En ambos casos hace falta el mismo mínimo que en trazabilidad: poder reconstruir la cadena sin abrir el chat.

Un MCP server con scopes amplios es una API key disfrazada. Un CLI en el portátil del usuario con la sesión del admin es impersonación. El protocolo no arregla eso: lo arregla identidad propia del agente, allowlist y revocación sin echar al humano.

Lo que ninguna interfaz arregla sola

Si solo tenéis tres acciones internas y un solo cliente agente, un servidor MCP puede ser capa de más. Empezad con tools HTTP o CLI documentados en el flujo; MCP cuando el catálogo o los clientes justifiquen el estándar. Un CLI sin sandbox no escala a producción multi-tenant: es aceptable en un spike local, no en un copiloto que toca datos de cliente.

Ninguno sustituye el contrato de dominio. "Buscar tickets del tenant actual, máximo 5, sin HTML crudo" vale igual envuelto en MCP, CLI o POST. Si el contrato es vago, el protocolo solo ordena el caos. MCP y CLI son envoltorios para agentes, no reemplazo de diseño de producto.

Si el equipo puede responder qué superficie usa cada acción del piloto, con qué identidad y qué queda en el log, la elección MCP frente a CLI deja de ser teológica. Si no puede, el problema no es el protocolo: es que aún estáis en demo. Ese salto lo contamos en una demo no es un agente en producción.