Skip to main content
Glama
Sign In

Borro

by markets.borro
OverviewDiscussionsAdmin

Keeper jobs: paid work open now

keeper_jobs
Read-onlyIdempotent

Every paid job on Borro right now, in one list: the positions past their liquidation limit (from Borro's keeper's /jobs.json), the triggers holding now (from /triggers.json) and the Bailouts offers a rescuer can take now (from /jobs.json). A liquidation is paid from the liquidated position's collateral, a trigger by the tip its owner set, and a rescue by the fee its owner offered; Borro itself pays none of them. Each job says what it pays (an estimate from a simulation or the offer's terms, never a promise), its gas, how long it has been open, when Borro's keeper steps in (borro_keeper_acts_after: it is the backstop for liquidations and triggers, and it may give outside agents a head start; it never rescues, since Borro puts no capital in), and the call that prepares it (liquidate, trigger_fire or bailout). Liquidations need no money of your own: the market's liquidator takes the collateral, sells it, repays the debt and pays you what is left. A rescue is the one job that takes your own USDG: it is lent against the rescued position, owed back ahead of the owner with the offer's fee, and can be lost if the position is liquidated anyway. Reads no chain; says so when the lists are empty or stale.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "keeper_jobs"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the read-only/idempotent profile, but the description goes well past them: it explains who funds each payout (collateral, owner's tip, owner's fee — 'Borro itself pays none of them'), warns that rescue is the only job requiring your own USDG and that the capital can be lost, and discloses staleness behavior ('says so when the lists are empty or stale'). That is exactly the context an agent needs before recommending a job.

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

Conciseness4/5

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

Front-loaded with the one-sentence purpose before the economic detail, which is the right ordering. It is a single dense block, though, and the 'Borro pays none of them' point is made twice ('Borro itself pays none of them' and 'since Borro puts no capital in'), which is modest redundancy in an otherwise tight description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no input schema, no output schema, and no annotations describing returns, the description carries the full burden and meets it: it lists per-job contents (payout estimate, gas, age, `borro_keeper_acts_after`, preparing call) and frames payouts as estimates rather than promises. An agent can act on this without opening any schema.

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?

Zero parameters, so the baseline is 4 and there is nothing for the description to compensate for. It doesn't need to explain inputs, and it correctly spends its words on outputs instead.

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 a specific verb+resource+scope: 'Every paid job on Borro right now, in one list,' then enumerates the three job classes (liquidations past limit, live triggers, rescue offers) and their source endpoints. That enumeration alone distinguishes it from siblings like `bailouts`, `liquidate`, and `trigger_list`.

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 routes the agent onward by naming the executable siblings each job maps to ('the call that prepares it (liquidate, trigger_fire or bailout)'), which effectively tells the agent this tool is a discovery scan, not an action. It does not explicitly state when to prefer `bailouts` or `trigger_list` over this aggregate view, which keeps it from a 5.

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