Skip to main content
Glama

Build Leverage Transaction

build_leverage_tx

Build the UNSIGNED transaction to open a leveraged position, for the given wallet to sign. Non-custodial: this server never signs, sends, or holds keys. The canonical output is the executable { approvals[], tx{to,data,value} } — sign and broadcast it directly (approvals first), plus the same position preview as simulate_leverage. meta.signingUrl is an optional one-click link for a human to sign in their own wallet. The embedded swap calldata is time-sensitive (see meta.expiresAt) — rebuild if stale.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
amountYesAmount of payToken in human units (e.g. '10000' for 10,000 USDC).
chainIdNoChain to target. Supported: 1, 4663. Default: 1.
leverageNoTarget leverage, e.g. 3. Provide this OR desiredLtv.
payTokenYesAddress of the token you pay in. May be the collateral (opened directly) or any other token (zapped: swapped to collateral first). Native ETH = the zero address 0x0000…0000.
slippageNoSwap slippage as a ratio (0.005 = 0.5%). Default 0.005, capped at 0.01.
desiredLtvNoTarget LTV percent, e.g. '66.67'. Provide this OR leverage.
strategyIdYesMorpho market id of the strategy (from list_strategies / get_strategy).
userAddressYesThe wallet address that will sign and send. Approvals and onBehalfOf are built for it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Discloses that the transaction is unsigned and non-custodial, and that the server never signs or holds keys. Warns about time-sensitive calldata and need to rebuild if stale. Adds value beyond annotations (readOnlyHint false, destructiveHint false) by clarifying output safety.

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?

Three well-structured sentences, front-loaded with core purpose. Each sentence adds distinct value: purpose, output format and non-custodial nature, time sensitivity. No wasted words.

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?

Covers output format, signing steps, optional URL, and expiry. References simulate_leverage for preview. Lacks error conditions or failure modes, but sufficient for a transactions builder with no output schema.

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?

Input schema has 100% coverage with detailed parameter descriptions. Tool description does not add new parameter-level information beyond schema, but provides important context about output format. Baseline 3 is appropriate.

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?

Clearly states it builds an unsigned transaction to open a leveraged position. Distinguishes from sibling tools like simulate_leverage (preview only) and build_manage_tx (manage existing positions). Emphasizes non-custodial nature.

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 describes when to use (to open a leveraged position) and what to do with output (sign and broadcast). Mentions optional signing link and expiry. Implicitly distinguishes from simulate_leverage, which is for preview only.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.