Priors (hosted, read-only)

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds the highly relevant behavioral cue 'Read-only,' and its list of returned fields (defaulted, frozen status) tells the agent what it can learn. It does not discuss rate limits, caching, or freshness, but given the annotations, this is more than sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense, front-loaded sentences. The first sentence lists the record's contents efficiently, and the second gives the decision rule and read-only status. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is a read-only query with one fully-documented parameter and no output schema. The description covers purpose, usage context, and the full set of returned fields, leaving little for an agent to wonder about. It could mention chain availability or freshness, but that is a minor gap for this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the single agent_id parameter is fully documented in the schema with its type, range, and an example ('462'). The description adds no extra syntax or format information beyond what the schema provides, 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Show') and resource ('a Priors agent's full credit record on Robinhood Chain'), then enumerates the exact fields returned. It clearly distinguishes itself from siblings like score_of, request_borrow, and request_repay, which each cover narrower slices of agent data.

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

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

It explicitly says when to use it: 'Use it before trusting, paying or lending to an agent.' This names the decision contexts and implies the alternative siblings (score_of for just the score, request_borrow for lending actions) without ambiguity.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so 'Read-only' in the description merely restates structured data and earns no credit. Beyond the safety profile the description adds no behavioral traits such as data freshness, caching, auth requirements, or failure modes. It does implicitly tell the agent this reflects live facilitator state, which is modest added context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that identifies the resource first and then enumerates returned fields; nothing is wasted. The one flaw is the trailing 'Read-only', which duplicates the annotation and could be dropped, and the mid-sentence comma list is dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no parameters, the description carries the return-value burden and does so thoroughly, covering health, chain/asset, protocol versions and schemes, signer, pending settlements and merchant registration state. It is essentially complete for a status tool; only freshness/error behavior is unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly adds nothing about parameters and instead spends its words on the returned data, which is the right allocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource ('Priors x402 facilitator (facilitator.priors.trade)') and a precise verb ('Show'), then enumerates the exact facets returned: status, chain, settled asset, supported x402 versions/schemes/networks, signer address, pending settlements and merchant registration state. That is far more specific than a tautology. It does not, however, explicitly differentiate itself from potential overlap with siblings like find_services or recent_activity, which is the only thing keeping it off a 5.

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

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

Usage is only implied: a zero-parameter, read-only status lookup is self-evidently safe to call, and the trailing 'Read-only' signals it is non-mutating. There is no explicit 'use this when...' statement and no named alternative, so an agent must infer when to reach for it versus find_services or pool_stats.

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

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

Annotations already cover the read-only/idempotent profile, and the description adds genuinely new behavioral context: the content is merchant-authored and must be treated as data rather than instructions (a prompt-injection warning), plus the payment rail (x402/USDG on Robinhood Chain) and the handoff tool for transacting. That is real value beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core action and scope, then the trust warning, then the payment handoff. No filler; each sentence carries a distinct piece of information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-param, read-only discovery tool with no output schema and full annotation coverage, the description covers purpose, trust caveat, and next step. It stops short of hinting at the shape or volume of results (e.g. pagination or result fields), which would complete the picture.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single query parameter, which already documents that the word is matched against name, description or URL. The description only restates 'optionally filtered by a search word', adding no syntax or matching detail beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (List) plus resource (services registered with the Priors facilitator) and narrows the scope with two concrete qualifiers: accepts x402 payments in USDG, on Robinhood Chain. This is distinguishable from siblings like pool_stats or stock_assets 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.

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

Explains the optional search-word filter and routes the agent elsewhere for the actual payment step ('to pay one, use the local @priors/mcp server's pay_url (see how_to_connect)'). It does not state when-not to use it versus other discovery tools, but the context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: the wallet key must be set as an environment variable and payments flow through x402 in USDG. It does not describe the response shape, but for a help/explanation tool that is a minor gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the purpose and closing with the invocation trigger; the middle segment is information-dense but every clause maps to a distinct setup topic. Slightly packed, but no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless, read-only explanatory tool with no output schema, the description covers what an agent needs: what is explained, when to invoke it, and the server/key prerequisites. Only the returned content format is left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Explain how to use Priors from an MCP client') and enumerates the exact topics covered: the hosted server URL, the local @priors/mcp server with wallet key, and x402 payment in USDG. This clearly separates it from action siblings like request_borrow or pool_stats.

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

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

Gives an explicit trigger: 'Call this when the user wants to pay, borrow, repay, or set Priors up.' That covers the main use contexts well, but it does not name sibling tools (e.g., request_borrow/request_repay) or state when not to call it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the 'Read-only' sentence repeats structured data rather than adding to it. The description does not mention freshness, caching, or whether figures are real-time, but with annotations covering the safety profile the lower bar is met.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler; the long enumeration is justified because there is no output schema and each named figure is genuinely informative. It is slightly list-heavy but every item earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, enumerating the returned fields (liquidity, principal out, total assets, reserve, fees, bad debt, agent count, loan counts, loan terms) is exactly the compensating detail an agent needs. Combined with annotations that cover the safety profile and a zero-parameter schema, the definition is close to complete; only freshness or units are left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly spends no words on inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Show the Priors credit pool's current figures') and enumerates exactly which figures are returned, so an agent knows precisely what this tool yields. It does not explicitly contrast itself with siblings such as recent_activity or agent_record, which is the only thing keeping it from a 5.

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

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

