Skip to main content
Glama

Prepare: put a hold on a Borro position

hold_open
Read-onlyIdempotent

Unsigned transactions putting part of the wallet's Borro position on hold for one payee, up to a cap in USDG and until an expiry, while the shares keep earning (the vault's interest or lending fees, and the $BORRO Drip). vault: "USDG" (the default: usdg, the cap unless given, goes into bUSDG and the hold is those shares, openWithUsdg) or a stock's ticker (shares of its Borro vault the wallet holds, "all" or an amount; worth more than the cap at the vault's cover). mode: "metered" (the default: x402 requests paid with vouchers, hold_pay) or "charge" (the payee charges up to the cap). With payment_required (a merchant's 402 offering the borro-hold scheme) the payee, the vaults it takes, the least cap and life are the merchant's. expiry_seconds: up to 90 days (default the merchant's, else a day). The payer cannot take the shares back before the expiry and a 4-day grace after it, in which the payee may still collect; the payee or its operator can release them any time, and after the grace anyone can reclaim them for the payer. The terms the payer accepts (the stock's desk, the most slippage on its sales, the most fee) come from the vault's listing and the fee now, and max_slip_bps or max_fee_bps tighten them; they are fixed for the hold's life. An exact approval to BorroHolds comes before it when one is missing; simulated from the wallet. Returns the hold's id.

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>"
    },
    "name": "hold_open"
  }
}

Input Schema

NameRequiredDescriptionDefault
capNoThe most USDG the payee can ever be paid from the hold, in whole units as a decimal string, like "1.5"
modeNometered (default) or charge
saltNo32 bytes of 0x hex for the hold's id (default: fresh)
usdgNoUSDG hold: the USDG to put in (default: the cap and 0.000002 for the vault's rounding), in whole units as a decimal string, like "1.5"
payeeNoWho the hold pays (or give payment_required)
vaultNo"USDG" (default) or a stock's ticker, like NVDA
sharesNoStock (or bUSDG) hold: the vault shares to hold, like "0.5", or "all"
walletYesThe wallet's address (0x...); the transactions are built for it to sign
operatorNoCharge mode: an address that may charge and release for the payee
max_fee_bpsNoThe most fee the payer accepts, in basis points (default: BorroHolds' fee now)
max_slip_bpsNoThe most slippage the payer accepts on a stock hold's sales, in basis points (default: the listing's now)
expiry_secondsNoHow long the hold lasts, in seconds (60 to 7776000)
payment_requiredNoA merchant's 402 PaymentRequired (its PAYMENT-REQUIRED header value or JSON body) offering borro-hold

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?

With annotations already declaring readOnly, idempotent, and non-destructive behavior, the description adds substantial operational context: the payer cannot withdraw before expiry plus grace, the payee/operator can release, anyone can reclaim after grace, terms are fixed for the hold's life, an approval may be needed, and the call is simulated from the wallet.

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 relevant, but it is presented as one dense run-on paragraph with nested parentheticals. It also repeats some parameter details already covered by the schema, making it harder to scan than necessary for a 13-parameter tool.

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?

For a complex transaction-preparation tool with no output schema, the description covers the key behavior, constraints, default paths, irreversible consequences, approval step, and that it returns the hold's id. It does not fully specify the complete return shape (unsigned transactions plus id) or signing/gas flow, but it is otherwise complete.

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 the baseline is 3, but the description adds real meaning beyond the schema for vault behavior (USDG into bUSDG vs stock shares), mode behavior (metered vouchers vs charge), payment_required merchant overrides, expiry defaults, and how max_slip_bps/max_fee_bps tighten listing terms.

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 states a specific verb and resource: it prepares unsigned transactions that put part of the wallet's Borro position on hold for one payee, with a cap, expiry, and earning behavior. It also distinguishes the main variants (USDG vs stock vault, metered vs charge) from sibling payment tools like hold_pay.

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 gives clear context for choosing the USDG default versus a stock ticker, metered versus charge mode, and the merchant-driven payment_required path. It stops short of explicitly saying when not to use this tool or directly comparing it to hold_status/hold_end/hold_collect.

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