Function calling lets a model request that your code run a specific function with specific arguments. The model never executes anything itself — it returns a structured request, your code decides whether to run it, and the result goes back into the conversation.
Also called: tool use, tool calling · Reviewed
You describe the functions available — name, purpose, and the shape of their arguments. When a request would be better served by one of them, the model replies with a structured call rather than prose: the function name and the arguments filled in. Your code validates it, runs it if appropriate, and passes the return value back as a new message. Selection accuracy holds up well across a handful of clearly distinct tools and starts degrading noticeably somewhere past twenty, which is the point to split the work across specialised agents instead.
The model then continues with the real result in its context. Asked for the weather, it does not invent a temperature; it asks for the weather function to be called, then reports what came back.
It is the bridge between a model that only produces text and a system that can do things. Looking up live data, writing to a database, sending a message, running a calculation — all of it becomes available without the model needing any of it baked into its training.
It is also what makes agents possible. An agent loop is largely a model choosing tools, seeing results and choosing again, so function calling is the primitive the whole pattern rests on.
Assuming the model runs the function. It does not. It produces a request, and everything that happens next is your code — which means validation, permissions and rate limits are your responsibility. A model asking to delete a record is not authorisation to delete it.
The second is offering too many tools. Reliability drops as the list grows, because choosing correctly between forty similarly described functions is a harder problem than choosing between five. Clear, distinct descriptions matter more than coverage.