Wiki
Core11 min read

Tools and function calling

A tool is a typed function, and its description is the interface the model reads to choose it. Get the schema wrong and the agent fails before it reasons.

A tool is a function with a name, typed parameters, and a description. The runtime advertises the toolset to the model; the model emits a structured call like {"name": "get_weather", "args": {"city": "Pune"}}; the runtime validates it, executes it, and returns the result as an observation. The model never runs anything — it only asks, and the harness decides whether and how to honour the ask.

Start here

The model picks a tool by reading its description, the same way it picks the next word by reading context. A precise description is not documentation for humans — it is the prompt that determines whether the right tool gets called. A vague one is a bug that shows up as random behaviour.

The model picks a tool by reading its description

get_weatherscore 0

Gets weather.

send_emailscore 0

Sends stuff.

search_ordersscore 0

Looks up things.

No description matches the request — the choice is a coin flip, so the agent may call the wrong tool and burn a loop recovering.

Toggle to vague descriptions and watch a perfectly answerable request become a guess. Tool choice is prompt-driven: the schema is the interface, and a vague description is a bug. This overlap score is a stand-in for a real model's reading — illustrative, not a benchmark.

Toggle the descriptions between vague and precise on the same request and watch a well-specified call turn into a guess. This is why tool design is prompt engineering with a schema attached.

Anatomy of a call

  • Name and description — what it does and, crucially, when to use it. Write the "when" explicitly; models overweight it.
  • Typed parameters — types, required vs optional, enums, ranges. The schema constrains the model's freedom before it acts.
  • The emitted call — structured output, not prose. Modern models can emit several calls in one turn, which the runtime can run in parallel.
  • Validation — the harness checks the call against the schema before executing. A malformed call becomes an error observation the model can correct, not a crash.

Design rules that matter in practice

  • Few, sharp tools beat many overlapping ones. If two descriptions could both fit a request, the model will pick the wrong one roughly half the time.
  • Read-only tools liberally, mutating tools narrowly. Fetching is cheap to get wrong; deleting is not (the safety chapter returns to this).
  • Make errors legible. "Invalid city" is a better observation than a stack trace — the model can act on the first and not the second.
  • Idempotency is your friend. Retries happen; a tool that charges a card twice on a retry is a design flaw, not a model flaw.

Careful

Never trust raw model output. The schema is a contract, and the harness enforces it: validate every argument, reject unknown fields, and treat a schema violation as a correctable error rather than an exception. Tools are the agent's attack surface — anything reachable through a tool is reachable by whatever text influenced the model (the injection lesson is the other half of this).

Check yourself

Eduspheria wiki · Agentic AI, Foundations

0 / 4 answered

  1. 1What does the runtime do with a tool call before executing it?
    Multiple choice
  2. 2A tool's description is documentation for humans only and does not affect which tool the model picks.
    True / false
  3. 3What property makes a tool safe to retry — the same call does not charge a card twice?
    Short answer
  4. 4Which toolset design reduces wrong tool choices?
    Multiple choice

Next: the resource the whole loop spends — context.