@gblin-protocol/mcp-server

prepare_action

Read-onlyIdempotent

Builds unsigned transactions for GBLIN vault operations such as mint, redeem, exit, and bid, returning ordered steps with gas limits for the caller to sign and send.

Instructions

Builds the unsigned transactions for an operation on the GBLIN vault, in the order they are sent. Actions: mint_with_eth (amount in ETH), mint_with_weth (amount in WETH), mint_with_usdc (amount in USDC, through the Zap), redeem_in_kind (amount in shares; pro rata basket tokens, no fee, no price feed), exit_to_eth (amount in shares, through the Zap, all or nothing), exit_to_usdc (amount = the USDC needed), bid (trade with the rebalancing auction; row optional, the largest gap by default). Every output bound is non-zero and every step through the vault or the Zap carries its gas limit. Nothing is signed or sent: the steps are returned to the caller.

Input Schema

Name	Required	Description
`row`	No	bid only: the basket row to bid on. Default: the row with the largest gap.
`action`	Yes	The operation to prepare.
`amount`	No	Decimal amount. Unit depends on the action (see the description). Not used by bid.
`wallet_address`	Yes	The wallet that will sign and receive.

Output Schema

Name	Required	Description
`next`	No
`steps`	Yes	Transactions to send in order.
`action`	Yes
`wallet`	No
`expected`	No	What the operation should deliver, with the minimums applied.
`warnings`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.1.5Oct 1, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive; the description reinforces and extends this by confirming nothing is signed or sent. It adds real behavioral context beyond annotations: transaction ordering, gas limits embedded in each step, non-zero output bounds, and the Zap routing details.

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, then per-action semantics, then the safety guarantee. Dense but nearly every clause carries information; the parenthetical chains are slightly heavy but not wasteful.

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?

An output schema exists, so return values need not be described, and the description still says steps are returned. For a multi-action builder of unsigned transactions this is close to complete; only prerequisite context (e.g., token approvals before minting) 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 baseline is 3; however the description genuinely adds value by defining the unit of `amount` per action (ETH, WETH, USDC, shares, or the USDC needed) and confirming `row` is bid-only with a largest-gap default, which goes beyond the schema's generic wording.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Builds the unsigned transactions for an operation on the GBLIN vault') and enumerates all seven actions with their units. It does not explicitly name a sibling, but the enumeration and the 'unsigned, nothing signed or sent' framing make the scope unmistakable.

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 is only implied: 'the steps are returned to the caller' hints that this is a preparation step to be followed by signing, and per-action notes ('exit_to_eth ... all or nothing', 'amount = the USDC needed') narrow inputs. No explicit when-to-use/when-not or comparison to alternatives such as preview_steps, seal_action_demo, or quote_safe_swap.

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