There is no statement of when to call this versus alternatives, and no prerequisites or exclusions. The 'Read-only' note hints that it is safe to call freely, but the agent must infer that this is the tool for inspecting aggregate pool state rather than a specific agent's record.

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

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

Goes well beyond the readOnlyHint/idempotentHint annotations: it clarifies that read-only here means building unsigned calldata that is never signed or sent, discloses the conditional approval step ('if needed'), the approval amount ('exactly that USDG'), the recipient ('paying the PT-USDG to the wallet itself'), and the required ordering. This resolves the apparent tension between readOnlyHint=true and a buy operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense but well-ordered sentence front-loads the action and follows with the call sequence; every clause carries information. Slightly heavy with parentheticals but no wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should say something about the returned calls; it explains their content and ordering but not the shape of the response. For a 3-parameter, fully documented, annotation-covered tool, this is nearly complete, with only the return format left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents address, amount_usdg, and slippage_bps. The description adds only the 'minimum out' concept, which loosely maps to slippage_bps, but gives no added syntax or range detail. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource: 'Build the unsigned calls that buy PT-USDG with USDG for a wallet on Robinhood Chain.' This clearly distinguishes it from siblings pt_sell, pt_redeem, and pt_quote, and even describes the exact call sequence (approval then router swap).

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

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

Usage is implied by the flow description ('if needed' approval, 'wallet signs and sends them in order'), but there is no explicit when-to-use guidance or named alternative such as running pt_quote first to obtain the quote that 'minimum out' references. Nothing tells the agent when not to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered and 'Read-only' is redundant. The description does add real behavioral context by disclosing the oracle spot-rate dependency, the maturity payout and fixed-APY computation, and the vault eligibility check, but says nothing about invalid addresses or wallets holding no PT-USDG.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One front-loaded sentence that opens with the verb and resource before listing the returned fields; dense but no filler. The trailing vault clause is syntactically convoluted ('behind an agent's line'), which slightly hurts readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly enumerates the return values (balance, spot value, maturity payout, days left, fixed APY, vault eligibility), which is what an agent needs to interpret the response. It omits edge-case behavior for wallets with no position or unrecognized addresses.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with a single documented address parameter (including the 0x pattern), so the schema carries the load. The description adds no format, chain, or validation detail beyond it, making the baseline 3 correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Show a wallet's PT-USDG on Robinhood Chain') and enumerates the data it returns, so the agent knows this is a position-read, distinct from pt_quote/pt_buy. It never names or rules out a sibling, so it stops short of the 5-tier differentiation.

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

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

There is no when-to-use or when-not-to-use guidance relative to pt_quote, pt_redeem, or stock_position. 'Read-only' hints at the read/mutate split but nothing tells the agent when to prefer this over the sibling quote or position tools.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description goes beyond them by naming what the quote yields (oracle spot rate output, minimum named trade, days to maturity, fixed APY a buyer locks) and clarifying withdrawal/duration semantics, adding real context for a quote call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence, but the primary action ('Quote buying PT-USDG...') is front-loaded and the parenthetical explains the token inline. The trailing 'Read-only.' earns its place as a safety signal, though the em-dash chain is somewhat packed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 enumerating the returned figures (spot-rate output, minimum, days to maturity, fixed APY), so an agent knows what a quote produces. Combined with the annotation-backed safety profile, an agent has enough to call it correctly; only explicit when-to-use routing is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents side, amount and slippage_bps including enum semantics and defaults. The description adds no extra parameter detail beyond what the schema provides, which matches the baseline 3 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.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (quote) and resource (PT-USDG trade) and enumerates the three operations covered: buying, selling before maturity, redeeming after. It clearly distinguishes itself from the mutating siblings pt_buy, pt_sell and pt_redeem by being the quote/preview counterpart.

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

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

The description says 'Read-only' and covers all three side modes, which implicitly positions it as the preview step before pt_buy/pt_sell/pt_redeem. However it never explicitly says to use this instead of those tools when you only want a price, nor states prerequisite conditions, so the routing guidance is implied rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the description reinforces it ('Nothing is signed or sent. Read-only.') and adds real behavioral context: the call builds a two-step unsigned sequence and the approval is for exactly the PT-USDG amount, conditional ('if needed'). It does not mention any rate limits or failure modes, keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and the two-step flow are front-loaded, and the alternative routing comes after. It is dense and slightly clause-heavy, but no sentence is filler and the ordering is sensible.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only transaction builder with no output schema, the description covers what is produced (unsigned calls, nothing signed or sent), the order of operations, and the maturity precondition. It is complete enough to call correctly; only the return payload shape is left implicit, which is acceptable given no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters are already documented in the schema, including the market default and the redemption slippage default. The description largely restates those semantics rather than adding syntax or edge-case detail, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb and resource ('Build the unsigned calls that redeem a wallet's PT-USDG for USDG 1:1'), including the chain (Robinhood Chain) and the exact mechanics (approval to Pendle's router, then router redemption). An agent can distinguish this from pt_sell, pt_buy, pt_quote and pt_position 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.

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

Gives an explicit when-not condition ('Before maturity it says to sell instead') and routes the agent to the sibling that enumerates markets ('pt_position lists them'). Default behavior versus the `market` override is spelled out, so the agent knows which path to take without inference.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive), and the description adds real substance beyond that: the two-step call sequence (approval of exactly that PT-USDG, then router swap), the USDG recipient (the wallet itself), and that nothing is signed or sent. It stops short of describing the returned call format or failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One dense but front-loaded sentence carries the whole operation, followed by two short confirmation clauses ('Nothing is signed or sent. Read-only.'). No filler, and the most decision-relevant information (what it builds, where, before maturity) comes first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

