What is Function Calling?
Definition
Function calling, also called tool use, is a mechanism in which a language model responds not with prose but with a structured request, usually JSON, to call a function the application has defined, along with the arguments to pass. Each function is described by a name, a description and a JSON Schema for its parameters. The application, not the model, executes the call and returns the result to the model.
Also known as: tool use, tool calling, LLM tool use, function call, tool invocation

The model asks; your code acts
The most common misunderstanding is that the model runs code on your server. It doesn't. It produces a structured message that amounts to “I'd like to call this function with these arguments”. Your application reads that message, validates it, actually runs the function and sends the result back. That split is the basis of both security and debugging: control always stays with the application.
Vendors use different names for the same idea. OpenAI calls it function calling and also refers to it as tool calling; Anthropic calls the mechanism tool use. Field names differ, but the shape is the same: a name, a description and parameters defined in JSON Schema.
Defining a tool
This definition lets a shop assistant look up an order. The parameter block is standard JSON Schema; in Anthropic's API it goes in input_schema, in OpenAI's in parameters:
{
"name": "get_order_status",
"description": "Returns shipping and delivery status for an order. Use only when the user has given an order number.",
"input_schema": {
"type": "object",
"properties": {
"order_id": {
"type": "string",
"description": "Order number starting with UK-, e.g. UK-48213"
}
},
"required": ["order_id"]
}
}When a user asks “Where's order UK-48213?”, the model replies with a call instead of text, something like:
{ "name": "get_order_status", "input": { "order_id": "UK-48213" } }The description is not decoration. The model decides when to use a tool largely from that text, and a vague description leads to a tool being called at the wrong moment, or never.
The request loop
- The application sends the user's message to the model along with the definitions of the available tools.
- The model either answers directly or returns one or more tool calls.
- The application validates the arguments and runs the function on its side, typically an API request or a database query.
- The result goes back to the model, matched to the call's ID.
- The model uses the result to write its answer, or asks for another tool.
Repeat that loop several times, let the model decide which tool to use in what order, and you have an AI agent.
Rules for using it safely
- Always validate arguments. Some APIs offer a strict mode that forces calls to match the schema exactly, but business rules (does this order belong to this user?) still have to be enforced server-side. JSON that parses is not the same as a request that is allowed.
- Base authorisation on the session, not on the model. The user's identity should come from the authenticated session, never from an argument the model filled in.
- Confirm side effects. Tools that charge money, delete records or send email shouldn't run without user confirmation. Idempotency keys stop a retried call from doing the same thing twice.
- Treat tool output as untrusted. Text returned from a web page or an email can contain instructions aimed at the model, a risk known as prompt injection.
Function calling is the contract between a model and one application. Discovering and offering tools from many independent servers in a standard way is what the Model Context Protocol adds.

