JOVANA
Explore Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
All guides

Giving the Model Hands: Tools and Function Calling

How a text model reaches outside itself — the function-calling handshake, and the toolbox: code, the web, and the whole computer.

The handshake: how a model calls a function

A language model can only produce text — so how does it "call" code? The trick is a contract. You describe each available tool to the model as a structured schema (a name, what it does, and the arguments it takes). When the model wants to use one, instead of normal prose it emits a structured request naming the tool and filling in the arguments. Your code — not the model — actually runs the function and feeds the result back. This pattern is function calling, the backbone of modern tool use.

// You give the model this tool definition:
{
  "name": "get_weather",
  "description": "Current forecast for a city at a given time.",
  "parameters": {
    "city": "string",
    "when": "string (ISO time)"
  }
}

// The model, when it decides to use it, emits:
{ "call": "get_weather", "args": { "city": "Taipei", "when": "2026-06-26T15:00" } }

// YOUR code runs get_weather(...) and returns the JSON result to the model.
The function-calling contract: you declare tools; the model requests one; your runtime executes it.
The function-calling handshake as a loop: the model reasons and proposes a tool call, your code executes it, and the result is observed before the next step.

Diagram of an LLM agent loop cycling through reason, act, and observe stages.

Choosing the right tool — and getting the arguments right

Give a model ten tools and two jobs appear: pick the correct one, and fill its arguments faithfully. Picking is tool selection, and it is mostly a prompting problem — clear, non-overlapping tool descriptions make selection easy; vague or near-duplicate tools make the model dither or pick wrong. Many production stacks force the arguments to be valid by constraining the output to a fixed shape (often via a JSON schema), so the model can't emit a half-formed call.

  1. Keep the toolset small and orthogonal — each tool should do one clearly distinct thing.
  2. Write descriptions for the model, not for other engineers: say when to use it and when not to.
  3. Validate the arguments before executing; on a bad call, return a clear error so the model can correct itself.
  4. Log every call and result — you will need this trace to debug why the agent did what it did.

The starter toolbox

Three tools show up so often they are almost a default kit. A code interpreter lets the model write and run code in a sandbox — superb for math, data wrangling, and anything where running beats guessing. A web browsing tool lets it fetch live pages and search the open web, the cure for a stale knowledge cutoff. And computer use goes furthest: the model sees a screen and controls a mouse and keyboard, operating ordinary software that has no API at all.

Web browsing turns a tool into retrieval: the model fetches external pages and grounds its answer on what it brings back.

Retrieval-augmented generation pipeline: a query retrieves documents that are fed into the model to produce a grounded answer.

Notice the ladder of power and risk. A code interpreter is sandboxed and fairly contained. Web browsing reaches the live internet, where pages can carry hostile instructions. Computer use can touch anything on the machine. More reach means more capability and more ways to cause harm — which is why later guides spend real time on recovery and human oversight.

One protocol to plug them all in

If every team invents its own way to expose tools, every agent has to be wired by hand. The Model Context Protocol (MCP) is an open standard that fixes this: a tool provider runs an MCP server that advertises its tools, resources, and prompts in a uniform shape, and any MCP-aware agent (the client) can discover and call them without bespoke glue. Write a tool once as an MCP server and any compatible agent can use it.