Tool use: how LLMs decide to call functions
Tool use: LLM کب طے کرتا ہے کہ فنکشن کال کرنا ہے
35 min read
Three ways to see it
The mechanism is simpler than it sounds. The application tells the model: 'You have access to these tools, here is their schema.' Each tool is described in a small JSON object with a name, a description in plain English, and a JSON schema for its inputs. When the user asks a question, the model decides whether it has enough information to answer directly or whether it needs to call a tool. If it needs to call, it produces a structured response that names the tool and fills in the arguments. The application executes the tool, returns the result to the model, and the model continues. The model is the brain. The application is the body. The tools are the hands.
A tool definition for a Pakistani context. Imagine you give Claude a tool called verify_ntn with this schema: 'Verifies whether a given NTN is registered with FBR and currently an active taxpayer. Input: ntn (string, 7 digits). Output: status (active or inactive), filer_status (boolean), last_filing_year (number).' The description is the most important thing. The model reads it like a job description. Vague descriptions cause hallucinated calls. Sharp descriptions cause precise calls. Treat tool descriptions the way you would treat a contract with a junior employee, because that is exactly what they are.
The decision logic inside the model is not magic. The model has been trained on thousands of examples where text like 'please check the status of NTN 1234567' led to a tool call with the name verify_ntn and the argument 1234567. Through this training the model learns to recognise when a user request maps to a tool. The model is not always right. Two common failures: it calls a tool when it should not, hallucinating a need; or it answers without calling a tool when it should, hallucinating an answer. Good system prompts and good tool descriptions tilt the model toward the right choice. Evaluations test how often it tilts wrong.
Quick check
Quick check: what makes modern AI different from a rule-based program?
The why-tree
Why-tree level one: why let the model decide rather than write the orchestration in code? Because the space of possible user requests is too large to enumerate. A model can adapt to a phrase it has never seen, choose the right tool, and explain the choice. Hand-coded orchestration handles ten requests; model orchestration handles thousands.
Try this with Claude
AI-edge prompt to try with Claude or ChatGPT: 'Design five tools for an AI assistant at a Pakistani export firm. Each tool must include name, description, JSON schema for inputs, and one Urdu refusal clause. Examples: lookup HS code, check letter of credit status, draft Form-E. Then critique your own design and tell me which tool is most likely to be misused.' Read critically.
Sources
Sources and further reading. Anthropic, 'Tool use with Claude' (docs.anthropic.com/en/docs/build-with-claude/tool-use). OpenAI Function Calling guide (platform.openai.com/docs/guides/function-calling). LangChain Tool documentation (python.langchain.com/docs/concepts/tools). LlamaIndex Tools guide (docs.llamaindex.ai). 'Toolformer' paper, Meta AI 2023 (arxiv.org/abs/2302.04761) for the academic background.