Un artículo reabre el debate sobre MCP: contexto inflado e impuesto de tokens
La crítica sostiene que el Model Context Protocol se diseñó para los modelos de 2024 y que hoy encarece cada llamada. En Hacker News hay más de cien comentarios y ningún acuerdo.
El Model Context Protocol (MCP) vuelve al centro de la discusión. Un artículo de blog sostiene que el protocolo se pensó para los modelos de 2024 y que hoy se traduce en contexto inflado y en un sobrecoste de tokens, y la discusión ha aterrizado en Hacker News con alrededor de 165 puntos y más de cien comentarios en unas trece horas. En X circulan tanto apoyos como réplicas. No hay cambio de especificación ni un benchmark detrás: la crítica es arquitectónica y habla de lo que cuesta operar un agente, no de una versión nueva.
Dónde está el desacuerdo
Un lado sostiene que cada definición de herramienta —nombre, descripción y esquema JSON— se inyecta en el prompt en cada turno. Conectas tres servidores MCP al mismo agente y el prompt de sistema engorda, el modelo tiene más opciones entre las que elegir y pierde precisión, y las mismas definiciones se pagan una y otra vez. De ahí el "arráncalo y usa una CLI directa" que se repite en el hilo.
El otro lado defiende MCP por control y auditoría. Para agentes que no tienen acceso completo al shell, un protocolo con límites de herramienta explícitos es más fácil de revisar y de confinar que soltarle un terminal al modelo. No es un argumento de velocidad, es de superficie de ataque y trazabilidad.
Lo que nadie discute en el hilo es que las herramientas consumen contexto ni que el contexto cuesta dinero. Lo que se discute es el tipo de cambio.
Antes de decidir, mide
No hace falta resolver el debate para actuar sobre él. Los pasos son de aplicación, no de protocolo.
Primero, cuenta. Vuelca tus definiciones de herramientas y tu prompt de sistema a un fichero y pásalos por un tokenizador. Si no tienes uno a mano, dividir el número de caracteres entre cuatro da una estimación, mala pero honesta mientras no midas de verdad. Hazlo servidor por servidor: si uno aporta la mayor parte del contexto y se usa en pocos turnos, es el primer candidato a cargarse de forma condicional.
Segundo, carga por tarea. La mayoría de los agentes no necesita todas las herramientas en todos los turnos. Separa el conjunto por pasos —leer, escribir, consultar— y adjunta solo el subconjunto que toca. Funciona con MCP y sin él, y no obliga a renunciar a los límites: mantén una lista blanca y registra cada llamada.
Y tercero, mira el coste que no se ve. Añadir un segundo proveedor para clasificar con un modelo barato implica otra cuenta, otra clave, otro SDK y otros límites de tasa. Cuando cambiar de modelo cuesta una migración, el sobrecoste del protocolo deja de ser el problema grande: es el que te impide experimentar.
El debate no se va a cerrar en un hilo de Hacker News, y probablemente no haya una respuesta única. Algunos agentes necesitan límites auditables; otros solo necesitan un bucle rápido sobre dos funciones. La decisión es por agente, no por equipo entero. Lo que falta es que alguien publique números comparables de contexto y de factura en lugar de argumentos, y hasta entonces lo razonable es medir el propio.
