Coste de MCP medido: 26 tools, $0.03 por llamada

Conectar un servidor MCP al agente añade un coste por llamada antes de que ocurra nada: los 26 tools del servidor de GitHub cuestan $0.0302 en cada llamada a Claude Opus 4.8, se use alguno o no. El mecanismo pasa desapercibido hasta que se consulta el consumo. Además, el tamaño depende más del modelo que de cuántos tools se conecten, y la mayor parte del coste puede recuperarse. Medimos toda la cadena: cinco familias de modelos, cinco servidores MCP reales, series sintéticas de 0 a 40 tools y las opciones de caching y reducción que permiten rebajar la factura.

TL;DR

• Las definiciones de los tools vuelven a facturarse como tokens de entrada en cada llamada a la API; un tool pequeño consumió 401 tokens en Claude Opus 4.8.
• El mismo conjunto de tools consume 2.7x más tokens en Claude que en GPT-5.6 (173 frente a 64 por tool en nuestras mediciones).
• El servidor MCP real de GitHub (26 tools) cuesta $0.0302 por llamada en Opus 4.8, frente a $0.0029 en Gemini 3.6 Flash: una diferencia de 10x.
• El caching explícito reduce el bloque transportado a una décima parte, pero los conjuntos que no llegan al mínimo no pueden cachearse y modificar un solo tool obliga a volver a facturar el bloque completo.

¿Cómo convierte un servidor MCP sus tools en tokens de entrada?

El proceso consta de tres etapas. Solo la última cuesta dinero, pero se repite en cada llamada. Primero hay que acotar el problema: los servidores MCP exponen tres primitivas, tools, recursos y prompts. Solo los tools tienen un coste permanente, porque la API dispone de un parámetro tools que debe incluir todos los schemas en cada request. Los recursos y prompts no tienen un campo propio en la API; solo consumen tokens cuando su contenido se incorpora a la conversación. En la etapa 1, el cliente del agente solicita al servidor tools/list mediante JSON-RPC y recibe los schemas. Esto ocurre una vez por sesión y no interviene ningún modelo. En la etapa 2, el cliente convierte esos schemas al parámetro tools de la API y elimina campos exclusivos de MCP como annotations y outputSchema. Tampoco cuesta nada. En la etapa 3, el proveedor renderiza esos schemas como texto oculto del prompt en cada request, porque la API no conserva estado y el modelo no recuerda qué tools existen. Ese texto se factura a la tarifa completa de entrada en todas las llamadas, se use o no.

La demostración más sencilla es una request cuyo mensaje de usuario solo dice “Reply OK”. En Opus 4.8 cuesta 11 tokens de prompt. Al añadir un tool get_weather modesto, con dos parámetros y una descripción de una línea, la misma request pasa a costar 412 tokens. Ese único tool añade 401 tokens y $0.002 a cada llamada que lo incluya. Hay una diferencia importante respecto al contenido enviado: el JSON del tool contiene unos 130 tokens de texto, pero el renderizado del proveedor casi triplica esa cifra.

¿Cuánto cuesta un tool en cada modelo?

Depende mucho más del modelo de lo que la mayoría de los equipos espera. Enviamos conjuntos sintéticos idénticos de tools, con tres parámetros y descripciones de una línea, en series de 0 a 40 tools a cinco familias. Después medimos las diferencias facturadas:

Los mismos tools producen una diferencia de 2.7x: Claude genera el harness de tools más detallado del grupo y GPT-5.6, el más conciso. La relación con el JSON enviado tampoco es uniforme. Claude factura alrededor de 1.36x una estimación simple basada en dividir los bytes del payload entre cuatro, mientras que GPT-5.6 y Gemini facturan aproximadamente la mitad. El número de tokens de los bloques de tools no es transferible entre familias. El presupuesto debe calcularse por modelo, no por schema.

¿Cuánto cuestan por llamada los servidores MCP reales?

Esta tabla muestra cinco servidores reales sin modificar del repositorio oficial de MCP. Los convertimos con el mapeo estándar de campos y medimos su overhead por llamada:

