Tool calling lets an LLM request that your application execute a specific function — checking live data, performing a calculation, taking an action — rather than answering purely from what it already knows. The model decides what to call and with what arguments; your code decides whether and how to actually run it.
The Flow, End to End
User: "What's the status of order 4521?"
↓
LLM decides a tool is needed, and which one:
{"function": "get_order_status", "arguments": {"order_id": "4521"}}
↓
Your application VALIDATES this request (see Tool Validation)
↓
Your application EXECUTES the actual function:
get_order_status("4521") → {"status": "shipped", "eta": "2 days"}
↓
The result is sent BACK to the LLM as new context
↓
LLM generates the final, natural-language response:
"Your order is shipped and should arrive in about 2 days!"The model never directly executes anything — it only ever requests an action. Your application code remains the only thing that actually performs it, which is exactly what makes validation and permissions meaningful safety boundaries (see Tool Calling Security).
Why This Matters
Without tool calling, an LLM can only work with what's in its training data or what's included directly in the prompt (see RAG) — it has no way to check live data, perform precise calculations reliably, or take real actions. Tool calling is the mechanism that connects a model's language understanding to the real, current, dynamic world.
What This Section Covers
| Note | Focus |
|---|---|
| Function Calling | Terminology — how this relates to "tool calling" |
| How Tool Calling Works | The mechanism in more technical depth |
| Tool Schema | Describing a tool so the model can use it correctly |
| Tool Selection | How the model decides which tool (if any) to call |
| Tool Result | Feeding execution results back to the model |
| Tool Calling Security | Validation, permissions, and safe execution |
| Tool Calling vs API, Tool Calling vs Agent | Related but distinct concepts |
Common Mistakes
- Executing a requested tool call without validating arguments first — treat every tool call request as untrusted input, not a guaranteed-safe instruction
- Confusing tool calling (the model requesting an action) with the model directly executing that action — it never does; your code is always the one that runs it
Interview Relevance
Q: "Explain how tool calling works, end to end." — the decide → validate → execute → return result → final response flow above is exactly the expected shape of a strong answer.
Practice Question
Explain why tool calling requires application-level validation even when the request comes from the LLM itself, not directly from a user.
