Skip to main content
Glama

Borro

by markets.borro
OverviewDiscussionsAdmin

Agent credit: a line

credit_line
Read-onlyIdempotent

One agent credit line (account) or the lines a wallet owns (owner: five a call, newest first; page 2 for the next five): its market, credits posted, USDG owed, LTV against its target, trigger and LLTV, a health word, what the agent can still borrow, the daily limit and what went out and is left of it today, the price at which it can be liquidated, its agent, keeper, owner, allowlist and sale settings, the agent's gas station and whether it is allowlisted, USDG it holds, and whether protect would act now. holder: what holding $BORRO gets this line (Hold $BORRO. Borrow for less.): up to half its interest back every Monday, what Borro's keeper makes if it liquidates the line unless it was left short or left bad debt, and where switched on gas on the house; counts (Borro's keeper counted it on the last day it counted), share, via (owner or agent: whichever has the larger share), heldBorro (wallet plus own lock), borroForFull ($BORRO for the full rate at today's price), weekSoFarUsdg, interestBackBps (the part of the line's interest that would come back, up to 5000; share and interestBackBps are estimates if held through a whole UTC day) and gasOnTheHouse (only where switched on, and only for a counted line owing gas.minDebtUsdg, 25 USDG by default, or more whose holder holds at least gas.minShare, half by default, of the $BORRO its lines' full rate needs, within weekly limits); live false until Borro's keeper publishes its count.

Input Schema

NameRequiredDescriptionDefault
pageNoWith owner: which five lines, newest first (default 1)
ownerNoA wallet whose lines to list
accountNoA line's address

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/closed-world safety, but the description adds substantive behavior: five lines per owner call, newest first, page 2 for the next five, and 'live false until Borro's keeper publishes its count.' It also flags estimates and conditional gasOnTheHouse eligibility.

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 single long run-on sentence with nested parentheses that enumerates dozens of return fields. While the field detail may be necessary without an output schema, the structure is hard to parse and not front-loaded beyond the opening clause.

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?

Because there is no output schema, the extensive field list is warranted and covers modes, pagination, holder benefits, conditional fields, and freshness. Some terms (health word, LTV target) remain undefined, but the agent has enough to invoke and interpret the call.

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%, so the baseline is 3; the description reinforces the owner/page pagination ('five a call, newest first; page 2 for the next five') and account mode but adds little syntax beyond the schema.

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 opening clause names the resource and the two access modes (account = one line, owner = list), so the agent knows it reads a credit line. It does not name a verb or explicitly contrast with sibling tools like credit_bill or credit_guardrails, which keeps it below a 5.

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?

No sentence says when to choose this over credit_bill, credit_guardrails, holder_benefits, or the other credit_* tools; the account/owner split is implied by the schema rather than framed as usage guidance.

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