Tool use and function calling

Tool use is the way a language model asks for something to be done in the world. The model cannot act on its own, so it writes a structured request, a separate program runs that request, and the result comes back as text the model can read and reason over. Function calling is the common name for the mechanics of that exchange.

A model only produces text

Start with what a language model actually is. It is a program that has been trained to continue text. You give it some words and it predicts, one piece at a time, what words are likely to come next. That is the whole of its native ability. It reads a run of characters and it writes a run of characters. It does not open files. It does not send anything over a network. It does not run other programs. It has no hands.

This is easy to forget, because a good model sounds like it knows things and can do things. Ask it the capital of a country and it answers. Ask it to add two numbers and it usually gets them right. But every one of those answers is the model continuing text from what it learned during training. Nothing it says has been checked against the world at the moment you ask. If the fact changed after the model was trained, the model does not know. If you ask it what is in a file on your own computer, it cannot look. It can only guess from the words in front of it.

So there is a gap. On one side is a model that is good at reading and writing text and at reasoning over what it reads. On the other side is everything that is not text the model already holds: the live web, a database, the files on your disk, a calculator that never makes arithmetic slips, the ability to run a piece of code and see what it prints. The model needs a way to reach across that gap, and it needs it to be a way that fits its one native ability, which is producing text.

The idea of a tool

A tool is any action outside the model that can be described and run on the model’s behalf. Searching the web is a tool. Reading a file is a tool. Running a snippet of code is a tool. Looking up a customer record in a database is a tool. What these have in common is that each one takes some input, does something the model cannot do itself, and produces a result.

The model never runs the tool. It cannot. Instead there is a second program, which we will call the host, that sits around the model and does the actual running. The host is ordinary software written by a person. When the model wants a tool run, it does the only thing it can do: it writes text. But it writes a very particular kind of text, a structured request that names the tool and lists the inputs. The host reads that request, runs the real tool, and writes the result back into the conversation as more text. The model reads the result and carries on.

Think of the model as a brilliant advisor locked in a room with a slot in the door. The advisor can think and write, but cannot leave. To learn today’s weather, the advisor writes a note, “please tell me the weather in Chennai,” and slides it through the slot. An assistant outside reads the note, checks the weather, writes the answer on the back, and slides it back. The advisor never left the room and never touched the outside world. It only wrote a request and read a reply. Tool use is that slot in the door, made precise enough for software to rely on.

How function calling works, step by step

The mechanics have a standard shape. It is called function calling because each tool is described to the model the way a function is described in programming: a name, and a list of inputs it expects. Here is the full round trip.

1. The host tells the model, up front, which tools exist. For each one it gives a name, a short description of what it does, and a description of the inputs it takes.
2. The user asks for something. The model, reading the request and the list of tools, decides whether a tool would help. If it can answer from what it already knows, it just answers.
3. If a tool is needed, the model does not answer in plain prose. It emits a structured request naming one tool and filling in its inputs, for example the tool search with the input query set to a phrase.
4. The host sees that request, pauses the model, and runs the real tool with those inputs. It runs actual code: it calls a search service, opens a file, executes the snippet.
5. The host takes whatever the tool produced and writes it back into the conversation as a tool result, labeled so the model knows which request it answers.
6. The model reads the result as new text and continues. It may now answer the user, or it may decide it needs another tool and go around the loop again.

The important thing to see is where the boundary sits. The model chooses the tool and the inputs. The host does the doing. The model never gains any new ability of its own between one turn and the next. All that changed is that some text it could not have known before, the weather, the file’s contents, the output of the code, is now sitting in front of it, and it is very good at reasoning over text.

The model decides what to do. The host does it. Tool use is the disciplined handoff between the two, and it is made entirely of text.

What a tool description actually contains

For the model to request a tool correctly, it has to be told about the tool in a form it can act on. That description is called a schema. A schema states the tool’s name, what it does, and the shape of its inputs: which inputs there are, what type each one is, which are required, and often a sentence explaining each. It is a contract. It says, if you want this tool run, here is exactly the information you must supply.

A tool for reading a file might be described roughly like this in plain terms: name, read_file; description, returns the contents of a text file on the local disk; input, a single required field named path, which is the location of the file as text. That is enough for the model to form a valid request: call read_file with path set to the file it wants. It is also enough for the host to check the request before running it, since the host knows a path is required and knows it should be text.

