Skip to main content
Glama
quackai-org

@quackai/q402-mcp

Official
by quackai-org

q402_yield_withdraw

Withdraw stablecoins from a Q402 Yield lending position back to the Agent Wallet, redeeming USDC or USDT on BNB Chain or Base. Use amount 'max' to redeem the maximum available.

Instructions

WRITE - MOVES FUNDS. Withdraws the Agent Wallet's supplied stablecoin (USDC / USDT) out of its Q402 Yield lending position back to the Agent Wallet. Pass amount="max" to withdraw the maximum currently redeemable (can be < full position under vault caps). Server-managed Agent Wallet path (Mode C): authenticated by the configured live Multichain API key - the server holds the encrypted key, signs the withdraw, and sponsors gas. CHAINS: 'bnb' (USDC or USDT); 'base' (USDC only). The venue is the chain's curated lending market and is reported in the receipt. Other chains are not yet available.

REQUIRES CONFIRMATION - like q402_pay, this tool refuses to execute unless confirm: true is set. Call it FIRST without confirm to get a one-line preview of exactly what will happen (amount, token, chain, wallet); show that to the user, get explicit approval, THEN re-call with confirm:true. Never set confirm:true on the user's behalf without that approval.

SANDBOX BY DEFAULT - like q402_pay, no funds move unless a live Multichain key (q402_live_*) is configured AND Q402_ENABLE_REAL_PAYMENTS=1. Without both, confirm:true returns a sandbox preview (no on-chain withdraw) with a setup hint - confirm:true alone does NOT move real funds.

RETRY SAFETY - on a timeout or an unconfirmed broadcast the tool returns status="uncertain" and echoes back the idempotencyKey it used. The withdrawal MAY have settled, so do NOT blindly call again - that starts a NEW withdrawal and can double-withdraw. To resume the SAME operation, re-call with idempotencyKey set to the echoed value; the server dedupes on it and replays the original result.

Use q402_yield_positions first to see the current position size (especially before an amount="max" withdrawal).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainNoChain to withdraw on. 'bnb' (USDC or USDT) or 'base' (USDC only). The actual venue is reported in the receipt.
tokenYesStablecoin to withdraw. USDC or USDT on bnb; USDC only on base.
amountYesHuman-readable decimal amount to withdraw, e.g. "100.00", or the literal "max" to withdraw the maximum currently redeemable (can be < full position under vault liquidity caps).
confirmNoMUST be true to actually withdraw funds - set only after the user explicitly approved this exact withdrawal in chat. Omit (or false) to preview without moving funds.
protocolNoVenue to withdraw from when the wallet holds the same token in more than one lending venue on a chain. Omit when unambiguous; on an "AMBIGUOUS_POSITION" error re-call with one of the `protocols` the server lists.
walletIdNoOptional Agent Wallet address to withdraw to when the owner holds multiple wallets. Defaults to Q402_AGENT_WALLET_ADDRESS env, then the owner's default wallet on the server.
consentTokenNoTwo-phase consent token. Leave unset on the first call to get a preview + token; re-call with confirm:true AND this token after the user approves. Bound to (chain, token, amount, wallet).
idempotencyKeyNoOptional durable idempotency key. Omit and the tool generates a FRESH random key per invocation, so every call executes a distinct withdrawal. Pass your own STABLE key only for opt-in retry-safety - re-calling with the same key replays the first result instead of double-withdrawing. If a call returns status="uncertain", it echoes the idempotencyKey it used - pass that exact value back here to resume the same withdrawal rather than start a new one.
Behavior5/5

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

With no annotations, the description carries full burden and does so thoroughly. It discloses the confirmation gate, sandbox behavior (no real funds unless live key + env var), retry safety (status='uncertain', idempotencyKey replay), server-side key handling, gas sponsorship, and venue reporting. This goes far beyond a typical description.

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?

The description is long but all content is purposeful, formatted in scannable uppercase lead-ins ('REQUIRES CONFIRMATION', 'SANDBOX BY DEFAULT', 'RETRY SAFETY') that front-load critical behaviors. It is dense with information but avoids fluff. Slight deduction for length, though nothing is redundant.

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?

Despite having 8 params and no output schema, the description fully covers operational prerequisites (confirmation, sandbox), retry handling (uncertain status, idempotency key), chain/token constraints, and where to find results ('reported in the receipt'). It even references related tools for pre-condition checks. This is comprehensive for a high-complexity transaction 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 coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema: clarifies amount='max' can be less than full position due to caps, explains consentToken flow, and gives the full retry-safe idempotencyKey semantics ('re-calling with the same key replays the first result instead of double-withdrawing'). This lifts it above baseline.

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?

The description opens with 'WRITE - MOVES FUNDS. Withdraws the Agent Wallet's supplied stablecoin out of its Q402 Yield lending position back to the Agent Wallet.' This names the specific verb (withdraw), resource (Q402 Yield lending position), and direction (back to Agent Wallet), making the tool's purpose unmistakable. It also distinguishes from siblings like q402_yield_deposit and q402_yield_positions, creating clear differentiation.

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?

Provides clear context: 'Use q402_yield_positions first to see the current position size', explicit confirmation workflow ('Call it FIRST without confirm... get explicit approval, THEN re-call'), sandbox default conditions, and chain availability ('Other chains are not yet available'). It does not explicitly name a contrary alternative sibling, but the guidance is concrete and actionable enough to rate above baseline.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/quackai-org/q402-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server