¿MCP está muerto?

(quandri.io)

1 puntos por GN⁺ 5 시간 전 | 2 comentarios | Compartir por WhatsApp

MCP conecta los LLM con herramientas externas, pero en los flujos de trabajo de desarrollo el costo de contexto, la estabilidad operativa y la duplicación con CLI/API se vuelven una carga importante
En las mediciones de Quandri, las 77 definiciones de herramientas de Linear, Notion, Slack y Postgres ocupan aproximadamente 21,077 tokens, equivalentes al 10.5% del contexto de 200K de Claude
Para consultar un issue de Linear, el enfoque con MCP consume alrededor de 12,957 tokens porque siempre arrastra 42 definiciones de herramientas, muy por encima de los ~200 tokens del enfoque con CLI
MCP implica un proceso de servidor separado y suma autenticación, inicialización, conflictos y latencia por recorridos externos, mientras que CLI/API es más fácil de reproducir, depurar y combinar desde la terminal
Quandri envolvió su CLI existente en Skills y recuperó unos 21K tokens; solo usa MCP cuando no existe CLI o cuando se necesita control de permisos a nivel de equipo

Los costos clave que dejó en evidencia MCP

MCP (Model Context Protocol) conecta los LLM con herramientas externas como GitHub, Linear, Notion y Slack, pero en flujos de trabajo reales de desarrollo los principales problemas son el uso de contexto, la estabilidad operativa y la superposición con CLI/API existentes
Desde su lanzamiento a fines de 2024 fue descrito como el “USB-C del ecosistema de IA”, pero para quienes lo usan a diario en desarrollo primero se hicieron evidentes otros costos
Después de esta medición, Claude Code introdujo Tool Search with Deferred Loading, que carga los esquemas de herramientas MCP solo cuando se necesitan y reduce el uso de contexto en más de 85%
En Claude Code, el problema de expansión del contexto hoy está bastante mitigado, pero siguen pendientes cuestiones de rendimiento, depuración y arquitectura

Consume gran parte de la ventana de contexto

La ventana de contexto es el espacio que usa el LLM para trabajar, y al conectar servidores MCP una gran parte puede ocuparse solo con definiciones de herramientas, no con el trabajo real
Al extraer y medir las definiciones reales de herramientas de los servidores MCP conectados en el entorno de Quandri, se observó que al conectar los 4 servidores, solo las definiciones de herramientas consumen el 10.5% de la ventana de contexto
Tamaño de las definiciones de herramientas:
- Linear: 42 herramientas, ~51,229 caracteres, ~12,807 tokens
- Notion: 14 herramientas, ~16,156 caracteres, ~4,039 tokens
- Slack: 12 herramientas, ~15,168 caracteres, ~3,792 tokens
- Postgres: 9 herramientas, ~1,755 caracteres, ~438 tokens
- Total: 77 herramientas, ~84,308 caracteres, ~21,077 tokens
Uso de contexto por modelo:
- En Claude con contexto de 200K, las definiciones de herramientas representan 10.5%
- En GPT-4o con contexto de 128K, las definiciones de herramientas representan 16.5%
Solo Linear ya carga siempre 42 definiciones de herramientas y ocupa más de ~12,800 tokens; incluso si en la práctica solo se usan get_issue y save_issue, se incluye toda la definición
Ejemplos de definiciones de herramientas grandes:
- linear/save_issue: 2,479 caracteres, ~619 tokens
- slack/search_public: 1,614 caracteres, ~403 tokens
- linear/list_issues: 1,588 caracteres, ~397 tokens
- notion/fetch: 1,379 caracteres, ~344 tokens
- slack/send_message: 1,248 caracteres, ~312 tokens

Carga de rendimiento y estabilidad operativa

MCP requiere iniciar y mantener procesos separados, por lo que pueden aparecer fallas de inicialización y autenticaciones repetidas
Cada invocación de herramienta necesita un viaje de ida y vuelta a un servidor externo, lo que ralentiza la velocidad de respuesta de la IA
Si el proceso del servidor MCP falla, las herramientas pueden desaparecer en medio de la sesión
No siempre queda claro qué permisos tiene realmente cada herramienta, así que la visibilidad de permisos es baja
En el benchmark de Jira MCP de MCP is dead. Long live the CLI, MCP fue 3 veces más lento por llamada que una invocación directa a la REST API, y la primera llamada incluyendo la inicialización fue 9.4 veces más lenta
Esta diferencia de rendimiento no se limita a Jira; surge de una arquitectura que agrega una capa de proceso llamada servidor MCP entre el LLM y la API base
La misma sobrecarga también aplica a los servidores de Linear, Notion y Slack en el stack de Quandri

Duplica lo que ya existe en CLI/API

CLI/API permite que personas y LLM usen los mismos comandos, mientras que MCP solo existe dentro de la conversación del LLM
CLI/API puede combinarse libremente con pipes, jq y grep, mientras que MCP queda atado al formato que devuelve el servidor
CLI/API puede reproducirse y depurarse de inmediato en la terminal, mientras que MCP solo puede reproducirse dentro del contexto de la conversación
El LLM ya aprendió a usar CLI/API a través de man pages y StackOverflow, mientras que MCP necesita definiciones de herramientas aparte
CLI/API por lo general ya está instalado, mientras que MCP agrega configuración de servidores, autenticación y gestión de procesos

El costo en tokens de consultar un issue de Linear

Al consultar el mismo issue de Linear, el enfoque con MCP consume alrededor de 65 veces más tokens que el enfoque con CLI
El enfoque con CLI usa ~200 tokens:
- Prompt del comando curl: ~50 tokens
- Respuesta: ~150 tokens
El enfoque con MCP usa ~12,957 tokens:
- 42 definiciones de herramientas de Linear que siempre se cargan: ~12,807 tokens
- Llamada a la herramienta y respuesta: ~150 tokens
El ejemplo con CLI invoca directamente la API GraphQL de Linear:

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

Alternativa: estrategia CLI-first y Skills

Un enfoque que ofrezca CLI → API → documentación en ese orden es más liviano y directo
Como el LLM ya aprendió a usar CLI a partir de man pages y StackOverflow, no hace falta cargar siempre definiciones de herramientas aparte
Si se usa directamente la CLI existente, no se desperdicia contexto en definiciones de herramientas y, como humanos e IA usan la misma interfaz, depurar es más fácil
También puede combinarse libremente con otros comandos mediante pipelines
Si MCP es como “poner todo el menú sobre la mesa de una vez”, Skills se parece más a “pedirle al bibliotecario solo el libro necesario”
MCP carga todas las definiciones de herramientas al conectarse y ocupa contexto de manera permanente, mientras que Skills se carga solo cuando hace falta y solo ocupa contexto mientras se usa
A medida que aumenta el número de servidores, también aumenta la presión de contexto de MCP, mientras que Skills no consume contexto de forma permanente en proporción al número de skills
La clave es poner las instrucciones de uso de la CLI dentro de Skills; combinado con una estrategia CLI-first, resulta lo más eficiente
El ejemplo de Linear Skill incluye solo la URL de la API, el método de autenticación, el comando curl para consultar issues, la forma de buscar con GraphQL y la indicación de que el JSON se parsea con jq:

# Linear Issue Lookup Skill  
- Linear API: https://api.linear.app/graphql  
- Auth: Bearer Token ($LINEAR_TOKEN env var)  
- Get issue: 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  
- Search issues (GraphQL): adjust the query field for JQL-like filtering  
- Results are JSON, parse with jq

Con este enfoque, el LLM carga ese contenido en el contexto solo cuando invoca la skill correspondiente
En lugar de arrastrar siempre las 42 definiciones de herramientas de Linear, basta con cargar los comandos CLI necesarios

Casos donde MCP sigue siendo válido

Cuando un servicio no tiene CLI, MCP puede ser la única forma de conexión
Para usuarios no desarrolladores que no usan terminal, MCP puede ser más accesible
En comunicación bidireccional en tiempo real que va más allá de una simple solicitud-respuesta, MCP puede ser adecuado

Criterios para elegir en el acceso a bases de datos

Al final, una base de datos consiste en ejecutar consultas, y el LLM ya conoce bien SQL y las consultas de MongoDB
Si se ponen en una Skill la información de la BD, el esquema y la forma de usar la CLI, el LLM puede escribir consultas sin MCP
El ejemplo de Postgres Skill incluye solo el host, el esquema de tablas y el uso de la CLI psql:

# Postgres Skill  
- Host: postgres://localhost:5432/myapp  
- Tables: users (id, name, email), orders (id, user_id, status)  
- CLI: psql -h localhost -d myapp -c "SELECT * FROM users WHERE ..."

En bases de datos, MCP también tiene ventajas:
- Seguridad de consultas: el servidor MCP puede forzar un modo de solo lectura y bloquear consultas riesgosas a nivel de servidor
- Protección de credenciales: con el enfoque CLI la cadena de conexión puede quedar expuesta en el prompt, mientras que el servidor MCP gestiona internamente las credenciales
Para desarrollo local o una base de datos personal, Skills + CLI es liviano, rápido y fácil para recuperarse de errores
Para una BD de producción o un entorno compartido por equipos, MCP puede ser más apropiado, ya que importan salvaguardas como validación de consultas y control de acceso a nivel de servidor
En la mayoría de los flujos de trabajo de desarrollo, MCP tiende a ser una solución sobrediseñada

Cómo lo usa Quandri

Quandri usa Bash + CLI, Skills y MCP según el servicio
Para herramientas de uso diario como gh, psql y aws, usa Bash + CLI:
- sin costo de contexto
- con alta flexibilidad
- y con depuración directa en la terminal
Para flujos de trabajo repetitivos de varios pasos, como redactar commits y revisar PRs, usa Skills:
- se cargan solo al invocarse
Para servicios como Slack, Linear y Notion, que no tienen una CLI fuerte, usa MCP
También usa MCP cuando importa la autenticación por equipo o la delimitación de permisos, como en el acceso a bases de datos de producción
Si ya existe una CLI y se puede autenticar localmente, normalmente esa vía es la más ligera
Si el servicio no tiene CLI o se necesita autenticación consistente para todo el equipo, MCP sí aporta valor

Conclusión y método de medición

Más importante que conectar todo es enseñar bien
En Quandri, reemplazaron servidores MCP con Skills que envuelven la CLI existente y recuperaron alrededor de 21K tokens de contexto
En los flujos de trabajo diarios desaparecieron las fallas de inicialización y la depuración siguió en la terminal
Cargar solo las herramientas necesarias, en el momento necesario y junto con instrucciones de CLI, es más eficiente
MCP podría evolucionar para resolver estos problemas en el futuro, pero por ahora Skills parece una mejor opción
Método de medición:
- en el entorno de Claude Code, extrajeron el esquema JSON de cada herramienta de los servidores MCP realmente cargados
- midieron el tamaño con base en el nombre de la herramienta, la descripción y los parámetros
- la estimación de tokens usó la heurística de ~1 token por cada 4 caracteres
- la estimación total por servidor se extrapoló a partir del promedio de herramientas de muestra

¿Quieres seguir recibiendo temas de tecnología seleccionados? Sigue el canal de Telegram. @GeekNewsES

2 comentarios

aer0700 3 시간 전

Creo que simplemente habría que elegir la tecnología que mejor se adapte a la situación de cada quien. Para decir que está muerto, me parece que ya se está usando demasiado.

GN⁺ 5 시간 전

Comentarios de Hacker News

