What Is Tool Calling and How Do You Train for It?
Tool calling is the task type where a model maps a natural-language request to one structured function call with valid arguments. Set task: tool-calling-closed-book, give the platform your tool schemas plus a few dozen example calls, and the student learns the mapping instead of looking it up.
What is tool calling in a small language model?
It is constrained generation against a schema. The model does not produce prose; it produces a function name and an argument object that must validate against the JSON Schema you supplied.
“Closed-book” in tool-calling-closed-book means the tool catalogue is learned during training rather than retrieved at inference. You are not passing documentation in the prompt for the model to read — the routing logic is in the weights. That is what makes a 270M model a viable dispatcher: it does not have to reason about tools it has never seen, only about the fixed set it was trained on.
The typical shape of the job: a fixed set of backend functions, a natural-language front door, and a deterministic orchestrator that executes whatever call comes back.
How do you train a model for it?
Two files carry the whole task. The tool calling data preparation guide has the full spec.
job_description.json holds task_description plus tools, a list of JSON Schemas in OpenAI’s function-calling format. Constrain aggressively here — enum on string parameters and minimum/maximum on numbers do real work, because they tell the teacher what an invalid call looks like.
train.jsonl holds the examples. Each is a messages conversation whose assistant turn carries the call in tool_calls and omits content:
{"messages": [{"role": "user", "content": "Oven heated to 220°C, pizza ready to bake."}, {"role": "assistant", "tool_calls": [{"type": "function", "function": {"name": "put_in_oven", "arguments": {}}}]}]}
One format detail causes most data-prep failures: the emitted call uses the HuggingFace convention, where arguments is a real JSON object. OpenAI’s chat-completions format stringifies it. The schemas in job_description.json follow the OpenAI shape; the calls in train.jsonl do not. Also, exactly one call per assistant turn — multiple calls per turn are not supported.
Which models can do tool calling on distil labs?
A subset, and this is enforced at validation rather than degraded quietly. The supported models catalog is the authority.
| Role | Eligible for tool-calling tasks |
|---|---|
| Students | Qwen3, Qwen3.5, Llama 3 family, LFM2/LFM2.5, FunctionGemma, Gemma 4 |
| Teachers | Only those ticked in the catalog’s Tool calling column |
Gemma 3 and SmolLM2 are not eligible students. Among teachers, the trap is inside one family: deepseek.v3.2 qualifies while deepseek.r1 and deepseek.v3.1 do not. zai.glm-5 supports tool calling and is the current pick for new work; because it is a reasoning teacher, synthgen.teacher_temperature must sit between 0.5 and 0.7.
base:
task: tool-calling-closed-book
student_model_name: Qwen3-1.7B
teacher_model_name: zai.glm-5
synthgen:
teacher_temperature: 0.6
How is a tool-calling model scored?
On call equivalence rather than text similarity. The metrics reference defines three:
tool_call_equivalence(recommended) — compares prediction and reference, treating unset parameters as their schema defaults.binary_tool_call— strict dictionary equality, no default handling.staged_tool_call— quarter-credit for valid JSON, correct function name, correct parameter keys, exact match. A 0.5 means the right function with wrong arguments; a 0.25 means valid JSON calling the wrong function.
Use the staged metric while iterating. It tells you whether your problem is schema adherence, routing, or slot filling, and those need different fixes.
How much does fine-tuning actually change?
Enough that base-model scores are close to irrelevant. Our LFM2.5 350M benchmark trained one 350M student on three tool-calling tasks against a 120B teacher:
| Task | Teacher (120B) | LFM2.5 350M base | LFM2.5 350M tuned |
|---|---|---|---|
| Shell commands (Gorilla) | 97.03% | 61.4% | 98.0% |
| Smart home control | 92.11% | 63.2% | 96.7% |
| Banking voice assistant | 96.95% | 34.5% | 95.9% |
The student passed the teacher on two of three. That study used openai.gpt-oss-120b, the teacher those runs actually set.
Related terms
Multi-turn tool calling is the conversational variant — see multi-turn tool calling explained. Slot filling is extracting the arguments once the function is chosen. Orchestrator is the deterministic code that executes the returned call and asks for anything missing. For picking a student, see Qwen vs Llama vs Gemma for tool calling, LFM2.5 350M, and FunctionGemma 270M.