Una de las preguntas más interesantes que me hicieron en la última clase de mi curso "Strands Agents + AgentCore: De Cero a Agentes en Producción".

Ayer, en medio de la clase, llegó la pregunta:

"Ricardo, estoy viendo en Twitter y LinkedIn una pelea entre CLI y MCP para tools. ¿Cuál usamos? ¿Es verdad que MCP se come el contexto?"

La pregunta no es trivial. Tiene impacto directo en costos, latencia, confiabilidad y arquitectura de cualquier agente que llevemos a producción. La respuesta corta: no hay una respuesta única. Hay un framework de decisión que la comunidad fue construyendo en los últimos meses.

En este post te cuento qué está pasando, por qué se generó el debate, y cómo decidir en cada caso.

¿Qué son MCP y CLI?

MCP (Model Context Protocol)

Lo lanzó Anthropic en noviembre de 2024 como un estándar abierto para conectar agentes a herramientas externas (GitHub, Slack, bases de datos, lo que sea). La promesa fue clara: el "USB-C de la IA", un protocolo único para que cualquier modelo hable con cualquier herramienta sin reinventar la integración cada vez.

A mayo de 2026, MCP es el estándar de facto. La Linux Foundation lo gobierna a través de la Agentic AI Foundation, hay más de 177,000 tools registradas y casi 100 millones de descargas mensuales del SDK.

CLI (Command-Line Interface)

La interfaz de línea de comandos existe desde 1971 en Unix. Son los comandos de toda la vida: git, gh, kubectl, docker, aws, ffmpeg. No es tecnología nueva. Es la interfaz más veterana del desarrollo de software, y eso, sorprendentemente, resultó ser una ventaja enorme para los modelos de lenguaje grandes (LLMs).

El problema que detonó el debate: MCP devora contexto

A fines de 2025 y principios de 2026, los developers que pusieron MCP en producción empezaron a notar algo grave: MCP consume una cantidad enorme de tokens antes de que el agente haga una sola cosa útil.

El ejemplo concreto

Cuando conectás el servidor MCP de GitHub, este inyecta el esquema completo de herramientas en la ventana de contexto del modelo:

{
  "tools": [
    {
      "name": "create_issue",
      "description": "Create a new issue...",
      "inputSchema": { ... }
    }
    // ... y se repite para ~90 herramientas más
  ]
}

El servidor MCP de GitHub tiene del orden de 93 herramientas, lo que se traduce en ~55,000 tokens consumidos solo en definiciones, antes de que el agente reciba el primer prompt útil.

Con 3 servidores MCP conectados (GitHub + Slack + tu base de datos), podés llegar a consumir el 70%+ de una ventana de contexto de 200K tokens solo en metadata.

Anthropic mismo lo reconoció

En noviembre de 2025, Adam Jones y Conor Kelly del equipo de Engineering de Anthropic publicaron "Code execution with MCP: Building more efficient agents", donde reconocen el problema explícitamente:

"As MCP usage scales, there are two common patterns that can increase agent cost and latency: tool definitions overload the context window, and intermediate tool results consume additional tokens."

Cuando los creadores del protocolo te dicen "sí, hay un problema", no es polémica de Twitter. Es una corrección de arquitectura real.

La chispa: Peter Steinberger y OpenClaw

El debate explotó en febrero de 2026 cuando Peter Steinberger, creador de OpenClaw (el agente open source que pasó de 0 a 190,000 stars de GitHub en pocas semanas y terminó con Steinberger fichado por OpenAI), tiró una frase que se hizo viral:

"MCP was a mistake. Bash is better."

Steinberger no estaba haciendo clickbait. Su tesis era pragmática: los LLMs ya saben usar bash de memoria porque los entrenaron con miles de millones de líneas de scripts, Stack Overflow y man pages. No hace falta enseñarles un protocolo nuevo cuando ya hablan el viejo a la perfección.

⚠️ Disclaimer importante: OpenClaw también fue protagonista de uno de los desastres de seguridad más sonados del 2026 (ClawHavoc Attack, registrado como Common Vulnerabilities and Exposures CVE-2026-25253, miles de instancias expuestas en internet). El argumento técnico de Steinberger sobre CLI vs MCP es sólido, pero su modelo de seguridad fue criticado duramente por Cisco, Gartner y Meta. Es importante separar las dos cosas.

