Function calling
Function calling lets a model request a named function by returning structured arguments that an application, or the provider, then runs.
Function calling is how a model asks your software to fetch data or take an action. You describe each function up front, with a JSON schema for its inputs. The description should say what the tool does, when to use it and what each parameter means. When a request needs a function, the model stops writing text and returns the function name with the arguments filled in. Your code runs it and sends the result back in a second request.
The same feature has two names. Anthropic calls it tool use. A tool choice setting decides whether the model may call any function, must call one, or must call a particular one. Strict mode makes the arguments follow the schema every time instead of on a best-effort basis. With strict mode, a booking field that needs a number of passengers arrives as the number 2, not the text “two”. A model can also ask for several functions at once when the calls do not depend on each other.
Some tools run on the provider’s side, such as web search and code execution. For those tools you do not run anything. The provider does the work and returns the result.
A model only has its prompt and its training until another system fetches data or takes an action.
Follow one weather question out to your code and back.
- 1 · describeYou send the model a list of functions, each with a name, a description and a JSON schema for its inputs.
- 2 · chooseInstead of a finished answer, the model can return a tool call, a function name plus filled-in arguments.
- 3 · runYour application runs the function, because the model never executes it.
- 4 · answerYou send the output back, and the model writes a reply or asks for another call.
The model fills in the call. For a function you defined, your code is what runs it.
| Who | What they ask | What it works with |
|---|---|---|
| Travel app | “What is the weather in Paris today?” | A get_weather call with location set to Paris |
| Shop support | “Refund this lost order.” | An order id passed into a refund function |
| Account page | “What plan is this user on?” | A user id passed into an account lookup |
| Research chat | “What is the latest on this topic?” | A provider web-search tool, run on the provider's side |
- The model can reach data outside its training, such as today's weather, through your functions.
- Your code can carry out an action the model only proposed, such as a refund.
- With strict mode on, your function receives arguments of the types it expects.
- Several independent calls can be requested in a single turn.
- For functions you define, the model runs nothing. Your code does the work and returns the result.
- If a required detail is missing, a model may guess a value the user never gave.
- Tool definitions are not free. Each one takes up room in the model's context and is billed as input tokens.
- A short, vague description leaves the model unsure how the tool behaves and when to use it. The description is the biggest single lever on tool performance.
Sources used
This explainer is written in original language. The links below support its factual claims.
- docsFunction calling, OpenAI · read 27 Sept 2026
- docsTool use with Claude, Anthropic · read 27 Sept 2026
- docsFunction calling with the Gemini API, Google · read 27 Sept 2026
- docsStrict tool use, Anthropic · read 27 Sept 2026
- docsDefine tools, Anthropic · read 27 Sept 2026