Fabrica (Sepolia testnet)

Prepare a withdrawal from the lending pool

withdraw_from_lending_pool

Prepare withdrawing amountUsd (default: the whole position) from the wallet's deposit at one tick of the DeFi lending pool (Sepolia Testnet). Checks first that the wallet has a deposit at the tick, read from the pool contract, and that the amount is within it, and warns when the tick has too few funds not lent out to pay all of it when signed: that part waits in the pool's withdrawal queue and is claimed later from the pool page. Prepared, not sent: returns a signRequest (summary, warnings, signLink to fabrica.land, expiresAt 15 minutes out, payload null for now) and stores it so the sign page can load it. The person opens the link, signs in with that wallet and signs; nothing happens until then. The server holds no keys and submits nothing. wallet is the address that will sign.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tick": "<tick>",
      "wallet": "<wallet>"
    },
    "name": "withdraw_from_lending_pool"
  }
}

Input Schema

Name	Required	Description
`pool`	No	The pool's address, when the network has more than one
`tick`	Yes	The pool tick: tick from the list this tool returns when tick is left out. A tick sets the largest loan it funds (a share of a property's value, or a fixed dollar amount) and the longest loan length
`wallet`	Yes	The wallet that will sign (0x address). The sign page only lets this wallet sign.
`amountUsd`	No	Amount to withdraw in US dollars (default: the whole position at the tick)

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: the server holds no keys and submits nothing, a signRequest is stored with a 15-minute expiry and null payload, and nothing happens until the human signs. It also discloses the partial-liquidity case where unpaid funds wait in the pool's withdrawal queue, which is meaningful behavioral context an agent could not infer.

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 action and its scope are front-loaded, then the check, then the prepared-not-sent behavior. It is dense with useful detail, though the 'nothing happens until then' clause slightly repeats the earlier 'Prepared, not sent' statement.

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 return-value burden and does so fully: it enumerates signRequest fields, the expiry, and the null payload. For a non-idempotent, open-world preparation step, an agent has everything needed to call it and explain the result to a user.

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 all four parameters are already documented, and the description largely restates them (amountUsd default, wallet as signer, tick selection). It adds a bit of operational meaning by tying wallet to who the sign page will accept, but offers no new syntax or constraints 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 and resource ('Prepare withdrawing amountUsd … from the wallet's deposit at one tick of the DeFi lending pool'), including network scope (Sepolia Testnet) and the default behavior. The 'prepare, not send' framing also implicitly separates it from the deposit counterpart and from any actual submission step.

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?

Preconditions are spelled out: the wallet must already have a deposit at the tick and the amount must be within it. It also explains the downstream flow (open link, sign with that wallet) and the queued-payout case. It never explicitly names deposit_to_lending_pool as the alternative, so sibling routing is left to inference.

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

All Fabrica (Sepolia testnet) tools Inspect

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.