@gblin-protocol/mcp-server

prepare_gblin_payment

Read-only

Build a gasless GBLIN payment: get the EIP-712 message to sign, signed-authorization calldata, and x402 payload, so payers need no ETH and share no private key.

Instructions

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.

Addedv1.1.5Oct 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint, openWorldHint) by disclosing the security posture: no private key is requested, held or transmitted; the EIP-712 domain is read from the token rather than assumed; 'receive' cannot be front-run because only the recipient can submit. These are exactly the behavioral facts an agent needs before signing and relaying.

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 action and the return payloads, then method selection, then the relay caveat, then the no-private-key guarantee. Every sentence carries unique information, though the single long paragraph is dense and could be split for faster scanning.

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 multi-step signing/relaying tool with 7 parameters, an output schema and full schema coverage, the description covers the missing pieces: the gasless mechanism, method semantics, relay handoff, and security guarantees. Nothing needed to invoke it correctly is absent.

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 cross-parameter behavior beyond the field docs: it clarifies that relay: true forces method 'transfer', that the domain comes from the token, and that amount_usd is converted at live NAV. It stops short of documenting valid_for_seconds bounds or amount interplay in more depth than the schema already does.

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 ('Build a gasless GBLIN payment') and immediately explains the EIP-3009 signing model that makes it distinct from a normal transfer. It also names the three artifacts returned (EIP-712 message, calldata, x402 payload), so an agent knows exactly what it produces versus sibling tools like relay_gblin_payment or verify_gblin_authorization.

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

Usage Guidelines5/5

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

Explicitly routes between the two methods ('receive' for a known recipient, 'transfer' for an x402 facilitator) and gives the condition for each. It also states when to set relay: true ('when nobody else will carry the payment') and names the downstream tool relay_gblin_payment, leaving nothing to inference.

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