Se volvió a medir el impuesto por tokens MCP: dos descripciones de herramientas causaron el aumento.

Entre el 9 y el 22 de septiembre de 2026, las definiciones combinadas de herramientas de nueve servidores MCP populares aumentaron de 36,320 a 38,738 tokens. Eso representa un incremento de 2,418, es decir, el 6.7%, y un solo servidor aportó 2,094 de esos tokens. La cantidad de herramientas apenas cambió, pasando de 108 a 109. Lo que sí aumentó fue la longitud del texto que describe las herramientas ya existentes.

Los números clave

Una nueva medición con un script idéntico, realizada trece días después de la primera, arrojó los siguientes resultados:

• El bloque de herramientas de los nueve servidores aumentó en 2,418 tokens, lo que supone un incremento del 6.7%.
• firecrawl-mcp pasó de la versión 3.24.0 a 3.25.2 y mantuvo exactamente 27 herramientas, pero aportó 2,094 tokens.
• Dentro de ese servidor, 2,225 tokens provinieron de definiciones más extensas de herramientas que ya estaban presentes. Dos herramientas fueron retiradas y otras dos se añadieron, lo que supuso un cambio neto de menos 131. El equilibrio entre los documentos es exacto: 892 se añadieron, 1,023 se eliminaron y 2,225 aumentaron.
• Dos herramientas fueron responsables de casi todo el aumento. firecrawl_scrape y firecrawl_search explican 2,108 de los 2,225 tokens, y solo la descripción de firecrawl_scrape pasó de 1,110 caracteres a 4,458.
• El costo está concentrado. notion-mcp-server pesa 17,409 tokens (44.9%) y firecrawl-mcp 11,088 (28.6%). Juntos representan el 73.5% del total, mientras que los otros siete servidores se reparten el 26.5% restante.
• Cinco servidores no publicaron ninguna actualización durante ese período, y se volvieron a analizar para obtener cifras idénticas a nivel de bytes. Ese resultado invariable sirve como control y es la razón por la cual se puede confiar en la diferencia.

Por qué esta pregunta es importante ahora

Últimamente ha habido críticas fuertes contra MCP, y una queja central es que los servidores inflan silenciosamente el contexto que lleva consigo un agente. Ya existía un punto de referencia del 9 de septiembre, que abarcaba nueve servidores, 108 herramientas y 36,320 tokens, por lo que se podría repetir la misma prueba el 22 de septiembre. Actualmente, el conjunto cuesta 38,738 tokens, y casi todo el aumento proviene de un servidor cuyo número de herramientas se mantuvo estable porque sus descripciones existentes se alargaron. Esa es la afirmación de los críticos, respaldada por cifras y un método publicado.

Qué es el impuesto por tokens

El impuesto por tokens es el presupuesto de contexto consumido por las definiciones de herramientas antes de que el usuario escriba algo. Cada servidor conectado responde a una llamada a tools/list, y esa respuesta se incluye en el prompt del modelo. En los nueve servidores populares bajo observación, la cantidad total fue de 38,738 tokens el 22 de septiembre de 2026, en comparación con 36,320 el 9 de septiembre. En un período de 200K, ya se ha utilizado aproximadamente el 19% antes del primer mensaje, cantidad que un desarrollador podría haber instalado fácilmente.

Instantánea tomada el 22 de septiembre de 2026 a las 18:29 UTC: 9 servidores, 109 herramientas y 38,738 tokens. Para reproducirla, analice cada especificación de paquete npm y luego cuente los nombres estrictos, las descripciones y los datos de inputSchema utilizando el tokenizador o200k_base.

Cómo funciona la medición

