…
Módulo 1 · Parte C de 3

Herramientas a escala

En el Módulo 1b, conectaste una sola herramienta al bucle del agente: el modelo solicitó una función con nombre, el motor de ejecución la ejecutó y el resultado se incorporó a la siguiente llamada al modelo. Este proceso no cambia en esta sección. Únicamente aumenta la cantidad de herramientas disponibles: el modelo deberá elegir ahora entre más descripciones y cada herramienta puede ocultar un proceso más elaborado.

La página sigue ese contrato desde las funciones locales hasta un backend de búsqueda y un subagente. Un subagente como herramienta sitúa un agente especializado detrás de un único esquema para que el workflow externo pueda enrutar el trabajo sin exponer cada capacidad interna. Model Context Protocol (MCP) ofrece al cliente una forma estándar de descubrir e invocar herramientas servidas por otro proceso. Úsalo en un límite de capacidades, después de validar el servidor, la identidad y el alcance. Ambos patrones mantienen reducida la lista de herramientas del bucle principal y motivan los workflows acotados del Módulo 2.

El contrato de llamada a herramientas permanece fijo

La siguiente figura retoma el bucle de la sección 1b. Las siguientes secciones cambiarán el origen del esquema y el motor de ejecución, mientras el modelo seguirá solicitando una herramienta por nombre y leyendo su resultado.

El LLM solicita una llamada, el código responde y el LLM concluye. El modelo nunca ejecuta la función.
El servidor aplica el esquema. Antes de las llamadas a funciones estructuradas, las aplicaciones solían extraer XML personalizado o JSON escrito a mano del texto del modelo. Cualquier error en dichos XML o JSON hacía que parsearlos automáticamente fuera una tarea difícil. El campo de herramientas transporta el esquema por separado; así, el servicio puede restringir los argumentos al esquema y devolver un campo tool_calls coherente. El código de enrutamiento puede contar entonces con que tc.function.name y tc.function.arguments estén presentes y se puedan analizar.

Cómo el modelo elige entre varias herramientas

Los agentes rara vez disponen de una única herramienta. Cuando hay varias, el modelo decide a cuál llamar a partir del campo description.

La celda siguiente proporciona al modelo dos herramientas y una pregunta que exige elegir. La visualización muestra qué camino tomó y por qué.

Editar cualquier descripción cambia el enrutamiento del modelo, ya que el campo de descripción es una de las variables de ingeniería de prompt con mayor impacto en un agente que usa herramientas.

Conecta glossary_search a una herramienta real

La celda conecta glossary_search con un catálogo de términos de NVIDIA que se ejecuta en el navegador. Esta herramienta no necesita clave y permite buscar definiciones breves con enlaces a las fuentes. La herramienta web_search compartida en el curso aplica la misma idea al catálogo completo. Abre el explorador del glosario para inspeccionar cada término, consultar las fuentes de webSearch e instantAnswer o ejecutar una búsqueda por ti mismo.

En la siguiente sección se sustituye el motor de ejecución por una búsqueda exacta de términos, pero se mantiene el mismo contrato de herramienta. El backend cambia; el contrato que utiliza el modelo permanece fijo.

El nombre de una herramienta debe describir una capacidad. Una herramienta llamada nvidia_glossary_api es frágil: cambiar el backend fuerza a actualizar cada prompt que referencia el nombre. Una herramienta llamada glossary_search describe lo que necesita el modelo que realiza la llamada. Una búsqueda ordenada por relevancia, una búsqueda exacta o un índice más completo pueden situarse detrás de ese contrato sin alterar el prompt del agente.
Aplicado · Backend¿Sustituir el ejecutor sin cambiar la herramienta?

Cambiar el backend sin cambiar el contrato

El mismo bucle se ejecuta aquí como un script mountRunCell, con un cambio: el motor de ejecución. La búsqueda anterior devolvió un resumen breve para varios resultados. Este backend devuelve el artículo completo que mejor coincide, recuperado de la página de glosario almacenada en caché. El esquema y el bucle no cambian; solo mejora la fuente que alimenta glossary_search.

El modelo solo ve el contrato. Invoca glossary_search con una consulta en lenguaje natural y lee el valor devuelto, sin saber qué motor de ejecución respondió. Se puede comenzar con un índice de resúmenes y sustituirlo más adelante por artículos completos o una búsqueda en vivo sin modificar el bucle. La precisión puede variar si cada motor de ejecución resuelve las coincidencias de forma distinta, pero el contrato se mantiene.
Profundo · Delegación¿Ocultar un agente especializado detrás de una herramienta?

