Tool use in AI models: How a chatbot learns to call apps and act

Tool use, also called function calling, is how an AI model asks other software to do something it cannot do alone. The model writes a structured request, such as “look up this weather” or “create this calendar event”. Ordinary program code then carries it out and hands back the result.

This is the layer beneath any assistant that acts instead of only replying. Bloomberg’s reporting on Apple, covered in our story on the push to turn Siri into a true AI agent, describes exactly that goal. Apple has not confirmed it, and nothing public says how Apple would build it.

A model that writes the order but never cooks the meal

Picture a waiter in a restaurant. The waiter takes your request, writes a ticket and passes it to the kitchen. The kitchen cooks. The waiter then brings the dish back and tells you about it.

The model is the waiter. It reads your message, decides a tool is needed, and writes a ticket. The kitchen is the application’s own code, which actually runs the action. The model never touches the calendar, the file system or the web by itself. It only produces text in an agreed format.

That separation is the key idea. It keeps the risky part, doing things in the real world, in ordinary software that developers can inspect and restrict.

The loop: Describe, request, run, report

OpenAI’s developer documentation lays out the flow in five steps. Anthropic’s documentation describes the same round trip for Claude.

1. The developer sends the user’s message along with a list of available tools. Each tool has a name, a plain-language description and a schema, which is a template listing the inputs it accepts.
2. The model replies with a tool call instead of a final answer. In Anthropic’s API this arrives as a tool_use block, and the response carries stop_reason: "tool_use".
3. The developer’s application runs the function with those inputs.
4. The application sends the output back. In Anthropic’s API this is a tool_result block.
5. The model writes a final answer, or asks for another tool.

Step 5 is what makes agents possible. Repeating the loop lets a model search, read the result, decide what to do next and act again. Both companies document that a single response can contain zero, one or several calls.

Where the idea came from

Language models are weak at things like exact arithmetic and up-to-date facts. In February 2023, Timo Schick and colleagues at Meta AI and collaborators published Toolformer (arXiv:2302.04761). It showed a model could teach itself to call a calculator, two search engines, a translator, a question-answering system and a calendar. The training was self-supervised and needed only a handful of demonstrations per tool. The authors reported better zero-shot results on several tasks, often matching much larger models.

A related line of work came from Shunyu Yao and colleagues in October 2022. Their ReAct paper (arXiv:2210.03629) had a model interleave written reasoning with actions, such as querying a Wikipedia API. This reduced the hallucination and error propagation seen in plain chain-of-thought reasoning on question answering and fact verification. On the ALFWorld and WebShop benchmarks, the authors reported absolute success-rate gains of 34% and 10% over imitation and reinforcement learning methods.

Model providers then turned the idea into a standard feature of their commercial APIs. Today OpenAI calls it function calling or tool calling, and Anthropic calls it tool use.

Who runs the tool, and what counts as one

Anthropic’s documentation separates two kinds of tools by where the code runs. Client tools run inside the developer’s application. That includes custom functions as well as Anthropic-defined ones such as bash and text_editor. Server tools, such as web_search and code_execution, run on the provider’s infrastructure, so the developer does not write the handler.

Tools are also how bigger agent features are built. Anthropic’s documentation lists computer control, memory and web fetching as tools. The Model Context Protocol, an open standard for connecting models to outside tools and data, gives tools a common plug shape so one tool can serve many models. On a phone, the equivalent would be exposing app actions to the assistant, which is the role of Apple’s App Intents framework.

Limits: Wrong guesses, crowded menus and real consequences

Tool use is only as reliable as the model’s judgment about when and how to call a tool. Anthropic’s documentation notes that when a required input is missing, some models may ask for it while others may guess a value, and that this is not guaranteed. A guessed city in a weather lookup is harmless. A guessed recipient in a payment is not.

Providers offer guardrails. Both OpenAI and Anthropic document a strict setting that makes calls match the declared schema. This ensures the format is valid. It does not ensure the model chose the right action. Both also let developers disable parallel calls and, in Anthropic’s case, force the use of a particular tool with tool_choice.

Cost and clutter matter too. Tool definitions count against the context limit and are billed as input tokens. OpenAI’s guidance suggests keeping fewer than 20 functions available at the start of a turn and using tool search for large sets.

Security is the other limit. Text returned by a tool is fed back to the model, so a malicious web page can try to steer it, an attack known as prompt injection. Permission checks therefore belong in the application code, not in the model’s good behavior.

What to watch as assistants start acting

The practical test for any new assistant, Siri included, is which tools it can reach and who approves each action. An assistant with a few well-defined tools and a confirmation step is a different product from one with open access to every app.

Watch three things. First, how many tools a model can handle accurately, since long menus hurt choice quality. Second, how providers standardize tool descriptions so one tool works across models. Third, how consent is designed for actions that spend money, send messages or delete data. Those details, more than model size, decide whether an “agent” is useful or risky.