- La CLI ha surgido como la nueva tendencia en interfaces de herramientas para agentes, pero una CLI personalizada también sufre los mismos problemas de contexto que MCP y debe renunciar a la estructuración y a varias ventajas
- El MCP local en modo
stdio y el MCP remoto basado en Streamable HTTP responden a casos de uso completamente distintos, y esta distinción se está pasando por alto en el debate actual
- Las funciones de Prompts y Resources de MCP son un mecanismo para distribuir en tiempo real habilidades y documentación estandarizadas en toda la organización, y son clave para pasar del vibe coding a una ingeniería agéntica más sistemática
- Los servidores MCP centralizados estandarizan la autenticación OAuth, la telemetría y la observabilidad, lo que permite seguridad a nivel organizacional y medir la efectividad de las herramientas
- Para desarrolladores individuales, la CLI puede ser adecuada, pero a nivel organizacional y empresarial, MCP es la herramienta del presente y del futuro para garantizar consistencia, seguridad y calidad
Ciclo de hype impulsado por influencers
- Hace apenas 6 meses, Model Context Protocol (MCP) era el tema más candente de la industria, y todos los vendors querían lanzar productos relacionados con MCP
- Incluso entonces existía el escepticismo de “si al final es solo una API, ¿por qué hace falta un wrapper?”, y de hecho hubo equipos que se saltaron por completo el ciclo de hype de MCP y eligieron escribir wrappers de herramientas simples sobre endpoints REST API
- En la mayoría de los casos de uso, se ha extendido la percepción de que MCP es un overhead innecesario frente a llamar a la API directamente
- El discurso actual de la industria ha girado hacia las críticas a MCP y la exaltación de la CLI, algo relacionado con la dinámica de influencers de IA que generan tendencias nuevas constantemente para mantener la atención
- Incluso figuras reconocidas como Garry Tan y Andrew Ng tienden a generalizar experiencias personales, y la cultura influencer que alimenta el FOMO y el hype está distorsionando la conversación en este campo
- Sí hay casos reales en los que la CLI encaja mejor como interfaz de herramientas para agentes, pero no ocurre así en todos los casos
El ahorro de tokens con CLI: realidad y límites
Herramientas CLI incluidas en los datos de entrenamiento
- Utilidades CLI como
jq, curl, git, grep, psql y aws, que ya están incluidas en el dataset de entrenamiento de los LLM, pueden ser usadas por el agente de inmediato sin instrucciones, esquemas ni contexto adicional
- MCP, en cambio, debe declarar de antemano las herramientas en la respuesta de
tools/list, por lo que introduce overhead frente a herramientas CLI ya conocidas
- Las herramientas CLI ya presentes en los datos de entrenamiento siempre deberían usarse antes que MCP
Límites de las CLI personalizadas
- Las herramientas CLI personalizadas (bespoke) no pueden ser entendidas por el LLM por sí solas, así que hay que proporcionar explicaciones en
AGENTS.md o README.md
- Se puede definir un directorio
/cli-tools y confiar en nombres descriptivos, pero los agentes se equivocan con frecuencia usando este enfoque, y al final hace falta más documentación explicativa
- Incluso una herramienta como
curl pierde su ventaja de ahorro de tokens en el momento en que necesita comprender un esquema OpenAPI personalizado
Extracción y transformación encadenadas
- Con cadenas de CLI se pueden buscar datos y transformarlos para reducir la cantidad que entra en la ventana de contexto
- Sin embargo, contenidos formateados como HTML, JSON o XML también pueden extraerse con selectores como DOM/CSS, JSONPath o XPath, por lo que no es una ventaja exclusiva de la CLI
Consumo gradual de contexto
- Mientras MCP precarga de antemano todo el conjunto de herramientas y sus esquemas, la CLI puede cargar contexto gradualmente mediante
--help
- Pero en el caso de herramientas CLI personalizadas, el agente tiene que explorar el contenido de ayuda a lo largo de varios turnos y, al final, carga información similar a la de un esquema MCP pero sin estructura
- En flujos lo bastante complejos, el agente termina recorriendo casi todo el árbol y el ahorro resulta mínimo
- Según la investigación de Vercel, cuando se colocó el índice completo de documentación en
AGENTS.md, mejoró el uso de documentación por parte del agente, lo que sugiere que proporcionar todo el esquema por adelantado favorece una selección correcta de herramientas
- Ahora que Anthropic ofrece una ventana de contexto de 1 millón de tokens, es válido preguntarse si el ahorro de tokens sigue siendo un argumento decisivo
La dualidad de MCP: stdio vs Streamable HTTP
Límites del modo stdio
- En modo
stdio, el servidor MCP se ejecuta localmente junto al agente, lo que añade complejidad innecesaria frente a escribir una CLI simple
- En la mayoría de los casos de uso, MCP en modo
stdio es innecesario
El valor transformador de Streamable HTTP
- MCP con transporte Streamable HTTP permite ejecutar la misma lógica en un servidor centralizado, y es un elemento clave para que la adopción en organizaciones y empresas pase del vibe coding a la ingeniería agéntica
- La mayoría de los influencers no está distinguiendo entre estos dos modos
Ventajas de un servidor MCP centralizado
Capacidades ricas de backend
- En un servidor central se pueden aprovechar capacidades de plataforma más potentes en las herramientas, como una instancia de Postgres o consultas de grafos Cypher basadas en Apache AGE
- Desde el agente solo hace falta configurar el endpoint HTTP y el token de autenticación, así que el despliegue es sencillo
- También se puede usar una base local como SQLite, pero tiene límites cuando se trata de compartir estado en toda la organización
Runtime efímero para agentes
- En entornos de runtime efímero como GitHub Actions, un servidor MCP remoto permite usar herramientas que requieren backends complejos sin necesidad de instalación
- La gestión de cargas stateful en entornos stateless se delega al servidor central
Autenticación y seguridad
- Si se usa una CLI para acceder a una API segura, todos los desarrolladores necesitan acceso directo a la API key, lo que genera una gran carga operativa
- Si se centraliza detrás de un servidor MCP, los desarrolladores se autentican por OAuth contra el servidor MCP, mientras que las API keys sensibles y los secretos quedan controlados detrás del servidor
- Cuando alguien deja el equipo, basta con revocar su token OAuth, ya que nunca tuvo acceso directo a otras keys o secretos
Telemetría y observabilidad
- En un servidor MCP centralizado se pueden recopilar trazas y métricas de OpenTelemetry con herramientas estándar
- Esto permite saber qué herramientas son efectivas, qué runtime de agente se está usando y en qué punto fallan las herramientas
- También se puede hacer con CLI, pero un despliegue local exige actualizaciones en cada consumidor y obliga a reproducir el scaffolding de telemetría en cada herramienta CLI
Despliegue estandarizado inmediato y actualizaciones automáticas
- Las herramientas distribuidas como paquetes generan problemas de compatibilidad de versiones de API, pero MCP permite que el servidor notifique actualizaciones a los clientes mediante Subscriptions y Notifications
- Los MCP Prompts equivalen a un
SKILL.md entregado por el servidor, y los MCP Resources equivalen a un /docs entregado por el servidor
El valor organizacional de MCP Prompts y Resources
- Contenido dinámico: los archivos
*.md en un repositorio son archivos estáticos que requieren actualización manual, pero los prompts y resources basados en servidor pueden generarse dinámicamente en tiempo real
- Documentación útil solo en ciertos contextos, datos de precios o el estado actual del sistema pueden inyectarse dinámicamente sin llamadas de herramienta
- Actualizaciones automáticas y consistentes: los archivos
*.md distribuidos en repositorios o paquetes requieren sincronización, pero cuando se entregan como prompts MCP siempre permanecen actualizados
- Incluso la documentación oficial de terceros puede proxyearse mediante el servidor, evitando copiarla y actualizarla manualmente en cada repositorio
- Compartir conocimiento en toda la organización: contenido aplicable a toda la empresa, como seguridad, mejores prácticas de telemetría o consideraciones de despliegue de infraestructura, puede distribuirse de forma consistente a todos los repositorios, todos los workflows y todos los frontends de agentes (Claude Code, Codex, VS Code Copilot, GitHub Agents, OpenCode, etc.)
- En entornos de microservicios, también es posible que un equipo acceda a la documentación de otro servicio, o que un equipo de servicio entregue habilidades dinámicamente en cada despliegue
- Ya se han confirmado casos reales donde MCP Prompts y Resources funcionan en OpenCode, Claude Code CLI y otros, y con solo la configuración del cliente MCP no hace falta gestión adicional después del despliegue
Conclusión: a nivel organizacional, MCP es el presente y el futuro
- Hace 6 meses MCP era el tema del momento y ahora se le culpa de inflar el contexto, pero se están ignorando los trade-offs y trampas similares de las CLI personalizadas
- Cuando un equipo se plantea cómo pasar del vibe coding a la ingeniería agéntica, llega de forma natural al diseño y la misión de MCP
- Como muestra un caso reciente dentro de Amazon AWS —donde se exige aprobación de un ingeniero senior para cambios asistidos por IA—, los equipos al final tendrán que operar y mantener los sistemas de software producidos por agentes de IA
- Los consejos de Garry Tan y Andrew Ng pueden ser válidos en entornos individuales homogéneos, pero son difíciles de aplicar tal cual en organizaciones donde equipos con distintos niveles técnicos y experiencia deben converger en una calidad consistente
- Para lanzar software confiable y mantenible, hace falta una disciplina de ingeniería que garantice consistencia, seguridad, calidad y precisión, y para ello MCP es hoy la herramienta adecuada para organizaciones y empresas
6 comentarios
clies una herramienta local, ymcpes un servidor, así que su uso es muy distinto.¿No sería lo mismo si ejecutas el CLI en el servidor?
¡MCP reencarnado!
Documento relacionado: MCP está muerto. Larga vida a la CLI
Ojalá avanzara más la discusión sobre alguna función de sandbox de CLI para que también se puedan usar herramientas de CLI en apps móviles; al intentar compatibilizar el entorno móvil real, parece que al final el cuello de botella termina siendo justamente el sandboxing.
Comentarios en Hacker News
Siento que la mayoría de las funciones de integración con IA que están saliendo hoy en día están mal diseñadas
En una situación donde ni siquiera los comandos básicos están estandarizados, lo único que abunda es documentación inexacta generada por LLM en lugar de documentación real
Al final, parece que eso que llaman “estándares de IA” va a aparecer y desaparecer una y otra vez. Los LLM son esencialmente basados en texto, así que es difícil que funcionen con la precisión de un protocolo de red. Este tipo de ingeniería centrada en texto termina creando una pirámide inestable de abstracciones
Creo que lo más útil de las herramientas de IA es una estructura donde agentes probabilísticos están envueltos por compuertas deterministas
Por eso uso MCP sobre HTTP. Por ejemplo, NanoClaw filtra mensajes de WhatsApp de forma determinista y hace proxy de claves API para reforzar la seguridad. Este tipo de estructura hace que la IA sea más confiable
Esta estructura ofrece seguridad y facilidad de gestión, y además permite generar automáticamente un CLI desde un catálogo de herramientas
Puedes ver un ejemplo de implementación en smith-gateway
El núcleo open source puede verse en tenuo
MCP separa claramente la toma de decisiones de la IA y la ejecución determinista del sistema. Yo uso Claude Code junto con servidores MCP, y es muy eficiente porque la IA resuelve creativamente los problemas mientras la ejecución sigue rutas predecibles
MCP es una especificación de protocolo fija para la comunicación entre apps de IA
En lugar de forzar APIs entre aplicaciones como en el enfoque tradicional de “integración”, ofrece una abstracción de comunicación reutilizable como HTTP, FTP o SMTP
Creo que si la IA va a interactuar con múltiples servicios, necesita un lenguaje común de este tipo
La especificación puede verse en modelcontextprotocol.io/specification/2025-11-25
En realidad, lo que hace falta no es un protocolo nuevo, sino especificaciones de CLI o API explorables de manera incremental. Sostienen que MCP es solo una solución temporal de la época en que los primeros agentes no podían ejecutar CLIs
Desde esa perspectiva, MCP es solo una solución temporal por inmadurez tecnológica
Cuando MCP apareció por primera vez, me pareció una basura sobreingenierizada, así que no le presté atención
Hasta ahora no me arrepiento. Con LangChain me pasa igual. Es peligroso seguir algo solo porque está de moda
Con una inversión mínima de tiempo se puede obtener una gran ganancia en eficiencia
sniff test) es útil, pero por sí sola no bastaA veces una herramienta tosca sobrevive precisamente porque resuelve de forma simple problemas complejos de integración
Si la descartas de entrada por verse fea, podrías perder la oportunidad de que luego se convierta en infraestructura estándar
Más que sobreingeniería, lo ven como una estructura clara e intuitiva
Remote MCP está bien porque la autenticación se maneja automáticamente y facilita el acceso a servicios
Pero, comparado con la combinación de CLIs + Skills, tiene mucha sobrecarga de contexto (context bloat) y además pierde ventajas del Unix CLI, como el procesamiento por pipelines o la entrada por heredoc
El CLI es eficiente porque puede generar automáticamente skills a partir de la salida de
--helpMCP requiere procesos persistentes, mientras que un CLI puede ejecutarse solo cuando hace falta
Yo sigo pensando que MCP es una capa innecesaria
Estoy de acuerdo en que CLI > MCP, pero las ventajas de documentación y centralización pueden resolverse de otras maneras
Por ejemplo, usando Skills se pueden incluir instrucciones tanto para CLI como para APIs, y cargarlas solo cuando haga falta
Las ventajas de un MCP centralizado también pueden implementarse perfectamente con proxies existentes o AWS SSO
Al final, me parece mejor documentar con Skills y dejar la interacción real a CLIs o APIs REST
Se argumenta que el contenido de Skills termina incluyéndose en el contexto y generando carga, y que un proxy no puede reemplazar por completo la funcionalidad de MCP
MCP puede activar prompts y recursos con comandos
/y referencias@, algo que no es posible con un proxyEl demo relacionado puede verse en los .gif al final del artículo y en la especificación de MCP
Siento que MCP encaja mejor en entornos de consumo
En entornos de desarrollo es complejo e ineficiente, pero para usuarios generales permite entender fácilmente qué funciones puede realizar un modelo a través de MCP
No requiere configuración del entorno, y en una GUI incluso se pueden visualizar las respuestas como Siri o Google Assistant
Desde la perspectiva de ofrecer herramientas de IA a usuarios no desarrolladores dentro de una empresa, el acceso centralizado mediante MCP ha sido muy útil
Permitió gestionar de manera consistente el tono de marca, la terminología interna, el acceso a datos compartidos y el contexto de dominio
A través del método de recursos de MCP, se pudieron ofrecer “skills” estandarizadas y controlar los patrones de conexión a los datos
El autor examina varios conceptos desde distintos ángulos, pero parece no conocer ideas ya existentes como Token Notation (TOON)
Da la impresión de que estuviera deseando que algo así existiera
El verdadero problema de MCP es la carga de mantenimiento
Por ejemplo, si necesitas integración con GitHub, terminas dependiendo de un wrapper de npm en lugar de usar una API que ya está bien documentada
Yo simplemente uso el CLI
ghocurl. Si la API cambia, el agente lee la nueva documentación y se adaptaCon MCP, tienes que esperar a que se actualice el wrapper intermedio
Las afirmaciones sobre seguridad también son contradictorias: al principio salió sin autenticación y ahora lo presentan como una ventaja de seguridad
En realidad, eso es un problema que métodos antiguos como chroot o los scoped tokens ya habían resuelto
El único punto donde MCP realmente tiene ventaja es en los flujos OAuth para no desarrolladores. Como herramienta para desarrolladores, me parece mejor simplemente crear un CLI superior