What Is Function Calling in LLMs?
Part 1's ACT step needs a real, technical mechanism to actually happen. This part covers that mechanism precisely — function calling (also called tool use), the specific, real way a language model requests that your code execute something on its behalf.
A real, precise definition
Function calling: a model, instead of only generating plain text,
can generate a real, STRUCTURED request to call a specific
function you've described to it — naming the function and
providing real, valid arguments matching a schema you definedThe model itself never actually executes anything — this is a genuinely important, precise distinction. It generates a real, structured request; your own application code is responsible for actually running the function and reporting the real result back.
The real, complete mechanism, step by step
1. You describe available real functions to the model (name,
description, expected real arguments) — this is the "tool"
or "function" schema
2. The model, given a real user request, decides whether calling
one of these functions would help answer it
3. If so, the model outputs a real, structured object naming which
function and what real arguments to use — NOT plain text
4. Your code reads this real, structured output and actually calls
the real function
5. Your code sends the real, actual result back to the model
6. The model uses that real result to continue — generate a final
answer, or request another function call (part 1's loop)A real, concrete function schema
check_inventory_tool = {
"name": "check_inventory",
"description": "Check the current real stock level for a specific Bright Leaf Coffee product",
"input_schema": {
"type": "object",
"properties": {
"product_id": {"type": "string", "description": "The real product SKU"},
},
"required": ["product_id"],
},
}This real, structured schema is genuinely what the model reads to understand what functions exist and how to call them correctly — the description fields matter directly, since the model uses them, in real, natural language, to decide when a given function is actually relevant to a real request.
Writing a vague, unclear description — "does inventory stuff" instead of the precise real description above — genuinely degrades the model's ability to choose the correct function at the correct real moment. This is directly analogous to the AI Fundamentals series' own prompt engineering guidance — precise, real, descriptive language produces measurably more reliable model behavior.
A real, complete request and response
response = client.messages.create(
model="claude-sonnet-5",
max_tokens=1024,
tools=[check_inventory_tool],
messages=[{"role": "user", "content": "Is the Ethiopian Light Roast in stock?"}],
)
# real, structured output, not plain text
if response.stop_reason == "tool_use":
tool_call = next(b for b in response.content if b.type == "tool_use")
print(tool_call.name) # "check_inventory"
print(tool_call.input) # {"product_id": "eth-light-roast"}Notice response.content here contains a real, structured object — tool_call.name and tool_call.input — not a plain string. This structural difference from every earlier project in this site's tutorials (which read response.content[0].text directly) is the genuine, real technical signature of function calling actually happening.
What genuinely happens if you DON'T execute the requested function
The model's real request just sits there, unexecuted — nothing
happens automatically. Function calling is a real REQUEST
mechanism; your own code is entirely responsible for the actual
execution and reporting the genuine result backThis is a real, honest, important clarification — the model has no independent, real ability to actually run code, query a database, or call an external API on its own. Every real action ultimately happens through your own application code, which is exactly why part 18's security coverage matters — you control, and are responsible for, everything that actually executes.
Function calling vs. simply asking for structured output
Structured output (the AI Projects series' own JSON-format technique):
the model formats its FINAL answer as JSON — genuinely useful, but
it's a one-way, real output format request
Function calling: the model requests something be EXECUTED, and
expects a real result back to continue reasoning with — a
genuinely different, two-way, real interactionNext: AI agent tools and function calling explained — building this part's mechanism into the complete, real toolkit an agent actually uses.