Cada pocos meses alguien publica que MCP está muerto, y cada pocos meses un equipo lleva a producción otro servidor MCP. Las dos cosas son ciertas a la vez. Los modelos mejoraron mucho para ejecutar comandos de shell, leer documentación y escribir scripts pequeños, así que muchas de las razones iniciales para envolver cada herramienta en un protocolo se han debilitado. Aun así, algunas tareas siguen necesitando una interfaz estándar, autenticada y remota a la que cualquier agente pueda conectarse sin código de conexión a medida. Este artículo separa los dos grupos. Verás dónde una CLI sencilla o un archivo de habilidades supera a un servidor MCP, dónde el servidor sigue ganando y cómo decidir en unos cinco minutos.
Qué hace MCP realmente
Una definición sencilla
El Model Context Protocol, o MCP, es un estándar abierto que Anthropic publicó en noviembre de 2024. Define cómo una aplicación de IA (el cliente) pide a un programa separado (el servidor) tres cosas: herramientas que puede invocar, recursos que puede leer y prompts que puede reutilizar. Los mensajes viajan como JSON-RPC, a través de entrada y salida estándar en servidores locales, o mediante Streamable HTTP en los remotos. OpenAI y Google lo adoptaron durante 2025, y más tarde el protocolo pasó a la Agentic AI Foundation de la Linux Foundation, así que ningún proveedor único lo controla.

Imagínalo como un adaptador de viaje. La toma de pared (el servicio) y el enchufe (el agente) nunca necesitan saber nada el uno del otro. El adaptador del medio resuelve la incompatibilidad.
El problema para el que se creó
Antes de MCP, conectar M asistentes con N servicios significaba M por N integraciones a medida. Cada par tenía su propio flujo de inicio de sesión, sus propias peculiaridades de esquema y sus propios errores. MCP lo convirtió en M más N: escribes un servidor por servicio, un cliente por asistente, y cualquier combinación funciona. Ese ahorro es real, y explica por qué aparecieron miles de servidores públicos en aproximadamente un año desde su lanzamiento.
💡 Conviene recordarlo: MCP es infraestructura, no inteligencia. Juzga si la infraestructura cuesta menos que la alternativa para tu tarea concreta, no si está de moda este mes.
El caso en contra de MCP
Los críticos no van desencaminados. Tres quejas aparecen una y otra vez, y cada una resiste la medición.
Las definiciones de herramientas se comen el contexto
Cada herramienta que expone un servidor llega con un nombre, una descripción y un esquema JSON. La mayoría de los clientes cargan todas en la ventana de contexto del modelo al inicio de la sesión. Aquí hay un cálculo aproximado e ilustrativo: un servidor con 40 herramientas a unos 400 tokens por esquema añade 16.000 tokens. Conecta cinco servidores de ese tamaño y habrás gastado 80.000 tokens antes de que el usuario escriba una sola palabra.

Esa factura tiene tres partes: dinero, latencia y atención. Los tokens cuestan dinero en cada solicitud, los prompts más largos responden más despacio, y un contexto saturado deja menos espacio para el material que el modelo realmente necesita. La calidad de la selección también tiende a caer cuando dos servidores exponen cada uno una herramienta llamada search y el modelo tiene que adivinar cuál quisiste decir.
Los agentes ya hablan shell
Los agentes de programación dominan git, gh, curl, jq, docker y psql. Estas herramientas aparecen miles de veces en los datos de entrenamiento, tienen una bandera --help y su salida es texto plano. Cuando un modelo puede ejecutar gh pr list --json title,author y analizar el resultado, un servidor MCP de GitHub añade una capa sin aportar mucha capacidad.

Una CLI también compone. El modelo encadena un comando con otro, escribe la salida en un archivo y lee solo las líneas que necesita. Una llamada a una herramienta MCP devuelve todo su resultado al contexto, salvo que el autor del servidor haya previsto la paginación, y muchos no lo hicieron.
Las skills y los scripts cuestan menos
Los archivos de skills siguen otro camino. Una skill es una carpeta con una breve descripción en markdown y, opcionalmente, scripts. Solo el nombre y un resumen de una línea ocupan sitio en el contexto hasta que el agente decide que necesita la skill, y entonces lee las instrucciones completas. Pagas cuando se hace el trabajo, no en cada solicitud.