Las tres voces que estructuraron el debate

1. David Zhang (Duet) y el "trilemma"

David Zhang, construyendo Duet, describió el dilema imposible que enfrentó al integrar MCP, incluso después de haber resuelto OAuth y client registration dinámico:

1. Cargar todo al inicio → perdés memoria de trabajo para razonamiento.
2. Limitar integraciones → el agente solo habla con pocos servicios.
3. Cargar herramientas dinámicamente → agregás latencia y middleware complejo. Lo bautizó el "trilemma de MCP". Su decisión: sacó MCP completamente y adoptó CLI + ejecución de código.

2. Cobus Greyling y la tesis del "puente que ya existe"

En Replace MCP With CLI (Feb 2026), Greyling escribió la frase que mejor sintetiza el argumento pro-CLI:

"Con MCP, construís el puente hacia la herramienta. Con CLI, el puente ya existe."

Todo servicio serio ya tiene su CLI: AWS, GCP, Azure, GitHub, Stripe, Twilio, Kubernetes. Son production-grade, los mantienen los proveedores, y los modelos los conocen sin que les expliques nada.

3. Anthropic y el contraataque: Code Execution with MCP

Anthropic no se quedó callada. En noviembre 2025 publicó una solución intermedia muy elegante: en lugar de pedirle al modelo que llame tools una por una vía MCP, el agente escribe código corto que llama esas tools por debajo en un sandbox.

El resultado, según sus propios benchmarks, es una reducción de hasta el 98% de tokens consumidos (pasaron de 150,000 tokens a 2,000 tokens en su ejemplo de prueba).

Hay implementaciones en producción que ya validaron ese resultado: 70,000 → 800 tokens (~98% de reducción) en agentes reales sobre GitHub.

¿Por qué CLI funciona tan bien para LLMs?

Cuatro razones técnicas que vale la pena entender:

1. Los LLMs ya saben usar CLI "de memoria"

El modelo no necesita que le expliques qué hace git log --oneline -10. Lo vio millones de veces en su entrenamiento. Con MCP, cada esquema es nuevo para el modelo y tiene que interpretarlo en runtime.

# CLI: el modelo ya sabe esto
docker ps --filter "status=running" --format "{{.Names}}: {{.Status}}"

// MCP: el modelo recibe esto y tiene que interpretarlo
{
  "name": "list_containers",
  "inputSchema": {
    "properties": {
      "status_filter": { "enum": ["running", "stopped", "all"] },
      "format_fields": { "type": "array" }
    }
  }
}

2. CLI tiene "divulgación progresiva" gratis

Un agente con CLI puede ir descubriendo herramientas a medida que las necesita:

aws --help                          # ¿qué servicios hay?
aws s3 --help                       # ¿qué puedo hacer con S3?
aws s3 cp --help                    # ¿cómo se usa cp exactamente?

Cada llamada consume pocos tokens y solo cuando el agente realmente necesita esa información. MCP, por contraste, carga todo el esquema antes del primer mensaje.

3. Composabilidad tipo Unix

# Pipeline real que un agente puede armar solo
aws ec2 describe-instances --query 'Reservations[].Instances[?State.Name==`running`].InstanceId' \
  --output text | \
  xargs -I {} aws cloudwatch get-metric-statistics --instance-id {}

Hacer esto vía MCP requiere coordinar múltiples llamadas estructuradas, parsear resultados intermedios, mantener estado. Bash lo hace en una línea.

4. Cero overhead de protocolo

• CLI: genera comando → ejecuta → lee output. Directo.

- MCP: negocia capacidades → carga esquemas → construye llamada → servidor ejecuta → wrap del resultado → parse. Cada paso suma tokens.

La comparación honesta: ¿cuándo gana cada uno?

El framework de decisión que se puede implementar

Este es el árbol de decisión que valdria la pena utilizar:

