El mecanismo: quién hace qué
Cuatro pasos, y el tercero es la clave.
1. El desarrollador describe la herramienta. Tres campos: nombre, descripción y esquema de entrada en formato JSON Schema. La descripción no es documentación para el equipo: es la única pista que tiene el modelosobre cuándo usar la herramienta.
2. El modelo rellena el formulario. En la respuesta no llega texto, sino un bloque de tool call: qué herramienta pide, con qué argumentos y con un identificador para emparejar después el resultado. El motivo de parada de la respuesta también cambia a «uso de herramienta».
3. Tu código la ejecuta. La documentación del fabricante lo dice con estas palabras: las herramientas de cliente corren en tu propia aplicación; el modelo responde con el bloque de tool call, tu código realiza la operación y devuelve el resultado.
Hay una excepción: las herramientas de servidor —búsqueda web, descarga de páginas, ejecución de código— corren en la infraestructura del proveedor; ahí tú no ejecutas nada, solo recibes el resultado.
4. El resultado vuelve a la conversación. Como bloque de resultado, emparejado con el identificador de la llamada original. El modelo sigue desde ahí.
Y de aquí sale la partida de coste más importante de los agents: una llamada a herramienta son dos llamadas al modelo. Una antes y otra después.
¿Dónde se rompe?
Hay una clasificación universitaria que mide específicamente la llamada a funciones, y su historial de versiones dice más que el orden actual: llamada simple → datos en vivo → llamada multiturno y multipaso → evaluación agéntica.
Cuatro patrones de fallo, medidos, sobre un conjunto de cien preguntas de varios pasos:
| Patrón de fallo | Qué hace el modelo |
|---|---|
| Evitar la herramienta | tiene buscador y aun así responde de memoria, con un resultado caducado o incompleto |
| Suposición falsa | da por hecho que un suceso todavía no ha ocurrido y por eso ni siquiera lanza la búsqueda |
| Mala descomposición | no parte la pregunta de varios pasos, sino que prueba con una única búsqueda que lo abarque todo |
| Mala lectura | encuentra la página correcta y malinterpreta su contenido |
Un hallazgo lateral de la misma medición: sin uso de herramientas la precisión cae drásticamente. Es decir, la herramienta vale muchísimo, pero los cuatro fallos de arriba le pasan a quien sí tiene herramienta.
Y un resultado nada trivial que sorprende a mucha gente. Esa misma clasificación midió aparte la sensibilidad al formato en 39 modelos: la misma herramienta, el mismo modelo, solo cambia el formato de la documentación.
- En el formato de la documentación de funciones hay una tendencia consistente en casi todos los modelos: JSON es lo mejor, XML va peor y Python es lo peor.
- En el formato de retorno, Python y JSON superan a cualquier variante de XML, y los modelos pequeños son más sensibles a ello.
- Sin etiquetas de tool call los modelos rinden algo mejor que con ellas.
- Al formato y al estilo del prompt, en cambio, los modelos son bastante indiferentes.
Los extremos son elocuentes: hubo un modelo probado cuyo rendimiento quedó próximo a cero solo por exigirle formato JSON, y a otro le pasó lo mismo con las etiquetas de tool call.
La lección práctica: si no funciona, cambia primero el formato y solo después el modelo.
¿Cuántas herramientas caben en un prompt?
Aquí dos fabricantes dan dos números distintos, y ninguno publica metodología.
| Fuente | Recomendación | Naturaleza |
|---|---|---|
| Un fabricante | por debajo de 20 al empezar una ronda | «sugerencia laxa», sin justificar |
| El otro | por encima de 30-50 empeora la elección | afirmación, sin dato de medición |
Para lo que sí hay un número concreto: una configuración típica que enlaza varios servidores consume unos 55.000 tokens solo con las definiciones de herramientas, antes de que el modelo haga nada. Según el fabricante, una solución de búsqueda de herramientas reduce eso en más de un 85 %, porque carga solo las 3 a 5 herramientas que tocan a la pregunta.
Una cifra aún más rotunda de la misma fuente, con un enfoque de ejecución de código: de 150.000 tokens a 2.000, un ahorro del 98,7 %.
Pero a la pregunta de dónde está exactamente el punto de ruptura no hay medición independiente. Lo que sabemos: más contexto da, medidamente, una salida menos fiable, pero ningún estudio lo midió en función del número de herramientas. Es una pregunta abierta de verdad.
En la práctica de ahí sale una regla: la pregunta no es cuántas herramientas puedes conectar, sino cuántas ve el modelo en una petición concreta.
Lo que no se garantiza
Tres cosas que la documentación explícitamente no promete.
No sabes cuántas llamadas vienen. Un fabricante escribe literalmente que la respuesta puede contener cero, una o varias llamadas, y que lo mejor es que tu código esté preparado para todas. La llamada en paralelo viene activada, pero se puede desactivar.
Cumplir el esquema no es acertar el contenido. Existe un modo que fuerza a que la llamada cumpla el esquema. Es útil, pero no garantiza que el modelo eligiera la herramienta correcta ni los valores correctos. Los cuatro patrones de fallo de arriba son llamadas válidas según el esquema y equivocadas en el fondo.
El error hay que devolverlo a la conversación. El bloque de resultado tiene un campo propio para marcar el error, y de ahí aprende el modelo para el paso siguiente. Si te limitas a descartar el error, el modelo no sabe que lo hizo mal. En un agent en producción hay además una protección: tras tres errores de formato seguidos, la ejecución se detiene.
¿Cuánto más cara es una ronda con llamada a herramienta?
Se añaden dos partidas antes de que hagas nada.
La primera es el recargo del system prompt. Activar el uso de herramientas añade automáticamente un system prompt cuyo tamaño está publicado modelo a modelo: en los modelos de hoy, aproximadamente entre 280 y 590 tokens, según si el modelo puede elegir libremente o está obligado a llamar a una herramienta. Esto aparece incluso antes de las definiciones de herramientas.
La segunda son las definiciones mismas. Se facturan como tokens de entrada, en cada llamada.
Cálculo propio. Tomemos un modelo de precio medio (2 $ por millón de tokens de entrada, 10 $ por millón de salida) y comparemos dos casos:
| Respuesta normal | Una ronda con llamada a herramienta | |
|---|---|---|
| Número de llamadas al modelo | 1 | 2 |
| Tokens de entrada en total | 500 | 2.688 |
| Tokens de salida en total | 150 | 230 |
| Coste | 0,0025 $ | 0,0077 $ |
El multiplicador: 3,07×. En mil rondas eso son 7,68 dólares en vez de 2,50.
(Cálculo propio. El recargo del system prompt es un dato medido y publicado por el fabricante; el tamaño de la definición de herramienta y el del resultado son estimaciones propias, y en la realidad varían mucho. El cálculo no incluye prompt cache.)
Dos cosas modifican esto.
Hacia arriba: con N llamadas a herramienta hay N+1 llamadas al modelo, y cada llamada arrastra todo el historial acumulado. Así que el multiplicador no se queda en tres: en una ejecución larga sigue empeorando.
Hacia abajo: el prompt cache es la optimización más importante. Si hay acierto de caché, el token de entrada va a una décima parte del precio, y como buena parte de la entrada de la segunda llamada es literalmente igual que la de la primera, pega justo donde más se nota.
Un contraste para el cálculo propio: la medición propia de un fabricante dice que los agents consumen unas cuatro veces más tokens que una conversación. El 3,07× se refiere a una sola llamada y encaja bien en ese orden de magnitud: las dos cifras llegaron por caminos independientes.
Malentendidos habituales
- «El modelo llama a la API.» No. Rellena el formulario y la llamada la hace tu código. La excepción es la herramienta de servidor que corre en el proveedor.
- «Si el esquema es estricto, la llamada será correcta.» El esquema fuerza la forma, no el contenido. La inmensa mayoría de los fallos medidos son válidos según el esquema.
- «La descripción de la herramienta es documentación.» La descripción de la herramienta es un prompt. Es lo único con lo que el modelo decide cuándo usarla.
- «Lo conecto todo y ya elegirá.» Una configuración que enlaza varios servidores puede llevarse 55.000 tokens solo en definiciones, antes de trabajar. No cuenta el número de herramientas conectadas, sino el de las visibles para el modelo.
- «Siempre vuelve una llamada.» Cero, una o varias. El código tiene que estar preparado para cada caso.
- «Solo importa el modelo.» El mismo modelo da una tasa de acierto medidamente distinta con otro formato de documentación: JSON es consistentemente mejor que XML o que Python.
Lo que conviene llevarse
El function calling no es una llamada, es una propuesta. El modelo dice qué quiere; la ejecución, el tratamiento de errores y los permisos siguen en tu lado. Eso es buena noticia: ahí es donde puedes intervenir.
Las tres cosas que más mejoran esto en la práctica: una buena descripción de herramienta (porque es un prompt), el formato JSON (porque los modelos son medidamente mejores con él) y el prompt cache (porque buena parte de la entrada de una ronda con herramienta se repite).
Cómo de aquí sale un bucle de agent completo lo recorre entero el post qué hace un agente, paso a paso , de principio a fin; y del estándar con el que hoy se suelen conectar las herramientas te da una panorámica el post MCP , con sus advertencias de seguridad.