Cada servidor se inició mediante stdio a través de npx. El procedimiento envía “initialize”, luego “tools/list”, y almacena la respuesta en bruto. De cada herramienta solo se conservan los tres campos que realmente recibe la API de uso de herramientas: nombre, descripción e inputSchema. El objeto se normaliza con claves ordenadas, las herramientas se ordenan por nombre, y el resultado serializado se cuenta con o200k_base. La ejecución del 9 de septiembre utilizó esta misma definición estricta, y cada servidor se probó con su versión más reciente publicada el 22 de septiembre de 2026.

Se examina el servidor en ejecución en lugar de leer su código fuente, y la diferencia es real. Varios servidores compilan su lista de herramientas en tiempo de ejecución, ocultando herramientas detrás de una marca o generando una descripción a partir de un modelo. Por lo tanto, el array al que accede un modelo puede diferir del que se encuentra en el repositorio, y leer el código fuente proporcionaría un número creíble que ningún modelo llega a ver. La inspección del servidor también tiene sus limitaciones: un servidor que requiere credenciales puede mostrar a un cliente no autenticado una lista más corta que la que muestra a un usuario conectado. Las nueve instancias devolvieron esta vez una lista completa, pero el método no puede descartar esa posibilidad en general.

Por qué es creíble una diferencia de trece días

Cinco servidores no publicaron nada durante el período, por lo que sirven como control interno. Se trataba del servidor de sistema de archivos, el servidor de memoria, el exa-mcp-server, el tavily-mcp y el servidor de pensamiento secuencial, y todos volvieron a sus valores de referencia exactos: 1,668, 907, 415, 1,666 y 867 tokens respectivamente. No cerca de ellos, sino exactamente en esos valores. Una sonda o tokenizador con desviaciones habría alterado a los cinco, por lo que todo el aumento de 2,418 se debe a los cuatro servidores que sí publicaron datos.

El servidor responsable

firecrawl-mcp, con tres lanzamientos del 12 de agosto al 22 de septiembre, es la fuente de 2,094 tokens adicionales. @playwright/mcp aportó 324 a través de dos lanzamientos más una herramienta nueva. Se lanzaron además dos servidores más: @upstash/context7-mcp (dos lanzamientos) y @notionhq/notion-mcp-server (uno), y el tamaño de sus bloques de herramientas se mantuvo exactamente igual. Publicar código y cambiar lo que se transmite por la red no es lo mismo, y lo segundo ocurre solo de vez en cuando.

¿Más capaz, o simplemente más pesado?

En su mayoría, solo son más pesados, hecho que falta en gran parte del debate. firecrawl-mcp tenía 27 herramientas antes y 27 después. Intercambió dos herramientas por otras dos, un cambio que supuso una pérdida de 131 tokens. Los 2,225 adicionales provinieron de que las herramientas ya existentes obtuvieron descripciones más largas y esquemas de entrada más extensos para las mismas capacidades. Los usuarios pagaron 2,225 tokens más por las mismas veinticinco herramientas que ya poseían.

Los dos cambios más significativos merecen cifras precisas. firecrawl_scrape ganó 721 tokens de descripción y 462 tokens de esquema. firecrawl_search ganó 691 y 234. En total, eso suma 2,108 de los 2,225. Otras siete herramientas restantes solo cambiaron en 117 tokens en total, y dieciséis no cambiaron en absoluto. La situación no refleja un ecosistema en constante mejora, sino dos definiciones de herramientas reescritas en profundidad.

Si esto se considera desperdicio depende de algo que no se midió. Una descripción más larga suele ser una reparación legítima: se aclara qué herramienta el modelo seguía utilizando incorrectamente, y los tokens garantizan fiabilidad. Sin embargo, 4,458 caracteres es aproximadamente la longitud de una sección completa de prosa, asociada a una función y transmitida con cada solicitud. El costo sí se midió adecuadamente. El beneficio, en cambio, sigue siendo desconocido.

A dónde van realmente los tokens

El patrón es la concentración y no la amplitud. Clasificados por su participación en los 38,738 totales:

