Live data in answers
Order status, stock and balances come from your systems, not model memory.
Read more about Live data in answers
Order status, stock levels, appointment slots and account balances come from your systems, not from model memory.
How a model asks your software to run a function, and your code decides if it runs.
You list the functions a model may use. It replies with a structured call, and your application runs it and returns the result.
With function calling, also called tool use, you send a model a list of functions it may use, each with a name, a description and a JSON Schema for its parameters. When the model decides a function would help, it replies with a structured call instead of plain text. Your application runs the function and sends the result back.
OpenAI added function calling to its API in 2023, and Anthropic, Google and most open-weight model families now support the same idea. See OpenAI's guide and Anthropic's tool use docs.
Each function gets a name, a description and its parameters.
For example get_order(order_id: string) with the description "Look up status and delivery date for one order".
Asked about order 4821, the model returns a call to get_order with that ID.
The user asks "where is my order 4821?". The model returns a call to get_order with {"order_id": "4821"}.
Your server validates arguments, checks permissions and queries the database.
Your server validates the arguments, checks the user is allowed to see that order, and queries the database.
The result goes back, and the model replies or calls another tool.
The result goes back to the model, which writes the reply or calls another tool.
Order status, stock and balances come from your systems, not model memory.
Order status, stock levels, appointment slots and account balances come from your systems, not from model memory.
A function like save_invoice is a reliable way to get clean JSON from a document.
Defining a function such as save_invoice(...) is a reliable way to get clean JSON fields out of a document.
Every AI agent is a loop of function calls; MCP standardises how tools are served.
Every AI agent is a loop of function calls. The Model Context Protocol standardises how those tools are served.
A clinic's WhatsApp assistant finds and holds appointment slots through two tools, but a booking is confirmed only when the front desk accepts it.
A clinic's WhatsApp assistant gets two tools: find_slots(doctor, date) and hold_slot(slot_id, patient_phone). A patient asks for a Saturday appointment. The model calls find_slots, offers three times, and calls hold_slot when the patient picks one. The booking is only confirmed after the front desk accepts it in the clinic's system. The model chose the actions; the software enforced the rules.
Models produce wrong IDs and out-of-range values. Validate every argument like user input.
Models can produce wrong IDs or values outside the allowed range. Validate every argument as you would user input.
The description is the model's only guide. Say what a tool does and when to use it.
The description is the model's only guide to when to use a tool. Say what it does, when to use it and when not to.
Refunds, deletions and outgoing messages should wait for a person to confirm.
Refunds, deletions and outgoing messages should require human-in-the-loop confirmation.
No. It only outputs the name and arguments. Your application executes it, which is where permissions, validation and logging belong.
Many recent open-weight models are trained for tool use and work well with a few clearly described tools. Test accuracy on your own calls before relying on one.
Last updated