MCP ha muerto. Larga vida al CLI

• MCP está perdiendo interés rápidamente en la industria y ahora el enfoque basado en CLI es más práctico
• Los LLM ya son hábiles usando herramientas de línea de comandos y pueden realizar suficiente trabajo solo con documentación y CLI, sin necesidad de un protocolo aparte
• El CLI permite que tanto humanos como LLM ejecuten y depuren en el mismo entorno, lo que simplifica identificar la causa de los problemas
• También en términos de composabilidad, esquemas de autenticación y estabilidad, el CLI es más eficiente que MCP y más fácil de mantener
• MCP genera fricción continua en el trabajo real por la inestabilidad en la inicialización, la reautenticación repetitiva y la falta de control de permisos
• En la mayoría de los casos, el CLI es la opción más simple y confiable, y las empresas deberían priorizar ofrecer API y CLI antes que servidores MCP

---

Límites de MCP y ventajas del CLI

• Desde el anuncio de Model Context Protocol (MCP) de Anthropic, la industria se apresuró a construir servidores MCP, pero herramientas importantes como OpenClaw y Pi no lo soportan y no hay un beneficio real
  • Los LLM ya pueden realizar tareas mediante CLI y documentación
  • MCP agrega nuevos endpoints y esquemas de autenticación, pero duplica capacidades existentes
• Los LLM están optimizados para usar herramientas CLI y son muy competentes en ello
  • Han aprendido de millones de man pages, respuestas de Stack Overflow y scripts de shell en GitHub
  • Por ejemplo, si le indicas a Claude un comando como gh pr view 123, lo ejecuta tal cual
• MCP prometía una interfaz más limpia, pero en la práctica igual hay que documentar del mismo modo la descripción de cada herramienta, sus parámetros y cuándo usarla

El CLI también es útil para humanos

• El CLI permite que humanos y LLM compartan los mismos comandos
• Si Jira tiene un comportamiento inesperado, puedes reproducirlo ejecutando directamente el mismo comando jira issue view
• En MCP, las herramientas solo existen dentro de la conversación con el LLM, así que cuando algo falla hay que revisar registros de envío JSON, lo cual es engorroso
• La depuración no debería requerir un decodificador de protocolo
• En el CLI, la entrada y la salida son claras, así que es más fácil rastrear problemas

Composabilidad

• El CLI puede combinarse en pipelines con jq, grep, redirección de archivos y más
• Ejemplo de análisis de un plan grande de Terraform:
  • terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'
• Con MCP, habría que volcar todo el plan en la ventana de contexto (costoso y muchas veces imposible) o implementar filtrado personalizado dentro del propio servidor MCP
• El enfoque con CLI aprovecha herramientas que ya existen y están bien documentadas, y tanto humanos como agentes pueden entenderlo

Problemas de autenticación

• MCP es innecesariamente rígido respecto a la autenticación
• Las herramientas CLI ya usan esquemas de autenticación probados: aws con perfiles y SSO, gh con gh auth login, kubectl con kubeconfig
• Se aplica el mismo flujo de autenticación tanto si lo usa una persona directamente como si lo ejecuta Claude
• Si surge un problema de autenticación, puede resolverse con los métodos existentes como aws sso login o gh auth refresh, sin necesidad de troubleshooting específico de MCP

Problemas operativos: sin piezas móviles

• Los servidores MCP locales requieren iniciar y mantener un proceso separado, y en Claude Code se crean como procesos hijo, lo que a veces causa problemas
• Las herramientas CLI son solo binarios en disco; no requieren procesos en segundo plano, gestión de estado ni procedimientos de inicialización

Incomodidades en el trabajo real

• Inicialización inestable: es frecuente tener que reiniciar Claude Code porque un servidor MCP no arranca, y luego volver a intentar tras reinicializar el estado
• Reautenticación repetitiva: al usar varias herramientas MCP, hay que autenticarse en cada una, pero este problema no existe con CLI que usan SSO o credenciales de larga duración
• Control de permisos tosco: en Claude Code se pueden permitir herramientas MCP por nombre, pero no es posible restringirlas a solo lectura ni limitar rangos de parámetros
  • Con CLI sí es posible un control de permisos detallado, por ejemplo permitir gh pr view pero exigir aprobación para gh pr merge

Cuándo MCP sí tiene sentido

