Skip to main content
The Human Bit

Concept guide · How AI works

How an AI actually does something, instead of just talking about it.

A model on its own cannot check today's weather, read your database or send an email. It can only produce text. Tool calling is the arrangement that lets it ask your software to run a real action and then use the result.

You describe the actions. The model asks for one precisely. Your software runs it and hands back the result.

What it actually is

Anthropic's documentation puts it plainly: "Claude determines when to call a tool based on the user's request and the tool's description. It then returns a structured call that your application executes." Instead of guessing an answer, the model hands back a precise, machine-readable request for one of the actions you defined.

The proof: a trace of one call

Here is the round trip from the documentation, using a single tool. You can read every step.

  1. You define a tool called get_weather that needs a location.
  2. You ask: "What's the weather in San Francisco?"
  3. The model does not answer in prose. It returns a structured call: get_weather with {"location": "San Francisco, CA"}.
  4. Your code runs the real lookup and returns the result: "15 degrees Celsius, partly cloudy."
  5. Now the model answers the original question in plain words, using that result.

The step that matters is the middle one. It is a request your software can run, not a sentence, and it is the difference between doing and describing.

What happens when a call goes wrong

A call can fail: a service is down, or a required detail is missing. The tools are built to signal an error and let the model try again or ask you. There is a known trap here. If you leave out a needed detail, a stronger model "is much more likely to recognize that a parameter is missing and ask for it," while a weaker one "might also infer a reasonable value," which is a polite way of saying it may quietly guess.

Try it now

Watch for a real action
  1. Pick an assistant you use that has a connector or tool, such as a calendar or a search action.
  2. Ask it to do one thing that needs the tool, then read the reply.
  3. Go and look at the real system, the calendar or the inbox itself.
Check: If the reply said "done" but the calendar did not change, it talked instead of acting. A real tool call leaves a real result you can see in the other system, not just in the chat.

The decision this gives you

Make something a tool when the action is real, checkable and has a clear shape: a lookup, a calculation, a booking, a record update. Leave it to the model's words when the part you want is judgement, drafting or explanation. Words are for thinking. Tools are for doing.

Common mistake

Believing that because the model said it did something, it did. With no tool wired up, "I have scheduled that for Tuesday" is just a well-phrased sentence. The action only happened if a tool ran.

The human bit

You decide which actions the model may take on its own and which must wait for your approval, and you check the real system rather than the chat. The line before anything that sends, pays or deletes is a person, not a tool.

Where this stops being exact

Some tools run in your own application and some run on the provider's servers, which changes who sees the data. Whether a given action needs your approval is a design choice you make, not a default. And the guessing-a-missing-value behaviour varies by model and by how clear your request is.

Official source

Use this in the product

The Human Bit Weekly

The useful changes, not every launch.

One short issue every Monday. What changed, what it means for your work, and the part that stays yours.

The Human Bit records when and how consent was given. Subscription is confirmed only after the email provider accepts the request.