The OpenAI Agents SDK can drive onchain transactions by connecting an agent to tools that read chain state, build transactions and hand them to a wallet, with guardrails and approval policies deciding what runs. The SDK's documentation lists four ways to reach MCP servers, from a hosted MCP tool the Responses API calls on the model's behalf to a local stdio process, and lets each server require approval for some or all of its tools (OpenAI Agents SDK: MCP). This guide maps function tools, MCP tools and guardrails to the steps of an onchain transaction: quote, build, simulate, sign and send.
​

Last reviewed: Nov 2026. Class and option names are quoted from the OpenAI Agents SDK Python documentation.
​

The OpenAI Agents SDK gives an agent tools in several forms: hosted tools that run on OpenAI's servers, function tools that wrap your own Python functions, agents exposed as tools, and MCP servers. For onchain work, function tools and MCP servers carry the chain logic, because the code that touches keys and RPC endpoints should run in infrastructure you control.
​

The SDK's tools page describes hosted OpenAI tools that execute on OpenAI servers, FunctionTool instances that wrap any Python function, agents as tools, and an experimental Codex tool (OpenAI Agents SDK: tools). A function tool is the most direct way to expose a narrow, typed onchain action, such as "quote a USDC transfer from Base to OP Mainnet", with arguments the SDK validates against a schema.
​

The MCP page lists four connection options: HostedMCPTool, where the Responses API calls a publicly reachable MCP server; MCPServerStreamableHttp for Streamable HTTP servers run locally or remotely; MCPServerSse for HTTP with Server-Sent Events; and MCPServerStdio for a local process over stdin and stdout (OpenAI Agents SDK: MCP).
​

An onchain transaction has five steps, and each fits a different tool type. Quoting and building can be function tools or MCP tools. Simulation should run before any signature. Signing should stay in a wallet outside the agent, and sending should require approval.
​

Eco's Routes agent integration guide describes a reference transfer script that requests a quote, verifies its signature and the funded intent against the signed set, checks the recipient on the delivery route, funds, and polls status until filled. Without an explicit execute flag it stops after printing the verified quote and moves no funds (Eco docs: Agent integration). That pattern, verify first and execute only on an explicit switch, translates directly into a function tool with a dry-run default.
​

Guardrails in the OpenAI Agents SDK check the user's input before the agent runs and the agent's final output after it finishes. A tripwire stops the run when a check fails. For transactions, an input guardrail can reject requests outside policy before any tool is called, and approval policies on MCP tools gate the calls that move funds.
​

The guardrails page explains that input guardrails run on the initial user input and output guardrails on the final agent output, and that when tripwire_triggered is true the SDK raises an exception. In blocking mode, with run_in_parallel set to False, the guardrail completes before the agent starts, so a tripped guardrail means the agent never executes and no tools run (OpenAI Agents SDK: guardrails). For an agent near funds, blocking mode is the safer default: a request to send to an unknown address or above a cap never reaches the model.
​

Guardrails see text, not every tool call. Per-call control comes from approval settings. The MCP page documents require_approval as either a single policy, "always" or "never", or a map from tool names to policies, for example requiring approval for a delete tool and none for a read tool (OpenAI Agents SDK: MCP). Set read, simulate and build tools to "never" and every send or wallet tool to "always". The tool_filter option goes further by exposing only a subset of a server's tools at all.
​

Sauce, Eco's onchain harness for agents, ships an MCP server that compiles, simulates and builds transactions on Ethereum, Base, Arc and Solana. With the OpenAI Agents SDK it fits the MCPServerStdio option for a local process, or MCPServerStreamableHttp for a self-hosted server. Its transaction-building tools return unsigned transactions, which keeps signing outside the agent.
​

Eco's docs list the server's building tools, including sauce_compile, sauce_simulate and sauce_tx, plus sauce_send to broadcast already-signed transactions and wallet tools available only over stdio (Eco docs). A server started with --no-wallets --no-stores lists 18 tools, no tool takes a private key or password, and the HTTP server never signs. Sauce programs also carry conditions that make the transaction revert when they fail, such as a required balance or a minimum swap output (Eco docs: Sauce introduction). See programmable transactions vs smart contracts for the model.
​

Whether a given Sauce transport works with HostedMCPTool depends on the server being publicly reachable, which the SDK requires for hosted tools (OpenAI Agents SDK: MCP). For most teams a local or self-hosted connection is simpler and keeps the server inside their own network.
​

The SDK gives good hooks for control, but each has a boundary. Guardrails inspect the request and the final answer, not each intermediate step. Approval policies depend on correct tool names. Simulation reflects one moment of chain state. Teams should combine all three with limits enforced in the wallet and in the transaction.

These are the common questions about onchain agents built with the OpenAI Agents SDK.
​

Yes: hosted MCP tools, Streamable HTTP, SSE and stdio servers (Agents SDK MCP).
​

Yes. require_approval accepts a per-tool map (Agents SDK MCP).
​

No. Return unsigned transactions and sign in a wallet you control. See the unsigned-transaction handoff.
​

The Apps SDK targets ChatGPT itself. See ChatGPT Apps SDK and payments.
​

SDK behavior is quoted from the OpenAI Agents SDK Python documentation and Eco behavior from Eco's documentation, fetched on November 12, 2026. No agent was run for this page.