1. ¿Existe un CLI maduro para esta tarea y el modelo ya lo conoce?
       ↓ SÍ → USÁ CLI
       ↓ NO → ¿Necesitás datos externos en tiempo real
                vía API de terceros con OAuth?
                    ↓ SÍ → USÁ MCP (o llamada directa a la API)
                    ↓ NO → ¿Es operación multi-agente / multi-tenant
                            con permisos granulares por servidor?
                                ↓ SÍ → USÁ MCP
                                ↓ NO → Considerá construir un CLI interno

Un consejo adicional: si vas a usar MCP, considerá seriamente el patrón Code Execution que propone Anthropic. Reduce el consumo de contexto al mínimo y podés seguir disfrutando del ecosistema MCP sin pagar el costo de cargar todos los esquemas upfront.

Lo que realmente está pasando: no es una guerra, es una corrección

Mi lectura, después de haber investigado un poco mas:

• 🔴 MCP fue sobrevendido como solución universal en 2025 → resultó costoso para muchas tareas cotidianas.
• 🟢 CLI fue subestimado por ser "viejo" → resultó perfecto para agentes porque los LLMs ya lo conocen.
• 🟡 El futuro es híbrido: CLI para operaciones locales y determinísticas, MCP para datos externos y multi-tenant, Code Execution para pipelines complejos. La frase viral "MCP is dead" es más una corrección de hype que una muerte real. Lo que murió fue la idea de que MCP tiene que ser el único puente entre los agentes y el mundo exterior.

¿Qué hacemos en el curso?

En "Strands Agents + AgentCore: De Cero a Agentes en Producción" construimos un Corporate Travel Agent con enfoque híbrido:

• CLI / SDK directo: para operaciones locales, herramientas internas, y APIs simples (como Open-Meteo para clima).
• MCP: cuando necesitamos un protocolo gobernado para integraciones empresariales (Duffel para reservas con OAuth).
• DynamoDB SDK nativo: porque para state management no tiene sentido envolver todo en MCP. La regla mental que me funciona: MCP es como Kubernetes. Fenomenal cuando lo necesitás, sobredimensionado cuando no.

Seguilo Aqui: https://www.ricardoceci.dev

Preguntas frecuentes

¿MCP está muerto?

No. MCP es el estándar de facto, gobernado por la Linux Foundation, con casi 100 millones de descargas mensuales. Lo que murió es la idea de que MCP debe ser el único puente entre agentes y herramientas. Para muchos casos cotidianos, CLI es más eficiente.

¿Cuándo conviene MCP sobre CLI?

Tres casos claros: (1) integraciones empresariales con OAuth multi-tenant, (2) ecosistemas multi-agente que necesitan gobierno centralizado, (3) servicios externos sin CLI maduro. Para todo lo demás (git, docker, kubectl, aws, manipulación local), CLI gana en tokens y latencia.

¿Es seguro darle bash a un agente?

Es la pregunta correcta. La respuesta es: depende del sandbox. Steinberger demostró el peligro con el incidente ClawHavoc en OpenClaw. La práctica recomendada es ejecutar el agente en contenedores con permisos restringidos, whitelist de comandos, y revisión humana para operaciones destructivas.

¿El patrón Code Execution reemplaza a MCP?

No, lo complementa. Code Execution te permite usar MCP servers existentes pero cargar solo las tools necesarias bajo demanda y procesar resultados intermedios sin pasarlos por la ventana de contexto. Es lo mejor de ambos mundos para integraciones complejas.

¿Cómo afecta esto a Strands Agents, LangChain, CrewAI?

Todos los frameworks principales soportan ambos patrones. La decisión es por herramienta, no por framework. En Strands Agents podés mezclar Agent(tools=[tu_funcion_python, mcp_client.tools]) sin problema.

Recursos para profundizar

• 📄 Code execution with MCP — Anthropic Engineering
• 📄 Replace MCP With CLI — Cobus Greyling
• 📄 Your MCP Server Is Eating Your Context Window — Apideck (DEV Community)
• 📦 OpenClaw en GitHub

¿Tu agente está sufriendo de context overflow? ¿Qué patrón estás usando vos? Dejame un comentario, me interesa saber cómo está resolviendo cada uno este trade-off en producción.