¿Quieres que un agente use tus funciones de Python como herramientas reales? La clave está en el contrato de la herramienta: nombre, descripción, parámetros y resultado esperado. Dominar esto evita loops infinitos, errores repetidos y presupuesto desperdiciado.

Esta habilidad es para quien construye agentes con LLMs y necesita que ejecuten acciones de forma confiable. Después de entender cómo funciona ReAct y los finish reasons de la clase anterior, toca darle manos al modelo: funciones que puede invocar.

Qué significa el contrato de una herramienta

Piensa en el contrato de una herramienta como ir a una ventanilla del banco a hacer un trámite [01:00]. Necesitas saber qué trámite es, qué se hace ahí, llevar todos los documentos que te piden y conocer qué te van a entregar al final.

Una herramienta funciona igual. Debe declarar cuatro cosas:

• El nombre de la herramienta.
• La descripción del trámite o acción.
• Los datos o parámetros que se le van a pedir.
• El output esperado de la ejecución.

¿Qué es el contrato de una herramienta en un agente? Es la ficha que define nombre, descripción, parámetros de entrada y resultado esperado de una función. El modelo lee esa ficha para decidir si la usa y cómo llenarla.

Si falta alguno de estos elementos o están mal redactados, el modelo lee una ficha incorrecta y puede usar la herramienta mal.

Por qué la descripción de una herramienta es tan importante

Las descripciones son fundamentales [01:30]. Puedes tener una función de Python que calcula la hora, pero si el título y la descripción no son adecuados, el modelo no sabrá leerla ni cuándo usarla.

Una buena descripción le dice al modelo cómo utilizar la herramienta. Una mala descripción no solo lo deja sin saber cómo usarla, sino que puede ocultarle cuáles son los parámetros requeridos, generando errores continuos.

¿Y qué cuesta descuidar esto? Puedes terminar con tu budget agotado en varios frentes:

• El presupuesto en créditos o dinero.
• El límite de requests por minuto.
• La cantidad máxima de loops que tu agente puede ejecutar.

Por eso el harness importa tanto. El harness es todo el código que rodea a tu modelo [03:00]. Si el modelo pide una herramienta que está en la lista y permitida, y los datos están bien escritos, la podrá ejecutar correctamente.

Qué pasa cuando el modelo alucina una herramienta

Los modelos, es decir los LLMs, son sistemas altamente estocásticos [05:00]. Pueden alucinar el nombre de una herramienta en cualquier momento, incluso con un system prompt estricto y descripciones muy buenas.

Un agente puede pedir correctamente buscar PAC o estimar costo, pero también puede pedir borrar instancia, una función que quizá ni siquiera existe en tu lista.

¿Por qué un agente repite acciones que no existen? Porque el mensaje de error no fue lo suficientemente explícito para corregir su comportamiento. Sin esa pista clara, se vuelve un agente terco que insiste en una acción inexistente.

Aquí hay un detalle que cambia todo: los mensajes de error que devuelve tu función son extremadamente importantes [04:30]. Recuerda que la función no la corre el modelo, la corre tu computadora. Si el modelo comete un error y el mensaje es claro, en el siguiente turno el llamado puede ser correcto.

Cómo usar otros agentes como herramientas

Un detalle emocionante: otros agentes también pueden ser herramientas de tu agente principal [06:00]. A estos los llamamos subagentes, y en inglés lo verás como subagents as a tool.

Imagina un jefe de proyecto que necesita saber cuánto cuesta explorar y lanzar una instancia en Brev. Puedes tener un subagente especializado con toda la documentación de Brev que responda esa estimación.

Una vez que el subagente estima el costo, le regresa el resultado al agente principal como cualquier otra herramienta, y el principal toma acciones con ese resultado.

Qué es MCP y cómo conecta herramientas externas

No todas las herramientas tienen que ser parte de tu código [07:00]. Seguramente has visto integraciones de ChatGPT o Claude con Google Drive, correo, Google Slides o generación de imágenes y videos en otros servicios.

¿Qué es MCP (Model Context Protocol)? Es un protocolo que permite a tu agente llamar herramientas que están fuera de tu código y tomar acciones con ellas igual que con las herramientas propias, pero alojadas en otro lado.

Algunos ejemplos concretos de lo que habilita MCP:

• El MCP de Google Drive deja a tu agente listar, eliminar, escribir y organizar documentos.
• El MCP de ClickUp o Linear deja a tu agente manejar tareas, asignarlas a personas u otros agentes.
• Esas tareas tienen estados como por hacer o completado, que el agente puede actualizar por ti.

ClickUp y Linear son herramientas para romper proyectos en tareas más pequeñas y asignarlas [08:30]. Con su MCP, tu agente puede administrar ese flujo completo en tu trabajo diario.

¿Ya tienes claro qué función de tu código convertirías primero en herramienta? Cuéntalo en los comentarios.