All parameters are fully described by the schema, and the description explains the operation's mechanics well for a build-transaction tool. With no output schema, the one remaining gap is that the shape of the returned unsigned calls is never stated, though 'build the unsigned calls' implies it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with each parameter documented including formats and defaults, so the baseline is 3. The description loosely ties to parameter semantics ('approval of exactly that PT-USDG', 'with a minimum out') but adds no syntax or format detail beyond what the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Build the unsigned calls that sell a wallet's PT-USDG for USDG' — plus chain and execution venue (Robinhood Chain, Pendle's router). The qualifier 'at the market before maturity' implicitly separates it from pt_redeem, so an agent can route between the two without opening schemas.

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

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

Gives clear usage context ('at the market before maturity') and notes the approval leg is only emitted 'if needed', which tells the agent the tool is self-contained. It never names pt_redeem or pt_quote as alternatives, so the when-not-to-use side is left to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the 'read-only' statement is redundant. The description does add useful detail on the returned fields (agent, amount, time, tx hash, due date, fee), which goes beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence with the sort order and field list front-loaded and no filler. Appropriately sized for a simple read-only list tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers what the tool returns (event types and fields) and ordering, which is the main thing an agent needs for a read-only listing. Return format specifics (e.g., pagination, response shape) are absent but no output schema exists, so slight gap remains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single 'limit' parameter already documents range and default. The description adds nothing about the parameter, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (list) and resource (latest loan activity on the Priors pool) and names the event types covered (borrows, repays, defaults). Clearly distinguishable from siblings like pool_stats or agent_record.

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

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

Implies a monitoring use case via 'latest' and 'newest first', but gives no explicit when-to-use or when-not-to-use guidance relative to siblings. No alternatives named.

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

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