Schemas matter for a second reason beyond correctness. They keep the model honest about the boundary of the possible. The model can only request tools it has been given. If no tool for sending email exists in the schema list, the model has no way to send email, no matter what it writes. The set of schemas is the exact set of actions available, which is why a host that cares about safety is careful about which tools it offers in the first place.

Why good descriptions matter more than they seem

The description attached to a tool is not decoration. It is the only thing the model reads to decide when to reach for that tool and how to fill in its inputs. The model has no other window into what the tool does. It cannot read the tool’s code. It cannot try the tool to see what happens. It has the name and the sentence you wrote, and from those alone it must judge whether this is the right tool for the moment.

So a vague description produces vague behavior. Imagine two tools, one described as “get data” and another described as “get data 2.” A person could not choose between those, and neither can the model. Now imagine the same two tools described as “look up a customer by their email address” and “look up a customer’s most recent order by customer id.” Suddenly the choice is obvious, to a person and to the model alike, because the description says precisely what the tool is for and what it needs. The same care that goes into naming a function well goes into describing a tool well, and for the same reason: the next reader has to pick the right one without guessing.

The inputs deserve the same care. If a date input just says “date,” the model may send it in any format it likes and the tool may reject it. If the input says “date as year, then month, then day, for example 2026-01-31,” the model has a pattern to follow and the requests come out usable. Writing tool descriptions well is one of the quieter skills in this whole field, and it pays off directly, because a badly described tool is a tool the model uses at the wrong time and with the wrong inputs.

Three concrete tools

Abstract talk about tools gets clearer with real ones. Consider three that show the range.

The first is search. The model is asked about an event more recent than its training. It has no way to know the answer, and its honest options are to guess or to reach for a tool. With a search tool available, it emits a request naming search with a query. The host runs the query against a real search service, and the pages or snippets come back as text. The model, which was blind to anything recent, can now read current results and answer from them. The model did not get smarter. It got informed.

The second is running code. Ask a model to compute a long arithmetic expression and it may slip, because it is predicting the answer rather than calculating it. Give it a tool that runs a snippet of code and returns what the code prints, and the picture changes. The model writes the calculation as a tiny program, requests the run-code tool, and the host actually executes it. The result that comes back is not a guess. It is what the computer computed. The model has offloaded the part it is weak at, exact calculation, to a tool that is exact by nature.

The third is reading a file. A model asked what a project’s configuration says cannot see the file. With a read-file tool, it requests read_file with the path, the host reads the bytes off disk, and the contents arrive as text. Now the model can answer from the real file rather than from a plausible-sounding invention. This last example is the doorway to a much larger idea, because reading a file is one small thing an agent might do, and real work usually needs many such tools working together.

From one host’s tools to a shared standard

There is a catch hiding in everything above. Each host invented its own way of describing tools and passing results. A tool built for one application’s model would not simply work in another’s, because the two spoke different dialects for the same idea. If you wrote a read-file tool for one assistant, you often had to write it again, differently, for the next. The mechanics of function calling were shared in spirit, but not in form, and that meant the same integrations were built over and over.

This is the problem the Model Context Protocol was made to solve. The Model Context Protocol, usually shortened to MCP, is an open standard introduced by Anthropic in November 2024 that lets any AI model reach external tools and data through one common interface. Instead of every application inventing its own dialect, a tool can be offered once, in the standard’s shape, and any model whose host speaks the standard can use it. It has been adopted well beyond Anthropic’s own tools.

The value is the same as any shared standard, whether a power socket or a common file format. Build a tool once and many different clients can use it. The plain idea underneath is exactly what this page described: a model emits a structured request, a host runs the real action, and the result comes back as text. MCP does not change that mechanism. It agrees on the form of the request, the form of the description, and the form of the result, so the mechanism works across the whole ecosystem rather than inside one application.

With that, the picture is complete. A model produces only text. Tools let it reach past that limit by asking for actions it cannot perform, described by schemas it reads, run by a host it does not control, with results returned as text it can reason over. When a model uses several tools in sequence, choosing each next step from what the last result told it, it starts to look less like a chatbot and more like something that pursues a goal. That shift, from a single answer to a loop of decisions and actions, is the subject of what an AI agent is, and the standard that carries these tools between applications is the subject of the Model Context Protocol.