Tool-Call Outputs

ToolCalls

Part of: Reading Model Outputs

You ask your assistant "what's the weather in Paris?" and the model doesn't answer. Instead it hands back something stranger: a little structured request that says call the function get weather with city="Paris" . That's not a failure, it's the model doing the smartest thing it can. It can't see the weather, so instead of hallucinating a number, it asks you to run the tool. Reading that branch in the response is how function calling works. What it is When you give a model tools (functions it's allowed to invoke), a single response can come back in one of two shapes. Either the model produces ordinary text content : a plain answer, or it produces a tool call : a structured request naming a function and the arguments to pass it. The model never runs the function itself; it only asks . Your code runs the tool, then feeds the result back so the model can finish. The key field is tool calls on the message. When it's present, the model wants a function executed. When it's absent (and content is filled), the model is just talking. Your job on every response is to branch on which one you got. How it works You inspect the message and route on the presence of a tool call: Notice that when th

Challenge: Tool-Call Dispatcher