• MCP puede ser adecuado cuando no existe en absoluto una herramienta CLI equivalente
• Se reconoce su valor como interfaz estandarizada y la posibilidad de que existan casos de uso donde MCP encaje mejor que CLI
• Sin embargo, para la mayoría de las tareas, el CLI es más simple, más rápido de depurar y más confiable

Lección clave y pedido para quienes construyen herramientas

• La mejor herramienta es la que funciona tanto para humanos como para máquinas, y el CLI, tras décadas de iteración de diseño, ofrece composabilidad, facilidad de depuración e integración con sistemas de autenticación existentes
• MCP intentó crear una abstracción mejor, pero ya existía una abstracción suficientemente buena
• Las empresas que invierten en servidores MCP mientras no tienen un CLI oficial deberían replantear su estrategia, y si ofrecen en orden una buena API → un buen CLI, los agentes lo aprovecharán por sí solos
• Se puede reducir la complejidad innecesaria del protocolo y mejorar la productividad y la mantenibilidad

[sonnet]

No es que MCP no tenga ventajas; más bien, despertamos de la ilusión de usarlo indiscriminadamente en casos donde sus ventajas no aplican. Incluso al exponer microservicios para LLM, no vas a usar CLI, y MCP es un protocolo de "API".

[brainer]

En ese entonces también bastaba con usar la API. De hecho, la razón por la que se usaba MCP era por las limitaciones del contexto largo, pero ahora esas limitaciones ya se han superado en gran medida.

[jamsya]

Coincido totalmente.
Aunque no instales AWS MCP, Claude Code igual se las arregla para traer lo que necesita usando AWS CLI 😂

[GN⁺]

Comentarios en Hacker News

• Evité decir esto durante mucho tiempo, pero ahora estoy convencido de que MCP no tiene ventajas reales
  Opero agentes de IA que controlan todo mi flujo de trabajo de desarrollo mediante comandos de shell, y aunque vean flags de CLI por primera vez, las entienden bien solo con la salida de --help
  En cambio, los servidores MCP siempre fueron inestables y requerían mantenimiento
  La CLI se puede componer con jq, grep, redirección de archivos y más, mientras que MCP queda atado al formato que devuelve el servidor
  Al final, creo que adoptar MCP no es por razones técnicas, sino solo una señal de marketing de “AI-first”

  • MCP creció explosivamente en 2024, pero creo que es un caso donde el cambio de paradigma se movió rápido a inicios de 2025 con la aparición de los agentes de terminal (Claude Code)
  • Yo prefiero MCP. El manejo de errores y la depuración son mucho más limpios que en CLI, y se pueden restringir flags peligrosos o dividir los resultados con paginación
    MCP puede entenderse simplemente como un wrapper, igual que REST o gRPC
  • Yo también evito MCP. Probé JIRA MCP y fue un desastre. En cambio, hacer que el LLM llame la API directamente y escriba scripts fue mucho más eficiente
    Ahora creo que las herramientas CLI para LLM están en la cima
  • En nuestra empresa exponemos herramientas solo web, como la wiki interna, vía MCP para que Claude consulte directamente logs y métricas
    Eso sí, es incómodo que los resultados de MCP siempre entren en la ventana de contexto. Sería bueno poder volcarlos al sistema de archivos
  • Los servidores MCP parecen un producto transicional creado cuando los LLM estaban menos avanzados. Creo que es mucho mejor entrenar con datos de CLI

• MCP es como una API de caja negra que se puede invocar de inmediato sin instalación ni aprovisionamiento de recursos
  En cambio, la CLI puede acceder al entorno local, así que es mucho más precisa
  Con las CLI de jq y duckdb, se pueden muestrear archivos de datos grandes, y Opus 4.6 ajusta automáticamente las consultas mientras explora
  La CLI tiene muy buena capacidad de respuesta en tiempo real, así que es especialmente útil para el análisis exploratorio de datos
  Algunas CLI que uso con frecuencia son showboat, br, psql y roborev

  • Yo tuve la misma experiencia. La entrada y salida de texto de la CLI encajan mejor con la forma en que se entrenan los LLM
    Me divertí usando duckdb con ChatGPT, y me pregunto si configuras el prompt del sistema para que mantenga una DB local
  • En vez de CLI, también se podrían ejecutar comandos dentro de un contenedor Docker para evitar problemas de instalación. Incluso podría crearse una “skill” para automatizar ese enfoque
  • Como alguien que no es hablante nativo de inglés, me da risa usar el plural como en MCPs

