Skip to main content
Glama

Prepare: post a Bailouts offer

bailout_offer
Read-onlyIdempotent

Unsigned transaction posting a standing offer on a position in the version 2 trade account: once its LTV (Morpho's own, at the market's oracle) reaches at_ltv, anyone may put in what brings it back to to_ltv, up to max_usdg; the account's own idle money goes in ahead of the rescuer, who is owed back ahead of the owner plus fee_bps of what it put in (1 to 2000), earned over term_days (1 to 30, default 7), and may foreclose on that position alone after the term. at_ltv under the position's LLTV, to_ltv under at_ltv; expiry_days (default 30) is when it lapses untaken. No money moves when it is posted. At most 4 live offers an account, one per position. While one is live, max_slip_bps and the agent's slip may come down and never up. From the agent: within the owner's cap (agent_bailout_max_usdg) and at least 10.0 USDG, on positions it may trade, at_ltv at least 200 bps over the position's LTV now, 2 times its fee on max_usdg counted into today's loss budget when posted. Refused in words when the position is not held, a bailout is owed, the position carries an offer, the bounds are off, or the agent's limits refuse it; warns when it is takeable at once or when max_usdg is short of what a rescue at at_ltv would take. Simulated from the wallet (the owner or the agent).

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": {
      "wallet": "<wallet>",
      "symbol": "<symbol>",
      "side": "<side>",
      "at_ltv": "<at_ltv>",
      "to_ltv": "<to_ltv>",
      "max_usdg": "<max_usdg>",
      "fee_bps": "<fee_bps>"
    },
    "name": "bailout_offer"
  }
}

Input Schema

NameRequiredDescriptionDefault
sideYesshort (the account's short on the stock) or long (its leveraged long)
at_ltvYesThe LTV a rescue opens at: a fraction under 1, like 0.7 (a percent with its sign is taken too)
symbolYesA stock on Borro by its ticker, like NVDA or AAPL (markets lists every one)
to_ltvYesThe LTV a rescue must bring it back to, under at_ltv
walletYesThe wallet's address (0x...); the transactions are built for it to sign
accountNoA version 2 trade account's address (default: the wallet's own, as its owner; an agent gives its owner's account)
fee_bpsYesThe rescuer's fee on what it puts in, earned over the term, in hundredths of a percent (1 to 2000)
max_usdgYesThe most a rescuer may put in, in whole USDG as a decimal string, like "250"
term_daysNoDays the owner has to repay before the rescuer may foreclose (1 to 30, default 7)
expiry_daysNoDays until the offer lapses if no one takes it (default 30, at most 365)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations, the description discloses critical behavior: no money moves when the offer is posted, the offer is simulated from the wallet, at most four live offers are allowed, slip settings may only decrease while live, and specific refusal and warning conditions apply. This adds substantial operational context for a preparation tool whose annotations already indicate a non-destructive, idempotent read-style call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is front-loaded and mostly relevant, but it is presented as a dense run-on paragraph with many semicolon-separated constraints. For a complex tool, much of the length is justified, but the structure makes it harder to scan than necessary.

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?

Given the tool's complexity, the rich input schema, and the absence of an output schema, the description is complete enough for an agent to understand what the prepared transaction does, when it will be refused or warned, and what constraints govern the offer. It also covers the simulated/preparation nature of the call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description still adds meaningful relational semantics: at_ltv must be below the position's LLTV and above to_ltv, max_usdg is capped by agent_bailout_max_usdg and a 10.0 USDG minimum, fee_bps ranges from 1 to 2000, term_days defaults to 7, and expiry_days defaults to 30. These constraints go well beyond the individual schema field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action and resource: an unsigned transaction that posts a standing Bailouts offer on a version 2 trade account position. It explains the core mechanics clearly, though it does not explicitly name sibling tools such as bailout, bailout_cancel, or bailouts to sharpen 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?

It provides strong guidance on when the offer can be posted, including required relationships between at_ltv and to_ltv, agent caps, minimum size, fee budget effects, and refusal/warning conditions. It does not explicitly compare itself to taking, cancelling, or repaying a bailout, but the surrounding context and mechanics make the use case clear.

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.

Resources