Skip to main content
Glama

MetaLend

by io.github.rabeles11
OverviewDiscussionsAdmin

Prepare a withdrawal

prepare_withdrawal
Read-only

[DEPRECATED] Build the EIP-712 typed-data payload to sign for withdrawing from a specific pool, without signing anything. Looks up the exact withdrawRequest domain/types/value MetaLend expects from your current balances, fills in amount and a short-lived deadline, and returns it ready to sign with your own wallet. Pass the resulting signature to submit_withdrawal. Omit amount (or pass "MAX") to withdraw the pool's entire balance — this uses the maxUint256 convention rather than the exact current balance, which avoids stale-balance/rounding failures. chain is required: the same pool contract address can exist on multiple chains (e.g. Aave reuses one address across Polygon/Arbitrum/Avalanche/Optimism), so poolContract alone cannot disambiguate a wallet holding balance in that pool on more than one of those chains. Also refuses to build typedData when the pool's live liquidity (see list_pools' poolLiquidity) does not exceed the amount being withdrawn (this also applies to MAX, using the pool's own balance) — the backend would reject the signed request either way, so this catches it before a wallet signs. A fixed on-behalf gas fee (see fee in the response, also available standalone via get_transaction_costs) is deducted from the withdrawn amount before it reaches your wallet — the response's expectedReceivedAmountRaw is what will actually arrive, not the full amount being withdrawn from the pool. Rate limited to 5 calls/minute per caller, no more than one call every 12s.

Input Schema

NameRequiredDescriptionDefault
chainYesChain name, e.g. BASE, ETHEREUM, POLYGON.
tokenYesToken symbol, e.g. USDC, USDT, MUSD, RLUSD, USDG, USDE, PYUSD. Required to disambiguate — some pool addresses serve multiple tokens.
amountNoRaw amount to withdraw. Omit or pass "MAX" for a full withdrawal (uses maxUint256).
poolContractYesPool contract address, from get_balances' perPool[].poolAddress. Combined with `chain` to identify the exact balance — the same address can exist on several chains.
walletAddressYesEVM wallet address (0x-prefixed, 40 hex chars). Any casing is accepted — it is normalized to its EIP-55 checksum before being forwarded upstream.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: it is deprecated, it does not sign, it hard-refuses when live pool liquidity is insufficient, it deducts a fixed on-behalf gas fee so expectedReceivedAmountRaw differs from amount, and it is rate limited to 5 calls/minute with a 12s minimum interval. The readOnlyHint=true is consistent with a build-only payload tool and is reinforced, not merely restated.

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?

Dense single block but front-loaded with the DEPRECATED marker followed by purpose, and nearly every clause carries actionable information. It is slightly overlong and would scan better as separated sentences, but there is little wasted text.

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 no output schema, the description carries the burden of describing returns, and it does: the typedData payload, the fee, and expectedReceivedAmountRaw as the actual received amount. Combined with the error-prevention and rate-limit notes, an agent has everything needed to call and interpret this tool.

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 description coverage is 100%, so the baseline is 3. The description adds real semantics on top: the MAX/maxUint256 convention and why it is used (avoids stale-balance/rounding failures), and why chain is mandatory (same pool address reused across chains). It does not add further guidance for token or walletAddress beyond the schema.

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 EIP-712 typed-data payload to sign for withdrawing from a specific pool, without signing anything.' It explicitly distinguishes itself from the sibling submit_withdrawal ('Pass the resulting signature to submit_withdrawal') and flags the deprecation up front.

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

Usage Guidelines5/5

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

Names the follow-on step (submit_withdrawal) and the conditions governing usage: omit amount or pass MAX for a full withdrawal, chain is required to disambiguate pools across chains, and the tool self-refuses when pool liquidity does not exceed the amount. An agent knows precisely when and how to call it.

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

All MetaLend toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources