@gblin-protocol/mcp-server

swap_gblin_to_usdc_jit

Read-onlyIdempotent

Redeems GBLIN positions into exactly the USDC needed for an x402 invoice or other USDC obligation, returning ready-to-broadcast calldata for the approval, zap sale and WETH-to-USDC swap.

Instructions

Returns ready-to-broadcast calldata that redeems exactly the USDC requested from a GBLIN position, just in time for an x402 invoice or any other USDC obligation. Three sequential transactions: (1) approve the shares to the GBLIN Zap, (2) GBLINZap.sellGBLINForEth, which redeems in kind and sells every leg for ETH, all or nothing, (3) a Uniswap WETH->USDC swap that spends only the guaranteed ETH minimum and still returns at least the requested USDC. EOAs sign three times; ERC-4337 and EIP-7702 wallets can batch them into one operation. Every step carries a non-zero minimum; ETH above the minimum stays in the wallet. Free. A redemption carries no protocol fee; the costs are the Zap's swaps and gas.

Input Schema

Name	Required	Description	Default
`usdc_needed`	Yes	USDC amount, decimal string.
`wallet_address`	Yes	Agent's 0x address (for cooldown check).

Output Schema

Name	Required	Description
`steps`	Yes	Transactions to send in order.
`action`	Yes	Always sequential_txs: send the steps one after the other.
`params`	No
`expected`	Yes	Shares spent, ETH and USDC expected, and the minimums applied.
`gas_hint`	Yes	Gas limit to set on the Zap step.
`compatibility`	No
`gas_hint_note`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.1.5Oct 1, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "action": {
+      "description": "Always sequential_txs: send the steps one after the other.",
+      "type": "string"
+    },
+    "compatibility": {
+      "type": "object"
+    },
+    "expected": {
+      "description": "Shares spent, ETH and USDC expected, and the minimums applied.",
+      "type": "object"
+    },
+    "gas_hint": {
+      "description": "Gas limit to set on the Zap step.",
+      "type": "number"
+    },
+    "gas_hint_note": {
+      "type": "string"
+    },
+    "params": {
+      "type": "object"
+    },
+    "steps": {
+      "description": "Transactions to send in order.",
+      "items": {
+        "description": "One transaction to send, in order: target, calldata, value in wei, and gas when the step needs an explicit limit. The same call is repeated as to, data and chainId (8453) for wallet batch APIs such as send_calls.",
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "action",
+    "steps",
+    "expected",
+    "gas_hint"
+  ],
+  "type": "object"
+}

First observedv1.1.2May 25, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Extremely rich disclosure beyond annotations: the three sequential transactions, all-or-nothing redemption, non-zero minimum per step, ETH above minimum stays in the wallet, EOA vs ERC-4337/EIP-7702 signing behavior, and that it is free of protocol fee with costs limited to Zap swaps and gas. Returning calldata is consistent with readOnlyHint=true, so no contradiction.

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?

Purpose is front-loaded, then the mechanism, batching, minimums and cost are layered efficiently. It is dense for a single paragraph but nearly every clause carries decision-relevant information; minor trimming of the mechanism detail could tighten it further.

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 three-transaction calldata builder with an output schema covering return values, the description supplies everything needed to call correctly: what it produces, the step sequence, batching behavior, slippage/minimum guarantees, and cost profile.

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

Parameters3/5

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

Schema coverage is 100% and both parameters are self-documented, so the schema carries the load. The description adds the sub-meaning that usdc_needed is the exact amount that will be guaranteed out and wallet_address drives a cooldown check, but does not add format detail beyond the schema. Baseline 3.

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: returns ready-to-broadcast calldata that redeems exactly the requested USDC from a GBLIN position. The JIT-for-x402 framing plus the explicit three-step mechanism makes the operation unambiguous and distinguishable from generic payment-prep tools.

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 concrete context: use when you need USDC to cover an x402 invoice or any USDC obligation against a GBLIN position. It stops short of naming an explicit alternative (e.g., prepare_gblin_payment) or a when-not condition, so a 4 rather than 5.

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