gblin-treasury-risk-regime

payments.prepare

Read-only

Builds 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. Method 'receive' lets only the named recipient submit the authorization, so nobody can front-run the transfer; method 'transfer' suits an x402 facilitator, which submits on the seller's behalf. With relay: true it also returns a second authorization that pays a relayer's fee in GBLIN. 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 a second authorization that pays GBLIN's relay fee in GBLIN at the live NAV. 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.

Changed1 schema field changedOct 6, 2026

changedInput schema / properties / relay / description

Previous value: -"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'."New value: +"true when nobody else will carry the payment on chain: also prepares a second authorization that pays GBLIN's relay fee in GBLIN at the live NAV. Forces method 'transfer'."

AddedSep 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnly/openWorld/destructive/idempotent hints, so the description carries the real behavioral burden and delivers: it discloses the return artifacts, the EIP-3009 signing flow, the front-running protection of 'receive', the relay fee behavior, and crucially that no private key is requested, held, or transmitted. That last point is exactly the kind of trust/security context annotations 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.

Conciseness4/5

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

Front-loaded with the core purpose and dense with non-redundant information; every clause about EIP-3009, x402, methods, and relay earns its place. It is a single long paragraph, though, and splitting the method/relay guidance from the security note would improve scannability.

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 7-parameter, enum-bearing tool with an output schema and annotations, the description supplies everything the structured fields cannot: the signing protocol, the two submission modes, relay semantics, and the no-private-key guarantee. Return values need not be detailed since an output schema exists, and what is given is more than sufficient.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: it explains why 'receive' resists front-running, why relay forces method 'transfer', and that the EIP-712 domain is read from the token rather than assumed. It does not restate the amount/validity parameters, which the schema already covers.

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?

Opens with a specific verb+resource: 'Builds a gasless GBLIN payment,' and immediately differentiates itself from siblings like payments.relay and payments.verify by describing exactly what artifact it produces (the EIP-712 message, calldata, and x402 payload). An agent can tell this is a preparation/signing-payload tool, not an execution or verification tool.

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 explicit selection criteria for the two methods ('receive' when only the recipient should submit, 'transfer' for an x402 facilitator) and for relay: true ('when nobody else will carry the payment on chain'). It stops short of naming the sibling tools it replaces or excludes (payments.relay, payments.verify), so routing against those is left to inference.

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.