Lidero en OpenAI el equipo encargado de ChatGPT App Store, los plugins de Codex y todo lo relacionado con MCP, y lo que pasan por alto los textos que dicen que “MCP murió” es que, en la práctica, no importa mucho si MCP se usa como protocolo de transporte
MCP no ha muerto porque casi todas las empresas del planeta están creando servidores MCP, y lo sabemos porque tenemos contacto directo con ellas
Muchas de esas empresas no tienen CLI, e incluso algunas ni siquiera tienen API externa, pero aun así están creando servidores MCP
Internamente se podría convertir cada servidor MCP en una CLI, usar modo código o implementar descubrimiento de herramientas, pero esos son solo detalles de implementación; lo importante es que los agentes de IA puedan acceder a servicios a los que antes no podían acceder
Puede ser debatible si MCP murió como capa de comunicación con la que el modelo conversa directamente, pero para nada significa que MCP haya muerto como protocolo
Esta afirmación se ha debilitado más que antes por las funciones de uso de computadora/navegador de la app Codex, y si todavía no las has probado, son realmente impresionantes
- Creo que es muy probable que MCP sí muera
  La razón principal es que, ya sea que la implementación real sea una API, la web o una CLI, encima añade otra capa más y otra persona más que puede desincronizarse
  La IA no debería usar un protocolo o un conjunto de instrucciones distinto del que usan las personas para acceder, conocer y utilizar algo
  Ahora mismo las empresas quieren exponer servidores MCP porque es la moda, pero en la práctica lo que pasa es que le piden a Claude que construya un servidor MCP sobre una API existente y, de vez en cuando, le vuelven a pedir que lo actualice para que coincida con la documentación pública
  Como la documentación de la API ya es pública y Claude Code también construyó el servidor MCP leyendo solo documentación pública de internet, MCP se siente como una solución provisional a las limitaciones actuales de los modelos
- Al final, MCP se parece más a una marca para “una API que puede usar un modelo de lenguaje grande”
  Como resultado, incluso empresas que no eran tan orientadas a la tecnología están creando APIs para que sus herramientas no parezcan anticuadas en la era de los agentes
  Estoy de acuerdo con el objetivo en sí, pero otra cosa distinta es si elegiría esto como protocolo para lograrlo; de todos modos, ya se convirtió en un protocolo que la gente conoce y realmente usa
- La frase “casi todas las empresas del planeta están creando servidores MCP” suena justamente a una cámara de eco
- MCP en realidad consume la aún valiosa ventana de contexto mientras resuelve un problema que no existe
  La afirmación de que, sin MCP, los agentes no pueden acceder a un servicio es, siendo generosos, engañosa, y como dice el artículo, también se puede acceder con herramientas de línea de comandos y su entrada/salida
  Incluso desde una perspectiva puramente técnica, MCP tiene menos composabilidad que las herramientas de línea de comandos, y creo que quienes no prioricen la composabilidad terminarán pagando ese costo
  Hablando sin rodeos, hay un sesgo de inversión, y el hecho de que se les esté vendiendo MCP a muchas empresas no refuta ese sesgo
  Basta ver Microsoft para notar que no hay mucha relación entre utilidad y qué tan profundamente se entierra una tecnología; de hecho, algunos dirían que es al revés
  También sospecho que el empuje actual de OpenAI hacia MCP se debe en gran parte a factores organizacionales, algo que puede ser difícil de ver desde dentro
- Que se esté creando MCP en lugares donde no existe CLI suena bastante preocupante
  No es lo mismo duplicar funciones existentes de CLI para una mejor integración con agentes que convertirlo en la única interfaz que amarra a todos a una especificación que después podría parecer menos adecuada
  Si eso pasa, después habrá que pagar la deuda de MCP, y al final puede salir más barato no hacerlo
