Skip to main content
Glama

Borro

Prepare: open an agent credit line, post or borrow

credit_open
Read-onlyIdempotent

Unsigned transactions. Without account: open a line owned by the signing wallet for an agent (never the wallet itself), in a market credit_markets lists ("CREDIT", the default), post its credits and optionally borrow USDG at once (to the wallet unless to names an allowlisted address); exact credit approval to the factory first. The owner's limits: ceiling (USDG, default the most the target allows today), daily_limit (USDG out in any 24 hours, borrows and the agent's withdrawals together, or "none"; default the ceiling, or $100 with a gas station; at most $5,000 with one), target_ltv (a fraction under 1 like 0.18, or a percent with its sign like "18%"; the market's default, 0.18 for CREDIT, at most the market's max trigger), trigger_ltv for protect (by the market's rule; CREDIT: the target plus 7 points, at least 0.27 and at most 0.3), allow (addresses borrowed USDG may go to, 16 at most), gas_station (true: put the agent's gas station on the allowlist), bills (true: bill pay, the agent's own wallet on the allowlist, for x402 bills through credit_bill; the daily limit then defaults to $100), keeper ("borro", the default, "none" or an address), sell_bps and slip_bps for protect's sales (CREDIT defaults 2500 and 300; 0 in a market with no pool). With account: post more credits (anyone) and/or borrow (the line's agent or owner) to an allowed address. A wallet holding $BORRO borrows for less once Holder Credit counts it (holder_benefits). Refuses locally what the line would refuse (over the daily limit, the ceiling or the target, during a write-off, past what the market has free, past 90% used, past what the depth gate allows, before CREDIT's price starts); simulated from the wallet. Check each transaction's to: the factory, a line the factory confirms (isAccount), or the credit for an exact approval.

Input Schema

NameRequiredDescriptionDefault
toNoWhere borrowed USDG goes: the owner or an allowlisted address (default the wallet, or the owner)
agentNoNew line: the agent's address, the wallet that will borrow from it (not the owner's)
allowNoNew line: addresses borrowed USDG may go to (16 at most)
billsNoNew line: bill pay, the agent's own wallet on the allowlist, so it can borrow what it is short of an x402 bill (credit_bill); the line then needs a daily limit ($100 unless given)
borrowNoUSDG to borrow now (optional), in whole units as a decimal string, like "1.5"
keeperNoNew line: "borro" (Borro's keeper, the default), "none", or an address
marketNoNew line: which market, by its symbol in credit_markets (default CREDIT)
walletYesThe wallet's address (0x...); the transactions are built for it to sign
accountNoAn existing line: post more and/or borrow from it (leave out to open a new line)
ceilingNoNew line: the most USDG the line may owe (optional), in whole units as a decimal string, like "1.5"
creditsNoCredits to post, in whole units as a decimal string, like "1.5"
sell_bpsNoNew line: most of the credits one protect sale may sell, in hundredths of a percent (0 to 2500; CREDIT default 2500; 0 in a market with no pool)
slip_bpsNoNew line: most a protect sale may fill under the feed's price, in hundredths of a percent (0 to 1000, default 300)
target_ltvNoNew line: target LTV, a fraction under 1 like 0.18 or a percent with its sign like "18%" (the market's default: 0.18 for CREDIT)
daily_limitNoNew line: the most USDG out in any 24 hours, like "100", or "none" (default the ceiling; $100 with a gas station, at most $5,000)
gas_stationNoNew line: put the agent's gas station on the allowlist, so the agent can borrow its own gas (credit_gas)
trigger_ltvNoNew line: LTV above which the keeper may protect it (default by the market's rule)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Goes well past the annotations: it discloses that output is unsigned transactions requiring an exact credit approval to the factory first, that refusals are computed locally by simulating from the wallet, and enumerates the specific rejection conditions (daily limit, ceiling, target, write-off, 90% used, depth gate, price timing). It also tells the agent to verify each transaction's `to:` against the factory, isAccount, or credit address.

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?

Every clause carries information, but it is delivered as one dense paragraph of comma-chained constraints with no line breaks or sub-headings between the open-line and existing-account modes. Substantively lean, structurally hard to scan, especially with 17 parameters.

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 17-parameter, two-mode, no-output-schema tool this covers modes, defaults, refusal conditions and downstream call targets. The remaining gap is the return shape itself — how many transactions come back and in what order beyond the factory approval — which the description only implies.

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%, yet the description still adds cross-parameter semantics the schema omits: daily_limit defaulting to the ceiling, or $100 capped at $5,000 when a gas station is present; trigger_ltv deriving from the target plus 7 points within 0.27–0.3 for CREDIT; sell_bps/slip_bps market-dependent defaults; and the owner-vs-agent interaction between `to`, `agent` and `allow`.

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?

Opens with 'Unsigned transactions' — the key distinction for a prepare-only tool — then states both modes concretely: opening a line owned by the signing wallet for an agent, or posting/borrowing on an existing account. An agent can tell this apart from borrow, credit_line and credit_guardrails without opening a schema.

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?

Explicitly separates the two invocation modes ('Without account' vs 'With account'), names the prerequisite lookup (credit_markets for the symbol) and the linked flows (credit_bill, credit_gas, holder_benefits). No sibling tool is named as an alternative for inspecting an existing line, so it falls short of a 5.

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