Skip to main content
Glama
Sign In

Borro

by markets.borro
OverviewDiscussionsAdmin

Prepare: claim a policy from the agent wallet (rung 0)

policy_claim
Read-onlyIdempotent

An unsigned transaction for an agent wallet to claim the policy it runs (rung 0: the signature is the evidence; a wallet has at most one claim, and claiming again replaces it). Once claimed, the wallet's credit lines open with the policy's earned default daily limit for its rung when they have a gas station or bill pay, and its record feeds the policy's. The answer's next_steps say how to reach rung 1 (PUT /policies/quote with JSON { wallet (0x address), quote (hex: the raw TDX quote), event_log (the dstack event log, an array or its JSON text), key_chain (an object: the dstack KMS key chain binding the wallet's key to the app), signature (hex: an EIP-191 signature by wallet over the bytes "borro-policy-quote" ++ keccak256(quote)) }, at most 256 KB, no key; Borro's keeper verifies it and attests on chain) and rung 2 (SP1 proofs per action through policy_prove). 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. Simulated from the wallet; nothing is sent.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "wallet": "<wallet>",
      "policy": "<policy>"
    },
    "name": "policy_claim"
  }
}

Input Schema

NameRequiredDescriptionDefault
policyYesThe policy's hash (bytes32: 0x and 64 hex characters), keccak256 of its manifest
walletYesThe wallet's address (0x...); the transactions are built for it to sign

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, and the description is consistent with them while adding real context: 'Simulated from the wallet; nothing is sent', the replace-on-reclaim behavior, the credit-line and record side effects, and the caveat that rung 0 proves nothing and a lying wallet can poison the policy it claimed.

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 core action is front-loaded in the first clause, but the body is a dense run-on that packs rung mechanics, JSON payload shapes, size limits and epistemic caveats into one block. Much of it earns its place, yet the structure makes it hard to scan and could be split or trimmed.

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 compensates by explaining that the answer carries next_steps for reaching rung 1 and rung 2, and it covers the side effects of claiming. For a two-parameter preparation tool it is essentially complete, with only minor redundancy.

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 both parameters are already documented in the schema. The description adds only indirect meaning (the policy hash as 'policy H', the wallet as the signer), which is useful framing but not syntax or format detail beyond the schema. Baseline 3 applies.

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 verb and resource: it builds an unsigned transaction for an agent wallet to claim a policy, and it names the rung-0 semantics (signature is the evidence, one claim per wallet, re-claiming replaces). It also distinguishes itself from policy_prove (rung 2) and points at the PUT /policies/quote path for rung 1, so an agent can place it among its siblings.

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

Usage Guidelines5/5

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

It lays out exactly when to use this tool versus the higher rungs: rung 0 is a wallet signature checked by nobody with a 250 USDG default, rung 1 needs a dstack TEE quote verified by Borro's keeper, rung 2 needs SP1 proofs via policy_prove. It even states the honest limits of each rung, which is unusually explicit routing 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