Te enteras a fin de mes: alguna herramienta MCP se ejecutó unas cuarenta veces y cada llamada facturó créditos reales. Repasando la transcripción, se comportó exactamente como un lector de archivos gratuito: el mismo JSON de entrada, la misma línea de “listo” a la salida. Nada en la conversación te decía qué llamadas estaban gastando dinero.

Ese es el punto incómodo en el que está hoy el ecosistema MCP. La generación de imágenes, vídeo y 3D y las APIs de pago se distribuyen como servidores MCP, y un agente los ve igual que ve read_file. El PR #142470, fusionado el 21 de octubre de 2026, añade las dos piezas que faltaban: un coste declarado por herramienta y un presupuesto por chat.

Tres claves nuevas

Dentro de una entrada de mcp_servers en config.yaml:

mcp_servers:
  renders:
    command: "render-mcp"
    trust: untrusted
    tool_costs:
      create_image: 20                                    # about 20 credits per call
      animate: {credits: [5, 20], note: "per animation"}   # a range, with a short note
      get_status: 0                                        # free; same as leaving it out
    spend_limit: 100     # per chat; 0 or absent = no limit
    cost_unit: credits   # label in prompts (default: credits)

tool_costs acepta tres formas:

• un número no negativo, para un coste fijo;
• un rango [min, max], que encaja con herramientas cuyo precio depende de la resolución o la duración;
• un objeto con credits que contiene un número o un rango, más un note para una línea en lenguaje llano.

spend_limit es un techo por chat; 0 o ausente significa sin límite. cost_unit solo cambia el texto de los avisos y los totales (por defecto credits), de modo que un servicio facturado en “runs” o “points” pueda decirlo.

El aviso de aprobación se convierte en una factura

Antes de las declaraciones, un servidor con trust: untrusted preguntaba “¿permitir create_image?” antes de una llamada con capacidad de escritura. Con un coste declarado, ese mismo aviso dice:

Costs about 20 credits.

Un rango se muestra como Costs 5-20 credits (per animation). En cuanto el chat ha gastado algo en ese servidor, aparece una segunda línea:

This chat has used about 40 credits on 'renders' (limit 100).

El valor aquí es que la aprobación deja de ser solo una pregunta de seguridad y pasa a ser una pregunta de presupuesto. Ya no estás aprobando una acción: estás aprobando 20 créditos más.

Dónde se guarda el total acumulado

Estas reglas importan más que la configuración, porque deciden si confías en el número:

• Los totales se llevan por chat y por servidor; nada se arrastra entre chats.
• Solo cuentan las llamadas que realmente se despacharon. Las llamadas rechazadas o bloqueadas no suman nada.
• Los cargos usan la estimación declarada, y el valor alto del rango: el diseño prefiere preguntar antes de tiempo.
• Una llamada cuyo servidor muere antes de recibirla igual cuenta, por la misma razón.
• El recuento vive en memoria: es un presupuesto para una conversación, no la factura del proveedor. Reiniciar Hermes resetea todos los totales.
• El total sigue a la conversación a través de la compresión de contexto y de /branch. En la CLI, /new abre un total nuevo (igual que un chat nuevo en Desktop); en las plataformas de mensajería el total pertenece al chat, así que sobrevive a /new. Cada ejecución de cron tiene su propio total.

Qué pasa cuando se supera el presupuesto

Esta es la parte que conviene memorizar:

1. Pregunta incluso en un servidor con trust: full. Un servidor así normalmente ejecuta herramientas con coste sin aviso; en el momento en que una llamada cruzara spend_limit, se detiene y pregunta.
2. Pregunta cada vez. Elegir “permitir durante esta sesión” no silencia las siguientes llamadas con coste en ese chat.
3. Donde nadie puede responder, rechaza sin despachar. Los jobs de cron, hermes chat -q y un gateway sin aprobador caen todos aquí. El modelo recibe un error de herramienta que nombra el gasto y el límite y le dice que no reintente — no un fallo silencioso.
4. Por debajo del límite no cambia nada. trust: full sigue sin avisos, y las herramientas anotadas con readOnlyHint: true no se despiertan salvo que el presupuesto lo exija.

En otras palabras, spend_limit no es un acelerador. Es una puerta que dice “pasada esta línea, hace falta que alguien apruebe”.

Los paquetes portables también pueden declararlo

Un paquete de plugin portable lleva la misma tabla para su servidor dentro de plugin.json:

"extensions": {
  "com.nousresearch.hermes": {
    "servers": {
      "meshy": {
        "trust": "untrusted",
        "costs": { "meshy_remesh": 5, "meshy_animate": { "credits": [5, 20], "note": "per animation" } },
        "spend_limit": 100,
        "cost_unit": "credits"
      }
    }
  }
}

Eso resuelve una asimetría real: el autor del plugin sabe exactamente cuánto cuesta una herramienta, y el usuario normalmente no. Las claves costs / spend_limit / cost_unit del paquete se traducen a las claves nativas.

Cinco trampas

1. Una tabla de costes mal formada deja fuera al servidor entero, en lugar de ignorarse. Cualquiera de las tres claves con la forma equivocada impide que ese servidor cargue y el error nombra la clave. Es deliberado: una errata no debe hacer desaparecer tu presupuesto en silencio.
2. Las claves de tool_costs deben ser los nombres de herramienta del propio servidor, no el prefijo de visualización de Hermes mcp_<server>_. Una clave equivocada no falla: imprime un aviso al conectar, fácil de pasar por alto.
3. Herencia al sobrescribir por mismo nombre: si añades tu propia entrada mcp_servers para el mismo servidor (por ejemplo, para subirlo a trust: full), las claves de coste del paquete siguen aplicándose salvo que tu entrada las fije. spend_limit: 0 desactiva el límite del paquete; tool_costs: {} descarta sus costes.
4. Es un presupuesto, no una factura. La facturación del proveedor puede no coincidir con lo declarado, y los totales se resetean al reiniciar. No lo tomes como contabilidad.
5. hermes plugins validate lista server costs: <name>. Revisa esa línea antes de instalar, en vez de reconstruir el gasto a partir de una transcripción después.

¿Puedes usarlo hoy?

La función está en main y no en la v0.22.4 ya publicada — el rango de comparación v0.22.3→v0.22.4 contiene 14 commits y esta función no es uno de ellos. Las instalaciones de producción esperan a la próxima release; los checkouts de código que siguen main pueden probarla ya.

El crédito del diseño es de un proyecto de la comunidad, Adolanium/hermes-tripo, que implementó “cada crédito, consultado” y “un límite por chat” con un hook nativo pre_tool_call. Los paquetes portables no pueden traer hooks, así que esto aterrizó como una función del núcleo guiada por datos declarados — lo que también significa que plugins oficiales como el de Meshy pueden usarla.

Si todavía estás decidiendo qué servidores merecen trust: full, nuestra guía de seguridad del catálogo MCP cubre los niveles de trust. Las declaraciones de coste y los niveles de trust responden a preguntas distintas; funcionan mejor juntas.