The description strongly reinforces the read-only hint by explicitly stating 'Nothing is borrowed by this tool: no key, no transaction.' It also discloses the two confirmation modes (Go mode vs Builder mode) with their respective URLs, which adds valuable behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action, followed by the key non-destructive clarification, and ends with a concise usage guideline. Every sentence earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only operation with full schema coverage and no output schema, the description provides all needed context: what it does, what it returns (two links), safety guarantees, and when to use it. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all parameters including constraints and examples. The description adds the context that the tool checks whether the agent can borrow the specified amount for the specified days, but does not add parameter syntax beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (prepare/check) and resource (a borrow on a Priors agent's credit line), and clearly distinguishes itself from any true mutation by emphasizing it returns confirmation links rather than executing a borrow. It's easy to distinguish from request_repay and other siblings.

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

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

The description gives a clear usage condition: 'Use it when the user wants to borrow USDG for an agent they own.' However, it doesn't explicitly mention alternatives or when not to use it relative to siblings like request_repay.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, but the description adds crucial behavioral context beyond this: 'Nothing is repaid by this tool: no key, no transaction.' This sets accurate expectations about side effects and required inputs. It also details the two return links and their modes, which is not captured by annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core action (preparing repayment), followed by the return links and critical no-action disclaimer. Every sentence earns its place with no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description fully explains what the tool returns (two links for repayment) and clarifies that no transaction occurs, which is essential for correct invocation. It also covers the required agent_id via schema. The definition is complete for an agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents the single agent_id parameter thoroughly. The description does not add syntax or format details beyond what the schema provides, but its explanation of the overall flow implicitly reinforces the parameter's purpose. Baseline would be 3; the extra context about loan listing and repayment modes warrants a slight bump.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Prepare the repayment of a Priors agent's open loans') and clarifies it returns links rather than executing repayment. Distinguishes from the sibling request_borrow by being the repayment counterpart.

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

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

Explicitly states when to use it: 'Use it when the user wants to repay the loans of an agent they own.' It also gives clear alternatives for how to complete the repayment (Go mode vs Builder mode) with URLs and conditions.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description still adds meaningful context beyond them by disclosing the score range (0–1000), that the record includes a repayment history, and that the source is a public on-chain record that cannot be faked. It omits failure behavior (e.g., unknown agent_id) and any latency/rate-limit notes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short, front-loaded sentences with no filler; the core action and value proposition (credit score + repayment record) come first, followed by sibling differentiation and usage advice.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 burden of describing returns, and it does name both return elements (score range and repayment record) plus the read-only nature. It could go further on the shape of the repayment record or error cases, but it covers what an agent needs to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents agent_id including the ERC-8004 example value. The description adds no parameter-level detail, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Look up any agent's Priors score and repayment record') and names the data source (Robinhood Chain). It explicitly distinguishes itself from the sibling agent_record ('Shorter than agent_record'), so an agent can choose between them without opening either schema.

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

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

Gives a clear usage context ('Useful before trusting or paying an agent') and an implicit alternative comparison to agent_record for fuller records. It does not state explicit exclusions or the inverse condition for preferring agent_record, so it falls short of a 5.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the redundant 'Read-only' adds little. However, the description usefully discloses the non-obvious reasons a token may be excluded (sharp price move, split/multiplier change, paused or blocked token) and the freshness signal (Chainlink price age), which is real behavioral context beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence naming the resource, followed by an enumeration of returned fields and a short read-only note. The nested parenthetical about non-lendable reasons is dense but each clause carries information; nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description correctly compensates by enumerating the returned fields (price, age, lendability, reason, LTV). Combined with annotations covering the safety profile, an agent has everything needed to call and interpret this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With one parameter at 100% schema description coverage, the schema already documents the symbol filter ('One ticker, e.g. SPY. Omit for all.'). The description adds no format, matching, or error semantics for the parameter, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List the Robinhood stock tokens the Priors stock vault accepts as collateral'), plus the scope of returned data (price, age, lend status, LTV). It does not differentiate itself from the sibling stock_position, which an agent could plausibly confuse with a collateral-token listing.

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

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

Implied usage is clear: check which tokens are lendable right now. But there is no explicit when-to-use guidance, no statement of when to use the optional symbol filter versus omitting it, and no routing to or away from siblings like stock_position.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered (and the trailing 'Read-only' is redundant). The description adds genuine behavioral value by disclosing what the response surfaces - vault holdings, LTV, current draw capacity, pending lending hold, and closing state - which is important since no output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that lists the reads in a natural order from holdings to line state. It is dense but every clause conveys a distinct returned field; only the redundant 'Read-only' tail adds nothing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a single required parameter, no output schema, and annotations covering the safety profile, the description fills the main gap by enumerating what is returned. Sufficient for correct invocation, though it stops short of stating how fresh or chain-specific the values are and when a caller should prefer it over stock_assets.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with agent_id fully documented in the schema including the ERC-8004 hint and an example. The description adds no parameter-level detail, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Show') and a precisely scoped resource: the stock tokens behind a Priors agent's stock line on Robinhood Chain. The enumerated fields (token, amount, vault valuation, LTV, borrowRoom, lending hold, closing) let an agent distinguish it from siblings like stock_assets, request_borrow, and request_repay 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.

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

Implied read-only inspection context is clear, but there is no explicit when-to-use or when-not-to-use guidance and no mention of alternatives such as stock_assets for the underlying asset list or request_borrow for acting on borrowRoom. An agent must infer that this is the read counterpart to the borrow/repay siblings.

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