Skip to main content
Glama
Sign In

Borro

by markets.borro
OverviewDiscussionsAdmin

Policy credit: a policy's record, or a wallet's claim

policy
Read-onlyIdempotent

Policy credit: an agent's borrowing terms follow the record of the code it runs (its policy: the content hash of code, model and prompt), across every wallet that claims it. Pass policy (a hash) for its ledger entry, or wallet for its claim and that policy's entry: the tier (newborn, proven or established, from the lines, repayments, liquidations and bad debt of every wallet that claims it), the earned default daily limit by rung, and the honest limits of each rung. Rung 0: a signature from the wallet ("I run policy H"), checked by nobody, defaults up to 250 USDG a day. Rung 1: a hardware attestation (a dstack TEE quote) that the wallet's key lives in an enclave running image H, verified off chain by Borro's keeper, which attests on chain; the raw quote is public, so anyone can re-verify; up to 500. Rung 2: a zk proof per action (SP1) that the action is what program H outputs on committed inputs, checked by the SP1 verifier contract at the registry; up to 1,000. Honest limits: rung 0 proves nothing (a lying wallet poisons the policy it claimed, and the policy's owner can disown it); rung 1 trusts the chip maker and the enclave operator, and Borro's keeper is the on-chain attester (the quote itself is published, so the keeper cannot invent one); rung 2 serves policies that are pure functions over Borro's public inputs, which no LLM-driven agent is; nothing proves which weights a closed model used. Reads Borro's ledger (https://borro.markets/policies.json), then the registry on chain.

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": "policy"
  }
}

Input Schema

NameRequiredDescriptionDefault
policyNoThe policy's hash (bytes32: 0x and 64 hex characters), keccak256 of its manifest
walletNoOr a wallet (0x...), for its claim and the policy's record

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior4/5

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

Beyond the annotations (readOnly, idempotent, non-destructive, openWorld=false), the description discloses data provenance — it "Reads Borro's ledger (https://borro.markets/policies.json), then the registry on chain" — and explains how the tier is computed from lines, repayments, liquidations and bad debt. It also candidly states trust assumptions per rung (rung 0 proves nothing, rung 1 trusts chip maker and keeper, rung 2 serves only pure functions, nothing proves which weights a closed model used). That is unusually rich behavioral context, though it does not describe failure modes (no claim found for wallet, unknown hash).

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?

Structure is sound — the access path is front-loaded, then rungs 0-2, then an "Honest limits" section — and the rung detail is genuinely needed to interpret the returned tier and limits. However it is a single dense ~250-word paragraph for a two-parameter read, and the trust-model prose (chip maker, SP1 verifier, closed-model weights) exceeds what an agent needs to call the tool correctly.

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 carries the return-value burden and does so: it names the tier vocabulary (newborn, proven, established), the per-rung daily limits (250/500/1,000 USDG) and the inputs that produce them. Gaps remain around error behavior (wallet with no claim, malformed hash) and whether one parameter wins when both are passed.

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?

Schema coverage is 100% and both parameters already document their formats (bytes32 hash, 0x wallet), so the baseline is 3. The description adds real meaning on top: the policy is "the content hash of code, model and prompt" and a wallet returns "its claim and that policy's entry," clarifying that the two parameters select different views rather than being independent filters. The interaction when both are supplied is left unstated.

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 description states a specific resource and its retrieval semantics: "Pass policy (a hash) for its ledger entry, or wallet for its claim and that policy's entry," then enumerates what comes back (tier, earned default daily limit by rung, honest limits of each rung). An agent can tell this is a read-side lookup of a policy record rather than the sibling mutations policy_claim/policy_register/policy_prove. It lacks a single crisp verb-phrase opening ("Reads the policy record for a hash or wallet"), which keeps it short of 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 Guidelines3/5

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

Usage is implied only through the parameter fork: pass a hash for the raw ledger entry, or a wallet for the claim plus the policy's record. There is no explicit when-to-use/when-not guidance and no naming of adjacent siblings such as credit_line, credit_guardrails or policy_claim to route the agent. The reader must infer that a wallet with no claim is the reason to prefer the policy form.

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