find_tool, which searches by what you are trying to do and runs the
one that fits. Their descriptions are the longest in the registry, and carrying
all of them on every turn made unrelated conversations more expensive.
Tools that spend
arm_schedule ⚠
Put a schedule live NOW, rather than letting a chain arm it when the stage before it succeeds. From this moment it fires unattended and SPENDS REAL FUNDS every time. Prefer letting a chain arm it: that way nothing recurs until the setup it depends on actually worked.
decide_firing ⚠
Answer a scheduled run that could NOT START because the owner already had a task in flight. One task runs per owner at a time. run_now takes the slot as soon as it frees — not ‘try again now’, because the slot is busy. skip drops this firing only. Unanswered, it is dropped after a week.
place_order ⚠
Wait for a PRICE, then run a workflow that is ALREADY SAVED. The trigger a schedule is to a clock. It holds no signature and compiles a fresh plan each time it fires, which is why one can rest for days without going stale — and why nothing is signed until the price is actually there. Use it for “buy X at Y”, “sell when it reaches Y”, and for unwinding a loan at a price: point it at a swap.router, loan.close or loan.shift plan. By default a short fill is ACCEPTED: it takes what the block will give, records it, and comes back for the rest. A STOP-LOSS is direction “at_or_below”; add trail_bps to make it trail the market up. A TAKE-PROFIT is the default “at_or_above”. Point either at the entry with protects and it sells only what that entry actually bought. A RUNG (rung true) fills only within a band AT your price and waits when the market runs past instead of chasing it — its band is the plan’s max_impact_bps. A TWAP (twap_slices + twap_interval_secs) fires at MARKET on a clock instead of on a price: it spreads the size into that many equal slices, one every interval, until it is done — for getting in or out over time regardless of where the price is. A TWAP cannot also carry a trail, a rung or a protects. A MARKET ORDER (market true) waits for no price: it is partially fillable, and each pass takes whatever clears at market within a per-bite price-impact cap (the plan’s max_impact_bps, else 20 bps = 0.2%, which the owner may change), then bites again for the rest until it is filled, expires or is cancelled. It needs partial true, direction at_or_above, no rung, trail, TWAP or protects, and a plan whose swap states no limit_price, min_out or limit_band_bps; the service refuses anything else with its reason. On-chain only: Binance orders use Binance’s own partial fills.
run_workflow ⚠
FOR A STRATEGY, WRITE A CARD INSTEAD (the strategy_* tools): a request with a rule, a condition or a repeat (“when”, “every”, “after a drop”) is a card, and the compiler makes its plan JSON. This tool is for the families no card covers yet (today a card covers a conditional buy or sell of one asset against one stablecoin, sized as a share; internal/planlang/cardcoverage has the numbers). MAKE A SAVED WORKFLOW RUN. This SPENDS REAL FUNDS. It is the ONE tool for that, and it works out WHICH of three things you meant by reading the run — you do not choose: nothing has run it STARTS the revision as authored the run stopped it RESUMES from the steps that already settled, at the same revision, and does not replay them the run completed it REPEATS — copies the plan to the next revision and runs the whole thing again. It REFUSES once first and tells you the number to pass back, because that is a second position rather than a repair something is in flight it does nothing and says what is happening So “run it”, “run it again”, “resume it” and “continue it” are all THIS tool with the same arguments. Do NOT save a new revision to get a stopped run moving, and do NOT author the plan under a new task id: both re-execute what has already been paid for.
start_chain ⚠
Begin a saved chain. This SPENDS REAL FUNDS: it runs the first once-stage immediately. A stage that ends stuck stops the chain and arms nothing after it.
Tools that do not spend
backtest_options ◇
What an option structure WOULD HAVE done, rolled through history. ONLY WHEN SOMEBODY ASKS FOR THE HISTORY. price_options answers what protection costs now and whether that is dear or cheap; this answers what the same shape did over years of rolls. They were one tool and everything that read them confused the two — the study’s opening price is 2021 by default, at a volatility index of 117.8 against a recent 51.8, and it was quoted as the current price. total reaches -100% for any structure that only buys premium, from every start date. The model spends the whole budget on options each roll, so that is the fate of a premium budget — not the return of a hedged portfolio, and not a forecast.
cancel_order
Stop a resting order for good. What it already filled stays filled — this stops it firing again, it does not undo anything. Refused while a run is in flight, because cancelling the row cannot recall a transaction.
check_allowance ◇
What the OPERATING ADDRESS may draw from the owner, and whether that covers an amount. A deposit.pull step needs TWO things and they fail differently: the tokens have to be held by the owner, and the account has to have PERMISSION to draw them. get_balances answers the first. This answers the second. Pass amount — in the asset’s own base units, so 500 USDC is “500000000” — to ask whether the allowance covers a draw of that size. Without it this only reports what is currently approved, and nothing is offered to fix. WHEN IT IS SHORT the console puts an Approve button in front of the person for exactly the gap. Tell them what it is for; you cannot press it. An approval moves no money — the tokens stay in their wallet and the account gains permission to draw them — and it is the owner’s signature, not this server’s. validate_workflow already checks this for the pulls in a plan. Use this one when there is no plan yet, or when somebody asks about an allowance directly.
check_supported
FIRST, before anything else: check that the assets, chains and operations the person actually named are supported. Someone asks for FRAX or for something on Solana and the answer is no — better known now than after a plan is built on it. It also answers the COMBINATION, which no list can: an asset, a chain and an operation can each be supported while the three together are impossible.
compare_options ◇
EVERY option structure priced at once, for choosing between them. For “what are my options for hedging this” and “which protection is cheapest” — the first call when somebody wants to know what is available. Ask this BEFORE price_options. Pricing nine structures one call at a time costs nine model turns and about a tenth of a second of actual work — this returns the same comparison in one, and names the detail worth following up. COVER/ROLL is the number to compare when choosing protection: what the structure’s first leg costs as a share of the position. Negative is premium paid out, positive is premium taken in. TOTAL is not that. It is the return on money spent ENTIRELY on options and rolled, so it reaches -100% for anything that only buys premium — a property of the model, not a forecast about the asset. Strikes are fixed per structure and are shown; they are not an argument.
find_skill
ASK YOUR QUESTION HERE FIRST. Returns the ANSWER — the handful of sections that address it, from across every guide, each cited by file and line. Not a list of names to go and read: the text you need comes back in this one call. Ask in the words a person used — “only fill if the price is right”, “unwind a loan without selling first” — and it searches the prose AND the exact identifiers. Prefer this to read_skill, which returns whole documents and costs several times as much for the same answer. Call with no query to see the whole shape of what exists.
find_tool
Find a tool, or RUN one. Pass query to search by what you are trying to do; pass run with a name to call it. The tools below are real and their full schemas are withheld to keep every turn cheap. Name one in run and it works exactly as if it had been offered directly; an argument marked * is required, and a wrong call comes back with that tool’s whole schema so one mistake costs one turn. LIQUIDITY RANGES · get_lp_deposit(budget*=1000, fee*=500|3000, token_a*=WETH|cbBTC, token_b*=USDC, buffer, chain, have_token0, max_slippage_bps, range, token1_share, width) — HOW MUCH OF EACH TOKEN A UNISWAP RANGE NEEDS, and what to swap to get there · get_lp_yield(tokens*, capital, chains, entry_price, exit_price, exit_prices, fee_tiers, from, priced_in, ranges, to) — BEFORE providing liquidity: what a range would have COLLECTED, from each pool’s real daily history, on every chain and fee tier at once · get_tick_range(fee*=500|3000, range*=2000-4000|2500, token_a*=WETH|cbBTC, token_b*=USDC, chain) — Turn a PRICE RANGE into the tick_lower and tick_upper a Uniswap V3 mint takes · list_lp_strategies(strategy) — The ways a liquidity position can be placed and managed, and what each one’s inputs are · run_lp_backtest(pool*=ethereum|USDC/WETH|500, capital, from, lower, params, strategy, to, upper) — Run ONE strategy over ONE pool’s real history and report what it did LIVE MARKET STATE · get_forecast(asset) — What the market EXPECTS, in one call: the prediction market’s odds that an asset ends a month above each strike, what is priced into each Fed meeting,… · get_hyperliquid(coin) — What a perpetual is paying on Hyperliquid in the LATEST SAMPLE: funding annualised, open interest, mark against oracle · get_liquidations(coin, limit, since) — Forced closes as they happened, with the address each happened to — which no centralised venue publishes · get_macro(series) — The macro series themselves: the Fed balance sheet, the Treasury account, reverse repo, and stablecoin supply beside them · get_market_regime(asset) — Whether the slow signal is asking to be long or flat, and why OPEN POSITIONS · check_allowance(assets*, owner*, account, amount, asset, chain) — What the OPERATING ADDRESS may draw from the owner, and whether that covers an amount · get_lending_positions(owner*, account, chain, chains, venue) — WHAT THIS OWNER ALREADY OWES AND HAS SUPPLIED AT THE LENDING VENUES, read from each one rather than from any record this system keeps · get_orders(owner) — What is resting, what filled, and in how many bites · get_uni_positions(owner*, account, chain, chains) — THE UNISWAP POSITIONS THIS OWNER ALREADY HOLDS — token id, pair, fee tier, price band and uncollected fees, read from the position manager on each c… OPTIONS AND HEDGING · backtest_options(currency*=WETH|cbBTC, structure*=put|collar, capital, from, skew, strikes, tenor_days, to) — What an option structure WOULD HAVE done, rolled through history · compare_options(currency*=WETH|cbBTC, capital, from, skew, structures, tenor_days, to) — EVERY option structure priced at once, for choosing between them · list_option_structures() — The option shapes that can be priced — every way to hedge, insure or be paid for taking risk: protective put, collar, straddle, covered call, cash-s… · price_options(currency*=WETH|cbBTC, structure*=put|collar, capital, from, skew, skew_decay, strikes, tenor_days, term_vol, to) — What an option costs RIGHT NOW, and whether that is dear or cheap · price_options_live(currency*=WETH|cbBTC, capital, moneyness, structure, tenor_days) — What an option costs RIGHT NOW, from Deribit’s live book RATES AND COSTS · get_bridge_cost(from*=base|arbitrum, to*=ethereum|arbitrum, asset, must_arrive, sending) — What to SEND so that a wanted amount lands after a crossing, or what a given amount will deliver · get_funding_and_oi(currency*=WETH|cbBTC, from, group_by, to) — Perpetual-swap funding and open interest HISTORY, daily from 2021: its headline funding is an AVERAGE over the window, never the current rate · get_lending_rates(asset, assets, chain, chains, venue) — WHAT EVERY MARKET CHARGES RIGHT NOW: supply APY, borrow APY, how much of it is already borrowed, and the loan-to-value at which it liquidates · get_swap_cost(amount_in*=1000000, asset_in*=USDC, asset_out*=WETH, chain, cost_bps, max_impact_bps, max_slippage_bps) — What a specific trade will actually cost, all in — and what a BOUND would do to it before you write one into a plan REFERENCE · get_run_status(owner*, task*, revision, run) — Report how a submitted workflow is going, step by step · list_networks_and_assets() — The chains, the assets each supports, and their decimals
forget_run
GIVE UP a run that stopped part-way, so this owner can start something else. It spends nothing and it is not an undo. DO NOT CALL THIS ON YOUR OWN INITIATIVE. It is the one destructive verb you hold: it throws away a record of somebody’s money that cannot be put back, and no refusal you are reading is permission to use it. Call it ONLY when the person has said, in their own words and in this conversation, to give that run up — abandon it, drop it, forget it, get rid of it. said carries those words and the call is refused without them. If they have not said it, ASK; a refusal you cannot get past is a thing to report, not a thing to clear. NEVER AFTER stop_run, in the same breath. Stopping and giving up are two different decisions and the person has made only the first: a run that has just been stopped is one they may still want to carry on. Calling this because stop_run appeared to change nothing is the exact mistake it exists to prevent — stop is SUPPOSED to leave the slot held. THIS IS NOT STOP. stop_run ends a run and deliberately leaves it holding the owner’s slot — that is what makes stop-then-run-again a pause. A run that stopped part-way holding settled steps BLOCKS every other start for that owner, on purpose, so a second position is never opened against a wallet the first is still holding. This removes the run record, which is the thing doing the blocking. Use it when a stranded run is refusing a start and that run is genuinely finished with. If it should be carried on instead, say run it again and run_workflow continues it — do not forget it first. NOTHING ON CHAIN IS UNDONE, and the settled steps stay settled: they are keyed on the task and revision, not on the record this removes, so running the task again still continues from them rather than replaying them.
get_account_state
Show the owner and the operating address — the account the agent operates and every plan spends from — and what each currently holds. Call this before deciding any amount.
get_balances
Read several asset balances for several holders AT ONCE, in one request. Called bare it reads BOTH addresses — the operating address and the owner’s wallet — across USDC, cbBTC and WETH, which is almost always the whole question: money can sit at either and a plan spends from the operating one. Asking for one holder and then the other costs two turns and answers nothing extra. Pass “chain” to read somewhere other than base. Holders are roles: owner_account (the OPERATING ADDRESS, which is what every plan spends from), owner_wallet (the OWNER), or a plain 0x address. Pass the owner — the operating address is derived from it.
get_bridge_cost ◇
What to SEND so that a wanted amount lands after a crossing, or what a given amount will deliver. Call it whenever a plan bridges. DO NOT WORK THIS OUT IN PROSE. A crossing keeps a fee, so sending exactly what the far side spends lands short and the run stops AFTER the money has already crossed — and the near miss is the common one: a gross-up rounded to the nearest cent is short by a fraction, which reads as correct and is not. Every “short 0.1 USDC” refusal is this arithmetic done by hand. Give must_arrive to size a crossing, which is the usual direction: it returns the exact integer for the bridge step’s Amount. Give sending to check an amount already written. Raw units both ways.
get_chain
Read a CHAIN: an ordered arrangement of workflows, which runs once and which recurs, plus where a running one has got to. A strategy is rarely one plan — a setup that runs once and a loop that runs monthly are edited and approved on different rhythms. Call this before changing one.
get_fill_at_price
AT THIS PRICE, HOW MUCH FILLS RIGHT NOW. The question a limit order is made of, and the one the ladder cannot answer: get_tradeable_size tells you what a COST buys, this tells you what a PRICE buys. Call it before place_order whenever somebody names a price. An order for $1m at a rate that clears $40k is not wrong, but the person should know it before it rests for a week — and if nothing fills, that is a real answer rather than an error: the price asked for is better than the market. Measured across every pool, which is what a plan here executes. The price is a PAIR of raw amounts, never a decimal.
get_forecast ◇
What the market EXPECTS, in one call: the prediction market’s odds that an asset ends a month above each strike, what is priced into each Fed meeting, the rate curve those meetings would move (policy rate, 2y, 10y, 10y-2y, breakeven inflation, VIX), and where the OPTION market has already committed — open interest by expiry with the busiest strike in each. THE LADDER IS WHAT A VENUE QUOTES; THE OPEN INTEREST IS WHERE MONEY SITS. Two kinds of evidence about the same level, and the pair is worth more than either. THE ONLY FORWARD-LOOKING NUMBERS HERE. Every other market tool answers what HAS happened — funding since 2021, what a put has cost, what a pool earned. This is what people are betting now. IT IS A PRICE, NOT A PREDICTION OF OURS, and it carries the venue’s fee and a thin book’s noise: a rung with little volume is one opinion. Use it to say what protection against a level is worth, never as a reason to reopen a decision somebody has made.
get_funding_and_oi ◇
Perpetual-swap funding and open interest HISTORY, daily from 2021: its headline funding is an AVERAGE over the window, never the current rate The answer names the window on every average (the whole series since 2021 when no from/to is given), then each venue’s latest whole day on its own line. Quote an average with its window. A question about the PRESENT rate across venues is strategy_feed_now’s, on the feed runtime’s funding view, and is never answered with an average from here or a figure computed from this answer. Funding is what one side of a perpetual pays the other. A POSITIVE rate is longs paying shorts, so sustained positive funding is the running cost of holding the long side — and the figure to set against any yield a delta-neutral position claims to earn. Read from FOUR venues separately — Binance, Bybit, Hyperliquid and Aster — and never silently averaged: where venues disagree, the disagreement is the reading. Open interest and the long/short ratios come from BINANCE’S daily archive alone — no other venue publishes an equivalent here, so they are one venue’s book rather than the market’s. When a symbol is absent the answer SAYS SO rather than showing zero — a missing series is a gap in the source, not a reading of no open interest, and nothing about positioning should be inferred from it.
get_hyperliquid ◇
What a perpetual is paying on Hyperliquid in the LATEST SAMPLE: funding annualised, open interest, mark against oracle. The watcher samples every few minutes; the answer leads with the sample’s age, and says STALE when it is older than 10 minutes (hlStaleAfter). Say the age, and when it says STALE, say the figure is old and not the rate now. THE LATEST SAMPLE, NOT HISTORY. get_funding_and_oi walks recorded days and answers whether a carry has been worth having; this answers what it paid at the last sample, which is what somebody asks before opening one. The venue keeps no history of its own, so these cannot be one call. A POSITIVE rate is paid by longs to shorts, so a short perp against spot collects it.
get_lending_positions ◇
WHAT THIS OWNER ALREADY OWES AND HAS SUPPLIED AT THE LENDING VENUES, read from each one rather than from any record this system keeps. Covers Aave v3, Aave v4 and Morpho, on every chain, for BOTH the operating address and the owner’s own wallet — they are separate borrowers and a debt on either is a real debt. Call this before any borrow, any repay, any loan shift, and before saying anything about what somebody holds. A position is the only thing that says whether a borrow can succeed: get_lending_rates says what it would cost, which is a different question.
get_lending_rates ◇
WHAT EVERY MARKET CHARGES RIGHT NOW: supply APY, borrow APY, how much of it is already borrowed, and the loan-to-value at which it liquidates. Aave v3’s reserves are enumerated FROM THE POOL, so it covers every asset Aave lists and not only the ones this system has a name for; Aave v4’s from its hub; Morpho’s are the curated markets. Call it before choosing a venue to borrow from, before quoting anybody a rate, and before assuming two venues cost the same — they routinely differ by more than a point on the same asset on the same chain. A Morpho row also says how much is free to borrow right now. Morpho markets run near 90% utilisation, so it is small and it moves, and a borrow larger than it is refused at validation: read it before choosing the market. ASK ONCE, FOR EVERYTHING THE PLAN TOUCHES. chains and assets are lists: a plan lending XAUt on ethereum and cbBTC on base is ONE call, {“chains”:[“ethereum”,“base”],“assets”:[“XAUt”,“cbBTC”]}. Narrowing to one pair at a time is a round trip per pair and was measured costing three calls for one plan. Omitting both is also fine and returns every market on every chain.
get_liquidations ◇
Forced closes as they happened, with the address each happened to — which no centralised venue publishes. WHAT IT IS FOR: liquidation, not price, is what stops a leveraged hedge hedging. A cluster of them at a level is the risk a perp carries that an option does not. Recorded forward only: the venue’s endpoint caps at 2000 rows, so a date before the watcher started is empty rather than wrong.
get_lp_deposit ◇
HOW MUCH OF EACH TOKEN A UNISWAP RANGE NEEDS, and what to swap to get there. Call it after get_tick_range and BEFORE writing the swap that funds a mint. THE SPLIT IS NOT 50/50 AND IT IS NOT A CHOICE. For a band at a price the two amounts are fixed by geometry, so use this range and put in 70/30 are the same decision made two ways: send range and this reports the split it implies, or send token1_share with a width and it reports the range that produces it. Sending both is refused. A symmetric band is NOT an even split — the two legs are a square root apart. Measured: $1,000 into WETH/USDC 0.05% on base, over a band the price sat inside, needed 45.3% WETH. A plan that swapped half left $47 unplaced. Nothing reverts; the position is simply smaller than the money paid for. It reads the pool’s live price, because a split against a stale one is wrong by however far the market has moved. IT QUOTES THE FLOORS TOO. A uni.mint or uni.increase states min0/min1, the least of each token the position manager may take; they are the only bound on the price the deposit runs at and the keeper refuses the step without them. The answer ends with the step’s amounts and floors in raw units, ready to write.
get_lp_yield ◇
BEFORE providing liquidity: what a range would have COLLECTED, from each pool’s real daily history, on every chain and fee tier at once. Answers the three questions a spot APY cannot — which network, which fee tier, and which range. An advertised APY is the last 24 hours across a pool’s whole book. This walks history a day at a time: the pool’s fees that day, times your liquidity over the pool’s, and ZERO on days the price left your band. A band that looked excellent was in range 19% of one window and idle for the rest, which no APY anywhere says. PASS EVERY RANGE YOU ARE WEIGHING IN ONE CALL. ranges is a list and each costs nothing extra, against a round trip per range otherwise. Omit it to get the widest band that held the price, which is the ceiling a narrower one is measured against. A range is “so many QUOTE per one BASE”. With one stablecoin that is dollars per coin and needs no thought; on WBTC/WETH or USDC/USDT set priced_in, because 25-40 and 0.025-0.04 are the same band from opposite ends. The direction used is always reported. IT ALSO ANSWERS WHAT YOU END UP WITH. Every answer carries a CASH IN HAND block: what the deposit is worth at the end, the impermanent loss, and the total against simply holding. Report that, not the fee figure alone — fees are half a ledger and people read them as the outcome. Still not modelled: compounding, rebalancing and gas. For “what if the price keeps going” pass exit_prices; for “what if I enter at X and leave at Y” pass entry_price and exit_price. A band traversed end to end sells every coin at the GEOMETRIC MEAN of its bounds, not at the price the asset finished at, and then stops earning — which is why a fast run to the top of a band is a bad outcome and not a good one. Fees are NET of Uniswap’s protocol fee, which the UNIfication vote switched on during 2026 — a quarter of the swap fee on the 0.01% and 0.05% tiers, a sixth on 0.3%. The subgraph’s own feesUSD is gross, so these figures are deliberately lower than a reader’s own arithmetic against it. REPORTING THE ANSWER, because this has been got wrong: the window DEFAULTS TO TWO YEARS, so name the window you actually got — the answer states its own length in days and years on the first line. The table gives two different rates: total is the return over the WHOLE window and per year is that annualised. Quoting total as an annual rate doubles it on a two-year window, which is exactly what happened to a 48.9% two-year figure reported as 48.9% a year. per year is an APR and NOT an APY: v3 keeps a position’s fees in a separate balance, so nothing compounds unless the owner collects and re-adds it by hand.
get_macro ◇
The macro series themselves: the Fed balance sheet, the Treasury account, reverse repo, and stablecoin supply beside them. THE INPUT, NOT THE VERDICT. get_market_regime does the net-liquidity arithmetic and answers long or flat; this is what it was computed from, for somebody who wants to see the balance sheet rather than the position.
get_market_regime ◇
Whether the slow signal is asking to be long or flat, and why. TWO INDEPENDENT READINGS, and the position is their union: on-chain valuation (MVRV against its own history) and net liquidity (Fed assets, less the Treasury account, less reverse repo). IT IS MEASURED IN MONTHS. It is not a reason to change a plan somebody has already decided on and says nothing about the next week — quote it when asked how the market looks, never as advice on a pending decision.
get_orders ◇
What is resting, what filled, and in how many bites. A partially filled order is working, not failing — it took what the price would give and is waiting for the rest.
get_prices
USD prices, from whichever source can answer for the asset. A tradeable asset (USDC, cbBTC, WETH) is quoted through the POOLS a swap would route through — the price you would actually get. A property token has no market and is quoted from 0xequity’s oracle, which is the price its OCLR router transacts at. This prices ONE UNIT; for a size that matters use get_swap_cost, which prices that size. PASS EVERY ASSET YOU CARE ABOUT IN ONE CALL. assets is a list and the cost of adding to it is one quote each, against a round trip per call otherwise — a plan touching four assets asked four times and spent four turns learning what one would have told it. Each asset is priced on EVERY chain that carries it, one row per chain, because the same token is not the same price in two places: WETH quoted $2429 on ethereum and $2492 on base within a second of each other. An asset absent from some chains is still priced on the ones that have it, and the others are named under it — so XAUt answers with its ethereum price rather than with the fact that Base does not carry it.
get_run_status ◇
Report how a submitted workflow is going, step by step.
get_schedule
Read a SCHEDULE — the recurring trigger attached to one workflow — with its next dates and what became of past firings. A firing marked BLOCKED is waiting for a person and will be dropped if nobody answers.
get_swap_cost ◇
What a specific trade will actually cost, all in — and what a BOUND would do to it before you write one into a plan. JUDGE A TRADE ON cost_vs_best_spot_pips, never on price_impact_pips: impact is measured against the route this quote chose and excludes the pool fee, so at size it can FALL while the trade gets more expensive. If cost_vs_best_spot_pips comes back null that means UNMEASURED, not free — read read_this, which says what to do instead. Call this before committing to an amount a person will care about. Send max_impact_bps or cost_bps to ask what that bound leaves: both shrink the offer, and offered_amount_in beside amount_in is the answer. Neither is slippage — slippage never changes the trade, only the floor it must clear.
get_tick_range ◇
Turn a PRICE RANGE into the tick_lower and tick_upper a Uniswap V3 mint takes. Call it for every uni.* or flash.* step that carries ticks. DO NOT WORK TICKS OUT IN PROSE. Between a price and a tick sit a logarithm, a DECIMALS adjustment, the pool’s tick spacing and Uniswap’s own token ordering — which is by address, so it cannot be guessed from the symbols. Only the spacing reverts when it is wrong. Forget the decimals term on WETH/USDC and the tick is out by about 276,310: a valid int24 that mints happily, at prices nobody asked for, holding one token and earning nothing. It reports the prices the rounded ticks actually mean, which are never exactly the ones asked for. Say those back to the person.
get_tradeable_size
THE INVERTED QUESTION, and the one an order is actually made of: not “what does this size cost” but “what size costs at most N basis points”. Returns a size per cost level, in one call. Use it before choosing any large amount, and before offering to split an order into tranches — whether splitting helps depends on the pair and this is what decides it. Read saturated (the size is a floor, not a maximum) and pools_answered (levels measured over different pool counts are not on the same curve) before believing a number.
get_uni_positions ◇
THE UNISWAP POSITIONS THIS OWNER ALREADY HOLDS — token id, pair, fee tier, price band and uncollected fees, read from the position manager on each chain. get_lending_positions is LENDING and does not cover these. Call this before writing any plan that acts on a position the person already has: uni.decrease, uni.collect and every revert.* step take a position_id, and it is a token id that cannot be guessed or derived. Asking the person for it is the wrong move when this answers it. Reads the operating address AND the owner. A position pledged as collateral is NOT listed — the Revert vault holds the NFT while the loan is open, so the position manager reports it as the vault’s. IT QUOTES THE UNWIND FLOORS. Every step that takes liquidity out (uni.decrease, uni.withdraw, uni.rebalance, uni.reposition, uni.split) states min0/min1, and each position here carries them: what burning all of it returns at the pool’s price now, less 100 bps, in raw units. Use those numbers, never 1 or 0 on a side the burn returns: the keeper refuses a floor more than 200 bps under the burn.
get_workflow
Read back a workflow that was saved, with its revision history AND whether a run of it has started, is in flight, or has STOPPED. Call this BEFORE changing a plan you did not just write, and before running one again: a revision cannot be edited in place, so a change means resending the whole document at the next revision, and reconstructing it from memory is how steps go missing.
list_capabilities
FOR A STRATEGY, WRITE A CARD INSTEAD (the strategy_* tools): a request with a rule, a condition or a repeat (“when”, “every”, “after a drop”) is a card, and the compiler makes its plan JSON. This tool is for the families no card covers yet (today a card covers a conditional buy or sell of one asset against one stablecoin, sized as a share; internal/planlang/cardcoverage has the numbers). The operations a workflow step can use, with the exact ref to copy, the parameters, and what Amount means for each. Call this FIRST, before writing any plan. PASS THE REQUEST AS THE QUERY — in the person’s own words, the whole thing, not one operation at a time: “take $1000 from my account and swap $200 to cbBTC and $200 to WETH” returns the funding step and the swap step in full and names the rest. Leave the query off only when you genuinely need the whole catalogue; it is several times larger and the operations you need are harder to find in it. When choosing between routes, weigh gas plus bridge fee plus the live-quote price impact, never gas alone (XAUt0 on Arbitrum is thin).
list_lp_strategies ◇
The ways a liquidity position can be placed and managed, and what each one’s inputs are. Seventeen strategies in eight families — hold one band and never touch it, recentre when the price leaves, widen with volatility, ladder several bands, keep part of the money out of the pool entirely. Each carries a plain-English summary and every input’s bounds and default. READ THIS BEFORE run_lp_backtest rather than guessing a strategy id or a parameter range. The list is fetched from the service, so it is what the service will actually accept — a strategy added there appears here without anything being changed. Pass strategy to see one in full, including per-option help for the ones whose inputs are choices rather than numbers.
list_networks_and_assets ◇
The chains, the assets each supports, and their decimals. Check here before naming an asset or a chain.
list_option_structures ◇
The option shapes that can be priced — every way to hedge, insure or be paid for taking risk: protective put, collar, straddle, covered call, cash-secured put and the rest — each with what it is FOR in one sentence, and its legs. Read this before price_options. Strikes here are MONEYNESS, a multiple of spot: 0.8 is twenty percent below, not a price of 0.8.
list_workflows
List the workflows this owner has SAVED before, newest first — the TaskID, revision, date and what each does. Call this when somebody refers to a plan from an earlier conversation (“the rent loop”, “run yesterday’s swap again”) instead of asking them for an id; then read the one they mean with get_workflow.
price_options ◇
What an option costs RIGHT NOW, and whether that is dear or cheap. For “should I hedge this”, “what does protection cost”, “how do I cap my downside” and “is volatility expensive”. THE MARKET AS IT IS, not a study. It gives the cost of cover today as a percentage of the position and in dollars, the annualised figure if rolled, where today’s volatility ranks in its OWN history over one year and over all of it, what the asset has ACTUALLY moved beside what is implied, and the levels worth an alert with what happens at each. THE PERCENTILE IS THE JUDGEMENT. A premium is a number; “cheaper than 16% of the past year” is a decision, and it transfers between assets where an absolute level does not. Quote the verdict and the levels as given. backtest_options is the separate question of what the shape would have done over years of rolls — ask it only when somebody wants the history.
price_options_live ◇
What an option costs RIGHT NOW, from Deribit’s live book. Use this for “what would it cost to hedge this”. price_options answers a different question — what protection HAS cost, rolled through history — and its figure is priced at the START of that window, which is 2021 by default. ETH’s volatility index read 117.8 then and 52.8 on 2026-09-12, and a put costs roughly what the volatility costs, so the historical figure is more than double the current one. Every leg is a real listed contract, named in the answer with its mark, its bid and its ask. Deribit lists the expiries and strikes it lists, so the nearest one is quoted and the substitution is shown rather than hidden.
read_skill
Read WHOLE guides, up to 3 — thousands of words each. Reach for it only when find_skill has shown you the right document and you need the rest of it: a procedure with steps that depend on each other, or a subject you are going to work in for several turns. For a QUESTION, find_skill answers it directly and for a fraction of the cost. The answer names which skills go with the ones you read.
run_lp_backtest ◇
Run ONE strategy over ONE pool’s real history and report what it did. Where get_lp_yield surveys pools for a band you name, this runs a named STRATEGY — including ones that move: recentre on exit, rebalance on a clock, scale the width with volatility, ladder several bands at once. The answer leads with how often the band held the price, because every APY below it is computed across the whole window regardless: a band in range 19% of the time earned nothing for the other 81%. It reports fees AND impermanent loss AND the comparison against simply holding. Report all three. Fees alone are half a ledger and read as the outcome. A BAND YOU NAME GOES WITH “static” OR “ladder”, and only those two. lower/upper are real prices — 2800 and 3200, not percentages. Use “static” for ONE band held all the way through, and “ladder” for SEVERAL ranges at once: it tiles rungs between the two bounds, and bands sets how many. Every other strategy MOVES or derives its own band and will refuse the bounds rather than quietly answer about a different band — name the strategy alone for those. History, not a forecast. Gas is not modelled.
save_chain
FOR A STRATEGY, WRITE A CARD INSTEAD (the strategy_* tools): a request with a rule, a condition or a repeat (“when”, “every”, “after a drop”) is a card, and the compiler makes its plan JSON. This tool is for the families no card covers yet (today a card covers a conditional buy or sell of one asset against one stablecoin, sized as a share; internal/planlang/cardcoverage has the numbers). Arrange workflows that are ALREADY SAVED into an ordered chain. Starts nothing. A stage with no scheduleId runs its workflow once and the chain waits for it to SUCCEED; a stage with one arms that schedule and carries on. Save the workflows and any schedules first — a stage naming a workflow that is not stored would fire into nothing.
save_schedule
FOR A STRATEGY, WRITE A CARD INSTEAD (the strategy_* tools): a request with a rule, a condition or a repeat (“when”, “every”, “after a drop”) is a card, and the compiler makes its plan JSON. This tool is for the families no card covers yet (today a card covers a conditional buy or sell of one asset against one stablecoin, sized as a share; internal/planlang/cardcoverage has the numbers). Attach a recurring trigger to a workflow that is ALREADY SAVED. It does NOT arm it and does NOT run anything. A schedule is deliberately not part of the plan document: a step’s id goes on chain and its bytes are in the hash somebody approved, and a cron has neither property — kept in the plan, changing the frequency would be refused as rewriting history.
save_workflow
FOR A STRATEGY, WRITE A CARD INSTEAD (the strategy_* tools): a request with a rule, a condition or a repeat (“when”, “every”, “after a drop”) is a card, and the compiler makes its plan JSON. This tool is for the families no card covers yet (today a card covers a conditional buy or sell of one asset against one stablecoin, sized as a share; internal/planlang/cardcoverage has the numbers). Store a validated workflow WITHOUT running it. Validates first and refuses to store anything that would not run. Call this once the plan is agreed and validated: it gives the console something to link to, so the person can open the workflow instead of reading it pasted into the conversation.
stop_run
STOP, PAUSE or TERMINATE a run of a task — all three are this one tool, because there is one act underneath. It spends nothing. It is NOT an undo. Everything already on chain stays exactly where it is; this ends the run that was managing it. Say that when you report it. PAUSING IS STOP THEN RUN AGAIN. Nothing is replayed: run_workflow picks the task back up from the steps that had already settled. Use this the moment somebody says stop — do not send them to the console for it.
validate_workflow
FOR A STRATEGY, WRITE A CARD INSTEAD (the strategy_* tools): a request with a rule, a condition or a repeat (“when”, “every”, “after a drop”) is a card, and the compiler makes its plan JSON. This tool is for the families no card covers yet (today a card covers a conditional buy or sell of one asset against one stablecoin, sized as a share; internal/planlang/cardcoverage has the numbers). Check a workflow against the real compiler WITHOUT running it. Returns VALID, or REJECTED with the reason. FOR CHECKING WITHOUT STORING. save_workflow runs this same compiler and refuses anything that would not run, with the same message — so validating a plan you believe is right and then saving it checks it twice. Use this when you want to test a plan, or a change to one, WITHOUT committing it; otherwise save, and fix what the save says. TO CHECK A PLAN THAT IS ALREADY STORED, pass task and NO document: {“task”: “swap-usdc-weth-a1b2c3”}. It is read from the store, so nothing is retyped — never copy a document out of get_workflow and back into here, because a plan whose Owner is one character out derives a different account and every balance it was sized against is somebody else’s. amounts is not needed in that mode: a stored plan was compared against them when it was saved.