Tool Use And Function Calling

Concepts Covered

• Tool use
• Function calling
• Structured arguments
• Tool results
• Reading versus acting
• Side effects
• Permissions
• Validation
• Why tools differ from prompts
• Why agents need tool boundaries

1. Plain-English Definition

Tool use means a model-backed system can ask external software to do something useful.

That "something" might be:

• search documents
• read a calendar
• query an order
• run a calculator
• fetch weather
• create a ticket

Function calling is a structured way for the model to express a requested tool operation and its arguments.

For example:

tool: getOrderStatus
arguments: { orderId: "A123" }

The model proposes or selects the tool call. Application code decides what is allowed and runs the real operation.

2. Why This Idea Exists

Models are useful with language. Products need software actions.

A model may generate a sentence about an order. It does not automatically know the current order status in your database.

A model may describe a calendar event. It should not create one unless the product gives it a controlled way to do that.

Tools exist to bridge that gap:

model reasoning about task <-> software capability

Function calling matters because free-form text is a weak interface for software operations. Structured tool requests are easier to validate, route, log, and reject.

3. The Beginner Mental Model

Think of a tool as an API surface the model can request through.

The product may tell the model:

You may use getPolicySnippet(query).
You may use lookupOrder(orderId).
You may not issue refunds directly.

The model chooses from visible capabilities. The application receives that choice, checks it, runs the tool if allowed, and gives the result back as context.

model requests tool -> app validates -> tool runs -> result returns

That is the core mental model.

4. What That Mental Model Misses

Calling tools "APIs for the model" is helpful, but it hides risk.

First, some tools only read. Others create side effects. Searching docs is not the same as sending money.

Second, the model can produce wrong arguments. A user ID, amount, date, or file path may be missing or unsafe.

Third, tool outputs can fail, be stale, be partial, or contain data the model should not reveal.

Fourth, the product decides approval policy. A function call shape does not by itself make an action authorized.

Fifth, tools do not remove hallucination risk. They can ground a system with real results, but the model may still misread a result or overstate what it means.

5. A Concrete Example

Imagine a support assistant.

The user says:

Where is my refund?

The model cannot infer the real payment state from wording alone.

The product might expose a read tool:

lookupRefundStatus(refundId)

The flow becomes:

user asks -> model requests lookup -> app validates access -> tool returns status -> model explains result

Now imagine a write tool:

issueRefund(orderId, amount)

That tool needs stricter policy: permission checks, amount checks, audit logs, idempotency, and maybe human approval.

Same vocabulary. Very different blast radius.

6. How It Works At A Practical Level

At a practical level, a tool-enabled model flow may include:

1. a tool name and description
2. an argument schema
3. product validation
4. tool execution
5. a result passed back to the workflow
6. a decision to continue or stop

For example:

available tools + user task -> model emits structured tool request
tool request -> application policy and validation
validated request -> software operation
tool result -> context for next model step

Function calling is valuable because schemas narrow the interface. The product can reject malformed arguments, hide unavailable tools, require confirmation, and treat results as typed data rather than guessing from prose.

7. Where You See This In Real AI Products

In coding assistants, tools may read files, search a repository, apply edits, or run tests inside workspace boundaries.

In travel assistants, tools may search flights or check availability before an answer is shown.

In support systems, tools may fetch account state, policy snippets, order status, or ticket history.

In personal assistants, tools may interact with calendars, reminders, and messages under permission rules.

In research workflows, tools may search sources and return material for summarization.

The product becomes more capable when the model can reach controlled software capabilities.

8. Common Confusions

Tool use is not the same thing as retrieval.

Retrieval is one kind of capability. Tools can also calculate, inspect state, or act.

Function calling is not a promise that a function already ran.

It can be a structured request the application still has to validate and execute.

A tool schema is not a permission system.

Permissions and side-effect policy belong in product code.

Tool output is not automatically user-safe output.

The workflow may need filtering, transformation, and explanation.

9. What This Does Not Mean

This does not mean models should get broad access to every internal API.

Expose narrow capabilities that fit the task and trust level.

This does not mean natural-language instructions replace backend checks.

The product must enforce safety outside the model prompt.

This does not mean tools are only for agents.

Even a single model response can use a tool to get a current fact or calculate a result.

10. What To Learn Next

The more tools and steps a system has, the more seriously you need to test behavior. Finish the foundation layer with What Are Evals?.