Function calling—also called tool calling or tool use—is the capability that lets a large language model (LLM) ask your application to run a specific piece of code. You describe the available functions to the model with a name, a plain-language description, and a JSON Schema for the parameters. When a user request needs one of those functions, the model does not answer in prose; it returns a structured call such as get_order_status({"order_id": "A-1042"}). Your code executes the function, sends the result back, and the model uses it to write the final answer.

Why it matters now: every serious AI agent, from customer-support bots to coding assistants, is built on this loop. It is the mechanism that turns a text generator into software that can query a database, call an API, or update a record. Both OpenAI’s function calling guide and Anthropic’s tool use documentation treat it as a core API feature, and higher-level standards such as the Model Context Protocol (MCP) are built on top of it.

The Key Idea: The Model Never Runs Your Code

The most common misconception is that the LLM executes the function. It does not. The model only proposes a call—a function name plus arguments in JSON. Your application (often called the harness or orchestrator) decides whether to run it, validates the arguments, executes it, and returns the output. That separation is what makes function calling safe enough for production: you stay in control of permissions, rate limits, and side effects.

How the Function Calling Loop Works

1. Define the tools

Each tool has a name (search_flights), a description the model reads to decide when to use it, and a parameter schema (origin, destination, date, with types and required fields). Clear descriptions matter as much as the code: the model chooses tools based on that text.

2. The model decides

You send the user message plus the tool definitions. The model either answers directly or responds with one or more tool calls. OpenAI signals this with a tool_calls finish reason; Anthropic returns tool_use content blocks with a tool_use stop reason. The concept is identical; only the field names differ.

3. Your code executes

Your application parses the arguments, checks them against the schema and your business rules, and runs the real function—a SQL query, an HTTP request, a calculation.

4. Return the result

You send the function output back to the model, linked to the original call ID. The model can then answer the user, or request another tool call. Agents are simply this loop repeated until the task is done.

Controlling Which Tools the Model Uses

Most APIs offer a tool choice setting: let the model decide (auto), require at least one tool call, force a specific function, or disable tools. Many models also support parallel tool calls, requesting several independent functions in one turn—for example, checking weather in three cities at once. And strict schema modes constrain the model so its arguments always validate against your JSON Schema, which removes a whole class of parsing errors.

Function Calling vs. Related Concepts

Structured outputs force the model’s final answer into a JSON shape; function calling is about requesting an action mid-conversation. MCP standardizes how tools are discovered and exposed across applications, so one server can offer the same tools to many AI clients; under the hood, the model still uses function calling to invoke them. RAG retrieves documents to ground answers, and retrieval itself is often implemented as just another tool the model can call.

Real-World Use Cases

Support agents that look up orders and issue refunds within policy limits. Analytics assistants that translate questions into SQL against a governed warehouse. Sales copilots that read and update CRM records. Internal automation that files tickets, schedules meetings, or posts summaries. Coding agents that read files, run tests, and apply edits—each action a tool call.

Risks and Best Practices

Treat arguments as untrusted input. A model can be manipulated into calling tools with harmful arguments, especially when it processes outside content. Read our explainer on prompt injection to understand the attack.

Least privilege. Give each tool only the access it needs: read-only database users, scoped API tokens, and allowlisted actions.

Human approval for irreversible actions. Payments, deletions, and outbound messages should require confirmation. Our guide to AI guardrails covers patterns for this.

Keep the toolset small and well described. Dozens of overlapping tools confuse models; a few clearly named ones with precise descriptions work better.

Log and evaluate. Record every call, argument, and result. Build test cases that check whether the model picks the right tool with the right arguments, as explained in our article on AI evals.

If you want to build AI agents that call real tools safely and work with real company data, explore Coderhouse’s courses below.

• AI Engineering Course — design tool-using agents, function schemas, and evaluation loops for production.

• Data Analytics Course — learn the SQL and data skills behind the queries and metrics your agents call.

FAQ

Is function calling the same as tool use?

Yes, in practice. OpenAI and Google use the term function calling, while Anthropic calls it tool use. Both describe a model emitting a schema-compliant request for your code to execute.

Do all LLMs support function calling?

All major commercial models and many open-weight models do, but reliability varies. Test tool selection and argument accuracy with your own functions before going to production.

How many tools can I give a model?

There is no universal limit, but accuracy usually drops as the list grows and tool definitions consume context. Start with a handful, group related actions, and load tools dynamically when an agent needs many.