Priors (hosted, read-only)

Draft a request for a line on the line board

line_ask

Read-onlyIdempotent

Draft an agent's owner's request on Priors' line board, asking the pool's roots (backers) for a credit line: give the agent's id, the line in USDG (at least 1), the most premium its owner would pay a backer (bps per 30 days, at most the pool's cap of 200), the term it means to borrow for (1 to 90 days) and, if you like, how many days the request stands (7 by default, at most 30). It checks the request against the board's rules and the agent's owner in the ERC-8004 registry, and returns the LineRequest to sign (EIP-712 typed data, domain "Priors Line Market" 1 on chain 4663), the address that must sign it, and the POST that lists it with the signature. A refusal says why. It signs and sends nothing, and asking promises no line: a backer may offer, or not; line_request shows the offers, and line_take drafts the take of one. 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": {
      "agent_id": "<agent_id>",
      "line_usd": "<line_usd>",
      "max_premium_bps": "<max_premium_bps>",
      "term_days": "<term_days>"
    },
    "name": "line_ask"
  }
}

Input Schema

Name	Required	Description
`days`	No	How many days the request stands on the board, from 1 to 30. Default 7.
`signer`	No	The address that will sign, to check it first (optional): the agent's owner in the ERC-8004 registry; any other is refused.
`agent_id`	Yes	The agent (ERC-8004 id) its owner asks a line for, e.g. 8792.
`line_usd`	Yes	The line asked, in USDG: at least 1, at most 1,000,000, 6 decimals at most.
`term_days`	Yes	The term the agent means to borrow for, in days: from 1 to 90, as the board takes it.
`max_premium_bps`	Yes	The most premium its owner would pay a backer, in bps per 30 days: at most the pool's cap, 200 (2%).

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Although annotations already declare readOnlyHint/idempotent/destructiveHint=false, the description adds substantial behavior beyond them: it validates against board rules and the ERC-8004 registry, explains that a refusal states why, and confirms nothing is signed or sent. It also discloses the exact return payload (EIP-712 typed data, domain 'Priors Line Market' 1, chain 4663, signer address, and the POST to submit), which is the key operational detail for a drafting tool.

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?

The action and its required inputs are front-loaded in the first sentence, with constraints, return payload, and follow-on tools ordered sensibly after. The opening sentence is dense to the point of being run-on, but nearly every clause carries distinct information.

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 output schema, the description compensates fully by describing the returned LineRequest, signing address, and POST payload, plus the refusal case. For a six-parameter drafting tool, nothing an agent needs in order to call it and act on the result is missing.

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 description coverage is 100% and the schema already documents every parameter, including the premium cap of 200 bps and the 1-30 day request window. The description largely restates those same bounds (USDG at least 1, 200 bps cap, 1-90 day term, 7-day default) rather than adding new semantics, and it omits any mention of the optional signer parameter. Baseline 3 is appropriate.

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?

States a specific verb and resource: draft an agent owner's request on Priors' line board asking backers for a credit line, with the full parameter set named inline. It also differentiates itself from siblings by explaining that line_request shows offers and line_take drafts the take, so an agent can tell which tool produces the request versus consumes it.

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?

The description explicitly frames the workflow: this drafts a request, 'it signs and sends nothing,' 'asking promises no line,' then line_request shows offers and line_take drafts the take. The gap is that it never distinguishes this from the sibling request_borrow, which appears to be an alternative borrowing path, leaving that comparison to inference.

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

All Priors (hosted, read-only) tools Inspect

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

Need Help?