A school roster tool must fetch attendance every turn. Which tool-use configuration fits?
Select an answer to reveal the explanation.
Short Explanation
When attendance has to show up every turn, don’t force the roster tool only on the first turn and then switch to auto—you’ll lose the guarantee after that. Keep tool_choice forced on every turn so the roster tool runs before Claude answers.
Full Explanation
If a school roster flow must fetch attendance every turn, setting tool_choice to auto is insufficient because Claude may decide attendance is not helpful and skip the lookup entirely under prompt pressure. Requiring explicit tool_choice forcing binds the turn to the attendance tool so the agent cannot proceed without fresh roster data from the student-information system. Setting tool_choice to auto so Claude calls attendance when it seems helpful allows silent drift from the authoritative district source and can misstate who is present, since the model may judge a fetch unnecessary. Describing attendance fetching in the system prompt while keeping tool_choice on auto substitutes guidance for live district data and risks privacy-sensitive fabrication about students, because Claude may ignore the description and rely on memory or skip the lookup. Forcing the attendance tool on the first turn then resuming auto selection removes the lever administrators need for deterministic classroom and compliance workflows, since subsequent turns are left to Claude’s discretion and may skip the fetch. Exam caveat: forced tool use still depends on a correct tool implementation and auth; forcing a broken or unauthorized tool only guarantees consistent failure, so pair tool_choice with health checks and clear error returns. Operational check: run multi-turn classroom queries with tool_choice set to require the roster tool, confirm every turn issues the fetch before answering, temporarily unset forcing and observe that skips become possible, then document why forcing is required in production attendance-facing agents.