1. 1 - mcp-savings, dos números que nunca se suman.
2. 2 - Dos números, deliberadamente nunca sumados.
3. 3 - Qué mide, y con qué unidad.
4. 4 - Lo que se negó a estimar.
5. 5 - ”Por petición” significa contexto ocupado, no dinero facturado.
6. 6 - Cómo atribuye una herramienta a su servidor.
7. 7 - Servidores detrás de OAuth: se miden, no se saltan.
8. 8 - Claude Code, sin instalar nada.
9. 9 - El panel lateral en OpenCode.
10. 10 - La CLI.
11. 11 - El hallazgo que decidió el diseño.
12. 12 - Y por qué acabó siendo superado.
13. 13 - Entonces, ¿sirve para algo hoy?
14. 14 - Lo que dejó como herencia.

mcp-savings, dos números que nunca se suman.

mcp-savings fue el primer intento de responder a la pregunta de cuánto cuestan los servidores MCP. Llegó antes que OxideGate, y ataca el problema desde el lado contrario: en lugar de mirar el cable, lee la configuración del propio agente.

Voy a contarlo entero, incluida la parte donde acabó siendo superado. Porque las decisiones que tomó siguen siendo buenas decisiones, y el motivo por el que se quedó corto es de los aprendizajes más útiles de todo el proyecto.

Dos números, deliberadamente nunca sumados.

La idea central de la herramienta cabe en una frase:

• PAY — lo que tus servidores MCP actualmente conectados añaden a cada petición.
• SAVED — lo que los servidores que ya apagaste han dejado de costarte.

Y una regla:

Su suma es una cifra mayor y más impresionante que no describe nada sobre lo que puedas actuar: no puedes ahorrar lo que todavía estás pagando, y no estás pagando lo que ya apagaste.

Parece una tontería hasta que ves cuántas herramientas de ahorro hacen exactamente eso. Sumar lo gastado y lo ahorrado da un número grande, queda bien en una captura de pantalla y no significa absolutamente nada.

Aquí van separados, siempre. La disciplina se llamó “contabilidad honesta” y condicionó todo lo demás.

Qué mide, y con qué unidad.

Aquí hay un detalle que distingue esta herramienta de casi todo lo que hay alrededor: usa dos unidades distintas y no las convierte entre sí.

Los tokens de sesión son reales y medidos. Vienen directamente de la contabilidad de uso del propio proveedor, reenviada por el agente. Nada se estima ni se adivina.

El peso de un esquema es una medida local y sin tokenizar. Es la longitud en bytes UTF-8 de cada definición de herramienta serializada. Es un proxy de cuánto texto cuesta describir esa herramienta. No es un recuento de tokens y no es una cantidad de dinero. Los bytes nunca se convierten en tokens en ningún punto del código.

Y un detalle que parece menor y no lo es: son bytes UTF-8, no unidades de código UTF-16. Es decir, no se usa la longitud que devuelve el propio lenguaje sobre una cadena. Las dos cifras dejan de coincidir en el momento en que una descripción lleva un acento — y las descripciones de herramientas llevan acentos.

Lo que se negó a estimar.

Esta parte es la que más me gusta de la herramienta.

Los tokens por servidor solo son exactos para modelos de OpenAI. No existe un tokenizador público y offline para Claude. Así que en lugar de aproximar con un tokenizador ajeno o con la regla de los cuatro caracteres por token, la función devuelve null.

Y en toda la salida, n/a significa “no hay un tokenizador local exacto”. Nunca significa “cero”.

Es la misma disciplina que atraviesa las otras dos herramientas, aplicada aquí a la tentación más grande de todas: dar un número aproximado porque queda mejor que un hueco.

”Por petición” significa contexto ocupado, no dinero facturado.

Un matiz que la documentación repite y conviene entender bien.

El esquema de una herramienta se sienta en la ventana de contexto de cada petición, y eso es lo que estos números dimensionan. Pero con el prompt caching, normalmente se escribe una vez y después se lee barato. Y una lectura de caché no se tarifa como input fresco.

Así que 17.000 tokens por petición son 17.000 tokens de tu ventana de contexto cada vez, pero no 17.000 tokens de input nuevo cada vez.

La distancia entre las dos cosas se ve en una sesión real medida: 105,4 millones de tokens leídos de caché contra 586,1 mil escritos.

