Dos tools que se hablan entre sí

La mayoría de los problemas reales no se resuelven con un solo tool. se resuelven con una cadena. El agente decide invocar un tool, lee su output, decide el siguiente, y así.

Tu trabajo: diseñar dos tools que compongan naturalmente.

El escenario

Un usuario le dice a la crew: "notificá a todos los del turno de la noche que el rendezvous se movió a las 23:00".

Para resolverlo, el agente tiene que:

1. Listar quiénes están en el turno de la noche → list_crewmates_on_shift(shift_id).
2. Notificarle a cada uno → notify_crewmate(alias, message, channel).

Si los dos tools están bien diseñados, el agente compone la solución solo. Si están mal diseñados (output de uno no encaja en input del otro, descripciones que no mencionan el patrón), el agente se queda corto o inventa pasos intermedios que rompen.

La regla de composición

Para que dos tools encadenen sin fricción:

1. Los tipos del output coinciden con los inputs del siguiente. Si list devuelve crewmates: ["Em", "Ly"] y notify acepta alias: string, el agente itera con cero transformación.
2. Las descripciones se referencian mutuamente. En la description de notify_crewmate, mencionás que se usa después de list_crewmates_on_shift cuando hay múltiples destinatarios.
3. Los nombres son consistentes. Si una tool usa shift_id, la otra que devuelve turnos usa el mismo nombre, no id_de_turno.

Cómo se evalúa

7 criterios deterministas + 2 llm-judge:

• JSON válido.
• Los dos tools definidos correctamente con todos los parámetros.
• channel con enum.
• Las shapes son composables (output de list encaja en input de notify).
• Las descripciones son específicas y se referencian.

El test mental: si yo, leyendo solo tu schema (sin haber leído este texto), entendería cómo componer estas dos tools para resolver el caso del rendezvous, pasaste.