Skip to main content
Most tools of the Sauce MCP server call the same function as the sauce command of the same name. A result returns that command’s --json output as structured content, with the same JSON as text. When a result has notes, they state what must be true for a transaction to land, or where a value came from. Every input is described in the tool’s schema, which tools/list returns. An input the schema does not name is refused:

​
Which tools a server lists

Every server lists these 18, in this order: sauce_chains, sauce_globals, sauce_price, sauce_pools, sauce_compile, sauce_actions, sauce_tx, sauce_signed_cook, sauce_pot, sauce_reclaim, sauce_simulate, sauce_inspect, sauce_verify, sauce_send, sauce_skills, sauce_skill, sauce_dev, sauce_install_skills. A stdio server that keeps its stores also lists the stdio-only tools, after sauce_send: --no-wallets removes the six wallet tools and sauce_sign. --no-stores removes all nine.

​
Inputs and flags

A sauce command line maps onto the tools as follows:
  • the command sauce <command> is the tool sauce_<command>;
  • a program file is source, its text, or, over stdio, path, the file;
  • a result is the command’s --json output.
The flags map to inputs as follows: Error messages and notes use the tools’ words: a flag is named by its input (saltHex, not --salt-hex), and a command by its tool.

​
Shared inputs

Several tools take the same inputs. The program. These are taken by sauce_compile, sauce_simulate, sauce_tx, sauce_signed_cook, sauce_sign and sauce_inspect. main’s arguments are always ABI-v1 encoded. The Pot and the cook. These are taken by sauce_simulate, sauce_tx and sauce_actions. sauce_pot takes the Pot inputs. Token amounts. assumeBalance and fund take <TOKEN|address>:<amount> strings:
  • USDC:1.5 is 1.5 USDC, in whole tokens, exact to the token’s decimals.
  • USDC:1500000n is 1.5 USDC: base units, with a trailing n.
  • USDC:1500000 is 1.5 million USDC, and the result’s notes point this out.
  • ETH:<amount> is the chain’s native currency.

​
Building tools

These thirteen tools are listed by every server.

​
sauce_chains

Lists every chain a program can run on, with its support status and where the server reads it. It reads nothing, takes no inputs and has no matching command. Returns:
  • chains: each chain’s slug, id, name, kind (evm or svm), aliases, support and endpoint.
    • support is "supported" or "preview".
    • endpoint is where the server reads the chain without a call’s rpcUrl: "config" (the --config file), "public" (a built-in public endpoint) or "none".
  • supported: the supported slugs.
  • requestChain: where to request a chain.
The registry has 46 chains. Kava, ZetaChain and Evmos have endpoint: "none".

​
sauce_globals

Lists the names a program on one chain may use without declaring them. It reads nothing. Matches sauce globals. The result has:
  • token symbols, with addresses and decimals;
  • protocol namespaces, with each contract’s address;
  • on Solana, the venue namespaces and the accounts a program writes where it uses them;
  • the chain names and the @sauce/token functions.
Tokenized stocks are left out unless stocks or search asks for them. Returns chain (key, slug, id, kind), the lists the filters select, and notes. This result is for { "chain": "base", "tokens": true, "search": "USDC" }:
With protocol: "UniswapV3" the result has protocol, holding namespace, name and contracts, each contract with its address and methods (name, signature, declaration, stateMutability).

​
sauce_price

Turns a price into the numbers a swap program takes on an EVM chain, or reads a pool’s price. Matches sauce price. Give exactly one of price, sqrtPriceX96 and pool. Returns:
  • price;
  • sqrtPriceX96, for the pair’s order;
  • token0 and token1;
  • for selling (sell) and buying (buy) the base token: priceLimit and maxAvgPrice (input paid per output bought, times 1e18) and minAvgPrice (output per input, times 1e18);
  • units, describing each value;
  • with slippageBps, limits.

​
sauce_pools

Lists a pair’s pools at the venues the registry records on the chain, with liquidity, deepest first, all read at one block. Matches sauce pools. Returns:
  • chain, block, tokens and sortedBy;
  • pools, each with its venue, the contract a program finds it through, its address (or a V4 pool’s id and key), fee, tickSpacing, liquidity, tick, sqrtPriceX96, and two sides with mid, taker, priceLimit and depth1Pct;
  • empty, the pools with no liquidity, and checked, what was looked at;
  • more, the count of pools that limit left out;
  • on Solana, skipped, and with pay, chosen, poolArgs and accounts.
