Skip to main content

Contact

What are you interested in?

Back to Glossary (T)
Glossary · T

Tool Calling (Function Calling).

Tool calling is the mechanism by which a language model triggers an action outside its own text window: instead of prose it returns a structured call with a function name and arguments. The surrounding application executes that call, and the result flows back into the conversation.

TOGLOSSARYDLM Digital

Tool Calling (Function Calling) — Explained in Detail

Technically, the model receives a list of available tools alongside the request. Each tool consists of a name, a description in natural language, and a schema defining the permitted parameters with their types and required fields. If the model considers a tool appropriate, it answers not with text but with a call: tool name plus arguments in the prescribed format. The description is not decoration but the actual steering mechanism — it is the only clue the model has for deciding when a tool is the right one and when it is not.

The key point to grasp is that the model itself executes nothing. It formulates a wish, no more. The application decides whether to grant it, validates the arguments, performs the action and returns the result as a new message. Only then does the model phrase the answer for the user, or call the next tool. This separation is the central security boundary of any agent: all permission checks, limits and approvals belong in the executing application, never in the instruction given to the model.

In practice the quality of the cut determines reliability. A few clearly separated tools work considerably better than thirty similar ones; speaking parameter names prevent misfires; and errors should be returned as readable text rather than as a status code, because the model can derive a second, better attempt from it. Two further rules apply to actions with an outside effect: they should be safe to run more than once, and an explicit confirmation belongs before any irreversible step — the point at which human-in-the-loop enters the picture.

A case from the website world: an assistant on a service page should name free appointment slots and, on request, record an enquiry. Two tools are enough. The first reads availability and may run without asking, because it changes nothing. The second creates an enquiry and is only executed after a visible confirmation, including validation of the email format and rate limiting in the application. The same logic sits behind WebMCP, except that there the website registers its tools directly for the visitor's agent.

Frequently Asked Questions About Tool Calling (Function Calling)

No. The model only returns a structured call with a function name and arguments. It is executed by the surrounding application, which can first check whether the call is permitted, whether the arguments are valid, and whether the user is authorised to make it. That is precisely why permission checks and limits belong in the code and not in the system prompt.

Tool calling describes the model's ability to produce a structured function call. MCP is the standard through which an application learns which tools exist at all, and how they can be reached. Put differently: tool calling is the mechanism, MCP the uniform wiring. An agent normally uses both together, and neither replaces the other.

Fewer than you would think. As the number of similar-sounding tools grows, the risk of confusion rises noticeably, because the model distinguishes them only by their descriptions. The proven approach is to start with a handful of clearly separated tools, sharpen each description to its purpose and its boundaries, and if needed split by area of responsibility rather than lengthening the list.

Ready for Your Project?

Apply this knowledge to your website — DLM Digital will help you.