Function Calling & Tool Use

The plain-language idea

A model can only generate text. It has no way to reach out to a database, call a weather API, or execute a calculation on its own — those capabilities don't exist inside the model. Function calling (also called tool use) is the mechanism that bridges that gap, and it works entirely through structured text, not through the model gaining any new capability.

Here's the actual sequence:

1. You give the model a set of tool definitions — for each tool, a name, a description of what it does, and a schema describing what parameters it takes.
2. Instead of answering directly, the model can respond with a structured request: "call getWeather with { city: 'Austin' }."
3. Your code reads that request and actually executes the function — the model itself does not run anything.
4. Your code sends the function's result back to the model as part of the conversation.
5. The model uses that result to generate its final, natural-language answer.

The model's only role is deciding which tool to call and with what arguments, based on the tool descriptions you gave it — it's still just generating text, but that text happens to be a structured call request instead of a direct answer. Everything people describe as "the AI can check the weather" or "the AI can query a database" is this loop, not the model reaching outside of itself.

See it in a real thing: a weather tool request/response cycle

A user asks a question the model can't answer from text alone: 'What's the weather in Austin?'

BackNext

// 1. Tool definition you give the model
{
  "name": "getWeather",
  "description": "Get current weather for a city",
  "parameters": {
    "type": "object",
    "properties": { "city": { "type": "string" } },
    "required": ["city"]
  }
}

// 2. Model's response isn't an answer — it's a call request
{ "tool": "getWeather", "arguments": { "city": "Austin" } }

// 3. Your code executes getWeather("Austin") — this runs in YOUR
//    environment, with your API keys, your network access, your rules

// 4. Result sent back to the model as part of the conversation
{ "tool": "getWeather", "result": { "tempF": 91, "condition": "sunny" } }

// 5. Model's final response, now grounded in a real result
"It's 91°F and sunny in Austin right now."

Step 3 is the part worth sitting with: your code decides whether to actually run that function, with what permissions, and against what real systems. The model requesting a call is not the same as the call happening — a well-built integration validates the arguments the model produced before executing anything, the same way you'd validate any other untrusted input, because the model can request a call with malformed or unexpected arguments.

What people usually miss

Watch out

• The model never executes anything. It generates a structured request; your application code is what actually runs the function, with your access and your permissions.
• Tool descriptions are the entire interface the model reasons from. A vague or ambiguous tool description leads to the model picking the wrong tool or malformed arguments — the description is doing real communicative work, not just documentation.
• Arguments the model produces are untrusted input, not a guaranteed-valid call. Validate them before executing, the same as you'd validate any other input from outside your system.
• A single turn can involve multiple tool calls in sequence, not just one call and done — the model can chain calls if the first result doesn't answer the question.
• This is not the model gaining new abilities. It's still bounded to generating text; tool use is an architecture your code builds around that text, not a capability upgrade inside the model.

Why this matters in interviews

"How does an AI assistant actually check the weather or query a database?" tests whether a candidate understands that the model requests, your code executes, and the result comes back — versus the common misconception that the model somehow reaches out and does it directly.