• El servidor de Notion lidera con una gran ventaja, con 17,409 tokens, el 44.9% del total, distribuidos en 24 herramientas.
• Firecrawl ocupa el segundo lugar con 27 herramientas y 11,088 tokens (28.6%).
• Playwright sigue con 3,734 tokens, el 9.6%, para 25 herramientas.
• El servidor de sistema de archivos de referencia utiliza 1,668 tokens (4.3%) para 14 herramientas, mientras que Tavily emplea 1,666 (también 4.3%) para solo 5.
• Context7 consume 984 tokens (2.5%) en 2 herramientas, el servidor de memoria 907 (2.3%) en 9 herramientas, y sequential-thinking 867 (2.2%) para una sola herramienta.
• Exa es el más ligero, con 415 tokens o 1.1%, y 2 herramientas.

La cantidad de herramientas predice mal el costo. @playwright/mcp ofrece 25 herramientas por 3,734 tokens, mientras que notion-mcp-server ofrece 24 por 17,409. La cantidad de herramientas es casi igual, pero la factura es 4.7 veces mayor.

Para quienes tienen más de dos o tres servidores, la pregunta relevante es cuáles de ellos son de tipo Notion.

¿Es correcta la crítica?

Sobre esta afirmación, en esta muestra y en este contexto, sí, aunque el mecanismo es más restringido de lo que suele implicar el debate. El costo está aumentando, lo hace sin nuevas capacidades, y se concentra en unos pocos servidores en lugar de estar distribuido por todo el ecosistema. La acusación común de que MCP como protocolo es inherentemente engorroso no se corresponde con lo que muestran los datos. Lo que indican los datos es que la documentación proporcionada por dos proveedores constituye la mayor parte del costo total.

Límites de la evidencia

• No se observa ninguna tendencia. Dos puntos separados por trece días solo forman una diferencia, no una trayectoria, y uno de ellos está determinado por el lanzamiento de un único proveedor. Un mes tranquilo daría un número estable o negativo, sin que el problema desaparezca.
• La muestra no representa a MCP en su totalidad. Estos nueve servidores fueron seleccionados en una ronda anterior porque están ampliamente instalados y pueden ser inspeccionados sin credenciales. Existen miles de servidores y nadie cuenta con una lista fiable de ellos.
• No se han modelado los agentes reales. Nadie se conecta exactamente a estos nueve, por lo que 38,738 describe una estructura definida para el ejercicio y no una factura que alguien pague. La parte reutilizable es el método, que puede ejecutarse en cualquier conjunto personal de servidores.
• El valor no está medido. La descripción de firecrawl_scrape cuadruplicó en longitud, pero para determinar si el modelo ahora la llama correctamente con mayor frecuencia se necesita un conjunto de pruebas, lo cual constituye un experimento distinto.

Revisión del primer borrador del número

El primer intento utilizó una serialización ingenua, devolviendo todo el objeto de la herramienta. Para el corpus del 9 de septiembre, esto arrojó 40,480 tokens, frente a los 36,320 ya publicados. La diferencia no se debió a un cambio en los servidores, sino a campos adicionales que el método publicado omite deliberadamente.

Al repetir la ejecución con la definición estricta archivada, se obtuvieron 108 herramientas y 36,320 tokens por unidad, de ahí el control mencionado anteriormente. Comparar dos métodos diferentes genera un artefacto, no una medida real, y en este caso el artefacto habría inflado el cambio en un 6.5% en la dirección más llamativa.

La misma precaución aplica a trabajos anteriores sobre este tema. Un artículo anterior informó 38,900 tokens para nueve servidores MCP, pero esa cifra provino de una ejecución diferente cuyo método no se volvió a verificar, por lo que no constituye la referencia aquí. El valor de 38,738 no representa una disminución con respecto a 38,900. La única pareja que se puede restar honestamente es 36,320 y 38,738, ya que un mismo script generó ambos valores.

Preguntas frecuentes

