@gblin-protocol/mcp-server

prepare_action

Read-onlyIdempotent

Build unsigned transactions for GBLIN vault operations: mint with ETH/WETH/USDC, redeem in kind, exit to ETH/USDC, or bid. Generates ordered steps to simulate then send from the wallet.

Instructions

Build the unsigned transactions for any operation on the GBLIN vault, in the order to send them. 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 you need), 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: simulate the steps with preview_steps, then send them from the wallet.

Input Schema

TableJSON 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

TableJSON 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

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description reinforces with 'Nothing is signed or sent' while adding per-action behavior: redeem_in_kind has 'no fee, no price feed', exit_to_eth is 'all or nothing', and every vault/Zap step carries a gas limit. These are meaningful traits beyond the 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 the core action, then a dense but useful per-action list where each clause carries distinct semantics. Efficient overall, though the long inline action enumeration makes it fairly heavy for a single paragraph.

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?

With an output schema present, return values need no explanation, and the description covers the prepare/simulate/send workflow, all action-specific units, and the safety framing. An agent has everything needed to invoke it correctly.

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% (baseline 3), but the description goes further by resolving the otherwise ambiguous 'amount' unit per action (ETH, WETH, USDC, shares) and clarifying that bid ignores amount and only optionally uses row. This adds real meaning over the schema text.

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 ('Build the unsigned transactions for any operation on the GBLIN vault') and enumerates the exact actions available. It is distinguishable from siblings like preview_steps (simulate) and the various get_* state tools without opening any schema.

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?

Explicitly names the workflow and the alternative: simulate with preview_steps, then send from the wallet. This tells the agent when to reach for this tool versus the simulation sibling. It stops short of stating when NOT to use it or prerequisites, so it is not a full 5.

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