Priors (hosted, read-only)

Draft the take of an offer on a line request

line_take

Read-onlyIdempotent

Draft an agent's owner's take of one offer on its request on Priors' line board: give the request's id and the offer's id (line_request lists them). It checks the offer stands on that open request and that its root is still a root of the pool, owned by the offer's signer, reads the agent's owner and nonce on the chain, and returns the pool's own Consent to sign (EIP-712 typed data, domain "Priors Credit" 2: that offer's root alone, the agent's nonce, the offer's premium as the cap, a deadline six days on), the address that must sign it, the POST to the board's /accept, and what taking does: a line from another root handed over whole, a line smaller than now, an open loan to repay first, the root's free backing, and what Score v2 would say of a line from that root under its current rules. A refusal says why. It signs and sends nothing; once the take is posted, the root's owner sends the line from its own wallet, or not. 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>",
      "offer_id": "<offer_id>"
    },
    "name": "line_take"
  }
}

Input Schema

Name	Required	Description
`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.
`offer_id`	Yes	The offer's id (its EIP-712 hash): 0x and 64 hex characters, as line_request gives it.
`request_id`	Yes	The request's id (its EIP-712 hash): 0x and 64 hex characters, as line_request gives it.

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?

Beyond the annotations it discloses the validation checks performed, the EIP-712 domain and deadline, the returned signer address and POST endpoint, the economic effects of a take, and that refusals explain themselves. It also clarifies that drafting does not sign or send and that the root's owner must act afterwards.

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 every clause carries substantive information, but the single sprawling sentence packs validation, return payload, mechanics, and caveats together with dense jargon, making it harder to scan than a structured list.

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 by explaining the returned Consent typed data, signing address, submission endpoint, and the resulting line economics. Nothing an agent needs to decide whether and how to call it appears to be 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%, so the schema already explains request_id, offer_id, and the optional signer check. The description only reinforces that ids come from line_request, which is the expected baseline when the schema does the heavy lifting.

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?

Names a specific verb ('Draft an agent's owner's take') and resource (one offer on its request on Priors' line board), and its scope is distinguishable from siblings like line_offer, line_request, and line_options.

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?

Clearly directs the agent to obtain request_id and offer_id from line_request and states the precondition that the offer must stand on an open request. It does not explicitly contrast with line_offer or line_options for adjacent workflows, so it falls short of full when/when-not guidance.

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?