Para flujos de trabajo internos, como "cómo desplegamos", "cómo escribimos las notas de publicación" o "cómo consultamos el almacén de datos", una skill con un script suele ser el camino más corto. No hay servidor que alojar, ni transporte que depurar, y todo vive en el repositorio junto al código que describe.
Dónde MCP sigue ganando
Ahora el otro lado. Estas son las situaciones en las que sustituir MCP por scripts genera más trabajo, no menos.
Servicios remotos con autenticación real
Un script en un equipo portátil puede leer un token de API de una variable de entorno. Eso funciona para un desarrollador. Deja de funcionar cuando cincuenta personas necesitan acceso a un CRM, cada una con permisos distintos, y el equipo de seguridad quiere tokens que caduquen. El flujo de autorización de MCP se apoya en OAuth 2.1, así que un servidor remoto puede pedir a cada usuario que inicie sesión, emitir tokens con alcance limitado y revocarlos desde un único lugar. El agente nunca guarda un secreto de larga duración pegado en el historial de la shell.

Los servidores alojados también funcionan donde no hay shell: una aplicación de chat, un cliente móvil, una barra lateral del navegador. Una CLI necesita una terminal. Un servidor MCP remoto necesita una conexión de red.
Trabajos largos y resultados asíncronos
Algunas tareas tardan minutos, no milisegundos. La generación de imágenes y de video son los ejemplos más claros. Una solicitud inicia un trabajo, una GPU en algún lugar lo recoge, y quien lo pidió tiene que volver a consultar más tarde. Un comando de shell que se bloquea noventa segundos resulta incómodo. Una herramienta con un contrato definido de inicio, consulta y resultado es más fácil de implementar bien.

El conector propio de PicassoIA sigue ese patrón. Su API es de estilo Replicate: creas una predicción, la consultas y obtienes la salida. A través de la conexión MCP, un agente puede acceder a cuatro modelos, PicassoIA Image, PicassoIA Image Editor Pro, PicassoIA Video y Seedance 2.5 Lite para video con audio, sin que nadie escriba los endpoints a mano. La plataforma permite cinco predicciones simultáneas por cuenta, compartidas entre las credenciales de API y las conexiones MCP, así que un agente que lance diez solicitudes a la vez tiene que respetar ese límite. Un servidor bien construido oculta esta contabilidad detrás de resultados de herramienta claros, igual que un pase de cocina mantiene los pedidos en orden mientras los cocineros trabajan en paralelo.
Imagina que un equipo de contenidos pide a un agente una publicación de lanzamiento, cinco imágenes principales y un clip animado corto. La redacción ocurre dentro del modelo. Las imágenes y el clip son remotos, lentos y tienen límites de peticiones, que es exactamente la forma que MCP maneja bien.
Equipos, registros de auditoría y permisos
Cuando un agente toca datos de producción, alguien pregunta quién hizo qué. Una pasarela MCP central puede registrar cada llamada a herramienta, aplicar listas de permitidos por equipo y bloquear acciones arriesgadas antes de que lleguen al servicio. Hacer lo mismo con scripts sueltos obliga a rastrear registros en distintos equipos portátiles.

Los revisores lo agradecen. Pueden leer un registro y un archivo de políticas y ver lo que el agente tenía permitido hacer, en lugar de auditar cincuenta historiales de shell distintos.
MCP frente a CLI frente a skills frente a API
Esta es la misma comparación como tabla de referencia rápida.
| Situación | Mejor opción | Por qué encaja |
|---|
| Git local, archivos, herramientas de compilación | CLI | Los modelos ya conocen los comandos, sin configuración |
| Flujo de trabajo de equipo, como las notas de publicación | Skill con script | Se carga bajo demanda, vive en el repo |
| Producto SaaS con permisos por usuario | Servidor MCP remoto | Inicio de sesión OAuth, revocación, registros centrales |
| Generación de imágenes o video | MCP o API directa | Trabajos asíncronos, límites de concurrencia compartidos |
| Extracción de datos puntual dentro de un script | Llamada directa a la API | Menos piezas móviles |
| Agente dentro de una aplicación de chat sin shell | Servidor MCP remoto | No hay terminal disponible |
| Herramienta necesaria en 1 de cada 100 sesiones | Skill o MCP con carga diferida | Evita pagar el costo del esquema cada vez |
Fíjate en que la respuesta rara vez es todo MCP o nada de MCP. La elección correcta depende de quién llama a la herramienta, cuánto tarda en ejecutarse y con qué frecuencia se necesita.
Cómo está cambiando MCP
La crítica caló, y el ecosistema respondió. Dos cambios son los más importantes.
Ejecución de código en lugar de volcados de herramientas
El equipo de ingeniería de Anthropic describió a finales de 2025 un patrón en el que el agente escribe código que llama a herramientas MCP, en lugar de enviar cada llamada por la ventana de contexto. Las definiciones de herramientas aparecen como archivos que el agente puede explorar, los resultados intermedios se quedan dentro de un sandbox y solo la respuesta final vuelve al modelo. En su ejemplo práctico, el uso de tokens bajó de unos 150.000 a unos 2.000, una reducción del 98,7%.

