Skip to main content
Tools are callable capabilities the LLM can invoke during a run. Agent SDK for Go converts each registered tool into a JSON schema the model sees, executes the tool when the model returns a tool call, and feeds the result back into the next LLM round.

Register tools

At creation — pass tools directly or via a registry:
Built-in tools live under pkg/tools/ (calculator, weather, search, and others).

Custom tools

Implement interfaces.Tool. All five methods are required:

Complete implementation

Tool arguments from the LLM arrive as map[string]any. JSON numbers decode as float64 — cast accordingly (see limit above).

schema helpers

pkg/tools provides type-safe helpers for Parameters():

Optional tool interfaces

See Approvals for the full approval and authorization flow.

Tool execution mode

When the model returns multiple tool calls in one turn, the SDK runs them in parallel by default:
Use sequential when tools share mutable state, hit rate limits, or must run in strict order.
Use the same WithAgentToolExecutionMode on NewAgent, NewAgentWorker, and all sub-agents in a deployment. A mismatch between the agent and worker causes a fingerprint error on the Temporal runtime.

How tools merge at run time

Each Run or Stream resolves the full tool list from all registered sources:
  1. Native / custom tools in ToolRegistry
  2. MCP tools (MCP)
  3. A2A skills (A2A)
  4. Sub-agent delegation tools (Sub-agents)
  5. Retriever tools when mode is agentic or hybrid (Retrieval)
  6. save_memory when memory store mode is on-demand (Memory)
Tool names must be unique across all sources — validation fails fast at NewAgent and on each run.
MCP tool names are prefixed as mcp_<serverKey>_<toolName> and A2A skills as a2a_<server>_<skillId>. This prevents collisions when multiple servers expose tools with the same logical name.

Examples

Tools

Built-in, approval, authorizer, custom, and dynamic registry

Approvals

Require human approval before tool execution

MCP

External tools via Model Context Protocol