@gblin-protocol/mcp-server

relay_gblin_payment

DestructiveIdempotent

Submits a payer's signed GBLIN payment and relay fee on chain for wallets without ETH, settling both atomically through Multicall3 and returning the transaction hash.

Instructions

GBLIN's relay carries a signed GBLIN payment on chain for a payer that holds no ETH. Takes the payment and the relay fee, each as { authorization, signature }, both 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 tool moves funds: it carries the authorizations exactly as signed.

Input Schema

Name	Required	Description	Default
`fee`	Yes	{ authorization, signature } of the relay fee, as prepared with relay: true and signed by the payer.
`payment`	Yes	{ authorization, signature } of the payment, method 'transfer'.

Output 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.

Changed1 schema field changedv0.6.4Oct 31, 2026

changedInput schema / properties / fee / description

Previous value: -"{ authorization, signature } of the relay fee, from prepare_gblin_payment's relay block."New value: +"{ authorization, signature } of the relay fee, as prepared with relay: true and signed by the payer."

Addedv1.1.5Oct 1, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Adds real behavior beyond annotations: on-chain verification and simulation before submission, Multicall3 atomicity ('either both settle or neither does'), fee conversion at live NAV, and the explicit 'this tool moves funds' warning. It does not cover failure/revert handling or rate limits, but the destructive/idempotent/openWorld profile is already carried by annotations.

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 purpose, then mechanics, then the fund-movement warning. Nearly every sentence earns its place; the 'Returns the transaction hash and its outcome' line is partly redundant given the output schema, and the Multicall3 name is detail most agents don't need.

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

Completeness4/5

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

For a fund-moving tool with nested objects, the description supplies atomicity, fee pricing, and prerequisite signatures, while annotations cover the safety profile and the output schema covers returns. What's missing is what happens on failed simulation/verification and whether re-submitting the same signed authorization is safe despite idempotentHint.

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?

With 100% schema coverage the baseline is 3, but the description adds meaning the schema does not: both structures are signed by the payer's wallet, and the fee is denominated in GBLIN priced at the live NAV. The distinction between payment and fee semantics comes through even though the nested 'authorization' object itself stays opaque.

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+resource ('carries a signed GBLIN payment on chain') plus the distinguishing scope condition ('for a payer that holds no ETH'). An agent can separate this from prepare_gblin_payment or verify_gblin_authorization without opening the schema, since this is the tool that actually submits.

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

Usage Guidelines3/5

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

Usage context is implied rather than stated: the payer must hold no ETH and the authorizations must already be signed, with the fee 'prepared with relay: true' noted only in the schema. No explicit when-not condition or named alternative (e.g., prepare_gblin_payment as the prerequisite step) is given.

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