Function Calling — When AI Presses Buttons

In the previous article you saw how RAG gives a language model access to fresh documents. But reading documents is still passive — like giving someone a reference library while chaining them to a desk. What if the model could actually do things — check live data, trigger workflows, send messages?

Function Calling is the mechanism that makes this possible. It does not make the AI smarter — it gives the AI hands. This article shows exactly how that works: why the model needs tools, how tools are defined, and how the complete loop from question to real-world action operates under the hood.

The Limitation of Text — Why LLMs Have No Arms

Picture a superintelligent brain floating in a nutrient jar on a laboratory table. It can think brilliantly — compose strategies, write poetry, solve equations. But it has no eyes, no ears, no hands. When you tell it "Send an email to Sarah," it can draft the perfect message but cannot press the send button. It has no connection to the outside world.

That is exactly how large language models work: text in, text out. They predict the next token based on statistical patterns from their training data. They have no mechanism to access external systems, execute code, or perceive real-time information. RAG partially addressed this by injecting relevant documents into the context — but RAG is passive: it provides knowledge, not agency.

Same question, same model — radically different reliability. In the first case, the model hallucinates a statistically plausible answer because its training signal rewards plausible text continuation, not epistemic honesty. In the second case, the hallucination is replaced by real data.

Unlike a real brain in a jar that would recognize its own limitations ("I cannot see — I am in a jar"), an LLM lacks this self-awareness. It hallucinates because its training signal rewards producing plausible answers — not admitting ignorance.

The Tool Inventory — JSON Schema as Contract

Before a model can use tools, a developer must declare them using a JSON schema (JSON is a standardized text format that computers use to exchange data) sent alongside every API request. Each tool definition has three components: a unique technical identifier (name), a natural-language explanation (description), and a parameter definition (parameters). The model reads these definitions and dynamically decides — for each user message — whether any tool is needed and which one.

{
  "tools": [{
    "name": "get_weather",
    "description": "Returns current weather
      for a city. Use when user asks about
      weather, temperature, or outdoor
      conditions.",
    "parameters": {
      "type": "object",
      "properties": {
        "city": { "type": "string" },
        "unit": { "enum": ["celsius","fahrenheit"] }
      },
      "required": ["city"]
    }
  }]
}

The quality of the description determines everything. A vague description like "database function" causes the model to ignore the tool even when the user asks a relevant question. A precise description like "Executes a read-only query against the orders database. Use when the user asks about order counts, revenue, or customer data" enables correct tool selection.

The Execution Loop — From JSON to Agent

Function Calling alone is only half the story. The complete architecture is a four-step loop that can repeat — and it is precisely this repetition that transforms a chatbot into an agent.

A simple example: The user asks "What is the weather in Berlin?" The model decides it needs the get_weather tool and generates the appropriate JSON call. The developer code receives the JSON, calls the real weather API, and gets "15 degrees, cloudy." This result is passed back to the model as a new message. The model formulates: "It is currently 15 degrees and cloudy in Berlin."

The real power shows in chaining: "Plan my day in Berlin tomorrow." The model calls get_weather ("12 degrees, light rain"), check_calendar ("No appointments"), and search_indoor_activities ("Museum Island, Philharmonie, ...") in sequence. Each loop iteration provides the model with new information that shapes its next decision.

The AI is like a CEO sitting in a corner office. Your developer code is the executive assistant in the outer office. The CEO says: "Call client Mueller and ask about the delivery date." The assistant picks up the phone, dials, gets the answer "Delivery on Friday," and relays it back. The CEO turns to the visitor and says: "Mueller delivers Friday." The visitor thinks the CEO knows everything — but the assistant did the real work behind the scenes.

This article showed how Function Calling gives a language model the ability to act — from passive text generation to active world interaction. The next article in the path shows how APIs and MCP standardize and scale the tool ecosystem.

Interactive: How a Function Call Works

Step through a complete Function Calling flow — from the user question through tool selection to the final answer. Watch how the call stack grows and shrinks at each step.

In the next article you will learn how APIs and the Model Context Protocol (MCP) standardize this tool infrastructure — so that not every developer has to reinvent the wheel.