Este texto hace pensar si fue escrito por una IA
En esencia, MCP se parece bastante a JSON-RPC con algunos campos especiales obligatorios
Puede haber preocupaciones sobre JSON-RPC, pero sí hace falta una capa de descubrimiento de servicios con la que los modelos de lenguaje grandes puedan integrarse
Tiene que poder funcionar en varios lugares, como sitios web, aplicaciones de escritorio y servicios backend, y la CLI es solo uno de los puntos de contacto con ese tipo de sistemas
Sea cual sea el reemplazo de MCP, aunque cambie el protocolo de comunicación o los campos para descubrir herramientas, es muy probable que termine teniendo una forma parecida
- Cada vez que leo algo sobre MCP siento que todo internet, o todo HN, entra en una especie de histeria colectiva
  Dicen que una API es mejor que MCP, pero MCP no es más que una API con un poco de guía para que la IA pueda descubrir cómo usarla
  También dicen que hay que usar CLI, pero no sé exactamente qué quieren decir con eso
  Que los modelos de lenguaje grandes usen bien herramientas CLI comunes como ffmpeg se debe a que ese conocimiento ya quedó fijado en sus pesos
  Si creas una herramienta CLI nueva, igual tienes que enseñarle a la IA cómo usarla, y si quieres que esa parte de “enseñarle” la proporcione el servidor, eso es MCP; si quieres dejarlo en una forma estática local, eso es una skill
  No entiendo por qué hay tanta discusión sobre un concepto tan simple
- El problema es que MCP ocupa contexto de manera relativamente permanente y no viene acompañado de un sistema limpio de instalación/desinstalación y descubrimiento
  Las skills deberían estar todas basadas en MCP, cargarse solo cuando hagan falta, y poder ser administradas y descubiertas fácilmente tanto por personas como por IA para que realmente funcionen
  Viendo el alcance real de aplicación, el alcance inicial era demasiado estrecho, pero si se construye algo encima, todavía podría revivir
Respecto a la afirmación de que “Problema 1: se devora la ventana de contexto”, no veo en qué se diferencia de ejecutar linearcli --help, notioncli --help y slackcli --help uno tras otro
De hecho, en MCP el entorno de ejecución puede meter en el contexto solo el título de cada herramienta, y la documentación completa añadirla según haga falta por servidor MCP o por herramienta
Para lograr el mismo efecto con CLI, todas las CLI tendrían que ofrecer un comando como --short-descr
El “Problema 2: baja confiabilidad operativa” tampoco implica que MCP deba ser más lento si la herramienta usa una REST API, porque el protocolo es parecido
Si es más lento, probablemente sea un problema de implementación, como una capa MCP añadida encima de la API y montada en un servidor subcontratado en un centro de datos lejano
Puede que la mayoría de los servidores MCP estén hechos un desastre, pero eso es un problema de la industria, no del protocolo
El “Problema 3: se solapa con las CLI/API existentes” sí aplica cuando ya existe una herramienta CLI, y un servidor MCP para SQL o un MCP para curl sí parece un desperdicio de tokens
Pero en la mayoría de las organizaciones no hay CLI, y si la hay, normalmente solo existe una API diseñada para que la use un programa, no un modelo grande de lenguaje
Decir “ofrezcan primero CLI → API → documentación” suena como decir que, en vez de un sitio web lento y derrochador, la empresa primero debería ofrecer un cliente nativo de escritorio y otro cliente nativo móvil
- No he investigado esto a fondo, pero salvo la versión más reciente de Claude Code, entiendo que MCP se precarga en el contexto
  Si no se necesita con frecuencia, hay que apagarlo y volverlo a encender cuando haga falta
  Si pones ejemplos de uso en un archivo de skills, también podrías reducir la primera llamada a --help, y si es una CLI, parece fácil lanzar un subagente con contexto separado y recibir solo el resultado
