Two tools that talk to each other

Most real problems aren't solved by one tool. they're solved by a chain. The agent decides to invoke a tool, reads its output, decides the next one, and so on.

Your job: design two tools that compose naturally.

The scenario

A user tells the crew: "notify everyone on the night shift that the rendezvous moved to 23:00".

To solve it, the agent has to:

1. List who's on the night shift → list_crewmates_on_shift(shift_id).
2. Notify each one → notify_crewmate(alias, message, channel).

If the two tools are well designed, the agent composes the solution alone. If they're badly designed (output of one doesn't fit the input of the other, descriptions that don't mention the pattern), the agent falls short or invents intermediate steps that break.

The composition rule

For two tools to chain without friction:

1. The output types fit the next tool's inputs. If list returns crewmates: ["Em", "Ly"] and notify accepts alias: string, the agent iterates with zero transformation.
2. The descriptions reference each other. In notify_crewmate's description, mention it's used after list_crewmates_on_shift when there are multiple recipients.
3. The names are consistent. If one tool uses shift_id, the other tool that returns shifts uses the same name, not id_de_turno.

How it's evaluated

7 deterministic criteria + 2 llm-judge:

• Valid JSON.
• Both tools defined correctly with all parameters.
• channel with enum.
• The shapes are composable (output of list fits input of notify).
• Descriptions are specific and reference each other.

The mental test: if I, reading only your schema (without having read this text), could understand how to compose these two tools to solve the rendezvous case, you passed.