One check before you sign (paid)
check_actionCALL THIS BEFORE YOUR AGENT SIGNS ANYTHING THAT MOVES MONEY. One request instead of five: it reads the counterparty record, decodes the calldata you are about to sign, looks up the seller’s own catalogue listing, runs an unpaid 402 handshake with the endpoint, and applies a published policy — and then, which is the point, compares them WITH EACH OTHER. The losses an agent actually suffers live between those readings and no single one of them can see them: the bytes paying an address you never checked, so a spotless counterparty record is about a party this transaction does not pay; an UNLIMITED APPROVAL wearing the shape of a one-cent payment; the seller’s listing naming a payee the calldata does not; a policy allowing a payment for a path that is not served. Every cross-check names BOTH readings that disagree in between, and none of them is an accusation — the record can be wrong. Send calldata whenever you have it: it unlocks the strongest check there is. A cross-check can only make the verdict worse, never better. SEND calldata, chain AND from and it is also SIMULATED: one eth_call at the latest block, the node executes it and throws the result away, nothing is signed or spent. A revert is the strongest finding available, because every other reading argues about whether you should send it and this one is that it will not work. Not a state diff, run against the current block, and a node that refuses is reported as our gap rather than as a failure. ran says which parts did not run and why, because a check that did not happen must never look like one that passed. PAID; its five components are each free on their own tools and what is sold here is the comparison.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | The address the transaction would be sent FROM. Only used to SIMULATE it, and worth sending: without it the call runs as the zero address and reverts for a reason about our request rather than your transaction. | |
| asset | No | The TOKEN you are paying in. Compared against the one the seller’s listing prices in: a payment in a token the seller does not credit leaves your side and arrives nowhere, and every other check passes on it. | |
| chain | No | The chain it is about to be sent on, e.g. base. | |
| action | No | What you are about to do, because the checks differ: `pay` weighs a recipient’s payment record, `allocate_capital` weighs a VAULT (pass its slug as `subject`) on exit, controller and evidence, `connect_mcp` and `call_tool` weigh a server or tool you are about to trust. Defaults to `pay`. Choosing the wrong one does not fail — it answers the wrong question, and `checked` in the reply names which checks actually ran. | |
| policy | No | A policy slug or version from list_policies. Defaults to conservative. | |
| subject | No | For allocate_capital: the vault slug. | |
| calldata | No | The hex bytes you are about to sign. Left out, the transaction is reported as UNREAD rather than fine. | |
| resource | No | The http(s) URL of the endpoint being bought, where there is one. | |
| valueWei | No | Native value in wei, where the transaction carries any. Simulation only. | |
| amountUsd | No | What is about to be sent, in dollars. | |
| recipient | No | The address about to be paid. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ran | Yes | Which parts ran and why each one did not. | |
| says | Yes | The worst thing found, in one sentence. | |
| parts | Yes | Each reading on its own: policy, transaction, listing, endpoint, settledOn. | |
| limits | Yes | What this check structurally cannot contain: what the action is FOR, terms agreed privately, any simulation, and calls the decoder refuses rather than guesses at. Read it before treating a clean answer as a safe one. | |
| verdict | Yes | The policy’s decision, worsened by the cross-checks and never improved by them. | |
| crossChecks | Yes | The comparisons between parts. Each names the TWO readings that disagree. The ones that AGREED are published too, because a comparison that ran and agreed is different from one that never ran. `tone` is `bad`, `warn`, `good` or `neutral`, and the fourth is the one to read carefully: a NEUTRAL check established nothing and can neither improve nor worsen the verdict. `the-price-has-moved-since-the-listing` compares the endpoint’s own quote with its catalogue entry in BASE UNITS after checking that both name the same token, so it is exact; where the tokens differ or either is unnamed it reports `the-two-prices-are-not-comparable` instead, because a 402 states an amount in the asset’s smallest unit and never its decimals. The same rule is applied by `preflight_payment` and `evaluate_action`. |