← Table of Contents · Page 137 of 868

WHAT TOOLS ARE

Part 2 of 8

TOOL CALLING Here is the part that surprises many beginners. The model does not run the tool. A language model can only produce text. So when it wants to use a tool, it writes a specially structured piece of text that says which tool and which inputs. This is called tool calling, and it is also commonly called function calling. The harness reads that structured text, runs the actual code, and then gives the result back to the model as the next piece of reading material. Think of a customer ordering from a waiter. The customer does not walk into the kitchen. The customer says what they want, the waiter carries the order to the kitchen, and the waiter brings back the food. The model is the customer, the harness is the waiter, and the tool is the kitchen. This arrangement has a great safety advantage. Because every request passes through the harness, the harness can check it before running anything. It can verify the inputs, confirm that the agent has permission, ask a human for approval, record the request in a log, and refuse if something looks wrong. A tool call usually looks like a small bundle of labeled data, written in a common text format such as JSON. JSON is a way of writing structured information as labeled values inside curly braces. Here is a sample, shown as indented lines. [START OF JSON CODE] // A tool call bundle requesting that the send_email tool be run { // The name of the tool to call "tool": "send_email", // The recipient address for the email "to": "[email protected]", // The subject line for the email "subject": "Report", // The body text for the email "body": "Here is the weekly report." } [END OF JSON CODE] Different model providers use slightly different wrappers around this idea, but the essentials are the same: a tool name plus a set of named inputs, often called arguments or parameters.
Advertisement
Read Aloud:
0:00 / 0:00