Un agente completo detrás de una sola herramienta

Una herramienta no tiene que ser una función simple. Un subagente completo puede estar detrás de una sola llamada a herramienta. El modelo que realiza la llamada sigue viendo un único contrato. El agente del otro lado puede consultar una base de datos, ejecutar código o buscar en un repositorio sin exponer esas herramientas internas al bucle principal.

La celda siguiente expone como herramienta un subagente que puede hacer consultas sobre una pequeña tabla de clientes. El agente principal nunca ve las filas: solo puede formular preguntas en lenguaje natural.

La carga cognitiva también se controla. Cada herramienta adicional, campo de esquema y frase de descripción consume contexto que el agente principal podría usar para su tarea. Una lista de herramientas plana y extensa suele rendir peor que un conjunto pequeño respaldado por subagentes, porque cada bucle solo ve las herramientas pertinentes para su nivel.

Descubrir herramientas en otro servidor con MCP

Aplicado · Construcción¿Revisar el flujo de descubrimiento e invocación de MCP?

Model Context Protocol (MCP) define una interfaz estándar para publicar herramientas. Un agente obtiene mediante tools/list la lista que ofrece un servidor e invoca cada herramienta con tools/call. Estas herramientas pueden ejecutarse en otro proceso, al que el agente se conecta durante la inicialización. Como todos los servidores comparten el protocolo, el agente puede incorporar nuevas fuentes de herramientas sin implementar una interfaz distinta para cada una. MCP resulta útil cuando el descubrimiento y el transporte requieren un protocolo común. Si el motor de ejecución ya conoce la ubicación y la forma de invocar una capacidad, suele bastar una función local, una skill del repositorio o una llamada directa a una API.

El descubrimiento es la frontera de confianza. Trata una respuesta tools/list como entrada no confiable. Antes de conectarte al servidor:
  • verifica su identidad;
  • muestra al usuario las capacidades solicitadas;
  • concede el menor alcance necesario;
  • vincula cada credencial con la audiencia de ese servidor.
Para conexión remota y descubrimiento para autenticación vía OAuth, rechaza destinos privados y de enlace local, y valida todas las redirecciones. La orientación de seguridad de MCP asigna al cliente la responsabilidad sobre el consentimiento, el manejo de tokens y los controles contra falsificación de solicitudes del lado del servidor (SSRF).

La celda siguiente simula un servidor MCP pequeño en JavaScript puro con el mismo formato JSON-RPC que MCP define (sin transporte). El agente recupera la lista de herramientas, entrega los esquemas al modelo y dirige cada elemento de tool_calls al controlador tools/call del servidor. El bucle del agente es idéntico al de una llamada a herramienta normal; solo cambia el origen de la lista.

El módulo 2 conserva este contrato y modifica la estructura que lo rodea. Un flujo de trabajo puede dirigir las llamadas mediante un pipeline fijo, distribuir el trabajo entre varias ramas o delegar una tarea acotada a otro bucle sin exponer todas sus herramientas internas al agente que realiza la llamada.

Antes de continuar

  1. ¿Qué sucede cuando el modelo llama a una herramienta con argumentos que no superan la validación? El bucle actual falla. ¿Cómo gestionarías el error de forma controlada sin hacer creer al modelo que la llamada tuvo éxito?
  2. El subagente utilizado como herramienta es opaco para el agente principal. Además de la respuesta, ¿qué información debería devolver para que el agente principal decida si puede confiar en ella durante el turno siguiente?
  3. El parámetro tool_choice se puede definir como "required" o como un nombre de herramienta específico. ¿Cuándo conviene forzar una llamada a herramienta y qué riesgo introduce esa decisión?
  4. Antes de añadir un servidor MCP remoto, ¿qué identidad, alcance, audiencia del token y destinos de red verificarías? ¿Cuál de esos campos puede abrir una ruta SSRF si se acepta sin validación?
Profundo · Fuentes¿Revisar las fuentes sobre uso de herramientas y MCP?

Referencias

Consulta la lista completa en Para ir más lejos · Referencias.

Prueba · un agente con dos herramientas reales

Este artefacto ejecuta un agente LangChain createReactAgent conectado a las dos funciones cuyos contratos acabas de leer: calculate para aritmética y glossary_search para búsquedas en el glosario de NVIDIA incluido en la página. Pide un número que no pueda calcular mentalmente o la definición de algún término que quieras conocer, y observa cómo aparece el indicador de la herramienta antes de que la respuesta empiece a transmitirse.

← Módulo 1b: El bucle ReAct