Function calling and tool use
It is the bridge to agentic AI: the model stops just talking and starts executing real actions on your application.
Reading time: 3 min
Function calling (tool use)
Function calling (or tool use) is the model's ability to ask for a function in your code to be executed. You describe which tools it has available and, when a request calls for it, the model responds with a structured call (the tool name and its arguments) instead of text.
The key point is that the model executes nothing: it only decides which tool to use and with which arguments. Your code runs it, with your permissions and your validation, and returns the result so the model can carry on. That is how the model goes from just talking to being able to query data and act on the application.
JSON Schema for tools
Each tool is defined with a name, a description and a schema of its arguments in JSON Schema: which fields it has, their types, which ones are required and which values they accept (for example, an enum with the possible statuses of an order).
The description is not decorative documentation: it is what the model reads to decide when to use the tool and how to fill in its arguments. A good description explains when to use it and when not to. Strict schemas (types, enums, required fields) greatly reduce made-up arguments.
The agentic loop
The agentic loop is the cycle in which the model asks for a tool, the code runs it and returns the result, and the model decides whether it needs another one or can already answer. A single request ("what's the status of Maria's order and can she return it?") may take several rounds: finding the order, checking its status and reading the return policy.
This loop needs limits: a maximum number of steps and a maximum time. It also helps if tool errors come back as text the model can understand ("order not found: check the number"), so it can correct itself instead of failing.
OpenAPI to expose tools
OpenAPI (formerly Swagger) is the standard for describing REST APIs. Since it already describes endpoints, parameters and schemas, it is tempting to turn it directly into tools for the model.
Turning an entire API into tools is a well-known bad idea: dozens of endpoints with names and responses designed for programmers burn context and confuse the model when choosing. The pattern that works is a short layer of intent-oriented tools ("check_order_status", "create_return") on top of the API, with descriptions written for the model.
Test yourself on this module
Copy this prompt and paste it into your AI (ChatGPT, Claude, Gemini…). It will give you a 20-question multiple-choice test on the module's concepts and then suggest a hands-on exercise.
Act as the examiner for Dani Pérez's "AI Engineering Guide". Examine me on the module "Function calling and tool use" (https://daniperez.pro/en/resources/ai-engineering-guide/function-calling). Concepts covered by the exam: - Function calling (tool use) - JSON Schema for tools - The agentic loop - OpenAPI to expose tools Exam: 1. 20 multiple-choice questions, each with 4 options (a, b, c, d) and a single correct answer. 2. Ask about understanding and judgement (what each thing is for and when NOT to use it), not about memorising definitions. 3. Spread the position of the correct answer evenly across a, b, c and d. 4. Ask me the questions in 4 rounds of 5. Don't give any example answer (like "1a 2b 3c 4d 5a"): I already know to answer with the letters. Don't tell me whether I got them right until I have answered all 20. 5. At the end, mark them all: for each question, my answer, the correct one and a short explanation. Give me my score out of 20 and tell me which concepts I should review. Hands-on exercise (after marking): 6. Ask me what application I have or want to build, and which language and framework I work with. If I don't have one, use this: a customer support application for an online shop, with tickets, customers, orders and a knowledge base (FAQ and return policies). In that case, focus the exercise on: defining tools to check the status of an order and to create a return request, and letting the model choose which one to call based on the request. 7. Suggest an exercise that applies this module's concepts to that application: goal, requirements, criteria to consider it done and common mistakes to avoid. 8. Don't solve it for me. When I bring you my solution, review it against those criteria.