Y por eso nada de esto se convierte en un coste. Deliberadamente. Solo la tarifa de tu proveedor puede hacer esa conversión de forma honesta.

Cómo atribuye una herramienta a su servidor.

Con una heurística de prefijo: se compara el identificador de una herramienta contra los patrones mcp__<servidor>__<herramienta> y mcp_<servidor>_<herramienta>.

Las formas más laxas, como un simple <servidor>_<herramienta>, no se aceptan a propósito. Y hay una medición detrás de esa decisión.

Contra la lista real de herramientas de un agente, un servidor llamado delegation capturaba las herramientas nativas delegation_read y delegation_list, que no eran suyas, y se le acreditaban 633 bytes que no cuesta.

Las formas laxas no tenían ni un solo caso confirmado donde ayudasen, y un caso medido donde perjudicaban. Se quitaron.

Servidores detrás de OAuth: se miden, no se saltan.

Un servidor remoto protegido por OAuth es un problema incómodo: si no puedes conectarte, no puedes pesarlo.

La solución fue reutilizar el token que el propio agente ya guardó. Un servidor que el usuario ya autorizó se lee de las credenciales del agente y su token se envía con la petición de medición.

Con tres límites explícitos: nunca ejecuta un flujo de autorización, nunca refresca un token y nunca escribe en ese archivo. Solo lee.

Y un servidor que no ha sido autorizado se reporta como error, en lugar de contarse silenciosamente como gratis.

Por qué importa tanto: un servidor que no se puede medir no cuenta ni para PAY ni para SAVED, así que su esquema desaparece del reporte sin dejar rastro. En un caso real, eso escondía 51,6 kB de los 73,7 kB que de verdad se estaban enviando. El 70% del coste, invisible.

Un reporte que se calla el 70% del problema es peor que no tener reporte.

Claude Code, sin instalar nada.

Este es el modo que mejor funciona, y funciona porque Claude Code deja todo en disco.

Los servidores MCP se leen de dos sitios, y los dos se respetan:

• Un archivo por servidor añadido por el usuario, donde el nombre del archivo es el nombre del servidor.
• La configuración de los plugins instalados. Y el servidor de un plugin cuenta como activo solo mientras el plugin esté habilitado, que es justo lo que hace que un plugin apagado aparezca como un ahorro realizado en lugar de simplemente desaparecer del reporte.

El comando de reporte también lee el uso real de tokens de sesión, de las transcripciones que Claude Code escribe por sesión.

Con un matiz declarado: la palabra es ACTIVAS. Claude Code no deja ninguna marca en disco de “sesión abierta”, así que se cuentan las sesiones escritas en los últimos 30 minutos. Una sesión abierta y ociosa más allá de ese margen se cae del recuento.

Está dicho en la documentación en lugar de dejar que lo descubras cuando los números no cuadren.

El panel lateral en OpenCode.

El adaptador de OpenCode escribe una instantánea que el plugin de interfaz lee y pinta como un panel compacto:

◢ MCP cost/request
Active 3.8K tok · 1 ON
Saved  975 tok
ON  ▇▇▇▇▇▇▇▇ engram 3.8K
OFF context7 saves 975
Session: 13.9K in · 9 out

Cuatro líneas y cuatro conceptos distintos, sin mezclar:

• Active es lo que los servidores conectados añaden por petición.
• Saved es el ahorro realizado de los que están apagados.
• ON/OFF viene del estado en vivo del agente, no de la configuración estática.
• Session es el uso reportado por el proveedor, que es una métrica diferente del coste de esquema por petición.

Y una regla de la que no se sale: solo el interruptor propio del agente mueve un servidor entre PAY y SAVED, porque solo eso detiene de verdad el envío de su esquema. Cambiar el flag interno de mcp-savings no cambia la cifra de SAVED.

Es la diferencia entre “he marcado esto como desactivado en mi herramienta” y “esto ha dejado de viajar”.

La CLI.

mcp-savings report            Tokens de sesión, servidores MCP, nativas del host
  --host <host>               opencode (por defecto) o claude-code
  --config <ruta>             Ruta de configuración del host
mcp-savings measure           Conecta con cada servidor MCP y lo pesa
  --host <host>               opencode (por defecto) o claude-code
  --model <modelo>            Modelo contra el que tokenizar
mcp-savings list              Lista servidores configurados y sus flags
mcp-savings disable <server>  Marca un servidor como desactivado por defecto
mcp-savings enable <server>   Quita esa marca

