AI, explained

What is tool calling?

Tool calling is the moment a language model stops writing text about your systems and starts touching them.

The model never runs anything itself. You give it a list of functions with names, descriptions and an argument schema. It decides which one fits the request and produces a JSON payload matching that schema. Your application validates the payload, runs the actual code, and hands the output back. The model is choosing, your system is doing. Keeping that distinction clear in your head prevents most of the security mistakes people make here.

Schema design is the whole job

A tool the model uses correctly and a tool it misuses are usually the same function with different descriptions. Some things that reliably help:

• Name the tool after the business action, not the endpoint. reschedule_appointment gets picked correctly far more often than patch_booking_v2.
• Write the description for a new hire, including when NOT to use it. "Use only when the customer has already been identified" prevents a class of wrong calls.
• Constrain arguments with enums and formats rather than free strings. Every free-text field is a place the model can invent something plausible.
• Keep the tool count small per decision point. Twenty tools in one context produces worse selection than eight, and most large agents work better split into stages.

The permission boundary

Treat every tool call as arriving from an untrusted client, because functionally it is. The model may be reasoning over a customer email, a scraped page or a PDF, and anything in that content can try to steer it. Authorisation belongs in your code, checked against the authenticated user's real permissions, never in the prompt telling the model what it is allowed to do. A prompt instruction is a suggestion. A permission check is a control.

Draw a hard line between read tools and write tools. Reads can be broad and cheap. Writes should be narrow, logged with the input that triggered them, idempotent where possible, and reversible or gated by human confirmation when the action costs money, sends something external or deletes anything.

What breaks in production

Three failures show up repeatedly. The model calls the right tool with a hallucinated identifier, which strict schemas and an existence check catch. The model loops, calling the same tool with slight variations, which a call budget and a clear stop condition catch. And a tool fails silently, returning an empty result the model then narrates as a fact, which is why error responses should say plainly that the call failed rather than returning nothing. An AI audit usually starts by mapping which of your systems can safely be reached this way at all.

Frequently asked questions

Related