What Is Function Calling in AI?

Function calling is a way of letting a language model trigger real code instead of just producing text. You give the model a list of functions it can use, each described as a JSON schema with a name, a description, and the parameters it expects. When the model decides a function would help, it does not run anything itself. It returns a structured object naming the function and the arguments to pass. Your application executes the actual function and hands the result back so the model can finish answering.

On its own, a language model just predicts the next token based on patterns in its training data, a process covered in more depth in how large language models actually generate text. It cannot check today's weather, query your database, or send an email, since none of that is text prediction. Function calling bridges that gap without changing what the model fundamentally does.

Vendors use "function calling" and "tool calling" almost interchangeably, though tool calling is usually the broader term, covering everything from a single custom function to a full tool calling in AI agents setup, where the model juggles a dozen tools across several turns of a conversation.

A worked example, step by step

Say you are building an app that answers weather questions. You register one function with the model:

{ "name": "get_weather",

"description": "Get the current weather for a given location.",

"input_schema": {

"type": "object",

"properties": { "location": {"type": "string", "description": "City and state, e.g. Austin, TX"}, "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]} },

"required": ["location"]

} }

That is the whole tool definition. No function body, no implementation logic, just the shape of it: a name the model will reference, a description it uses to decide when the tool is relevant, and a schema describing exactly what arguments it can pass.

Ask the model what the weather is like in Austin right now and, because a language model has no live data, it does not guess. Instead it returns a call intent that looks something like this:

{ "type": "tool_use",

"id": "toolu_01A2B3C4D5",

"name": "get_weather",

"input": { "location": "Austin, TX", "unit": "fahrenheit" }

}

Notice what is missing from that response: any actual weather. The model has not looked anything up. It has produced a request, essentially "run get_weather with these arguments," and stopped. Your code calls the weather API, gets back a real temperature, and returns that as a tool result. Only then does the model write the sentence a person reads, something like "it is 89°F and sunny in Austin."

That request, execute, return, continue cycle is the entire mechanism. It does not change as the tool count grows from one to fifty. Every AI agent framework built for multi-step tool use runs some version of this loop: send messages and tools, get back a call, execute it, append the result, repeat until the model has enough to answer.

Three ways function calling breaks, and how to fix each

Function calling looks clean in a demo with one tool and a cooperative prompt. In production, with real users and ambiguous requests, three failure modes show up constantly. All three are fixable with code you write once, not with a better prompt alone.

A hallucinated function name usually means your tool list is too long, too similar, or under-described. The fix is not hoping for a smarter model. Before executing anything, check the returned name against the literal list of functions you registered. If it does not match exactly, do not guess at the closest one and do not execute. Return an error result and let the model try again with that information.

Wrong argument types show up most often on numbers and booleans, since a model reasoning in text sometimes writes a number as a string. Validate every call's arguments against your schema before the value reaches your function. When validation fails, do not just log it: append the error back into the conversation as the tool result and let the model retry. Told which field failed and why, models are generally good at fixing it on the next attempt.

Omitted required fields tend to happen on underspecified requests. Ask a model to set up lunch with Sam tomorrow and it may invent a time rather than ask, or drop attendees entirely. The most durable fix happens at the schema itself: mark every field the function truly cannot run without as required, keep that list short, and write descriptions precise enough that only one reasonable value fits. Several APIs now offer a stricter schema mode, which Anthropic documents as strict tool use, that constrains generation so output matches the schema exactly, catching this at generation time instead of after. Where unavailable, validate for missing keys the same way you validate types. How precisely you write those descriptions is itself a prompt engineering problem: the same care behind writing prompts that actually work applies directly to describing a function's parameters.

Frequently asked questions

Is function calling the same thing as tool use?

Close enough in practice. Function calling is the original, narrower term for a model calling a developer-defined function. Tool use, or tool calling, is the umbrella term that also covers built-in capabilities like web search or code execution, which work the same way under the hood: a structured request, an execution step, a result returned to the model.

Does function calling let a model access the internet or execute code by itself?

No. A function call, on its own, is just a piece of structured text describing an intended action. It has no side effects until your application code reads it and decides to run something. That is a feature, not a limitation: it means you can log, validate, rate-limit, or reject a call before it ever touches a real system.

Can a model call more than one function at a time?

Yes. Most current APIs let a single response contain several function call requests, meant to run in parallel rather than one at a time. Execute them concurrently and return all the results together in one message. Splitting them across separate turns tends to quietly train the model to stop batching calls.

What happens if I execute a function call without validating it first?

Whatever your function does, it does, bad arguments and all. Skipping validation is the difference between a wrong function call staying a conversational hiccup and it becoming a real bug: a malformed database write, an email sent to the wrong address, or a charge that should not have gone through.