Skip to main content
Glama

Borro

by markets.borro
OverviewDiscussionsAdmin

Prepare: change an agent credit line's limits

credit_guardrails
Read-onlyIdempotent

One unsigned configure() transaction for the line's owner, starting from the line's current settings: agent (or revoke_agent: true, a JSON boolean, at once; never the owner's own wallet), keeper ("borro", "none" or an address), ceiling (USDG), daily_limit (USDG, or "none"), target_ltv and trigger_ltv (at most the line's max trigger, 30% for CREDIT; a new target over the line's trigger moves the trigger by the market's rule), sell_bps (0 in a market with no pool), slip_bps, allow (add addresses), deny (take them off), gas_station (true adds the agent's gas station, false takes it off), bills (true: bill pay, the agent's own wallet on the allowlist so it can borrow what it is short of an x402 bill, credit_bill; false takes it off; such a line needs a daily limit, $100 unless given). When the agent changes, the old agent's gas station and own wallet come off the allowlist in the same transaction and the new agent's go on in their place. A line with a gas station on its allowlist keeps a daily limit of at most $5,000 ($100 unless given). Checked as the line checks it; shows before and after. Ownership: transfer_to (the owner offers the line), or accept: true (the wallet it was offered to takes it with acceptOwnership, then names Borro's keeper again with setKeeper: two transactions sent one after the other; accepting clears the keeper, so until the second is sent the line has no keeper and no auto-repay; keeper: "none" leaves it off). Check each transaction's to: a line the factory confirms (isAccount).

Input Schema

NameRequiredDescriptionDefault
denyNoAddresses to take off it
agentNoA new agent address
allowNoAddresses to add to the allowlist
billsNotrue: bill pay, the agent's own wallet on the allowlist (credit_bill); false: take it off
acceptNoThe wallet the line is offered to: accept it, then name Borro's keeper again
keeperNo"borro", "none" or an address
walletYesThe wallet's address (0x...); the transactions are built for it to sign
accountYesThe line's address
ceilingNoThe most USDG the line may owe, in whole units as a decimal string, like "1.5"
sell_bpsNo0 to 2500 (0 in a market with no pool)
slip_bpsNo0 to 1000
target_ltvNoTarget LTV, a fraction under 1 like 0.18 or a percent with its sign like "18%"
daily_limitNoThe most USDG out in any 24 hours, like "100", or "none"
gas_stationNotrue: put the agent's gas station on the allowlist; false: take it off
transfer_toNoThe owner: offer the line to this address (it becomes theirs when they accept)
trigger_ltvNoProtect trigger LTV, at or above the target, like 0.27 or "27%"
revoke_agentNoRevoke the agent at once

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior5/5

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

The description goes well beyond the annotations by disclosing that transactions are unsigned and built for the owner to sign, that settings start from current values, that checks mirror the line's own checks, that before/after are shown, and that accepting ownership temporarily clears the keeper. It also explains the old-agent allowlist changes and the gas-station daily-limit constraint.

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 opening sentence is front-loaded and purposeful, and most content is relevant to the many parameters. However, the definition is a very dense paragraph with long parenthetical enumerations, making it harder to scan than it should be for a 17-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?

Given no output schema, the description is largely complete about transaction-building behavior, ownership acceptance, safety constraints, and expected account validation. The main gap is that it does not explicitly state the return shape, such as how transaction objects and the before/after view are returned.

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?

Although the schema has 100% description coverage, the description adds substantial semantic constraints not present in the schema: agent cannot be the owner's own wallet, keeper options, target/trigger LTV limits, sell_bps=0 when no pool, allow/deny behavior, bills implications, and accept ownership mechanics. These details materially improve correct parameter use.

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 title and opening sentence make clear that this prepares an unsigned configure() transaction for an agent credit line, starting from its current settings. It is specific about verb and resource, though it does not explicitly distinguish itself from sibling tools like credit_line, credit_gas, or credit_repay.

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?

The description explains what can be configured but does not state when to use this tool instead of alternatives such as credit_line, credit_gas, credit_bill, or credit_open. Usage is only implied by the list of configurable fields, with no explicit when-to-use or when-not-to-use 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