El texto no tiene fecha, pero dice que la carga diferida de herramientas fue una actualización reciente posterior a la redacción
Sin embargo, la carga diferida de herramientas se añadió en noviembre de 2025: https://www.anthropic.com/engineering/advanced-tool-use
Así que estas cifras tienen al menos 7 meses, y no entiendo por qué esto salió ahora
- Sigue siendo raro que todavía se esté discutiendo esto
  Con carga diferida de herramientas, contextos grandes y caché de prompts, 2026 ya es completamente distinto de 2025
  La discusión de que la CLI ahorra tokens también se cae si el primer paso es ejecutar --help
  Si no recuerdas cómo invocarlo ni sus parámetros, el problema de que eso tenga que estar en el contexto sigue igual
- Más que eso, parece un texto todavía más viejo, e insinúa como si GPT-4o fuera lo más reciente
- La carga diferida de herramientas no es parte de MCP
  Es un parámetro exclusivo de la API de Claude que la mayoría de las demás API de modelos grandes de lenguaje no admiten
- El artículo es del 29 de mayo de 2026, y decir que esa actualización “reciente” ocurrió después del texto es una mentira para quedar mejor
Creo que había un muy buen artículo sobre cómo MCP encaja bien a nivel organizacional cuando necesitas dar a personal no técnico que usa herramientas internas de agentes un acceso unificado y seguro a APIs internas de utilidades
La idea sería codificar los flujos de trabajo como skills para compartirlos entre instancias, y dejar a MCP lo que requiera acceso a API con conciencia de contexto
- ¿Es este artículo? https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/
- Si es así, me da curiosidad cuál sería la ventaja de MCP frente a que el agente acceda directamente a la API
- Me pregunto si esto pretende sustituir un esquema de permisos que proteja la API
  De una forma u otra, la API igual tendría que tener algún mecanismo de permisos
- Es cierto
  Justamente por eso empresas como Runlayer están creciendo rápido, y sin un plano de control central MCP se vuelve un campo minado
Además de los puntos ya mencionados, MCP remoto tiene la ventaja de que, al estar controlado por el servidor, el productor puede agregar nuevas funciones sin tener que actualizar las skills ni las CLI de todos los clientes
Además, MCP remoto es más seguro porque no requiere permisos para ejecutar código real en el sistema local
Las skills suelen empaquetar scripts con npx/uvx, y eso en la práctica es tan riesgoso como curl npm.com | bash
Implementé skills para conectar equipos al sistema interno de gestión de la empresa, y al final terminé registrándolo como MCP
MCP solo expone grep de documentación y llamadas API, así que por sí solo es totalmente inútil, pero la razón principal para tomar esta ruta fue el despliegue
Los equipos no técnicos quieren una UI donde agregas una URL y todo funciona, con OAuth guiado, y MCP hace eso posible en Claude o ChatGPT
La forma en que se muestran las llamadas MCP en la UI de chat también es mejor y más clara para el usuario
En vez de lidiar con un servidor MCP y distribuir una CLI para todas las plataformas, me pregunto si no sería mejor exponer la API por SSH
SSH es un protocolo perfecto para los modelos grandes de lenguaje
Los agentes de código ya pueden usarlo, y con ssh api@example.com list-users bastaría
Es muy probable que el 90% de los usuarios ya tenga ssh instalado, y como tanto la entrada como la salida son texto, encaja perfecto con los modelos grandes de lenguaje
Se encarga de autenticación con clave pública, salida en streaming, entrada/salida interactiva e incluso transferencia de archivos vía scp/rsync si se quiere
Si el usuario conectó su cuenta a Github o GitLab, incluso podrías tomar sus claves ssh y dejar la autenticación preconfigurada para que solo se conecte y entre de inmediato
- Solo hay que imaginar esto escalado a toda la organización
La analogía del restaurante no es buena
Es algo como “hay 10 menús abiertos sobre la mesa y no queda espacio para poner la comida, y cada vez que pides algo hay que volver a sacar el menú”, pero repetir pedidos no es tan común salvo que sea un restaurante de tapas
La comida también puede ponerse sobre el menú, y normalmente después de pedir se retira el menú para despejar la mesa, es decir, el contexto
Si se va a explicar con una analogía, haría falta un esfuerzo por hacerla más relevante