Function Calling (Tool Use)

Function calling (also called tool use) is a capability that lets an LLM go beyond generating text and instead trigger real actions in external systems — calling an API, querying a database, running a calculation, or executing code — by outputting a structured, machine-parseable request (typically JSON) specifying which function to call and with what arguments, which your application then actually executes and feeds the result back to the model to continue reasoning or respond to the user. This is the mechanism that turns an LLM from a "text in, text out" system into one that can interact with the real world: without function calling, an LLM asked "what's my account balance" can only guess or refuse; with function calling, it can invoke a `get_account_balance(user_id)` function you've defined, receive the real number back, and answer accurately. This matters enormously for SaaS builders because it's the foundational primitive underneath every AI feature that does something beyond conversing — booking assistants, data-lookup chatbots, autonomous coding agents, and any "AI that takes action" all rely on function calling as the bridge between the model's reasoning and your actual systems. The mechanics: a developer defines a set of available functions with names, descriptions, and typed parameters (a schema the model uses to understand what's available and when to use it); when the user's request requires one of these functions, the model doesn't call it directly — it outputs a structured request indicating the function name and arguments, your application code executes the actual function against your real backend, and the result is sent back to the model as a new message so it can incorporate that real data into its final response. A concrete worked example: a SaaS scheduling assistant is given a tool definition `{"name": "check_calendar_availability", "parameters": {"date": "string", "duration_minutes": "integer"}}`. A user asks "can I meet with Sarah tomorrow afternoon for 30 minutes?" The model recognizes it needs real data it doesn't have, and outputs `{"tool_call": "check_calendar_availability", "arguments": {"date": "2026-07-03", "duration_minutes": 30}}`; your application executes this against the real calendar API, gets back `{"available_slots": ["14:00", "15:30"]}`, sends that back to the model, and the model replies to the user: "Yes — Sarah is free tomorrow at 2:00 PM or 3:30 PM for 30 minutes. Want me to book one?" Function calling is also the underlying mechanism that powers MCP (Model Context Protocol), which standardizes how tools are exposed to models across different applications. Function/tool definitions benefit from the same design discipline as a well-documented API: clear, specific descriptions of what each function does and when to use it (not just its parameter types) measurably improve how reliably a model selects the right tool and fills in correct arguments — a poorly described `search(query)` function invites inconsistent use, while `search_customer_invoices(customer_id, date_range)` with an explicit description of exactly what it searches gives the model far less room for error. Builders should also validate and sanitize tool arguments the model provides before executing them against real systems, exactly as they would validate any other untrusted input, since a model can occasionally produce malformed or unexpected argument values that shouldn't be trusted blindly just because they came from an AI.