La última fila deja dos conclusiones. Sequential-thinking expone un solo tool y aun así cuesta más que los nueve de Memory en cuatro de las cinco familias, porque su única descripción es enorme: el número de tools no es la métrica; importa el tamaño renderizado. La primera fila es la que suele sorprender a quienes crean agentes: mantener el conjunto de tools de GitHub durante un episodio de 10 llamadas cuesta $0.30 en Opus 4.8 y $0.03 en Gemini. Es un orden de magnitud completo antes de realizar trabajo alguno. GLM 5.2 cuesta todavía menos en dólares aunque facture más del doble de tokens que Gemini. Una tarifa base baja compensa un renderizador detallado, así que hay que presupuestar por separado los tokens y el coste en dólares.

¿Qué parte del conjunto de tools usan realmente los agentes?

En cada llamada se utiliza una fracción pequeña, y por eso el coste parece tan desproporcionado. En el escenario de tooling de nuestra suite de agentes, un conjunto de 8 tools se incluye en las tres llamadas de un episodio típico, aunque cada una invoca como máximo uno. Cada llamada paga ocho schemas para usar uno. Según las tarifas medidas en Opus 4.8, ese bloque de 8 tools supone unos 1,674 tokens por llamada, cerca de 5,000 tokens por episodio dedicados exclusivamente a transportar schemas. El escenario de tool loop es el caso favorable: tres tools utilizados en casi todas las llamadas. Incluso ahí, el bloque vuelve a enviarse en las cuatro o cinco llamadas del loop. Los registros muestran una regla general: rara vez se utiliza más de un tool por llamada. Por tanto, el coste por llamada depende de lo que se haya conectado, no de lo que el agente haga.

¿Puede el caching absorber el coste de los tools?

En los modelos adecuados, casi por completo, aunque medimos tres limitaciones importantes. En Claude Opus 4.8, el bloque de tools es un prefijo que puede cachearse directamente. Al marcar el último tool con cache_control, nuestro bloque de 20 tools se escribió una vez, 3,682 tokens con el recargo de escritura de 1.25x, y cada llamada posterior lo leyó a 0.1x. El coste efectivo de transportarlo cayó un 90%. El caching automático de Kimi K3 obtuvo un resultado aún mejor sin configuración: en la segunda llamada, 2,048 de los 2,112 tokens del bloque, un 97%, procedían de la caché, con sus habituales bloques de 256 tokens. En nuestras mediciones iniciales de esa familia, los breakpoints explícitos de GPT-5.6 aplicaron la misma estructura de precios: escrituras a 1.25x y lecturas a 0.1x. La caché implícita de Gemini, en línea con todo lo que hemos medido sobre ella, no produjo ningún hit en tres pruebas precargadas con el bloque de tools. Cualquier descuento en Gemini debe considerarse un ahorro eventual, no una base para planificar costes.

Estas son las limitaciones. La primera es el mínimo de caché: un bloque de 2 tools ocupa unos 655 tokens en Claude, por debajo del mínimo de 1,024 tokens. Los conjuntos pequeños no pueden cachearse aunque se marquen explícitamente; los mínimos de cada modelo determinan si esta opción está disponible. La segunda es la volatilidad: el bloque de tools se encuentra al principio del prompt, así que cambiar la lista invalida todo lo que viene después. Medimos el coste directamente: añadir un tool a un conjunto cacheado de 20 en Claude Opus 5 obligó a reescribir el bloque completo de 4,082 tokens con el recargo de escritura. La lista de tools debe permanecer fija durante la sesión; de lo contrario, cada cambio obliga a pagar la reescritura. La tercera es que la beta de Anthropic para cambiar tools durante una conversación, documentada para Opus 5, busca precisamente eliminar esa restricción. Permite modificar los tools entre turnos sin invalidar la caché y es la funcionalidad que conviene seguir para agentes con un uso intensivo de tools.

¿Cómo se reduce el propio bloque de tools?

Conviene recortar parámetros antes que texto descriptivo. En nuestro bloque de 20 tools, reducir las descripciones a una sola frase breve ahorró un 10%; pasar cada tool de tres parámetros a uno ahorró un 34%; aplicar ambas medidas ahorró un 44%, de 3,768 tokens a 2,128. Los tokens se concentran en los schemas de parámetros, incluidos nombres, tipos y descripciones anidadas. Esto contradice la tendencia habitual de pulir las descripciones mientras se permite que los schemas crezcan sin control.

