Liquid Agent

Prepare a bridge payment (x402)

bridge_prepare_payment

Read-onlyIdempotent

Returns the exact x402 payment request for a bridge (network, asset, payTo contract, amount, EIP-712 domain) and the URL to call. Pay it with your own x402 client: sign one EIP-3009 authorization and repeat the GET with the PAYMENT-SIGNATURE header. You receive exactly amount at your own address on the destination. This tool does not pay or sign anything.

Input Schema

TableJSON Schema

Name	Required	Description
`to`	Yes	Chain you receive on: arc, arbitrum, optimism, polygon, avalanche, unichain, linea, world, sonic, monad, sei, ink, hyperevm, xdc, plume, codex (from Base) or base (from Arc).
`ref`	No	Optional referrer address: earns 20% of Liquid's fee. Omit if you have none.
`from`	No	Chain you pay on. Omit to pick the live route to `to` (Base to any listed chain; Arc to Base).
`amount`	Yes	USDC to RECEIVE on the destination, e.g. "1" or "25.5". Minimum 1.

Output Schema

TableJSON Schema

Name	Required	Description
`url`	No	URL to call with the PAYMENT-SIGNATURE header
`note`	No	Notes
`x402`	No	The x402 payment request (accepts: scheme, network, asset, payTo, amount, EIP-712 domain)
`quote`	No	The quote behind the price
`method`	No	HTTP method
`howToPay`	No	Step-by-step signing instructions

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 29, 2026

changedInput schema / properties / from / description

Previous value: -"Chain you pay on. Omit to pick the live route to `to` (base -> arc, arc -> base)."New value: +"Chain you pay on. Omit to pick the live route to `to` (Base to any listed chain; Arc to Base)."

changedInput schema / properties / to / description

Previous value: -"Chain you receive on."New value: +"Chain you receive on: arc, arbitrum, optimism, polygon, avalanche, unichain, linea, world, sonic, monad, sei, ink, hyperevm, xdc, plume, codex (from Base) or base (from Arc)."

changedInput schema / properties / to / enum

Previous value: -[
-  "arc",
-  "base"
-]New value: +[
+  "base",
+  "arc",
+  "optimism",
+  "unichain",
+  "sonic",
+  "world",
+  "monad",
+  "sei",
+  "xdc",
+  "ink",
+  "plume",
+  "polygon",
+  "avalanche",
+  "arbitrum",
+  "codex",
+  "hyperevm",
+  "linea"
+]

First observedSep 29, 2026

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint/idempotentHint true and destructiveHint false, and the description reinforces this with 'does not pay or sign anything' (consistent, not contradictory). It adds useful behavioral detail beyond the annotations: the exact fields returned, the two-step sign-and-retry flow, and that the recipient receives exactly `amount`.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with what it returns, then how to use it, then the non-signing caveat. No filler; every clause conveys actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be re-explained. For a prepare-style tool the description covers purpose, usage flow, and the safety boundary, leaving nothing an agent needs missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with enums and patterns documented for all four params, so the schema carries the load. The description reinforces the key semantic that `amount` is what you RECEIVE, but adds no syntax or format beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Returns the exact x402 payment request for a bridge', enumerating the returned fields (network, asset, payTo contract, amount, EIP-712 domain) and the URL. This clearly distinguishes it from siblings like bridge_quote (quote vs. ready-to-pay request).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete workflow guidance: pay via your own x402 client by signing one EIP-3009 authorization and repeating the GET with the PAYMENT-SIGNATURE header, and clarifies the boundary with 'This tool does not pay or sign anything.' It doesn't explicitly steer an agent to/from bridge_quote, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Liquid Agent tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.