Durante meses, el ecosistema de agentes para programar ha vivido una especie de fiebre por MCP. El protocolo se presentó como la gran vía estandarizada para conectar modelos con herramientas, datos y sistemas externos. Pero en paralelo, y casi sin hacer tanto ruido, muchos equipos están volviendo a algo mucho más viejo y mucho más simple: la terminal.
Ese giro no es una anécdota. Cada vez más desarrolladores están comprobando que, para gran parte del trabajo diario, un agente con acceso controlado a bash, git, rg, npm, docker, curl o jq resuelve más en menos tiempo que una batería de herramientas MCP cuidadosamente descritas. Y eso está abriendo una discusión que probablemente se repetirá bastante en 2026: MCP frente a CLI.
La clave, sin embargo, es que no se trata exactamente de una guerra de reemplazo. Se parece más a una disputa por el terreno de juego. El CLI está recuperando protagonismo porque los modelos actuales entienden muy bien la lógica de la terminal. Han sido entrenados durante años con comandos, flags, errores, salidas de consola, documentación estilo man page y flujos Unix. Anthropic define Claude Code precisamente como una herramienta agéntica que vive en el terminal, entiende la base de código, ejecuta comandos y ayuda a completar tareas rutinarias. OpenAI, por su parte, sigue actualizando Codex CLI como parte de su familia de herramientas para ingeniería asistida. Google describe Gemini CLI como un agente de terminal basado en un bucle ReAct que trabaja con herramientas integradas y también con servidores MCP locales o remotos.
Ahí está el primer dato importante: el mercado no se está moviendo hacia “solo MCP” ni hacia “solo terminal”. Las tres grandes líneas actuales de producto siguen considerando la terminal como interfaz principal o natural. Eso explica por qué el entusiasmo inicial por MCP ha empezado a encontrar una resistencia práctica. Cuando un agente puede entrar en un proyecto, hacer git pull, lanzar tests, buscar con rg, editar archivos, ejecutar docker compose, revisar logs y abrir una pull request con herramientas estándar, muchos equipos se preguntan si realmente merece la pena encapsular todo eso en herramientas MCP.
Por qué MCP ha empezado a generar dudas
El problema no es que MCP esté mal diseñado. De hecho, el propio protocolo se define como un estándar abierto para conectar aplicaciones de IA con herramientas y fuentes externas de forma estructurada. Su valor es real: ofrece un marco común, contratos definidos y una manera más ordenada de exponer capacidades a los modelos.
La fricción aparece en la práctica cotidiana. Para que un servidor MCP sea útil, hay que definir tools, describir schemas, mantener contratos, pensar permisos y cargar toda esa superficie en el contexto del modelo. Ese trabajo aporta claridad, pero también introduce coste. En muchos casos añade complejidad operativa, más mantenimiento y, sobre todo, más contexto estructural que compite con el espacio disponible para razonar sobre el propio código.
Esa crítica no es teórica. Incluso Gemini CLI, que soporta MCP, explica que opera mediante herramientas del entorno local y servidores MCP cuando hace falta. Es decir, no trata MCP como única vía, sino como una opción más dentro de un sistema que sigue siendo terminal-first. Eso refuerza una lectura cada vez más común en equipos técnicos: si el agente ya entiende bien la shell, envolver operaciones básicas en un servidor MCP puede ser más ceremonia que ventaja.
Donde el CLI gana por velocidad
En tareas de desarrollo cotidiano, la terminal sigue siendo una interfaz brutalmente eficiente. Un agente puede buscar una función vieja en un monorepo con rg, editar los archivos afectados, correr npm test o cargo test, revisar el git diff, rehacer cambios y dejar un commit listo. Todo dentro de un mismo flujo natural, sin tener que traducir cada acción a un contrato de herramienta nuevo.
Lo mismo ocurre con la depuración. Si el objetivo es reproducir un bug en staging, revisar logs, levantar contenedores, probar endpoints con curl y relanzar pruebas, la shell ya contiene casi todo el lenguaje operativo necesario. En esos escenarios, el modelo no necesita una abstracción adicional: necesita acceso seguro al entorno correcto.
Hay también una razón cultural. Los desarrolladores confían en el terminal porque pueden ver qué está pasando. Si el agente ejecuta git status, tail -f, docker logs o npm run dev, el comportamiento es transparente y auditable. Cuando todo se canaliza por tools MCP muy específicas, se gana estructura, sí, pero a veces se pierde parte de esa legibilidad inmediata.
Donde MCP sigue teniendo mucho sentido
Ahora bien, declarar muerto a MCP sería una exageración. El propio hecho de que Gemini CLI lo soporte y de que el estándar siga evolucionando demuestra que el protocolo no ha perdido relevancia. Lo que está ocurriendo es algo más interesante: se está delimitando mejor dónde aporta valor de verdad.
MCP tiene muchísimo sentido cuando el objetivo no es “dejar al agente actuar como un desarrollador”, sino dejarlo actuar dentro de límites muy concretos. Ahí entra la seguridad. Dar acceso directo al terminal a un agente puede ser práctico, pero también es más arriesgado. En cambio, un servidor MCP permite decidir con precisión qué acciones están permitidas, cómo se exponen, qué parámetros aceptan y qué sistemas quedan fuera de alcance.
Eso lo vuelve especialmente útil en entornos empresariales, integraciones con SaaS, herramientas internas, datos regulados o flujos donde hace falta una capa fuerte de control y gobernanza. En esos casos, reemplazar una API sensible por una tool MCP bien definida no es burocracia innecesaria: es una política de seguridad.
También hay un argumento de estandarización. Si una organización necesita que distintos clientes, asistentes o IDEs hablen con la misma capa de herramientas, MCP ofrece una interfaz común mucho más limpia que una colección de scripts ad hoc.
La conclusión real: no compiten, se reparten el trabajo
La lectura más razonable hoy no es “CLI contra MCP”, sino CLI para ejecución flexible, MCP para integración gobernada. El terminal convierte al agente en algo parecido a un desarrollador más dentro del proyecto. MCP convierte al agente en un consumidor de capacidades acotadas, con límites y permisos definidos.
Por eso la frase correcta probablemente no sea “el hype de MCP ha terminado”, sino algo más sobrio: el hype de usar MCP para todo ha terminado. Para buena parte del desarrollo diario, la terminal ya resuelve el problema con menos fricción. Para integraciones estructuradas y entornos regulados, MCP sigue siendo muy valioso.
En el fondo, el ecosistema está madurando. Durante un tiempo se quiso convertir MCP en la capa universal de toda interacción agente-herramienta. Ahora empieza a aparecer una visión más adulta: el CLI sigue siendo el lenguaje natural del desarrollo, y MCP es la capa correcta cuando lo que hace falta no es velocidad libre, sino control explícito.
Esa será, seguramente, la discusión que se repetirá una y otra vez en los próximos meses: no qué tecnología gana, sino cuándo conviene usar cada una.
Preguntas frecuentes
¿Qué es MCP exactamente?
MCP, o Model Context Protocol, es un estándar abierto para conectar aplicaciones de IA con herramientas, fuentes de datos y sistemas externos mediante interfaces estructuradas.
¿Los grandes agentes de terminal están apostando por el CLI o por MCP?
Por ambos, pero con un patrón claro: Claude Code, Codex CLI y Gemini CLI siguen siendo herramientas centradas en el terminal. Gemini CLI, además, soporta MCP como complemento, no como sustituto del entorno CLI.
¿Por qué algunos desarrolladores prefieren CLI frente a MCP?
Porque el CLI reduce fricción en tareas comunes, aprovecha herramientas estándar ya maduras y evita parte del coste de definir y mantener tools, schemas y contratos adicionales. Además, el comportamiento del agente suele ser más visible y fácil de depurar.
¿Cuándo tiene más sentido MCP que acceso directo a terminal?
Cuando hay que limitar capacidades, exponer APIs de forma controlada, trabajar con datos sensibles o integrar herramientas corporativas donde los permisos y la gobernanza importan más que la flexibilidad bruta.
