@gblin-protocol/mcp-server

relay_gblin_payment

DestructiveIdempotent

Carries a signed GBLIN payment and relay fee on chain for a payer with no ETH, submitting both atomically through Multicall3 and returning the transaction outcome.

Instructions

Have GBLIN's relay carry a signed GBLIN payment on chain for a payer that holds no ETH. Pass the payment and the relay fee, each as { authorization, signature }, both prepared by prepare_gblin_payment with relay: true and signed by the payer's wallet. The relay checks both against the chain, simulates them and submits them in one transaction through Multicall3: either both settle or neither does. The fee is paid in GBLIN at the live NAV. Returns the transaction hash and its outcome. This moves funds: run it only with authorizations the payer meant to sign.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`fee`	Yes	{ authorization, signature } of the relay fee, from prepare_gblin_payment's relay block.
`payment`	Yes	{ authorization, signature } of the payment, method 'transfer'.

Output Schema

TableJSON Schema

Name	Required	Description
`fee`	No
`note`	No
`block`	No
`relay`	Yes	The relay that carried the payment.
`status`	Yes
`payment`	No
`explorer`	No
`transaction`	Yes	The transaction hash.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.1.5Oct 1, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses the atomic Multicall3 settlement ('either both settle or neither does'), chain-side verification and simulation before submission, fee denomination at live NAV, and the return shape. Annotations cover the safety profile (destructive/idempotent), and the description adds concrete operational mechanics.

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?

Front-loaded with purpose, then how to supply the inputs, then behavioral mechanics, ending with the funds warning. Six dense sentences with no filler; each carries distinct, 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?

For a nested two-object, fund-moving tool with an output schema, the description covers inputs, prerequisite tool, atomicity, fee mechanics, return summary, and a safety caveat. Nothing an agent needs to invoke it correctly is missing.

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 baseline is 3. The description adds real value: both params are { authorization, signature } blocks produced by prepare_gblin_payment with relay: true, signed by the payer's wallet, with the payment method being 'transfer'.

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 ('have GBLIN's relay carry a signed GBLIN payment on chain') plus the distinguishing condition ('for a payer that holds no ETH'). It clearly differentiates itself from prepare_gblin_payment, which it names as the upstream tool.

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?

Gives the selecting condition (payer holds no ETH), names the prerequisite producer (prepare_gblin_payment with relay: true), and adds an explicit safety exclusion ('run it only with authorizations the payer meant to sign'). An agent knows exactly when this applies and when it must not be run.

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