¿Qué se considera como costo por tokens? Todo lo que el cliente proporciona al modelo sobre las herramientas antes de que comience cualquier conversación: en la práctica, las respuestas de las herramientas/lista de cada servidor se reducen al nombre, descripción y esquema de entrada. Cada solicitud en una sesión incluye este costo, a menos que el cliente almacene en caché el prefijo, y se cobra incluso si no se utiliza ninguna herramienta.

¿El caché de prompts lo hace gratuito? Más barato, no gratuito, y solo mientras el prefijo no cambie. Al analizar 96 versiones en estos nueve servidores, el 48% de las transiciones de versión modificó el bloque de herramientas que abre un prefijo en caché. Las versiones frecuentes implican una invalidación frecuente del caché.

¿Por qué es tan costoso notion-mcp-server? Sus 24 herramientas cuentan con esquemas de entrada que describen una amplia superficie de API, y el bloque de herramientas no ha sido modificado desde julio. No hay crecimiento alguno. Empezó alto y se mantuvo allí, lo cual es un problema distinto a los servidores económicos pero con alto tráfico y requiere una respuesta diferente.

¿Se pueden apagar las herramientas que no se utilizan? Algunos clientes permiten filtrar las herramientas de un servidor, y con estos datos esa es la opción más efectiva disponible, ya que eliminar los dos servidores más costosos reduciría la infraestructura en un 73,5%. El soporte al cliente varía, por lo que es sensato verificarlo antes de instalar otro servidor.

¿Se considera alto un 6,7% en menos de dos semanas? Si se proyecta a un año, podría sonar alarmante, pero hacer estimaciones a partir de solo dos puntos de datos es engañoso. Lo que ocurrió fue que, en un período de dos semanas, un lanzamiento de un proveedor añadió 2.094 tokens a una infraestructura formada por nueve servidores sin ninguna nueva funcionalidad.

Una verificación que vale la pena hacer hoy

Abra la configuración MCP del agente, cuente los servidores y encuentre el de mayor tamaño. ¿Aumentaron las descripciones de sus herramientas la última vez que se actualizó, y se habría notado ese cambio? También queda una pregunta sin responder: cuántos tokens envía realmente un cliente cuando afirma filtrar las herramientas de un servidor, una cifra que aquí se asume pero que nunca se verifica.

Leer más

• Las dos formas en que fallan los servidores MCP y una capa de protección para evitarlo — Los tokens demasiado amplios y un diseño de herramientas que no tiene en cuenta las tareas son la causa principal de los fallos en MCP. Los tokens con alcance definido, las verificaciones de audiencia, los errores sanitizados y los límites en las herramientas ayudan a solucionar este problema.
• Desplegando un servidor MCP en EC2 tras el cambio en la especificación stateless — Mueva un servidor MCP local a EC2 utilizando HTTP con transmisión en flujo, nginx y autenticación por token, y luego comprenda qué significan las sesiones stateless y OAuth 2.1 en despliegues reales.
• Un motor de conocimiento web a MCP: registros de fuentes, dos revisores y integración de privacidad — Cómo un registro de fuentes, almacenamiento basado en persistencia, un equipo editorial con dos revisores y un servidor MCP de solo lectura convierten los cambios diarios en la web en una base de conocimiento fiable y segura desde el punto de vista de la privacidad.
• Conecta LM Studio a servidores MCP para archivos, GitHub y un navegador — Configuraciones paso a paso de mcp.json que permiten a un modelo local utilizar el sistema de archivos, las herramientas OAuth de GitHub y Playwright, con selección de modelos y soluciones para errores comunes.
• Notas prácticas: Uso de k6 y Grafana MCP para pruebas de rendimiento impulsadas por IA — Guía detallada de las Notas prácticas: Uso de k6 y Grafana MCP para pruebas de rendimiento impulsadas por IA: contratos, verificaciones y espacios de código listos para usar para los equipos que implementan este patrón.