Skip to main content
Glama

Draft an offer on a line request

line_offer
Read-onlyIdempotent

Draft an offer on Priors' line board, for a root's owner (a backer): give the request's id (from find_line_requests), the root to back from, the amount in USDG and, if you like, the premium (bps per 30 days, the request's most by default) and how many days the offer stands (7 by default, never past the request). It checks the offer against the request and the board's rules, the root's free backing on the pool and its owner in the ERC-8004 registry, and returns the LineOffer to sign (EIP-712 typed data, domain "Priors Line Market" 1 on chain 4663), the address that must sign it, the POST that lists it with the signature, and what Score v2 would say of a line from that root to that agent under its current rules: that loans on it count toward the agent's record now, from a date, or never. A refusal says why. It signs and sends nothing: the root's owner signs in its own wallet and posts the offer; once the agent's owner takes it, line_request gives the vouchWithConsent call. Read-only.

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": {
      "request_id": "<request_id>",
      "root_id": "<root_id>",
      "amount_usd": "<amount_usd>"
    },
    "name": "line_offer"
  }
}

Input Schema

NameRequiredDescriptionDefault
daysNoHow many days the offer stands, at most until the request ends. Default 7, or less as the request ends sooner.
signerNoThe address that will sign, to check it first (optional): the root's owner in the ERC-8004 registry; any other is refused.
root_idYesThe root (a backer of the pool) the offer backs the agent from, e.g. 490.
amount_usdYesThe line offered, in USDG: at least 1, at most the line asked and the root's free backing.
request_idYesThe request's id (its EIP-712 hash): 0x and 64 hex characters, as find_line_requests gives it.
premium_bpsNoThe premium, in bps per 30 days, at most the request's. Default: the request's most.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already mark it read-only, idempotent, and non-destructive, yet the description still discloses a great deal of behavior: it checks the offer against the request and board rules, the root's free backing, and the ERC-8004 owner; it returns the LineOffer to sign (EIP-712, domain and chain stated), the signer address, the POST payload, and a Score v2 projection including when loans count. It also states a refusal explains itself and that nothing is signed or sent, which is exactly the mutation safety detail annotations do not carry.

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?

Purpose is front-loaded and nearly every clause carries information, but it is delivered as one long stream with nested parentheticals that an agent must parse carefully. It could be split into purpose, inputs, returns, and side-effect sentences without losing content, which would make it faster to scan.

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?

For a six-parameter tool with no output schema, the description covers returns, refusal behavior, signing-vs-posting responsibility, and the downstream consent step. There is no output schema, so spelling out the LineOffer, signer address, and POST payload in prose is exactly the missing piece an agent needs.

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 schema already documents every parameter, including the 7-day default and the premium defaulting to the request's maximum. The description restates those defaults and adds light relational meaning (amount bounded by the line asked and the root's free backing), but adds no syntax or format detail beyond the structured fields, so the baseline of 3 applies.

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?

The description opens with a specific verb and resource ('Draft an offer on Priors' line board') and scopes it to the root's owner (a backer). It names the sibling that supplies the request id (find_line_requests) and the sibling that completes the flow (line_request), so the agent can place this tool in the pipeline without opening any schema.

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?

Usage is clear: fetch the request id via find_line_requests, draft here, then the owner signs in its own wallet and posts, and line_request yields vouchWithConsent once the offer is taken. What is missing is an explicit when-not or a stated alternative for cases where the caller cannot or will not sign, but the operational context is otherwise unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources