Conditional USDG payments on Robinhood Chain: look up, explain and prepare if-so payments.
Scored across 14 tools
Most tools target clearly distinct actions across payment lifecycle, x402, fees, and info, and the descriptions explicitly cross-reference each other (e.g., list_payments tells you to use get_payment for live state). The main soft spots are the parallel v1/v2 pairs (ifso_get_payment vs ifso_get_v2_payment, ifso_prepare_payment vs ifso_prepare_v2_payment) and the overlap between ifso_get_payment and ifso_explain_payment, though the descriptions (id vs address, raw state vs plain words) do disambiguate.
All names are snake_case with a consistent ifso_ prefix and mostly verb_noun form (check_x402_offer, create_request, get_payment, list_payments, prepare_v2_payment, quote_fees). A few deviate to bare nouns or adjective forms (ifso_dispute, ifso_version, ifso_release_status), which is a minor inconsistency rather than a real problem.
14 tools is well within the ideal range and each appears to earn its place: read tools, prepare tools for v1/v2/x402, plus fees, version, dispute, and listing. The surface is scoped to a single domain with no obvious filler.
The read/prepare side is thorough, but the lifecycle is asymmetric: only ifso_dispute exposes a signable action, while claim, accept/OK, referee decide, settle, send-back, and cancel are described in ifso_explain_payment yet have no corresponding tool. There is also no way to manage or cancel a payment request created via ifso_create_request.
Run before signing a 402 that carries the ifso-conditional extension. Recomputes the payment address from the terms against IFSO's own v2.1 factory and refuses: an untrusted factory, a terms hash mismatch, a payTo that is not the terms' address, an amount or asset mismatch, a sender that is not the payer, a refund address that is not the payer, expired terms, a closed window or a window without a referee. Optionally checks the signed EIP-3009 authorization (to, value, from). Read only.
Inputs: requirements (required), payer, payload, maxAmount, +1 more.
Creates a payment request: someone asks to be paid an amount of USDG, USDe or ETH, and gets a link to share. The payer opens the link and funds an if-so payment to them. An optional note (at most 140 characters) and how many days the link stays open (1 to 30, default 7). Nothing moves until the payer funds it.
Inputs: asset (required), amount (required), recipient (required), days, +1 more.
For the buyer, inside the release window: returns the EIP-712 Decision (action 5, dispute) to sign with the buyer's wallet, and the relay call (POST /v1/v2/vaults/{vault}/dispute with the signature) that sends it with IFSO paying the gas. After a dispute only the referee decides (or the buyer's own OK, or the seller's decline); a silent referee means the money comes back at expiry. This tool never signs.
Inputs: vault (required), deadline.
One if-so payment in plain words, from the same chain read as ifso_get_payment: what it waits for, the deadline, who can do what next (claim, accept, tap OK, decide, settle, send back, cancel) and when and where it comes back if nothing happens. Payment ids are large whole numbers; pass them as a string.
Inputs: id (required).
The current state of one if-so payment, read from the chain: status (OPEN, MET, RELEASED, RETURNED, VOIDED, CANCELLED), amount in USDG, sender, recipient or claim link key, expiry and the condition that unlocks it. Payment ids are large whole numbers (up to 78 digits); pass them as a string.
Inputs: id (required).
One v2 if-so payment by its payment address: the terms, the asset and amount, whether the money has arrived, and the live state on the chain (not opened yet, OPEN, MET, RELEASED, RETURNED or CANCELLED).
Inputs: vault (required).
The kinds of condition an if-so payment can wait for (a date, a price at or by a deadline, a football league result, a Polymarket question, both people tapping OK, or a named referee), with example commands, the price tickers, the timing rules and the amount limits read from the contract. Use the example command format with ifso_prepare_payment.
Inputs: no named parameters.
The if-so payments where an address is the sender or the recipient, newest first, 20 at a time (the same list as the web dashboard, from the IFSO index of the chain, up to the newest 100). Each item has the id, status, amount, the other side and the expiry. Pass nextCursor back as cursor for the next page. For the live chain state of one payment use ifso_get_payment.
Inputs: address (required), limit, cursor.
Turns a command like "/ifso 0x... 20 on 2026-12-01" into a plain preview and the UNSIGNED data to create that if-so payment from the sender's own wallet: two transactions (USDG approve, then create) or one gasless authorization to sign. This server never signs, never holds a key and never sends anything; the sender reviews and signs in their own wallet. Same checks as the site's build step.
Inputs: text (required), sender (required), linkKey, referee, +4 more.
Builds a v2 if-so payment in USDG, USDe or ETH and returns its own payment address, known before any money moves, so it can be funded from anywhere on Robinhood Chain (any wallet, or the Robinhood app, which can send ETH and USDG to any address). Also returns the UNSIGNED data the sender may sign instead: an EIP-3009 authorization for USDG, a Permit2 signature for USDe, or one fundETH transaction for ETH. The money moves when the condition is met, or comes back to the sender after the expiry. This server never signs and never sends.
Inputs: asset (required), amount (required), sender (required), condition (required), +8 more.
For a seller's 402: returns x402 v2 PaymentRequirements (scheme exact, USDG on Robinhood Chain eip155:4663, payTo = the payment's own IFSO v2.1 address) plus the ifso-conditional extension with the full terms. Any facilitator that settles USDG there lands the money at that address. The seller is paid after the release window unless the buyer disputes before it ends; a dispute goes to the named referee, and if the referee stays silent the money comes back to the buyer at expiry. The flat agent fee (0.02 USDG) is added to the amount. Nothing is signed or sent.
Inputs: payTo (required), payer (required), amount (required), referee (required), +4 more.
The fee for an if-so payment of one condition kind (TIME, PRICE, SPORTS, MARKET, APPROVE_PARTIES or APPROVE_REFEREE): the flat creation fee, plus the flat result fee for SPORTS and MARKET, read from the contract (the same numbers as ifso_version). With an amount, also the total the sender approves and whether the amount is inside the contract's limits. Fees are flat and never a share of the amount.
Inputs: kind (required), amount.
The state of an x402 conditional payment by its terms hash (the x402 payment identifier): pending (no money yet), settled (the money is at the address), duplicate_swept (a second settle landed and went back to the buyer), disputed, released (paid to the seller) or returned (back to the buyer), with the window end and expiry. Retrying a settle with the same terms lands at the same address, so this tells failed from landed late. Read only.
Inputs: termsHash (required).
Which IFSO build is running, the chain id (Robinhood Chain mainnet is 4663), the address of every contract it uses (payments, conditions, outcome resolver, USDG) and the fee constants in base units and USDG. The same answer as GET /v1/version. Check these addresses before approving anything in a wallet.
Inputs: no named parameters.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Agent-to-agent escrow on Robinhood Chain. Post quests with ETH/USDG bounties and settle on-chain.
Fixed-cost loans on Robinhood Chain: quotes, and each transaction unsigned for your own wallet.
Stock lending on Robinhood Chain: read markets and prepare lends, loans, shorts and credit lines.
A muse's wallet on Robinhood Chain: stock tokens, USDG payments via rh777, vaults, on-chain ceiling.
Add one secure layer between your agents and this server.