MCP fue declarado muerto tras una oleada de publicaciones que afirman que las CLI son más baratas para los agentes de IA. Este artículo desglosa las cifras reales de tokens, las contrapartidas de seguridad y los casos en los que gana cada enfoque, para que elijas el adecuado para tu propio proyecto.
En marzo de 2026, Denis Yarats, CTO de Perplexity, dijo que su empresa estaba dejando de usar MCP internamente y apostando por APIs directas y herramientas de línea de comandos. Una publicación sobre ello se volvió viral, y en cuestión de días el veredicto estaba en todas partes: MCP está muerto. Los desarrolladores compartieron capturas de listas de herramientas que devoraban su ventana de contexto, y las respuestas estaban llenas de comandos de shell de una sola línea que hacían el mismo trabajo en una fracción del espacio.
Entonces ocurrió algo extraño. El protocolo no murió. Siguió publicando nuevos servidores, siguió ganando el apoyo de los nombres más grandes de la IA y hoy está bajo la tutela de la Linux Foundation. Entonces, ¿qué es lo cierto?
Este artículo separa el ruido de las cifras. Verás qué hace MCP realmente, en qué quejas sobre los tokens tienen razón, por qué las CLI resultan tan naturales a los agentes de programación y en qué casos una terminal simplemente no puede hacer el trabajo. Además, incluye una tabla de decisión que puedes usar hoy y una sección breve sobre cómo probar ambos enfoques con el conector MCP y la API REST de PicassoIA.
💡 Respuesta corta: MCP no está muerto, pero la forma perezosa de usarlo sí. Cargar de entrada cien definiciones de herramientas es un problema de diseño, no un problema del protocolo.
La chispa fue una declaración breve con una larga repercusión. El CTO de Perplexity dijo que la empresa estaba abandonando MCP para sus herramientas internas y volviendo a las APIs directas y a las CLI. En las semanas siguientes aparecieron entradas de blog con títulos como "MCP está muerto" y "MCP frente a CLI", y el debate se endureció hasta formar dos bandos.
Ninguna de esas publicaciones era un veredicto oficial. Eran opiniones, y varias estaban respaldadas por benchmarks reales que mostraban grandes ahorros de tokens cuando un agente ejecuta un comando en lugar de cargar un servidor de protocolo. Las quejas eran justas. La afirmación de que todo el protocolo está acabado iba demasiado lejos para las pruebas disponibles.
Las cifras que circularon fueron llamativas. Una comparación de automatización de navegador informó de unos 52.000 tokens para leer una página de producto a través de una instantánea de MCP, frente a unos 1.200 tokens para unas pocas consultas puntuales en la línea de comandos. Otro benchmark, que listaba dispositivos en una herramienta de administración de Microsoft, reportó alrededor de 35 veces menos tokens con una CLI. Toma cifras como estas como orientativas, ya que dependen del servidor, de la tarea y del cliente. Pero la dirección es difícil de discutir: un servidor sobrecargado resulta caro.
Si quitas las opiniones acaloradas, quedan cuatro quejas:
git, curl, grep y docker en innumerables ejemplos, así que los invocan bien sin instrucciones adicionales.Cada punto es cierto en algunas configuraciones. Ninguno es un defecto de la idea de un protocolo compartido.
El contexto no es gratis. Cada token que se gasta en descripciones de herramientas es un token que no se gasta en tu código, en tus documentos o en la propia conversación. Además, los prompts largos cuestan dinero en cada llamada, y los modelos tienden a perder el hilo de los detalles enterrados en medio de un contexto enorme. Por eso el argumento de los tokens llega tan fuerte a quienes usan agentes todo el día.
Anthropic presentó el Model Context Protocol en noviembre de 2024 como una forma común de que las aplicaciones de IA accedan a herramientas y datos externos. Imagínalo como el USB-C de los agentes. Sin un estándar, cada aplicación de IA necesita un plugin propio para cada servicio, y el número de integraciones se multiplica rápidamente.
Un cliente (la aplicación de IA) se comunica con un servidor (la integración) a través de una tubería local o por HTTP. El servidor anuncia herramientas, recursos y prompts, y el cliente permite que el modelo los invoque. Esa es toda la idea: una sola forma de conector para muchos dispositivos.
Los tres bloques de construcción responden a necesidades cotidianas. Una herramienta realiza una acción, como crear una incidencia o generar una imagen. Un recurso expone datos para leer, como un archivo o una fila de una base de datos. Un prompt es una plantilla reutilizable que el usuario puede activar, como "revisa esta pull request". La mayoría de los servidores reales se apoyan casi por completo en las herramientas, que es también donde se acumulan los costos de tokens.
El 9 de diciembre de 2025, Anthropic donó MCP a la Linux Foundation como proyecto fundacional de la nueva Agentic AI Foundation, cofundada con Block y OpenAI y respaldada por Google, Microsoft, Amazon Web Services, Cloudflare y Bloomberg. Los protocolos terminados no suelen recibir un hogar neutral ni reunir en torno a una mesa a tantos competidores.
Así que la pregunta útil no es si MCP sobrevive. Es cómo deberían invocarlo las personas.
Aquí los críticos tienen un argumento sólido. Según los informes, el servidor oficial de MCP de GitHub ocupa unos 50.000 tokens en descripciones de herramientas antes de que el agente haga nada. Un archivo de habilidades breve que enseña el mismo flujo de trabajo a través de la línea de comandos ocupa, según se ha informado, unos 200 tokens. Es una diferencia de dos órdenes de magnitud, y sale del espacio que tu modelo necesita para la tarea real.
El segundo costo se esconde en mitad del flujo de trabajo. Si un agente obtiene una transcripción larga de un sistema y la pega en otro, cada palabra cruza el modelo dos veces. La transcripción de una reunión de una hora puede alcanzar los diez mil tokens o más, así que pasarla dos veces significa pagarla dos veces, aunque el modelo nunca necesitara leerla.
En su publicación de ingeniería del 4 de noviembre de 2025 sobre la ejecución de código con MCP, Anthropic describió un flujo de trabajo de Google Drive a Salesforce que bajó de unos 150.000 tokens a unos 2.000, un ahorro de aproximadamente el 98,7 %. El agente movió el texto en código, así que el modelo vio solo una confirmación breve.
Léelo con atención. La solución seguía siendo MCP. El agente simplemente lo llamó a través de código en lugar de hacer una llamada a herramienta cada vez.
| Enfoque | Contexto inicial | Mejor en | Punto débil |
|---|---|---|---|
| Llamadas directas a herramientas de MCP | Alto con muchas herramientas | Conjuntos de herramientas pequeños y seleccionados | Sobrecarga y rodeos de datos |
| MCP con ejecución de código | Bajo | Grandes conjuntos de datos, muchos pasos | Necesita un sandbox |
| CLI en una shell | Casi nulo | Herramientas para desarrolladores | Necesita una terminal |
| CLI más un archivo de habilidades | Muy bajo | Flujos de trabajo repetibles | Necesita mantenimiento |
Las herramientas de línea de comandos acumulan décadas de documentación, respuestas en foros e historial de shell. Un modelo al que se le pide listar las pull requests abiertas de un autor escribirá la línea correcta a la primera:
gh pr list --state open --json number,title,author \
| jq '.[] | select(.author.login == "maria") | .title'
Una línea, y solo los títulos finales llegan al modelo. El JSON bruto nunca entra en el contexto. Las tuberías, los filtros y las redirecciones dan a los agentes composición sin costo adicional.
Una CLI no anuncia de una vez todo lo que puede hacer. El agente ejecuta --help para el único subcomando que necesita, lee unas pocas líneas y sigue adelante. Eso es divulgación progresiva, y es exactamente lo que les falta a los esquemas de herramientas grandes.
También hay una ventaja para las personas. Todo lo que ejecute el agente, puedes ejecutarlo tú mismo en una terminal para reproducir un error. Sin protocolo oculto, sin inspector especial.
💡 Regla general: si ya existe una CLI madura para la tarea (git, gh, aws, kubectl, docker), deja que el agente la use.
Un ingeniero de Google DeepMind planteó el contraargumento más claro: si tu agente vive dentro de una aplicación de notas en el teléfono, "usa simplemente la CLI" no es una opción. Lo mismo ocurre con las aplicaciones de chat en el navegador, los asistentes empresariales con restricciones y cualquier sandbox sin acceso a procesos. La mayoría de las personas que usan IA a diario no están sentadas frente a una terminal.
Una shell es un instrumento muy burdo. Un agente con terminal hereda el sistema de archivos, las variables de entorno y cada sesión iniciada en esa máquina. Puedes acotarlo, pero por defecto está totalmente abierto.
Para ser justos, ninguna de las dos vías es segura por defecto. Una página web, un correo o un ticket pueden llevar instrucciones ocultas dirigidas al modelo, y ese riesgo existe tanto si el texto llega mediante una llamada a herramienta como si llega a través de la salida de curl. Los sandboxes, las credenciales de solo lectura y la aprobación humana de las acciones arriesgadas importan en ambos mundos. La diferencia es que MCP te ofrece un lugar natural para aplicar esos límites, mientras que una shell sin protección lo deja en tus manos.
Un servidor de MCP puede exponer solo las herramientas que elijas. Un servidor remoto puede usar OAuth, de modo que cada persona actúe con su propia identidad, y una puerta de enlace central puede registrar cada llamada. Para un equipo de cincuenta personas, eso supera a cincuenta equipos portátiles que guardan cada uno un token de larga duración en un archivo de configuración.
El protocolo está respondiendo, y con rapidez, a las mismas críticas que plantearon los detractores:
Un resumen práctico de la postura actual: usa una CLI cuando tengas una terminal, usa un servidor de MCP seleccionado cuando necesites un protocolo y nunca conviertas automáticamente una API completa en decenas de herramientas.
| Situación | Mejor opción | Por qué |
|---|---|---|
| Agente de programación local con terminal | CLI | Menor sobrecarga, los modelos conocen las herramientas |
| La herramienta ya tiene una CLI excelente | CLI | Las tuberías mantienen los datos fuera del contexto |
| Aplicación de chat en el navegador o en el teléfono | MCP | No hay shell disponible |
| Muchos usuarios, herramientas compartidas, necesidades de auditoría | MCP | OAuth, herramientas acotadas, registros centrales |
| SaaS sin CLI y solo con OAuth | MCP | Inicio de sesión estándar y esquema de herramientas |
| Flujo de trabajo largo que mueve archivos grandes | Ejecución de código | Los datos se quedan fuera del modelo |
La mayoría de los equipos acaban usando ambos. MCP gestiona los pocos sistemas que requieren inicio de sesión y gobernanza, y la CLI gestiona todo lo que los desarrolladores ya hacen en una terminal.
Así se ve en la práctica. Un desarrollador independiente que trabaja con un agente en terminal recurrirá todo el día a git, gh y docker, y añadirá uno o dos servidores de MCP para cosas sin CLI, como una herramienta de diseño o un gestor de tickets. Un equipo de soporte que usa un asistente de chat en el navegador no tiene ninguna shell, así que un servidor de MCP alojado con inicio de sesión es la única vía viable. Un equipo de plataforma que ejecuta decenas de agentes quiere registros centrales y herramientas acotadas, así que pone una puerta de enlace delante de unos pocos servidores seleccionados.
Cualquiera de las dos vías depende de un modelo que llame a herramientas de forma fiable. En PicassoIA puedes comparar varios modelos de lenguaje en un solo lugar: Claude Sonnet 5 para automatizar tareas de programación, GPT 5.6 Sol para trabajo de programación complejo, Kimi K2.6 para crear agentes y Gemini 3.5 Flash para chat y código rápidos. Dale la misma tarea con herramientas a dos de ellos y observa cómo maneja cada uno una llamada fallida.
La generación de imágenes y de video es un buen banco de pruebas para este debate. Las salidas son grandes, los trabajos tardan y la herramienta tiene que informar del progreso. PicassoIA expone los mismos cuatro modelos a través de un conector de MCP y de una API REST: PicassoIA Image, PicassoIA Image Editor Pro, PicassoIA Video y Seedance 2.5 Lite para video con audio.
Pueden ejecutarse hasta cinco trabajos a la vez por cuenta, compartidos entre todas las conexiones.
Fíjate en lo que el protocolo hace bien aquí. El asistente no necesita conocer una URL, una cabecera ni un intervalo de consulta. Las descripciones de las herramientas le indican cómo iniciar un trabajo y cómo consultarlo, y el resultado vuelve al chat. Esa comodidad es exactamente lo que promete MCP, y para un usuario no técnico en el navegador es la diferencia entre "funciona" y "no es posible".
Los mismos modelos están disponibles en https://api.picassoia.com/v1, con un token bearer que empieza por pia_sk_. La forma sigue el estilo de Replicate: crear una predicción, consultarla y descargar la salida.
curl -s https://api.picassoia.com/v1/models/picassoia/picassoia-image/predictions \
-H "Authorization: Bearer $PICASSOIA_TOKEN" \
-H "Content-Type: application/json" \
-d '{"input": {"prompt": "A lighthouse at dawn, natural light, 16:9"}}'
La respuesta incluye un ID de predicción. Consulta GET /v1/predictions/{id} hasta que el estado indique succeeded y, después, descarga el archivo. Revisa las páginas de la API en picassoia.com para ver los campos de entrada exactos de cada modelo.
💡 Pruébalo tú mismo: ejecuta el mismo prompt una vez a través del conector de MCP y otra con curl. Mide el tiempo de ambos, cuenta los pasos y decide cuál encaja mejor en tu flujo de trabajo.
MCP no está muerto y la CLI no es una moda pasajera. Son dos herramientas con funciones distintas, y lo inteligente es asociar cada una al lugar donde realmente vive tu agente. Entra en picassoia.com, elige un modelo, escribe tu primer prompt y comprueba ambos caminos con tus propias imágenes.
Elige tu idioma
