execute_order, close_positions_batch, execute_prediction_order, …) and the harness will deterministically classify it, judge it against your mandate with a snapshot of Liquid’s own tool schemas in the loop, and return a signed verdict whose requestHash binds to those exact bytes.
Why this venue needs a gate
Liquid’s published safety model is a human tap: nothing executes until you press Confirm. The intended flow issuggest_trade → confirmation widget → the widget calls execute_order.
That last step is a normal MCP tool. execute_order, execute_orders_batch, execute_tpsl, close_position, generate_deposit_address and create_onramp_session all describe themselves as internal to the widget — “The model must NEVER call this tool directly” — while being listed in tools/list and callable by any client holding the trade scope. The instruction is prose addressed to a model, not a server-side rule.
So an agent that calls execute_order itself has walked straight past the Confirm tap, and the Chance verdict is the only gate left. The classifier says so explicitly in its notes whenever it sees one of those tools called directly.
What gets recognized
The MCP tool name is the discriminant. Both the rawtools/call envelope and the simplified { name, arguments } form are accepted, and client prefixes like mcp__liquid-co-invest__… are stripped. A mcp__hyperliquid__… prefix is never claimed — Hyperliquid is its own venue here, despite the shared substring.
Anything outside the snapshot that is not clearly read-shaped classifies as an unverified state-changing call and is judged fail-closed.
The two traps the classifier exists to catch
size means different things in different directions. On execute_order, suggest_trade and the prediction tools, size is USD notional (collateral × leverage) — the schema is explicit: “250 means 15 minimum:
Liquid ORDER (execute_order): BUY $2,000 notional at 40× BTC at market (market, tif gtc) with the note: size is USD notional, so this is 50 of collateral at 40× — NOT 2000 units of BTCSeveral of the largest actions carry no dollar figure at all.
close_positions_batch with confirmed: true and no selection closes every open position. disable_paper_trading puts every subsequent order back on real funds. Raising leverage on an open position moves its liquidation price without trading anything. Removing a stop-loss strips protection with no notional in the payload. A mandate written only in dollar limits does not constrain any of them, and the classifier calls each one out.
Previews and the confirmed flag
close_position, close_positions_batch, execute_prediction_order, close_prediction_position, cancel_prediction_order and update_leverage preview when confirmed is absent or false and execute when it is true. A preview is normally followed by the identical call with the flag flipped, so the harness judges it as the action it previews and says which of the two it is looking at.
Use it from Claude or ChatGPT
Your agent already talks to Liquid over MCP, so add the Chance connector (https://harness.chance.cc/api/mcp, see Connectors) alongside it and give the agent one standing instruction:
Before calling any Liquid tool that trades or moves funds, callThe harness never holds your Liquid OAuth token. It judges the payload; your agent keeps the keys, and funds stay in your own wallet throughout.verify_intentwith my rules as the intent and the EXACT tool call —{ "name": "execute_order", "arguments": { ... } }— as the action, withvenue: "liquid". Only proceed on ALLOW; on BLOCK or ESCALATE, stop and tell me why.
Use it from your bot
Provenance
The tool names, argument names, enums and sizing semantics behind this venue come from the Liquid MCP server’s owntools/list (45 tools, server identifying as Liquid-MCP 1.0.0, captured 2026-09), not from a reconstruction. Field meaning beyond the schema descriptions is inference and is labelled as such inside the knowledge module.