La medida más efectiva es no conectar lo que no se vaya a utilizar. Cada servidor MCP añadido incorpora su bloque completo a todas las llamadas; una segunda línea de configuración puede duplicar el coste. Si el cliente permite filtrar, registrar solo una parte de los tools del servidor reduce el sobrecoste de forma aproximadamente proporcional. Si se conservan cinco de los 26 tools del servidor de GitHub, los $0.0302 de Opus 4.8 bajan a unos $0.007 según el tamaño medio de los tools de ese servidor. Si se ejecutan modelos de más de una familia, hay que tener presente la diferencia de 2.7x: trasladar el mismo agente de Gemini a Claude sin recalcular el presupuesto casi triplica los tokens dedicados a transportar tools.

Preguntas frecuentes

¿MCP añade por sí mismo algún coste de tokens?

No. El protocolo MCP, el discovery, JSON-RPC y la infraestructura para invocar tools no llegan al modelo y no generan ningún cargo. El coste aparece cuando el cliente envía los schemas del servidor mediante el parámetro tools de la API. El proveedor vuelve a renderizarlos como texto facturable del prompt en cada llamada. La aportación de MCP es la escala: permite conectar 26 tools con una sola línea, y esos 26 schemas acompañan después a todas las llamadas.

¿Los tools que no se usan también cuestan?

Sí, exactamente lo mismo que los usados. El modelo debe leer todos los schemas en cada llamada para saber cuáles puede invocar. Los registros de nuestra suite de agentes muestran como máximo un tool invocado por llamada, mientras que el conjunto completo se factura siempre. Un servidor conectado pero inactivo solo añade coste de transporte. El caching puede reducirlo, pero únicamente recortar el conjunto o desconectar el servidor permite eliminarlo.

¿Los recursos y prompts de MCP consumen tokens como los tools?

No. Los tools son los únicos que tienen un coste de transporte por llamada, porque el parámetro tools vuelve a enviar todos los schemas en cada request. Los recursos solo se facturan cuando el cliente lee uno e inserta su contenido en la conversación. En ese momento se convierte en una entrada normal, con el mismo precio que cualquier documento recuperado, y se aplica la misma disciplina por capas: el contenido volátil de los recursos debe ir después de los breakpoints de caché. Las plantillas de prompts también se facturan únicamente cuando se invocan, como el texto renderizado que producen. Los recursos y prompts sin usar de un servidor conectado no cuestan nada. Por eso, cuando una integración MCP aparece en la factura, el primer dato que debe auditarse son los tools.

¿Cambiar la lista de tools invalida el prompt cache?

Sí, por completo. El bloque de tools se renderiza al principio del prompt, por lo que cualquier cambio obliga a reescribirlo y también invalida todo lo cacheado detrás. Medimos que añadir un solo tool volvió a facturar un bloque de 4,082 tokens con el recargo de 1.25x. Hay que mantener fija la lista de tools durante cada sesión, agrupar sus cambios y seguir la beta de Anthropic para modificar tools durante una conversación, diseñada precisamente para eliminar este coste en Opus 5.

Mediciones realizadas el 2026-07-31 a través del gateway de Synthorai: series sintéticas de tools (0-40 tools, n=2) y cinco conjuntos de tools de servidores MCP reales, con schemas capturados en vivo desde los servidores oficiales mediante JSON-RPC tools/list, en cinco familias de modelos; pruebas de caching con prefijos salteados y desglose de caché por llamada; utilización de agentes obtenida de los registros de la suite usada en nuestros estudios de costes de agentes. Los multiplicadores de caching de GPT-5.6 proceden de las mediciones iniciales de nuestra guía de costes. Las cifras en dólares son diferencias de coste facturado obtenidas del medidor del gateway, que aplica las tarifas públicas de entrada. Las tarifas y el comportamiento de renderizado pueden cambiar; compruébelos con sus propios registros de uso.

← Volver al blog