⏱️ Lectura: 13 min
Desde finales de 2024, el Model Context Protocol (MCP) fue presentado como el “USB-C de la inteligencia artificial”: un estándar único para conectar modelos de lenguaje con herramientas externas como GitHub, Linear, Notion o Slack. Año y medio después, varios equipos que lo usan a diario empiezan a cuestionarlo.
📑 En este artículo
- TL;DR
- Qué es MCP y por qué se volvió el estándar
- Problema 1: MCP devora la ventana de contexto
- Problema 2: baja confiabilidad operativa
- Problema 3: se solapa con el CLI y la API que ya existen
- Las alternativas: CLI-first y el patrón Skills
- ¿MCP está realmente muerto?
- Qué cambia para desarrolladores en LATAM
- Preguntas frecuentes
- Referencias
El equipo de ingeniería de Quandri midió el costo real de MCP sobre su propio stack y publicó un análisis con un título deliberadamente provocador: “MCP is dead”. Acá repasamos sus números, el debate técnico de fondo y qué alternativas existen, con foco en lo que significa para quienes desarrollamos en LATAM.
TL;DR
- MCP (Model Context Protocol) conecta LLMs con herramientas externas como GitHub, Linear, Notion y Slack desde finales de 2024.
- Con 4 servidores MCP conectados, las definiciones de herramientas ocupan el 10,5% del contexto en Claude (200K) y 16,5% en GPT-4o (128K).
- 77 herramientas suman ~21.077 tokens cargados siempre, aunque solo uses dos de ellas.
- Buscar un issue de Linear cuesta ~65x más tokens vía MCP que con un curl directo a la API.
- Un benchmark midió MCP 3x más lento por llamada y 9,4x más lento en la primera, que incluye la inicialización.
- Las alternativas son la estrategia CLI-first y el patrón Skills, que cargan instrucciones solo cuando se necesitan.
- Claude Code lanzó Tool Search con carga diferida: reduce el consumo de contexto de MCP en más del 85%.
Qué es MCP y por qué se volvió el estándar
MCP es un protocolo abierto que estandariza cómo un modelo de lenguaje descubre y llama herramientas externas. En lugar de que cada aplicación invente su propia forma de conectar la IA con GitHub, una base de datos o un gestor de tareas, MCP define un formato común: el modelo recibe una lista de herramientas disponibles, cada una con su nombre, su descripción y el esquema de sus parámetros, y puede invocarlas durante la conversación.
La promesa era enorme y por eso la adopción fue rápida. Si todos los proveedores hablan el mismo protocolo, conectar un asistente a Linear, Notion o Slack se vuelve cuestión de instalar un servidor MCP y listo. Esa misma facilidad, sin embargo, esconde un costo que no se nota hasta que se mide: cada herramienta que MCP expone tiene que viajar dentro del contexto del modelo. Y el contexto, en un LLM, es un recurso escaso y caro.
Problema 1: MCP devora la ventana de contexto
La ventana de contexto es, literalmente, el escritorio del modelo: todo lo que el LLM “tiene a la vista” para razonar. La analogía que usa el artículo original es la de un restaurante. Te sentás en la mesa y te despliegan diez menús enormes (las definiciones de las herramientas MCP). Ocupan tanto espacio que casi no queda lugar para la comida, es decir, para tu trabajo real. Y cada vez que pedís algo, hay que volver a sacar los menús.
Quandri extrajo y midió las definiciones reales de los servidores MCP conectados en su entorno. El resultado es contundente: con cuatro servidores activos, las definiciones de herramientas por sí solas consumen el 10,5% de la ventana de contexto de Claude. Estos son los números que reportaron:
| Servidor MCP | Herramientas | Tokens estimados |
|---|---|---|
| Linear | 42 | ~12.807 |
| Notion | 14 | ~4.039 |
| Slack | 12 | ~3.792 |
| Postgres | 9 | ~438 |
| Total | 77 | ~21.077 |
Linear solo aporta más de 12.800 tokens: 42 definiciones de herramientas cargadas permanentemente, aunque en la práctica solo uses get_issue y save_issue. Y esto escala con el modelo: en GPT-4o, con su ventana de 128K, ese mismo equipaje sube al 16,5% del contexto disponible antes de escribir una sola línea de trabajo útil.
💭 Clave: El problema no es que MCP sea lento al ejecutar; es que siempre ocupa lugar. Pagás el peaje de las 77 herramientas en cada turno de la conversación, las uses o no.
Problema 2: baja confiabilidad operativa
El segundo reclamo no tiene que ver con los tokens sino con la ingeniería de operaciones. Un servidor MCP es un proceso aparte que hay que levantar y mantener vivo. Eso introduce una lista de fallas que cualquiera que lo haya corrido en producción reconoce:
- Fallas de inicialización y reautenticación constante — hay que arrancar y sostener un proceso separado que pide credenciales una y otra vez.
- Respuestas más lentas — cada llamada implica un round-trip al servidor externo.
- Muerte del proceso a mitad de sesión — si el servidor MCP se cae, las herramientas desaparecen sin aviso.
- Permisos opacos — no siempre queda claro qué puede hacer realmente cada herramienta.
El dato de rendimiento es el que más duele. El autor del artículo original que inspiró a Quandri comparó un servidor MCP de Jira contra la API REST directa de Jira: MCP resultó 3x más lento por llamada, y 9,4x más lento en la primera llamada incluyendo la inicialización. No es un problema de Jira: es arquitectónico. Todo servidor MCP agrega una capa de proceso entre el LLM y la API subyacente, y esa capa cuesta latencia. La misma penalización aplica a Linear, Notion y Slack.
Problema 3: se solapa con el CLI y la API que ya existen
El tercer argumento es quizá el más filosófico. Buena parte de lo que MCP intenta resolver ya estaba resuelto: las herramientas de línea de comandos (CLI) y las APIs HTTP existen desde hace décadas, y los modelos ya las aprendieron de las páginas man, de StackOverflow y de millones de repos públicos. MCP, en cambio, vive solo dentro de la conversación con el LLM.
| Aspecto | CLI / API | MCP |
|---|---|---|
| Paridad humano-máquina | Los mismos comandos para personas y para el LLM | Solo existe dentro de la conversación |
| Componibilidad | Pipes, jq, grep combinables libremente | Atado al formato de retorno del servidor |
| Depuración | Se reproduce al instante en la terminal | Solo reproducible dentro del contexto |
| Datos de entrenamiento | Ya aprendido de man pages y foros | Requiere definiciones de herramientas aparte |
| Costo de instalación | Casi siempre ya instalado | Setup de servidor, auth y gestión de proceso |
El ejemplo que lo deja claro es buscar un issue de Linear. ¿Cuántos tokens cuesta la misma operación con cada enfoque?
# Enfoque CLI: ~200 tokens en total
curl -s -H "Authorization: Bearer $LINEAR_TOKEN" \
-H "Content-Type: application/json" \
-d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' \
https://api.linear.app/graphql
# -> Prompt (el comando curl): ~50 tokens
# -> Respuesta: ~150 tokens
# Enfoque MCP: ~12.957 tokens en total
# -> Definiciones de herramientas (siempre cargadas): ~12.807 tokens (42 tools)
# -> Llamada + respuesta: ~150 tokensLa diferencia es de unos 65x a favor del CLI. La llamada útil cuesta lo mismo (~150 tokens); todo el sobrecosto está en el equipaje de definiciones que MCP arrastra de fondo.
graph LR
A["LLM"] -->|"carga 77 tools al iniciar"| B["Servidor MCP"]
B -->|"round-trip por cada llamada"| C["API externa"]
A -.->|"curl directo, sin tools precargadas"| C
Las alternativas: CLI-first y el patrón Skills
Si MCP no es la respuesta universal, ¿qué se propone en su lugar? El artículo plantea dos estrategias complementarias.
Alternativa 1: estrategia CLI-first. Darle al modelo, en este orden, CLI → API → documentación. El LLM ya aprendió a usar herramientas de terminal, así que dejá que las use directamente. No gastás contexto en definiciones, la interfaz es la misma para humanos y para la IA (lo que facilita depurar), y todo se compone libremente con pipes.
Alternativa 2: el patrón Skills. Si MCP es “desplegar todos los menús sobre la mesa de entrada”, Skills es “pedirle al bibliotecario solo el libro que necesitás”. Una Skill es un archivo con instrucciones que se carga únicamente cuando hace falta, no al conectar.
| Aspecto | MCP | Skills |
|---|---|---|
| Momento de carga | Todas las definiciones al conectar | Solo cuando se necesita |
| Consumo de contexto | Siempre ocupado | Solo en uso |
| Escalabilidad | Crece con cada servidor | No proporcional a la cantidad de skills |
La clave es incrustar las instrucciones de uso del CLI dentro de la Skill. Así se combinan ambas alternativas. Un ejemplo mínimo de Skill para consultar Linear:
# Skill: consulta de issues en Linear
- API de Linear: https://api.linear.app/graphql
- Auth: Bearer Token (variable de entorno LINEAR_TOKEN)
- Obtener issue:
curl -s -H "Authorization: Bearer $LINEAR_TOKEN" \
-H "Content-Type: application/json" \
-d '{"query":"{ issue(id: \"ID\") { title state { name } } }"}' \
https://api.linear.app/graphqlComo el secreto vive en una variable de entorno, conviene configurarla según tu sistema. Acá va en los tres entornos más comunes:
# Linux / macOS (bash o zsh)
export LINEAR_TOKEN="lin_api_xxx"
# Windows (PowerShell)
$env:LINEAR_TOKEN = "lin_api_xxx"
# Windows (CMD)
set LINEAR_TOKEN=lin_api_xxx💡 Tip: Nunca pongas el token directo en el comando ni lo commitees. Usá variables de entorno o un gestor de secretos, y rotá la credencial si alguna vez quedó expuesta.
¿MCP está realmente muerto?
Acá conviene bajar un cambio. El título es marketing; la realidad es más matizada, y el propio artículo lo reconoce con una actualización importante. Desde que se tomaron esas mediciones, Claude Code incorporó Tool Search con carga diferida (deferred loading): los esquemas de las herramientas MCP se cargan bajo demanda en lugar de todos al conectar, lo que reduce el consumo de contexto en más del 85%. Es decir, el Problema 1 —el que motivaba el título— está en gran parte resuelto para quien use versiones actuales.
Lo que sigue en pie son los argumentos de confiabilidad, depuración y paridad humano-máquina. MCP agrega una capa de proceso, y esa capa puede fallar, ser más lenta y resultar más difícil de reproducir que un comando que corrés en tu propia terminal. La conclusión razonable no es “MCP murió”, sino “MCP no es gratis, y para muchas tareas el CLI directo más una Skill bien escrita es más simple, más barato en tokens y más fácil de depurar”.
📌 Nota: MCP sigue siendo útil cuando necesitás un protocolo estándar entre múltiples clientes y servidores heterogéneos, o cuando el proveedor no expone una API/CLI cómoda. La pregunta no es “MCP o CLI”, sino “¿qué cuesta menos contexto y es más fácil de mantener para este caso concreto?”.
Qué cambia para desarrolladores en LATAM
Para quienes trabajamos desde la región, este debate tiene aristas concretas. La primera es el costo: cada token que un modelo procesa se paga, y arrastrar 21.000 tokens de definiciones en cada turno encarece cualquier flujo automatizado. En equipos pequeños o startups con presupuesto ajustado, ese sobrecosto es real y se acumula rápido.
La segunda es la latencia. El round-trip adicional de un servidor MCP se siente más cuando la conexión hacia el proveedor del modelo no es óptima. Un enfoque CLI-first reduce capas y, con ellas, puntos de falla y demoras. La tercera es la mantenibilidad: una Skill es un archivo de texto que cualquier integrante del equipo puede leer, editar y versionar en Git, sin levantar ni monitorear un proceso extra. Para equipos chicos, menos infraestructura que vigilar es una ventaja directa.
La recomendación práctica es medir antes de decidir. Si ya usás MCP, asegurate de estar en una versión con carga diferida y revisá cuánto contexto consume tu configuración. Si vas a empezar de cero, probá primero el camino CLI + Skill para las integraciones que ya tienen una API o un comando decente; reservá MCP para los casos donde el estándar realmente te ahorra trabajo.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Qué es exactamente MCP?
MCP (Model Context Protocol) es un protocolo abierto lanzado a finales de 2024 que estandariza cómo un modelo de lenguaje descubre y llama herramientas externas como GitHub, Linear, Notion o Slack, exponiendo cada herramienta con su nombre, descripción y esquema de parámetros.
¿Por qué se dice que MCP “consume” la ventana de contexto?
Porque las definiciones de las herramientas se cargan dentro del contexto del modelo y permanecen ahí durante toda la sesión. En el stack medido por Quandri, 77 herramientas sumaban ~21.077 tokens, equivalentes al 10,5% del contexto de Claude (200K) y al 16,5% del de GPT-4o (128K).
¿De verdad MCP es 65x más caro que un curl?
Para una tarea puntual como buscar un issue de Linear, sí: la llamada útil cuesta ~150 tokens en ambos casos, pero MCP arrastra además ~12.807 tokens de definiciones siempre cargadas. El sobrecosto está en ese equipaje, no en la operación en sí.
¿Entonces conviene dejar de usar MCP por completo?
No necesariamente. Claude Code agregó Tool Search con carga diferida, que reduce el consumo de contexto de MCP en más del 85%. El problema de contexto está mayormente resuelto en versiones actuales; siguen vigentes los argumentos de confiabilidad, depuración y latencia.
¿Qué es el patrón Skills y en qué se diferencia de MCP?
Una Skill es un archivo de instrucciones que se carga solo cuando se necesita, en lugar de cargar todas las definiciones al conectar. Combinado con una estrategia CLI-first, evita ocupar contexto de forma permanente y es más fácil de versionar y depurar.
¿Cómo empiezo con una estrategia CLI-first?
Dale al modelo, en orden, el CLI, la API y la documentación de cada herramienta, y guardá las credenciales en variables de entorno. Escribí una Skill breve que incluya el comando exacto (por ejemplo, el curl a la API) y dejá que el modelo lo invoque directamente.
Referencias
- Quandri Engineering — “MCP is dead” — mediciones de consumo de tokens y argumentos sobre confiabilidad del stack real del equipo.
- modelcontextprotocol.io — documentación y especificación oficial del Model Context Protocol.
- github.com/modelcontextprotocol/servers — repositorio oficial con los servidores MCP de referencia (Linear, Slack, Postgres y más).
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios