Skip to main content

The tool() Helper

The tool() function creates type-safe tools with Zod schema validation:

Tool Types

The SDK supports four types of tools, automatically detected from your configuration:

Regular Tools

Standard tools with an execute function:

Generator Tools

Tools that yield progress updates during execution. Add eventSchema to enable generator mode:
Progress events are streamed to consumers via getToolStream() and getFullResponsesStream().

Manual Tools

Tools without automatic execution - you handle the tool calls yourself:
Use getToolCalls() to retrieve manual tool calls for processing.

Human-in-the-Loop (HITL) Tools

HITL tools extend manual-tool semantics with two sync-or-async hooks that let you decide per call whether to respond programmatically or pause for a human:
  • onToolCalled — fires when the model invokes the tool. Return a value to feed the model directly (like a regular execute), or return null to pause the loop like a manual tool. The caller resumes later by supplying a function_call_output item.
  • onResponseReceived — optional. Fires on a later turn when an incoming function_call_output matches a prior call of this tool (by callId → function_call.name). It receives the caller-supplied raw result and returns the value sent to the model. Throwing surfaces as a tool error to the model.
An outputSchema is required for HITL tools — it validates both the onToolCalled return value (when non-null) and the value delivered via function_call_output (whether transformed by onResponseReceived or passed through directly).
When onToolCalled returns null, the conversation state moves to status: 'awaiting_hitl' and the paused call surfaces via getToolCalls() / getPendingToolCalls(). Resume by calling callModel again with a function_call_output item for each paused call in the input.
HITL tools differ from requireApproval: approval gates pause before execution for a yes/no decision, while HITL tools let onToolCalled run arbitrary logic first and only pause when it returns null. Use HITL when the decision is data-driven (e.g., amount thresholds, risk scoring); use requireApproval when you always want explicit human consent. See Tool Approval & State.

Schema Definition

Input Schema

Define what parameters the tool accepts:

Output Schema

Define the structure of results returned to the model:

Event Schema (Generator Tools)

Define progress/status events for generator tools:

Type Inference

The SDK provides utilities to extract types from tools:

Using Tools with callModel

Single Tool

Multiple Tools

Type-Safe Tool Calls with as const

Use as const for full type inference on tool calls:

Execute Context

Tool execute functions receive a flat context object as their second argument. It merges TurnContext fields with a tools map and a setContext() method:

Context Properties

Tool Context

Tools can declare a contextSchema to receive typed, persistent context data from the caller. Context is keyed by tool name and persists across turns.

Declaring contextSchema

Providing Context in callModel

Pass context keyed by tool name:

Dynamic Context

Use an async function for one-time initialization that needs to fetch data:
resolveContext runs once at turn 0 to seed the context store. For per-turn mutations, use setContext() inside your tool’s execute function.

Mutating Context with setContext

Tools can update their own context using setContext(). Changes persist across turns via the shared store and are visible immediately — context.local is a live getter that always reads the latest values:

Observing Context Changes

Use getContextUpdates() on ModelResult to observe context mutations in real time:

Shared Context

Use sharedSchema on tool() and sharedContextSchema on callModel to share typed state across tools:
context.local is scoped to one tool. context.shared is visible to all tools and persists across turns. Pass the same sharedSchema to each tool for typed access, and sharedContextSchema to callModel for runtime validation.

Tool Execution

callModel automatically executes tools and handles multi-turn conversations. When the model calls a tool, the SDK executes it, sends the result back, and continues until the model provides a final response.

Automatic Execution Flow

When you provide tools with execute functions:

Execution Sequence

  1. Model receives prompt and generates tool call
  2. SDK extracts tool call and validates arguments
  3. Tool’s execute function runs
  4. Result is formatted and sent back to model
  5. Model generates final response (or more tool calls)
  6. Process repeats until model is done

Controlling Execution Rounds

maxToolRounds (Number)

Limit the maximum number of tool execution rounds:
Setting maxToolRounds: 0 disables automatic execution - you get raw tool calls.

maxToolRounds (Function)

Use a function for dynamic control:
The function receives TurnContext and returns true to continue or false to stop.

Accessing Tool Calls

getToolCalls()

Get all tool calls from the initial response (before auto-execution):

getToolCallsStream()

Stream tool calls as they complete:

Tool Stream Events

getToolStream()

Stream both argument deltas and preliminary results:

Event Types

Tool Result Events

When using getFullResponsesStream(), you can also receive tool.result events that fire when a tool execution completes:

ToolResultEvent Type

The tool.result event provides the final output from tool execution along with all intermediate preliminaryResults that were yielded during execution (for generator tools). This is useful when you need both real-time progress updates and a summary of all progress at completion.

Parallel Tool Execution

When the model calls multiple tools, they execute in parallel:

Manual Tool Handling

For tools without execute functions:

Execution Results

Access execution metadata through getResponse():

Error Handling

Tool Execution Errors

Errors in execute functions are caught and sent back to the model:

Validation Errors

Invalid tool arguments are caught before execution:

Graceful Error Handling

Handle errors gracefully in execute functions:

Best Practices

Descriptive Names and Descriptions

Schema Descriptions

Add .describe() to help the model understand parameters:

Idempotent Tools

Design tools to be safely re-executable:

Timeout Handling

Wrap long-running operations:

Next Steps