Skip to main content
Glama

Borro

by markets.borro
OverviewDiscussionsAdmin

Hold $BORRO. Borrow for less.

holder_benefits
Read-onlyIdempotent

Hold $BORRO. Borrow for less. What a wallet's $BORRO gets it on Agent Credit Lines, with or without lines. Keep $BORRO in the wallet that borrows (its own BorroLock lock counts as held) and its lines get, always: (1) up to half their interest back every Monday, in USDG: the full rate when it holds $BORRO worth a quarter of what its lines owe together, proportionally less with less; (2) liquidation profit back: when Borro's keeper liquidates a line, what it makes comes back, in proportion to the holding, unless the line was left short or left bad debt. And where switched on (rules.gas says whether it is): (3) gas on the house: on a line owing gas.minDebtUsdg (25 USDG by default) or more, while the holder holds at least gas.minShare (half by default) of the $BORRO its lines' full rate needs, Borro tops up the agent's wallet when it runs low on ETH (the owner's, if the agent has not borrowed on the line within 7 days), within weekly limits, if it is a plain wallet (no smart-account code). Send the $BORRO away and it stops (and forfeits that part of the week's unpaid benefits). Nothing to sign, lock or stake. Answers live (false until Borro's keeper publishes its count; until then nothing is counted or paid), counts (what Borro's keeper counted on the last day it counted), share, via, heldBorro, borroForFull ($BORRO for the full rate at today's price) and borro_to_add_for_full, covers_debt_usdg (the most its lines may owe at the full rate), weekSoFarUsdg, interestBackBps, gasOnTheHouse, each line with what it owes and its rate back, each market's Borro-run supply share (interest paid to anyone else's direct supply, or to the wallet's own part of Borro's USDG vault, gets nothing back), the rules and the paid weeks; share and the rates are estimates if held through a whole UTC day. With borrow_usdg: the same for a planned borrow on top. It reads; it builds no transaction.

Input Schema

NameRequiredDescriptionDefault
walletYesThe wallet's address (0x...); the transactions are built for it to sign
borrow_usdgNoOptional: a planned borrow in USDG, to see the $BORRO its full rate needs, in whole units as a decimal string, like "1.5"

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent and non-destructive behavior, but the description adds substantial behavioral context: liveness ('false until Borro's keeper publishes its count'), Monday interest rebates, forfeiture if $BORRO is sent away, gas top-up conditions and wallet-type constraints, exclusions for direct supply, and estimate caveats. It is dense and poorly structured, but unusually rich in disclosed behavior.

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

Conciseness2/5

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

The description is a dense run-on with many parentheticals and a marketing lead, so the core purpose and usage conditions are buried. It contains a lot of information, but it is not front-loaded or efficiently structured.

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?

With no output schema, the description must convey return content, and it enumerates live/counts/share/via/heldBorro/borroForFull/weekSoFarUsdg/interestBackBps/gasOnTheHouse plus per-line and per-market data, rules and paid weeks. It is nearly complete for an agent deciding whether and how to call it, though types and response formatting are absent.

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

Parameters3/5

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

Schema coverage is 100% for both parameters, so the schema already does the heavy lifting. The description mentions the wallet's $BORRO and borrow_usdg for a planned borrow, but adds little syntax or format meaning beyond what the schema already states.

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

Purpose3/5

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

The description eventually makes clear that this returns a wallet's $BORRO holder benefits on Agent Credit Lines, including with a planned borrow, and that it only reads. But it opens with a marketing slogan and does not state a crisp verb+resource or explicitly differentiate itself from sibling tools like credit_line or credit_gas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named. Usage is only implied by phrases such as 'With borrow_usdg: the same for a planned borrow on top' and 'It reads; it builds no transaction.'

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

All Borro toolsInspect
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.

Resources