What Is a Tool, and Why Does a Language Model Need One

Why this is worth knowing

• To see where a system gets fresh data from, and who answers for a wrong action
• To tell a setup that can act apart from one that can only talk
• To ask a vendor for the list of tools and the access rights attached to each

What is a tool, in plain language

A help-desk operator keeps the rules in mind. Contract terms, deadlines, the returns procedure — that is memory. An account balance, though, is looked up in a program: nobody memorises that, and it changes every day.

A tool for a language model is exactly that access to a program. The model was trained on text and knows the general rules. What is happening in the accounting system right now, it does not know.

A tool closes that gap. It is given a name, a short description of its purpose and a list of fields to fill in: contract number, period, amount. The model sees that list the way an operator sees a search form on screen. The request is executed by the program, and tool calling is the part where the model states what it needs.

How it works

The key point is step three. The model executes nothing; it only asks. Everything that follows is done by ordinary code under ordinary access rules.

One practical consequence follows. Rights to a tool are granted not to the model but to the role of the employee on whose behalf the request is made. A sales manager sees their own deals, an accountant their own documents. The model widens nobody's authority.

Tool descriptions sit in the input volume of every request. Ten detailed descriptions add as much to the bill as a short document would — and that is counted in tokens. So the list is kept short and the descriptions are rewritten tightly.

The number of steps per request is capped in advance. Without a cap, a model is capable of going in circles: it queries, fails to understand, queries again. A limit of three to five calls per request removes that line of spending and keeps response time in check as well.

Tool failures are handled separately. The system is unavailable, the contract is not found, a field was filled in wrongly — for each case it is written out what the model tells the person. Without that, a coherent answer arrives assembled out of nothing: the very same hallucination, only more expensive.

An example from practice

"The March invoice never arrived" is three different requests. The invoice was never issued. The invoice went to an old address. The invoice arrived but will not open.

In plain text all three get the same useless answer. With tools the case is worked through step by step: find the invoice by contract number, check the delivery status, verify the address on the account record. Three short queries instead of one long letter to the customer.

Then the boundary is decided. Find and display — available to everyone. Resend — allowed. Change the mailing address or recalculate the amount — only with human confirmation, because the cost of an error there reaches beyond a single conversation.

The result of such a setup is measured by the share of requests closed without an operator. The same flow is taken over two to four weeks, before and after. To estimate what the same work costs when done by hand, there is the manual process cost calculator.

What this gives a business

• The answer rests on data, not on the model's memory. Order status, stock balance, delivery date are taken from the system at the moment the question is asked. There is nothing to argue with: the record of where the answer came from sits right beside it.
• A log appears. Every call is written down: who asked, which tool was invoked, with which fields, what came back. Investigating a complaint takes minutes and does not require reconstructing a conversation from memory.
• Work splits into cheap and expensive. Some steps are covered by direct integration with no model at all — wherever the condition is rigid and written down. What is left to the model is interpreting wording and choosing a branch. To assess which parts of a process are ready for this, there is the readiness checklist.
• Risk is bounded by the list. The model can do exactly what is listed. If a tool is not connected, the action is physically impossible, not merely disallowed by agreement.

When this can be skipped

Tools are unnecessary wherever the answer lies entirely in text. Draft emails, translations, summaries of an attached document, working through a single file — the model manages without reaching outside.

They are also unnecessary when data changes rarely. A quarterly price list, a policy, a manual — that is a knowledge base, and connecting document search over it is cheaper.

The third case is one-off volume. A few requests a day are handled by a person in a minute, while the integration, the rights and the log cost as much as a separate project.

What is worth checking

First: ask for the list of tools together with their rights. For each one — on whose behalf the request runs, which fields it takes, what happens when the system fails. A three-line list beats a promise to "connect whatever is needed".

Second: separate reading from writing. Reading tools are launched straight away; writing tools follow once live traffic shows that the model chooses correctly. Actions involving money and outbound messages stay behind human confirmation even after that.

Third: check what happens on a wrong choice. A good setup answers "data not found" and hands over to a person. A bad one invents a plausible answer, and that only becomes visible when a customer complains.