Skip to main content
Define a tool when an agent needs to read application data, call an internal service, or take an action. The model calls the tool by its ID; the SDK checks the arguments, runs your code in your process, and sends the result back on the next turn.

Define a tool

Tool fields

Schemas take each language’s native validator: in TypeScript a function or an object with parse() or safeParse(); in Python a callable, a Pydantic model, or an object with parse or safe_parse; elsewhere a function or callable that returns the value or throws.

What a timeout does

A call to a tool ID that isn’t in the current tool list fails the run (unknown tool in Go, Unknown tool '<name>' in C#, PHP, Ruby, and Java, Unknown tool: <name> as an AgentError in Rust). In TypeScript with return-to-model, an unknown tool or unreadable arguments are answered like a tool error instead.

Require approval

Set a tool’s approval flag to true, or give it a function that decides per call. An agent-level approval function, where the language has one, applies to every tool and overrides both. A gated call pauses the run with status waiting_for_human; approve or reject it by call ID in State and approval.

Hand a call to a person or another system

A manual tool has no executor: your application, a queue, or another service does the work. An interactive tool runs a hook that can pause for a person. Both pause the run until you continue it with a tool output for the call ID; see State and approval. If the interactive hook returns a value instead, it becomes the tool result immediately. After you continue, onResponseReceived (or the language’s equivalent) can validate or transform the supplied output before the output validator checks it. The Rust external tool takes no executor:
If one model turn mixes automatic and pending tools, the runtime runs the automatic ones before it returns the pause.

Report progress and update context

A tool can publish preliminary results while it works and replace the application context for later turns. Progress appears as tool.preliminary_result events (see Streaming), checked against the event validator when you set one.

Recover from tool errors

By default an error from a tool fails the run and is rethrown. Set the tool’s error policy to return-to-model to send the error back as the tool’s result ({"error": "..."}) so the model can try something else. Keep the default for unsafe or unrecoverable failures. In TypeScript, toolExecution.maxOutputChars caps how much of a tool’s output the model sees; longer output keeps its start and end around a notice.

Run tools concurrently

When one model turn calls several independent tools, set a concurrency limit to run them at the same time. Go, C#, Ruby, and Java run tools one at a time until you do. Results are appended in the order the model made the calls, whatever order they finish in. In Go and C#, if several concurrent tools set the context, the last one in call order wins.
Last modified on November 5, 2026