Pass block to sauce_simulate to simulate on the prices a limit was taken from.

​
sauce_compile

Compiles a program for a chain. It reads no chain. Matches sauce compile. Returns:
  • chain, chainId, target, bytecode (0x hex) and size in bytes;
  • entryEncoding, always abi-v1, entryParams (main’s parameters) and returnType;
  • defines, each name the compile resolved and where it came from;
  • contracts, the protocol contracts the program calls;
  • compiler and engine, the compiler and the released engine it pairs with;
  • sourceSha256, the sha256 of the program’s text;
  • with args, the payload: its size and argumentsSize, in bytes;
  • on Solana, the account manifest.
A program that does not compile is an error result with the compiler’s message and where in the source the problem is. This result is for the program below, on Base, with omitBytecode:
pay.sauce.ts

​
sauce_actions

Compiles an actions document (JSON) into the program that runs it on an EVM chain and, given a Pot, builds its unsigned cook. Matches sauce actions. The document is validated against the resource sauce://actions/schema.json. Returns sauce_compile’s report for the generated program, plus:
  • source, the generated SauceScript;
  • parameters, the argument actions in the order main takes them;
  • given a Pot, transaction: the unsigned cook, exactly as sauce_tx returns it.
On a preview chain, refused takes the place of transaction.

​
sauce_tx

Builds the unsigned transaction that runs a program on its Pot, for the Pot’s owner to sign. Matches sauce tx. Returns, on an EVM chain:
  • Pot deployed: { chainId, to, data, value }, the cook (Pot.cook) with to set to the Pot.
  • Pot not deployed yet: { chainId, pot, transactions }. The first transaction is Kitchen.deployPot, marked deploysPot, which any account may send. The cook comes last.
    • Each transaction has gas, the limit to sign it with. A cook that would revert after the deployment (for example, on a Pot not funded yet) has no gas, and a note says why. Fund the Pot after its deployment lands, not at its address before then, or pass fund, which with an endpoint plans a token’s transfer after the deployment. ETH:<amount> adds to the cook’s value, with no separate transfer.
    • sendCalls holds every transaction in order, for a wallet that sends a batch.
  • Both forms carry from, the owner who must send the cook, and kitchenFee when it was read from the chain.
On Solana it returns { chain, via, feePayer, pot, fee, maxExecutionFee, createsPot, transaction, cursor }, a base64 transaction for the owner to sign. A cook too large for one transaction comes as the first step of a plan, { step, plan, transactions, cursor }, sent step by step through sauce_send. Every result has sourceSha256 and notes. On Arc, a note gives the chain’s minimum base fee: each transaction must be signed with a maxFeePerGas (or gasPrice) of at least 20 gwei, or it is never mined. On a preview chain it is refused before any endpoint is reached (Supported and preview chains).

​
sauce_signed_cook

Builds a cook the Pot’s owner signs and any account sends, with the Pot’s cookSigned (Signed cooks). It signs nothing: it returns the EIP-712 typed data for the owner’s wallet to sign, and, given that signature, checks it and builds the transaction to send. Every server lists it, stdio and HTTP. Matches sauce sign with no signer. Returns sauce sign --json’s object:
  • chainId, pot, owner, engine, program, value, maxExecutionFee, nonce, deadline and submitter: what is signed, numbers as decimal strings;
  • typedData, as eth_signTypedData_v4 takes it, and digest, the hash the signature is over;
  • with signature, the signature and cook: { chainId, to: <the Pot>, data: cookSigned(…), value }, for any account to send with exactly value;
  • deployPot while the Pot has no code, for any account to send before cook;
  • with cancel, { chainId, pot, owner, nonces, transactions, sendCalls } instead, for the owner to sign and send;
  • notes: who may send it and until when, the Kitchen’s fee beside the ceiling and what the Pot holds.
Call it twice. The first call returns typedData; the owner’s wallet signs it. The second call takes the same inputs without within (it is refused beside deadline), plus the nonce, deadline and maxExecutionFee the first returned, and signature, so it builds the same cook. On a local fork of Base with the current contracts, a signature made over one set of args and given with another was refused (the signature given is not <owner>'s …), and with the same inputs it returned cook. sauce_wallet_send from another wallet then sent deployPot and cook, and both succeeded. A cook that reverts leaves its nonce unused, and whoever holds the result can send cook until the deadline. It is refused on a preview chain and on Solana, before any endpoint is reached (Supported and preview chains).

​
sauce_pot

Predicts the owner’s Pot address, builds its unsigned deployment and, with an endpoint, reads what it holds. Matches sauce pot. Returns chainId, pot, owner, salt and kitchen, then the deployment:
  • on an EVM chain, Kitchen.deployPot as to, data and value, with sendCalls;
  • on Solana, the Kitchen’s create_pot instruction, which the owner signs.
With an endpoint, it also returns:
  • deployed (null without one);
  • on an EVM chain, kitchenFee, the least a cook’s value can be, with symbol, the chain’s native coin;
  • on an EVM chain, balances: native (with its symbol) and tokens, each registered token except tokenized stocks, null where a token cannot be read;
  • on Solana, the Pot’s associated token accounts.
On Arc the native coin is USDC, and the USDC token at 0x3600000000000000000000000000000000000000 reads the same balance. balances.native (18 decimals) and that token’s entry (6 decimals) count it twice, and a note says not to add them. A note also gives Arc’s 20 gwei minimum fee. This result is for an owner’s default Pot on Arc, trimmed:
On Base the same call reports kitchenFee.symbol and balances.native.symbol as ETH. On a preview chain the Pot is still predicted and read, and refused replaces the deployment. That result is not an error. On an EVM chain, sauce_pot, sauce_tx, sauce_actions (with an owner), sauce_simulate and sauce_signed_cook (without cancel) hold the Pot to the Pot guard before anything is built: a Pot not deployed yet must be where the deployed Kitchen’s predictPot puts it, a deployed one must be a Pot the deployed Kitchen created, and owner the zero address is refused. Without an endpoint the Kitchen cannot be read, so the address is not checked. With cancel, sauce_signed_cook builds the owner’s nonce cancellations without these checks, as sauce sign --cancel does.

​
sauce_reclaim

Lists a Solana owner’s open Kitchen code buffers and lookup tables, the rent they hold, and the unsigned transactions that close them. Matches sauce reclaim. Returns:
  • owner;
  • buffers;
  • lookupTables, each with state: active, deactivating (with closableFromSlot) or closable;
  • lamports, the total rent;
  • transactions, in base64 for the owner to sign, then for sauce_send.
A buffer or an active table that a transaction named in the last 300 slots is listed with inUse and left open.

​
sauce_simulate

Simulates the cook from the Pot’s owner against the chain’s current state, or a pinned block. Nothing is signed or sent. Matches sauce simulate. It needs an endpoint. On an EVM chain the simulation goes through eth_simulateV1, or through eth_call with state overrides where the endpoint lacks it; path says which. A Pot that is not deployed yet is deployed first in the simulation. Returns:
  • ok;
  • leftInPot, what the Pot still holds of the tokens the cook moved;
  • transactions, the gas of each transaction;
  • what main returns;
  • the ERC-20 transfers and approvals, native transfers, and each address’s net balance change.
A cook that reverts is an error result, with reverted: true, error (the decoded reason), ok: false and the stage. With scenarios, the result is { ok, block, scenarios }. On Solana the result reports compute units, the fee, each token account’s change, and computeStops: each swap at a price, held with its stopPrice or skipped, and deepTick where its walk goes on into the furthest tick array its accounts give (Swaps at a price and compute units).

​
sauce_inspect

Decodes a transaction, calldata or program back into what its author wrote: a Pot.cook, a Kitchen.deployPot, an ERC-20 call or a bare program. Matches sauce inspect. Returns the decoded call or program, and notes.

​
sauce_verify

Checks whether a settle payload, a Pot.cook or a transaction runs the settle program the package ships, and with which parameters. Matches sauce verify. Returns valid: true with the settle’s tokens, minOut and recipient. Otherwise it returns valid: false with the rejection code, as a result rather than an error.

​
Sending signed transactions

​
sauce_send

Broadcasts transactions a wallet or signer has already signed, waits for each to land, and reports what each did. It takes no key and never signs. Every server lists it, stdio and HTTP. Matches sauce send. How it sends:
  • Each transaction is simulated as signed first: on an EVM chain an eth_call from its sender, on Solana a simulation that checks every signature.
  • A transaction that would fail is not sent.
  • On an EVM chain, every cook and Pot deployment among the transactions is held to the Pot guard first, all together. One that fails it stops the batch before anything is sent, naming it: nothing was sent — transaction 2 of 2 (cook on Pot 0x…): ….
  • Each transaction lands before the next is simulated, and the first that does not succeed stops the rest.
  • A transaction already on chain is read back, not sent again.
  • On Arc, a transaction signed with a fee cap below the chain’s 20 gwei minimum base fee is refused before anything is sent:
Returns:
  • chain, chainId and ok;
  • sent, each entry with its hash (a signature on Solana), status, explorer, trace, fee or gas, and the decoded reason of a failure. A cook also lists what moved and leftInPot.
  • pots, for each Pot a transaction deployed. A server that keeps the Pot store records them there.
  • with a cursor, next, the plan’s next step.

​
Skill tools

These four tools are listed by every server. The same files are also served as resources.

​
sauce_skills

Lists every agent skill the server carries, with when to use it and its files. It takes no inputs. Returns package, version, latest (a newer published version, when there is one), index (sauce://skills/index) and skills, each with name, description and files with sizes. The package carries 13 skills.

​
sauce_skill

Returns one skill’s SKILL.md, or one of its files under references/ or examples/. Only files the package ships are served. Returns skill, path, uri, mimeType, bytes and text.

​
sauce_dev

Returns the package’s own documents (guides, API pages and runnable examples) for TypeScript work against the SDK, the sauce command, or this server. Returns topics and documents, each with its path and text.

​
sauce_install_skills

Returns the commands that set up a project for one coding agent, pinned to the server’s own version. It writes nothing. Matches sauce skills and sauce mcp setup. Returns:
  • agent, version and skillsFrom, where the agent reads skills;
  • commands: add, install, update, status, init and mcpSetup;
  • mcp, the file sauce mcp setup writes for that agent, with its exact content.

​
Wallet tools (stdio only)

A stdio server started without --no-wallets or --no-stores lists these seven tools. They serve the wallet directory: ~/.sauce/wallets by default, or the directory --wallets <dir> names. The HTTP server never lists them. Wallets over stdio covers the flow.

​
sauce_wallet_enable

Enables the server’s wallets to create, import and sign for the rest of the process’s life. It takes the password’s source, never the password. Give exactly one source. Returns dir, enabled, source, wallets and, with generate, passwordFile. A server started with a password source refuses to change it.

​
sauce_wallet_create

Creates a wallet with a fresh key, encrypted under the wallets’ password. Matches sauce wallet new. It needs the wallets enabled. Returns name, kind, address, path and policy (null when there is no policy file), never the key. An existing name is refused.

​
sauce_wallet_import

Imports the key a file on the server’s machine holds, named by its path, as a new wallet. Matches sauce wallet import. It needs the wallets enabled. The file must be a regular file only its owner can read, and it is left as it is. Returns name, kind, address and policy, never the key.

​
sauce_wallet_list

Lists the wallets. It needs no password and reads no chain. Matches sauce wallet list. It takes no inputs. Returns:
  • dir, the wallet directory;
  • enabled, and the source that enabled the wallets;
  • wallets, each with name, kind, address and policy.

​
sauce_wallet_address

Returns one wallet’s name, kind, address and policy. It needs no password. Matches sauce wallet address.

​
sauce_wallet_send

Signs and sends, from one of the server’s wallets, the transactions another tool built unsigned. It needs the wallets enabled. It has no single matching command; it signs as --wallet does on sauce run and the other sending commands. How it sends:
  1. It simulates every transaction first: on an EVM chain all together in one eth_simulateV1 block, on Solana each as signed. If any would revert, it sends nothing. On an EVM chain it holds every cook and Pot deployment to the Pot guard too, and a step that fails it stops the plan before anything is sent.
  2. It holds the transactions to the wallet’s policy, and refuses, naming the limit, what the policy does not allow.
  3. It sends each in order and stops at the first that does not succeed.
Returns wallet, from, chain, ok, policy and sent. Each entry of sent has hash, status, explorer and trace. An EVM cook adds moves, leftInPot and summary. A Pot deployment adds pots. A signed cook’s result sends deployPot, when there is one, then cook, from whichever wallet you name: the owner signed it, and any wallet sends it. A signed cook already sent is refused before anything is sent: not sent — transaction 1 (1 of 1) would revert: NonceUsed().

​
sauce_sign

Signs a cook with one of the server’s EVM wallets, as the Pot’s owner, for another account to send: sauce_signed_cook signed here. It needs the wallets enabled. Matches sauce sign --wallet. Returns sauce_signed_cook’s result with signature and cook, and deployPot while the Pot has no code. With cancel it returns { chainId, pot, from, nonces, sent }, each sent cancellation with its hash, status, gasUsed, explorer and trace. sauce_wallet_send sends cook from any of the server’s wallets. A wallet whose policy sets a native or tokens limit refuses to sign, naming the limit: a signed cook runs when someone else sends it, on the chain’s state then, so its outflows cannot be measured when it is signed. chains and to still apply, with the Pot as the address. It is refused on a preview chain and on Solana.

​
Pot store tools (stdio only)

A stdio server started without --no-stores lists these two tools. They read and write the Pot store that sauce pot list and sauce pot import use: ~/.sauce/pots by default, or the directory --pots <dir> names. Local server storage covers the store.

​
sauce_pot_list

Lists the Pots recorded in the store. It reads no chain. Matches sauce pot list. Returns store and pots. Each Pot has:
  • its chain, address, owner, salt and kind;
  • its Kitchen;
  • release and engine, the release it was minted under;
  • deployment, the transaction that deployed it.

​
sauce_pot_import

Records in the store a Pot this machine did not deploy, read from the chain. Matches sauce pot import. Returns store and pots, as sauce_pot_list gives them. A Pot already recorded keeps its record.

​
Resources

Every server serves these resources: These are the same files that sauce skills install copies into a project. They are also served as tools because many clients call tools but do not read resources.

​
Prompt

sauce_write_program walks an agent through a program for a task, end to end with the tools: read the skills, look up the chain’s names, compile, simulate, and build the unsigned Pot deployment and cook. The prompt’s message names the skills to read first: sauce-overview, sauce-script and sauce-cli, with sauce-solana in place of sauce-script on Solana. It embeds the sauce-overview skill, or sauce-solana on Solana. It then lists five steps: sauce_globals, sauce_compile, sauce_simulate, sauce_pot and sauce_tx.

​
How a tool reaches a chain

A tool that reads a chain looks for an endpoint in this order:
  1. the call’s own rpcUrl;
  2. the server’s entry for the chain in the --config file, { "rpcUrls": { "<chain id>": "<url>" } };
  3. a built-in public endpoint for the chain, unless the server was started with --offline;
  4. if there is none, the call is refused with an error naming the chain and asking for rpcUrl.
A result read through a public endpoint says so in its notes:
sauce_chains reports each chain’s endpoint as config, public or none. Some tools never read a chain:
  • sauce_chains, sauce_globals, sauce_compile;
  • the skill tools;
  • sauce_wallet_list, sauce_wallet_address and sauce_pot_list.
sauce_simulate, sauce_send, sauce_wallet_send, sauce_pools, sauce_reclaim, sauce_pot_import, a Solana cook, and any call given a transaction hash need an endpoint. URLs are never shown. An RPC URL, from the call or from the --config file, is never returned, logged or quoted, in results or errors. This includes an upstream error that repeats the URL. The config file’s path is not shown either. Two cautions:
  • A server someone else runs sees every rpcUrl you pass it. Pass only keys you are willing to share with its operator, or run the server yourself.
  • Over HTTP, a caller’s rpcUrl goes through a guard (Self-hosting over HTTP).

​
Supported and preview chains

Transactions are built and sent only on Ethereum, Base, Arc and Solana, and on the testnets Arc Testnet, Base Sepolia, Ethereum Sepolia, Solana Devnet and Solana Testnet. Every other chain in the registry is a preview chain, where programs compile and reads work. Chains lists both kinds, and sauce_chains reports each chain’s support (supported or preview). The testnets have no Permit2 entry and Arc Testnet has a 20 gwei fee floor (Testnets). These work on every chain:
  • sauce_chains, sauce_globals, sauce_price, sauce_pools;
  • sauce_compile, sauce_inspect, sauce_verify;
  • sauce_actions’ report, and sauce_pot’s prediction and reads;
  • the skill tools, the wallet listing tools and the Pot store tools.
sauce_simulate is not gated by preview status: it runs wherever the release’s engine and Kitchen are deployed and the endpoint supports the simulation. Where the engine has no code, the result is an error, the released engine <engine address> is not deployed on <chain>: this SDK's cook cannot run there. sauce_pot reports whether the engine is deployed on a chain. On a preview chain, the following are refused before any endpoint is reached: sauce_reclaim accepts only Solana, Solana Devnet and Solana Testnet, the supported Solana chains; on an EVM chain it is an input error. The refusal, from sauce_tx on Arbitrum One:
Each preview chain’s request names how to request support for that chain: a search for an existing request, a prefilled new one, and the title, body and comment to post, with placeholders for what the agent does not know. Each refusing tool’s output schema makes every field optional beside refused, so a client that validates structured content accepts the refusal.

​
Next steps