L1Reviewed 2026-07-19

Tool use and function calling

Letting a model call APIs or functions instead of only writing text.

What you'll learn

  • Explain tool use as structured outputs executed by your code.
  • Design JSON schemas that describe parameters and constraints.
  • Handle tool results by feeding them back into the next model turn.

In plain English

Tool use means the model can request actions—search the web, query a database, run code, send email—instead of only chatting. Your application executes the action and returns results to the model.

Function calling is the API pattern: you publish a list of functions with names and parameter schemas; the model emits a machine-readable call; your server runs it safely.

How it works

You register tools with descriptions the model reads in context. When the model outputs a tool call (often JSON with function name and arguments), the host validates arguments, runs the function, and appends a tool-result message. The model then continues with real data.

Good tool design uses clear names, typed parameters, idempotent reads where possible, and human approval for destructive writes.

Function-calling round trip—model requests tool; host executes and returns result.
python
tools = [
    {
        "name": "get_weather",
        "description": "Get current weather for a city",
        "parameters": {
            "type": "object",
            "properties": {"city": {"type": "string"}},
            "required": ["city"],
        },
    }
]

def get_weather(city: str) -> dict:
    # Real app calls a weather API
    return {"city": city, "temp_c": 22, "conditions": "clear"}

# 1) Model returns (conceptual):
model_call = {"name": "get_weather", "arguments": {"city": "Denver"}}

# 2) Host executes
if model_call["name"] == "get_weather":
    tool_result = get_weather(**model_call["arguments"])

# 3) Feed result back into the next prompt turn
messages = [
    {"role": "user", "content": "What is the weather in Denver?"},
    {"role": "assistant", "tool_calls": [model_call]},
    {"role": "tool", "content": str(tool_result)},
]
# Next LLM call uses messages to answer the user in plain language

Going deeper

Models may hallucinate tool names or arguments; validate strictly against schema and reject unknown calls.

Parallel tool calls and streaming UX are product concerns—the contract is still observe results, then decide again.

Common misconceptions

The model executes tools inside its weights.
Execution always happens in your infrastructure; the model only emits requests.
Detailed tool docs guarantee valid JSON.
Always parse and validate; retry or repair on schema failures.

Key facts

  • Tools extend LLMs with actions via structured call objects.
  • Schemas describe parameters for validation and model guidance.
  • Tool results are messages in the ongoing conversation state.
  • Permissions and approvals live outside the model.
  • Invalid or unsafe calls should fail closed with clear errors.

Sources used

These free resources informed this page. ANN writes original explainers; we do not copy course text behind paywalls.

Also explore AI companies, Live Feed, and Weekly Brief.