Carga diferida de herramientas
Varios clientes ya cargan las definiciones de herramientas bajo demanda. El modelo busca en un catálogo, saca las dos o tres herramientas que necesita e ignora el resto. Es el enfoque del fichero de tarjetas: la biblioteca tiene miles de tarjetas, pero abres un solo cajón. Elimina la queja más grande de la sección anterior sin renunciar al estándar.
Los autores de servidores también se adaptaron. Un servidor con seis herramientas de alto nivel, bien descritas, supera a uno que refleja línea por línea una API REST de 300 endpoints, porque el modelo tiene menos opciones y cada una significa algo.
Una lista de decisión de cinco minutos
Repasa esto antes de construir o instalar nada.

Elige MCP cuando
- Muchos usuarios necesitan su propio acceso con alcance limitado al mismo servicio
- El trabajo es asíncrono, como los trabajos de render o las exportaciones largas
- El agente se ejecuta en un entorno sin shell
- Necesitas registros centrales, listas de permitidos o revocación
- El propietario del servicio ya publica un servidor mantenido
Evita MCP cuando
- Una CLI conocida ya hace el trabajo
- La tarea son archivos locales, git o compilaciones
- Solo lo usas tú, en una máquina
- El servidor reflejaría una API REST uno a uno
- Lo cargarías en cada sesión pero lo usarías una vez por semana
Configuraciones mixtas que funcionan
La mayoría de los entornos maduros usan las tres. Un agente de programación usa la shell para git y las pruebas, lee una skill con las convenciones del equipo y se conecta a dos o tres servidores MCP remotos para el gestor de tickets, la base de datos y la generación de medios. Puedes probar las mismas ideas de llamada a herramientas con los LLM disponibles en PicassoIA, como Claude Sonnet 5, GPT 5.6 Sol, Kimi K2.6 y Gemini 3.5 Flash. La elección del modelo importa menos que mantener la superficie de herramientas pequeña y honesta.
Errores comunes de los equipos
- Envolver todo solo porque se puede. Un servidor alrededor de
ls o cat añade un proceso, un transporte y un esquema a cambio de nada que la shell no ofrezca ya.
- Ignorar la factura de tokens. Revisa cuántos tokens añaden tus servidores conectados antes del primer mensaje. Si la cifra te sorprende, desactiva servidores por proyecto o cambia a la carga diferida.
- Desplegar sin límites de autenticación. Un servidor local con acceso total a archivos y a la red se convierte en un riesgo cuando el modelo lee páginas web no confiables. Limita los permisos, prioriza por defecto herramientas de solo lectura y pide confirmación para las escrituras.
- Duplicar herramientas entre servidores. Dos servidores que ofrecen ambos búsqueda, descarga o envío confunden al modelo. Renombra las herramientas con claridad o apaga uno de los servidores.
- Tratar el protocolo como el producto. A los usuarios les importa el resultado. Si un script, una skill o una llamada directa a la API produce un mejor resultado con menos configuración, úsalo y sigue adelante.
Crea tus propias imágenes en Picasso IA
Entonces, ¿seguimos necesitando MCP? Para herramientas locales y conocidas, normalmente no. Para servicios remotos, autenticados, lentos y compartidos, normalmente sí. Esa división es toda la respuesta, y seguirá cambiando a medida que los clientes sean más hábiles cargando herramientas.
Si quieres ver un flujo de trabajo asíncrono y remoto en acción sin leer una especificación, genera algo. Abre Picasso IA, elige PicassoIA Image para una imagen fija rápida, refínala con PicassoIA Image Editor Pro y luego anímala con PicassoIA Video. Cada imagen de este artículo empezó como un prompt en lenguaje natural, y el mismo flujo de trabajo está abierto a un agente a través de la conexión MCP. Explora todo en picassoia.com/en/all-models, escribe una sola idea y mira hasta dónde llega una sola frase.