Con una advertencia honesta sobre measure: arranca brevemente los servidores que tienes desactivados, porque medir uno es la única forma de saber qué te ahorró apagarlo.

Podría no hacerlo y dejar esos servidores fuera del reporte. Sería menos invasivo y daría un SAVED de cero para todo lo apagado, que es exactamente el número inútil que la herramienta existe para no dar.

El hallazgo que decidió el diseño.

Aquí hay una medición que explica por qué la herramienta hace algo aparentemente redundante: conectarse ella misma a cada servidor MCP.

Verificado contra una instalación real de OpenCode, con dos servidores MCP los dos reportando como conectados:

• El endpoint de herramientas del agente devolvía 15 herramientas, y el de identificadores devolvía 18. Ni una sola venía de un servidor MCP.
• Una conexión MCP directa a esos mismos dos servidores encontró 20 herramientas, unos 22 kB de esquema.

Es decir: el agente no expone los esquemas MCP a través de su propia API.

Por eso measure se conecta a cada servidor por su cuenta, como un cliente MCP normal, y por eso la lista de herramientas del host se reporta por separado, como herramientas propias y de plugins. Si tu tabla de MCP sale vacía y la de nativas no, la razón es esta y no un bug.

Y por qué acabó siendo superado.

Llegamos a la parte incómoda, que va aquí porque contarla es más útil que esconderla.

mcp-savings mide desde el host: lee configuración, se conecta a los servidores y pesa sus esquemas. OxideGate mide en el cable: ve el cuerpo real de la petición, ya serializado, justo antes de salir.

Y esas dos cosas pueden contradecirse.

El host te dice qué servidores están configurados y qué esquemas declaran. El cable te dice qué llegó de verdad. Entre las dos hay un harness que puede diferir cosas, reordenarlas, no enviarlas o enviarlas dos veces. Cuando el host y el cable no coinciden, tienes dos números y ninguna autoridad para decidir cuál vale.

Esa fue la trampa. Y la salida no fue mejorar la heurística del host: fue mover el punto de medida y establecer una regla arquitectónica que ya vimos en el capítulo anterior:

Si un número no salió del proxy, no existe.

Una sola fuente de verdad, y todas las demás herramientas leyendo de ella. Así, un desacuerdo entre dos vistas es siempre un bug de presentación, nunca dos mediciones compitiendo.

Entonces, ¿sirve para algo hoy?

Sí, y en un escenario concreto: cuando no puedes o no quieres meter un proxy en medio.

• El modo de Claude Code no necesita instalar nada ni redirigir tráfico: lee lo que ya está en disco. Para un vistazo rápido al inventario, es el camino más corto.
• El panel lateral de OpenCode enseña el coste mientras trabajas, sin cambiar de ventana.
• El desglose PAY / SAVED sigue siendo la forma más clara de presentar el inventario de servidores, y esa idea sobrevivió entera al cambio de arquitectura.
• Y si te preocupa que el propio proxy contamine la medición —cosa que ya vimos que ocurre con los esquemas diferidos—, medir desde el host es la comprobación cruzada.

Lo que no deberías hacer es tratar sus bytes como la verdad sobre lo que viaja. Para eso está el cable.

Lo que dejó como herencia.

Tres ideas que sobrevivieron y hoy están en las otras dos herramientas:

1. Dos números que no se suman. PAY y SAVED separados es hoy la forma de presentar cualquier ahorro en todo el ecosistema.
2. Ausente no es cero. El n/a que significa “no hay tokenizador” y nunca “ninguno” es exactamente el mismo principio que hace que la lente distinga “no pude leer tu configuración” de “tienes 0 servidores”.
3. Medir contra servidores reales. Los tests corren contra servidores MCP de verdad, no contra simulacros. Las fixtures incluyen uno por stdio, uno que nombra su única herramienta a partir de una variable de entorno —para que una variable perdida se haga visible— y uno tras un 401 auténtico.

Esa última decisión, la de no simular lo que se puede ejecutar, es la que hizo posible el hallazgo de las 15 herramientas contra las 20. Un test con simulacros habría pasado en verde y no habría enseñado nada.

En el capítulo final juntamos las tres piezas y vemos cuándo usar cada una, qué queda sin medir y cómo escribir tu propia lente si ninguna de estas te encaja.