The Claude Agent SDK can run an agent that prepares onchain transactions when it is given an MCP server with transaction tools and a permission setup that keeps signing behind explicit approval. The SDK exposes MCP servers through its mcpServers option, names their tools with an mcp__ prefix, and lets a PreToolUse hook block or modify any tool call before it runs (Claude Agent SDK: hooks). This guide maps those controls to the steps of an onchain transaction: read state, build, simulate, sign and send. It uses the Sauce MCP server from Eco as the transaction tool server and shows where limits belong in the agent and where they belong in the transaction itself.
​

Last reviewed: Nov 2026. Option and hook names are quoted from Anthropic's Agent SDK documentation.
​

An onchain agent built on the Claude Agent SDK has two parts: the agent loop, which the SDK runs, and a tool server that knows how to talk to a chain. The SDK connects to MCP servers either by launching a local command over stdio or by calling a URL, and every tool those servers expose becomes callable by the model.
​

Anthropic's MCP guide for the SDK shows servers passed directly in the mcpServers option and explains the transport choice: a server documented with a command to run uses stdio, and a server documented with a URL uses an HTTP transport (Claude Agent SDK: MCP). For onchain work, the Sauce MCP server is started with the sauce mcp command and needs Node.js 24 or newer (Eco docs: Sauce for AI agents). Sauce is Eco's onchain harness for agents: its tools compile, simulate and build transactions, and its transaction-building tools return unsigned transactions.
​

The configuration in the diagram is illustrative; check the Sauce installation guide for the exact command and arguments for your client.
​

Tools that read state and tools that build or send transactions should get different permissions. Reading a balance or compiling a program cannot move funds. Building an unsigned transaction cannot move funds either. Only signing and broadcasting can, so those are the calls that need a deny rule or an approval step.
​

Sauce's documentation groups its tools the same way. Building tools include sauce_chains, sauce_price, sauce_compile, sauce_simulate, sauce_pot and sauce_tx. A separate tool, sauce_send, broadcasts transactions a wallet has already signed. Wallet tools such as sauce_wallet_send and sauce_sign exist only on a server started over stdio, and the HTTP server never signs (Eco docs). Starting the server with the --no-wallets flag removes local wallet access while keeping transaction building.
​

Spending limits in the Claude Agent SDK are enforced with three controls that run outside the model: allowedTools for the tools that are always safe, a permission mode that does not silently approve the rest, and a PreToolUse hook that inspects each transaction call and denies it when it breaks a rule. The model can ask for anything; these controls decide what runs.
​

allowedTools. The SDK's MCP guide shows wildcard and per-tool entries such as "mcp__github__*" and "mcp__db__query", and recommends allowedTools over permission modes for MCP access because a wildcard grants exactly one server and nothing more (Claude Agent SDK: MCP). For an onchain agent, list the read, simulate and build tools individually rather than the whole server.
​

Permission mode. The same guide warns that bypassPermissions auto-approves MCP tools but also disables most other safety prompts. The permissions page lists the modes: default, which sends calls needing approval to a canUseTool callback; dontAsk, which denies instead of prompting; acceptEdits; bypassPermissions; plan; and auto (Claude Agent SDK: permissions). For an agent near funds, default or dontAsk keeps unlisted tools from running unattended.
​

PreToolUse hook. The hooks page describes PreToolUse as firing on a tool call request with the ability to block or modify it, and lists it for both the Python and TypeScript SDKs (Claude Agent SDK: hooks). A hook on the broadcast and wallet tools can read the transaction's recipient and amount, compare them with a per-transaction cap, a daily total and an address allowlist kept in your application, and deny the call when any check fails. PostToolUse can then log every call for an audit trail. Eco's AI agent spend controls guide covers how to size those caps.
​

Agent-side limits stop a bad call before it runs, but they live in the same environment as the agent. A second layer belongs inside the transaction: conditions the chain checks at execution time, so a transaction that would breach them reverts even if every agent-side check was bypassed or the chain state changed after simulation.
​

Eco's documentation is explicit about the first limit. An agent running as the user can read wallet files, sign with tools that apply no policy, or edit the policy and ledger files themselves (Eco docs: Security considerations). Hooks in the same process share that exposure.
​

A Sauce program carries its conditions with it. The docs' first example requires that the Pot holds at least the payment amount before transferring USDC, with the message "not enough USDC", and any unhandled failure reverts the whole transaction (Eco docs: Sauce introduction). For swaps the docs list enforcing a minimum output and trying a second pool when the first fails. Those conditions protect the outcome; the SDK's hooks protect the decision to send. See programmable transactions vs smart contracts for the model behind this.
​

Every program the agent writes should be compiled and simulated before anything is signed. Simulation runs the transaction against current chain state without signing or sending it, reports what moved or why it would revert, and does not require a funded wallet when the tool supports an assumed balance.
​

Sauce's simulate tool runs the program from the Pot's owner against the chain's current state and accepts assumeBalance to give the Pot a balance for that simulation only; a reverting run comes back with reverted set to true and the revert reason (Eco docs). The docs also note that state can change between simulation and sending (Eco docs), which is why in-transaction conditions still matter. The CLI builds and sends on Ethereum, Base, Arc and Solana plus testnets such as Base Sepolia and Solana Devnet. Eco's simulation tools comparison covers other options.
​

This architecture narrows risk without removing it. Hooks and permission rules are code in the same environment as the agent, simulation reflects state at one moment, and in-transaction conditions only check what the program states. Each layer covers a gap in the others; none is sufficient alone.

These are the common questions about building onchain agents with the Claude Agent SDK.
​

Yes, through the mcpServers option, over stdio or HTTP transports (Claude Agent SDK: MCP).
​

PreToolUse, which can block or modify a tool call before it runs (Agent SDK hooks).
​

Anthropic's docs note it disables most other safety prompts and recommend allowedTools for MCP access instead (Agent SDK MCP).
​

In a canUseTool callback or a hook on send tools. See human approval for AI agent transactions.
​

SDK behavior is quoted from Anthropic's Agent SDK documentation and Sauce behavior from Eco's documentation, fetched on November 12, 2026. The configuration sketch is illustrative and was not run for this page.