What is tool calling?

A language model produces text. On its own, it cannot check a calendar, record a contact or look up the status of an order. Tool calling, also called function calling, gives it that ability within a frame: the model can request a specific action, with structured parameters, and the system carries it out and sends back the result.

How it works

The mechanism always follows the same pattern:

1. Declaration: the system describes the available tools to the model. For each tool, a name, a plain-language description and the list of expected parameters, described in a standard format called JSON Schema
2. Decision: reading the conversation, the model judges that a tool is useful. Instead of writing an answer, it returns a structured request: "call the tool save_contact with name = Sophie Martin, e-mail = ..."
3. Execution: the system checks the request, runs the action and gets the result
4. Follow-up: the result is sent back to the model, which writes its answer to the visitor taking it into account

The key point is the third step. The model only asks; it is the application's code that decides whether to run the action, checks the parameters and keeps a record.

Where it comes from

OpenAI introduced function calling in its developer interface in June 2023. The other major model providers quickly offered equivalent mechanisms under similar names. This capability is what allowed assistants that answer to become assistants that act, and it underpins AI agents.

What tools can be used for

In a business assistant, tools are mostly used to:

• Collect structured information: record a visitor's contact details or the elements of a quote request
• Pass on: request a human handover with a summary of the situation
• Look up current information: stock, availability, the status of a file in business software
• Notify another system: send a webhook to a CRM or a tracking tool
• Report a gap: note that a question went unanswered so the team can complete the documents

Safety rules

Giving tools to a model means giving it power. A few principles limit the risks:

• Declare, do not improvise. The model can only call the tools that have been described to it. It cannot invent one
• Check the parameters. The system checks that the requested values match the declared schema and the business rules before running anything
• Limit powers. A public assistant can read an availability or record a request; it should not be able to grant a refund or delete data
• Separate reading and writing. Looking up information is less risky than changing it. Write actions deserve stricter rules, or even human confirmation
• Log every call. Who asked for what, with which parameters, with what result. This log is used to check, correct and account for what happened
• Protect outbound calls. A tool that calls a web address must refuse internal or unplanned addresses, so a conversation cannot be used to reach a private system

These rules are part of the assistant's guardrails. They make manipulation attempts much less dangerous: even if a visitor manages to get an unwanted action "requested", the system refuses to run it.

The limits

• The model can pick the wrong tool or fill in a parameter badly. Clear descriptions and testing reduce these errors
• A slow tool slows down the conversation. The visitor waits during the call
• The data returned by the tool enters the conversation. If the tool returns too much information, or unnecessary personal data, the model may repeat it. Limit what it returns
• Every tool is an integration to maintain. When the business software changes, the tool has to follow

Do you need tools from the start?

For an SME, rarely. An assistant that answers from documents, collects contact details and hands over covers most needs. Tools that look up business software make sense when a frequent question depends on information that changes every day and that no document can keep up to date.

Tool calling in KernChat

In KernChat, actions are declared rows, not code written for each customer. The model sees each action as a tool described in JSON Schema; the server runs it through a generic executor and every run is recorded in a log. Common actions are built in: collecting a contact, creating a sales request, requesting a handover to the team, reporting an unanswered question, remembering a piece of information. The organization can declare others, such as calling a webhook or looking up an external service, whose addresses are checked before every call.