• MCP tiene sentido cuando hay que descubrir herramientas que no existen en CLI y llamarlas según el contexto
  Por ejemplo, echomindr, que hice yo, ofrece por MCP una base de datos que extrae decisiones de fundadores desde podcasts
  Cuando Claude recibe preguntas sobre startups, busca experiencias reales de fundadores y responde con eso
  La CLI sirve cuando una persona ya sabe qué herramienta quiere usar, mientras que MCP sirve para la selección de herramientas por descubrimiento

• Parece que el autor ve el uso de IA solo desde una perspectiva de desarrollador
  La mayoría de los usuarios usan LLM mediante interfaces web como ChatGPT
  Desde la perspectiva de una empresa, MCP es mucho más adecuado para conectar herramientas de marketing, ventas y gestión de proyectos

• MCP en sí no está mal, pero stdio MCP está sobreingenierizado
  En cambio, el enfoque de Streamable HTTP + OAuth Discovery es actualmente la forma más eficiente de integración con IA
  Por ejemplo, Sentry MCP permite autenticación y acceso a datos con una sola URL
  El problema es la forma de implementación de MCP. En vez de invocarlo con bash, si se expone MCP como un endpoint HTTP, funciona con mucha más flexibilidad

  • Tanto en CLI como en MCP, el sistema de permisos debería diseñarse de forma consistente a nivel de API. La parte de Streamable HTTP necesita un poco más de explicación
  • Pienso lo mismo. La autenticación centralizada y la telemetría son mucho más simples. Eso sí, debe usarse solo donde corresponde

• Algunos de mis clientes no tienen servidor MCP, pero los desarrolladores lo piden igual
  Al final terminamos exportando la API de Postman en JSON para entregarla, pero los desarrolladores querían un servidor MCP
  La compatibilidad con MCP funciona como una checklist de marketing

• Este blog parece estar demasiado sesgado hacia la perspectiva del desarrollador
  Cuando se conecta con herramientas o servicios para no desarrolladores, MCP resulta mucho más natural

  • Exacto. En una interfaz de chat no se puede ejecutar CLI, y los servicios para no desarrolladores ni siquiera tienen CLI
  • Yo también me preguntaba si era posible correr CLI en interfaces web o móviles como ChatGPT o LeChat
  • Las interfaces para no desarrolladores ya están evolucionando hacia formas como OpenClaw y Claude Cowork

• Al final, ofertas de trabajo como “se busca alguien con 5 años de experiencia en MCP” quedaron como un meme sin sentido

• Una de las razones por las que la CLI es mejor que MCP es que tiene un formato optimizado desde la teoría de la información
  La salida de las herramientas Unix coloca la información relevante cerca entre sí, por lo que el mecanismo de atención del LLM funciona con más eficiencia
  JSON es fácil de parsear, pero incómodo para leer y razonar
  El formato de CLI es intuitivo tanto para humanos como para LLM
  Referencia relacionada: Entropy and Information Layout

• Comparar MCP con CLI es como comparar OpenAPI y cadenas (JSON)
  MCP está definido formalmente, mientras que la CLI es una interfaz abstracta del nivel de (String, List String, Map Int Stream) -> PID
  Al final, ambos son APIs; lo importante es elegir la herramienta adecuada para lograr el objetivo

  • Pero la CLI ofrece documentación completa con --help, así que si el LLM puede entender eso, es difícil decir que la estandarización de MCP sea mejor
  • Más que la teoría, importa la experiencia real de uso. Si alguien quiere decir que MCP y CLI son lo mismo, debería crear un ejemplo donde, por ejemplo, Playwright CLI y MCP muestren el mismo uso de tokens y nivel de configuración
    Si no, en la práctica se siente directamente que ambos enfoques son distintos

[develosopher]

Si alguien desarrolló un SaaS y está dudando entre cli vs mcp para integrar IA, probablemente elegiría primero mcp. Dar soporte a una CLI implica aumentar los puntos de mantenimiento. Puede que ambos coexistan, pero no creo que desaparezca.

[hanje3765]

Parece que dicen que, a medida que aumenta la inteligencia de los LLM, la necesidad de MCP se ha vuelto más difusa.
Yo también lo he sentido así en la práctica.

[m00nlygreat]

Parece que se está organizando así: ejecución remota con mcp y ejecución local con skills.

[hulryung]

Yo también empecé a crear y usar herramientas directamente con la CLI en lugar de MCP.