gblin-treasury-risk-regime

payments.prepare

Read-only

Build a gasless GBLIN payment. The vault's share token implements EIP-3009, so the holder signs an authorization and anybody can carry it on chain: the payer needs no ETH. Returns the EIP-712 message to sign (its domain is read from the token, not assumed), the calldata that carries the signed authorization, and the x402 'exact' payload for paying an HTTP endpoint in GBLIN. Use method 'receive' when paying a known recipient: only that recipient can submit it, so nobody can front-run the transfer. Use 'transfer' for an x402 facilitator, which submits on the seller's behalf. With relay: true it also prepares the fee authorization for relay_gblin_payment, for when nobody else will carry the payment. No private key is requested, held or transmitted: the signature is produced by the caller's own wallet.

Input Schema

TableJSON Schema

Name	Required	Description
`to`	Yes	The recipient's address.
`from`	Yes	The payer's address: the wallet that will sign.
`relay`	No	true when nobody else will carry the payment on chain: also prepares the relay fee authorization, paid in GBLIN at the live NAV, for relay_gblin_payment. Forces method 'transfer'.
`method`	No	'receive' (default) can be submitted only by the recipient; 'transfer' by anyone.
`amount_usd`	No	Amount in USD, converted at the live NAV. Give this or amount_gblin.
`amount_gblin`	No	Amount in GBLIN shares, e.g. '0.25'. Give this or amount_usd.
`valid_for_seconds`	No	How long the authorization stays valid. Default 600, maximum 86400.

Output Schema

TableJSON Schema

Name	Required	Description
`relay`	No	With relay: true, the fee authorization to sign and where to send both.
`amount`	No
`digest`	Yes	The EIP-712 digest of typed_data.
`method`	Yes
`submit`	No
`warnings`	No
`next_steps`	No
`typed_data`	Yes	The EIP-712 message to sign with eth_signTypedData_v4.
`x402_payload`	Yes	The x402 exact-scheme payment payload, with the signature left to fill.
`authorization`	Yes	from, to, value, validAfter, validBefore, nonce.
`payer_balance`	No
`x402_accepts_for_sellers`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 23, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Adds substantial behavior beyond annotations: the operation is gasless, no private key is requested/held/transmitted, the EIP-712 domain is read from the token rather than assumed, and method choice has front-running implications. It also explains relay behavior and the returned artifacts, giving the agent expectations the annotations alone cannot convey.

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?

Seven sentences, each carrying distinct information: what it builds, why it is gasless, what it returns, method selection, relay behavior, and key-handling guarantees. The description is front-loaded with the core purpose and contains no filler sentences.

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?

For a complex preparation tool with an output schema, the description covers return payloads, method semantics, relay dependencies, and security model. The 100%-covered schema handles parameter-level details, so nothing critical is missing for an agent deciding whether and how to call this tool correctly.

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

Parameters4/5

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

The schema already covers all 7 parameters (100%), so the baseline is 3. The description adds meaningful context: 'from' is the signer and no key touches the server, 'receive' vs 'transfer' maps to submission rights, and relay forces method 'transfer'. This goes beyond the schema without redundant restatement.

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 concrete verb and resource: 'Build a gasless GBLIN payment.' It explains the EIP-3009 mechanism, what the tool returns (EIP-712 message, calldata, x402 payload), and distinguishes the 'receive' vs 'transfer' modes. This makes the tool's role clear even among payment-related siblings.

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?

Provides explicit decision rules: use 'receive' for a known recipient to prevent front-running, use 'transfer' for an x402 facilitator, and set relay:true when nobody else will carry the payment. It does not directly contrast this tool with sibling prepare tools like actions.prepare, so it stops short of full when-not guidance.

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

All gblin-treasury-risk-regime 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.