Home/ Part V — Intermediate Track: From Playground to Real Projects/16. Tool Calling and Function Calling (Where Apps Become Real)

16. Tool Calling and Function Calling (Where Apps Become Real)

Overview and links for this section of the guide.

What this section is for

Tool calling is where LLM apps move from “generate text” to “do work.” A tool is a function/API your app exposes that the model can call to:

  • retrieve data,
  • perform computations,
  • take actions (sometimes with side effects),
  • verify and ground outputs.

This section teaches you how to design tool calling so it is:

  • reliable,
  • auditable,
  • bounded (no runaway loops),
  • safe (least privilege and approvals).
The big idea

Tools separate “thinking” from “doing.” The model proposes actions; your system performs controlled actions and returns results.

Mental model: tools are capabilities

A tool is not “a helper.” It is a capability you grant to the model. That means:

  • tools expand what the model can do,
  • tools expand what can go wrong,
  • tool design is security design.

Once you treat tools as capabilities, “least privilege” becomes the default posture.

Why tool calling makes apps “real”

Tool calling is how you build features that aren’t just text:

  • ground answers in real documents (retrieval),
  • fetch data from your system of record (tickets, orders, inventory),
  • run validations and computations,
  • execute workflows with explicit steps (planner → executor),
  • reduce hallucination by using authoritative sources.

But you only get these benefits if you design tools cleanly and handle failure modes explicitly.

The risks (and why you must design guardrails)

Tool calling introduces predictable risks:

  • tool misuse: the model calls a tool with bad parameters
  • side effects: accidental writes, duplicate actions, unintended changes
  • runaway loops: repeated calls, retry storms, infinite plans
  • prompt injection via data: untrusted documents instruct the model to call tools
  • data leakage: tools return sensitive data which is then echoed

Section 16.5 is dedicated to preventing these failures.

Never let tools be “whatever the model wants”

Tools should be narrow, validated, logged, and budgeted. Otherwise you’re building an unsafe agent, not a product feature.

Section 16 map (16.1–16.5)

Where to go next