Tool Use: Function Calling
Knowledge in parameters is not always enough. Some tasks require checking weather, querying databases, executing code, calling search, or sending requests. The key to Tool Use is not that "the model suddenly knows how to use APIs," but that it learns to judge when to hand a problem off to an external tool and reorganize the tool results into a readable answer.
First decide if a tool is needed
Then construct call parameters
Finally answer using the results
Switch tasks to see when the model decides to call a tool
You can switch task types and then switch the current stage. The page will show the user question, the model's internal judgment, the tool call parameters, the tool return value, and the final answer compared to "without tool calling."
Current User Request
This step is not natural language for humans, but structured parameters for the tool.
The real value comes from the external system; the model will then continue generating based on these results.
If No Tool Is Called
Answer After Calling Tool
How Tool Use Differs from RAG
RAG is more like "looking up information"
It mainly retrieves evidence snippets from a knowledge base and lets the model answer based on that text. The core is supplementing facts and context.
Tool Use is more like "performing actions"
It can call weather APIs, database queries, calculators, calendars, code executors — not just fetching text snippets, but obtaining real system results.
RAG often answers "what is it"
For example, policies, product descriptions, knowledge Q&A, FAQs, manual Q&A — these lean more toward document retrieval.
Tool Use often answers "check / calculate / do"
For example, checking weather, calculating exchange rates, placing orders, reading inventory, sending emails, running SQL — these lean more toward tool execution and state reading.
What else does a good tool-calling system need
Clear tool schema
Tool name, parameters, types, and required fields must be clearly defined; otherwise, the model can hardly generate executable calls stably.
Parameter validation
Not every parameter generated by the model should be executed directly. Real systems usually perform type checking, permission checks, and risk limitations.
Result return format
Tool output cannot just be a blob of raw data; it usually needs to be organized into a format that is easy for the model to read and auditable by users.
Failure handling
Tool timeouts, no data, and insufficient permissions are all common. The system must let the model know "this attempt was not successful" rather than silently fabricating results.
In a nutshell: Tool Use enables models not only to "speak" but also to "check, calculate, and do" through external systems, which is a prerequisite capability for many Agents to truly land in production.