Hedgehood Options

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

With no annotations, the description carries the full burden and does substantial work: it discloses the approval 0.1% headroom rationale, the no-dust 'all' path, post-action HF/LTV in the response, the error-answer set, oracle independence, and that this server never signs or sends. It stops short of describing the exact returned object (to/value/gas) or any rate or gas constraints.

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?

Purpose is front-loaded in the first clause and every sentence carries real information about calldata shape, approvals, or outcomes. It is dense and parenthetical-heavy, which makes the 'when short' and approval-headroom clauses harder to parse than necessary.

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?

No output schema exists, so the description must fully describe the return value; it names HF/LTV and the error answers but not the actual payload fields (calldata, target address, whether approve and repay are one or two transactions). For a 3-parameter calldata-builder this leaves an agent guessing about the response shape.

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 0%, so the description must compensate. It explains the 'usdg' parameter well (amount vs 'all' semantics with no dust) and ties 'account' to the owner key, but the 'market' parameter and its null default are never explained, leaving one of three parameters undocumented in both schema and description.

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 the specific verb and resource up front: 'The unsigned calldata to repay USDG debt', followed by exactly what the calldata contains (approve + repay call shape). An agent can immediately tell this apart from the other borrow_* quote and status 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?

Usage is implied by the action name and by the enumerated terminal answers (nothing_to_repay, exceeds_debt, insufficient_balance), plus the note that the caller must send it with the owner key. However, it never says when to reach for this instead of borrow_status or how to sequence a status check before quoting.

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?

With no annotations, the description carries the full burden and does well: it explicitly declares 'Read-only; nothing is sent' and lists the returned market and position fields, including oracle status values (live / held / unavailable). It also warns that the market id is discovered at each call and that the mainnet market is being migrated to a new oracle. It does not cover authentication, error behavior, or freshness guarantees.

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 scope and purpose, then provides return fields and rules without filler. However, it is delivered as one very long semicolon-heavy sentence followed by two short sentences, which makes scanning harder than a bulleted or paragraph-structured form. Every clause carries content, so it earns most of its length.

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 and no annotations, so the description must explain return values and safety behavior; it does so comprehensively by listing market metrics and 'my' position values, plus otherPositions and market-selection semantics. It also states read-only behavior and the LTV/LLTV rule. The missing piece is a clear definition of the required 'account' parameter and any error/empty-state behavior.

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 0%, so the description must compensate. It explains the optional 'market' parameter meaningfully: positions on another market appear under otherPositions, and 'market' selects one; it also notes the market id is discovered at each call. The required 'account' parameter is never explicitly described, though 'my' fields imply it is the position owner's address.

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 resource and scope: Morpho Blue market status on the BORROW side, with collateral, debt, and market metrics. 'Share Lending, BORROW side' distinguishes it from the lending-side status tool, but it never explicitly contrasts itself with the many borrow_*_quote action tools. The verb is implicit ('status' in the name) rather than clearly stated as a read operation in the first phrase.

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: an agent can infer this is the read-only status check before borrow actions, reinforced by 'Read-only; nothing is sent.' The description does not say when to use this instead of borrow_take_quote, borrow_repay_quote, or lend_status, nor does it name alternatives. The market-selection note ('Positions left on another market show under otherPositions; market selects one') is useful but concerns parameters more than tool selection.

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?

With no annotations, the description carries the full burden and does so well: it discloses the exact call sequence (approve only when allowance is short, then supplyCollateral with 0x), that no oracle read occurs, the error code and its precise trigger, and that the response includes position before/after with HF and LTV. It also clarifies the trust boundary — the server never sends the transaction.

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?

Front-loads the purpose, then layers behavior, preconditions and the return shape in dense but purposeful clauses; nothing is filler. It is somewhat run-on with stacked parentheticals, which slightly hurts scanability.

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 3-param tool with no annotations and no output schema, the description covers return content (calldata plus before/after HF and LTV), error behavior and the sending model. The main remaining gap is the `market` parameter's meaning and default behavior when omitted.

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 0%, so the description must compensate and only partly does. `shares` is richly specified (decimal or 'all' of the wallet, fund shares, redemption-queue shares excluded) and `account` is implied as the owner-key holder, but the optional `market` parameter is never mentioned in the description at all.

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: produces unsigned calldata that posts `shares` fund shares as collateral via approve + supplyCollateral(marketParams, shares, account, 0x). That action is clearly distinct from sibling quote tools like borrow_withdraw_collateral_quote, borrow_repay_quote and borrow_take_quote, and it also makes clear this is a quote (calldata) rather than an execution.

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 the caller the operative context: the server never sends, so the caller must submit with the account's owner key, and it names the failure condition (insufficient_balance when the wallet holds fewer shares, with redemption-queue shares excluded). It does not explicitly route to alternatives such as borrow_withdraw_collateral_quote, so it stops 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.

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

No annotations are provided, so the description carries the full disclosure burden. It states that the result is unsigned calldata, that the server never sends it, that the account owner key must sign, and it enumerates refusal reasons plus an LTV warning threshold, giving the agent strong behavioral 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?

The description is front-loaded with purpose and then details. It is mostly efficient, though the embedded borrow(...) signature and dense refusal clause list make it slightly heavier than necessary.

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 tool with no annotations and no output schema, it covers the return shape (calldata, post-action HF/LTV, warning), refusal conditions, and the non-sending behavior. The main remaining gap is explicit routing among sibling quote tools and fuller parameter guidance.

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 0% schema description coverage, the description must define all three parameters, but it only alludes to usdg, account, and marketParams via the call signature. It does not explain the optional market parameter, its null default, or the expected units/format for usdg and account.

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 and resource: it produces unsigned calldata to borrow USDG against posted collateral, and even gives the contract call signature. This clearly distinguishes it from the repay, supply-collateral, withdraw-collateral, and generic quote 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?

It implies usage by describing a borrowing quote and lists refusal conditions such as oracle_stale, unhealthy, and insufficient_liquidity. However, it never explicitly says when to use this tool instead of borrow_repay_quote, get_quote, or borrow_status, and offers no direct when-not guidance.

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?

With no annotations the description must carry the behavioral burden, and it largely does: it discloses that only unsigned calldata is returned (the server never sends), enumerates refusal reasons (unhealthy, oracle_stale, insufficient_collateral), and explains oracle fail-closed semantics including the no-debt bypass. What remains underspecified is the exact return shape and how HF/LTV and the 70%-of-LLTV warning are emitted.

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 core action is front-loaded in the opening clause, and the subsequent refusal and warning details earn their place. The single long sentence stacking multiple refusal reasons is dense but not 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?

For a quote tool with no output schema, no annotations, and 0% parameter coverage, the description covers refusal behavior and oracle edge cases well but leaves the return payload structure and key parameter defaults unaddressed. An agent could invoke it but may not fully anticipate the response or the 'all' shares default.

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 0%, so the description is the only source of parameter meaning. It partially compensates by spelling out the withdrawCollateral signature (marketParams, shares, account, account), but this maps awkwardly onto the three schema params and leaves the 'shares' default of 'all' and the optional 'market' (default null) unexplained, risking confusion.

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 and resource: unsigned calldata for withdrawCollateral that takes fund shares back from Blue, naming the exact contract function and its arguments. It is clearly distinct from supply/repay siblings. It stops short of an explicit routing statement but the action is unambiguous.

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 gives useful workflow context ('You send it with the account's own owner key; this server never sends') and lists refusal conditions, which implicitly tells the agent when the call succeeds. However, it never states when to use this versus siblings like borrow_supply_collateral_quote or close_quote.

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?

With no annotations, the description carries the full burden and does so: it discloses that the server never sends, that the caller must sign and submit with their own key before validUntil, the exact sizing rule min(|position|, quantity or whole position), where the calldata lands (fill.send / fillOrderAs), and the two refusal modes (nothing_to_close, close_only:*). That is exactly the mutation/safety context the annotations would otherwise supply.

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 critical scoping clause comes first and every sentence adds information. It is dense but justified given the signing/refusal semantics; the inline parenthetical alternatives could be trimmed slightly but nothing is 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?

With no annotations and no output schema, the description still covers return shape (signed quote with fillOrderAs calldata in fill.send), submission responsibility, expiry, and failure modes. The only genuine hole is the undocumented session_key, which matters for actually calling 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 0%, so the description must compensate. It does well for `quantity` (defines the min() sizing and the whole-position default) and implicitly for `account`/`instrument`, but `session_key` is never mentioned anywhere, leaving one of four parameters fully undocumented.

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 first sentence gives a precise verb and resource: it produces a quote that closes (exits) an open position in a named instrument, and it spells out the sizing and side logic. That distinguishes it cleanly from the sibling get_quote (which opens/quotes generically) without needing to open 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?

It says clearly when to use it (to exit an open position before expiry) and when it is inapplicable (nothing_to_close when the account is flat). It also names the concrete send paths (`hedgehood close --send` or npm MCP's close_position), but it never contrasts with the sibling get_quote for the opposite intent, so an agent must infer the open-vs-close split.

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?

No annotations are provided, so the description carries the full behavioral-disclosure burden. It mentions that the result includes accounts seen trading under the agent, but it does not confirm read-only behavior, permissions, error cases, or response shape.

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 a single concise sentence fragment with no wasted words, but its structure is weak because it lacks an explicit action or front-loaded statement of purpose.

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 annotations and no output schema, the description should do more to explain the returned record, the meaning of the associated accounts, and any operational constraints. It gives a useful high-level summary but leaves meaningful gaps.

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 0%, and the single agent_id parameter is not documented in the schema. The description partly compensates by tying agent_id to the ERC-8004 Identity Registry and by noting the associated accounts, but it does not explain identifier format or constraints.

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 identifies the specific resource returned: an ERC-8004 Identity Registry record plus accounts seen trading under the agent id. It is clear enough to distinguish from the market/quote-oriented siblings, though it uses a noun phrase rather than an explicit verb.

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 guidance on when to use this tool versus alternatives, no exclusions, and no context about when an agent record lookup is appropriate. The description only states what the tool returns.

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?

With no annotations, the description carries the full burden and does well: it discloses ordering, included record types, key fields, the limit ceiling, since semantics, and that a summary is returned. It does not mention auth requirements, rate limits, or whether since is inclusive/exclusive, leaving some operational details implicit.

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 purpose, then compactly enumerates the returned activity and constraints. No sentence is wasted, and the sibling redirection is placed efficiently at the end.

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 or annotations, so the description appropriately describes the returned activity types and summary. It is nearly complete, but the account parameter format and some pagination semantics remain unspecified.

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 0%, so the description must compensate. It explains limit as at most 500 and since as unix seconds, but it does not explain the required account parameter at all, leaving one of three parameters semantically undocumented.

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 resource and scope: past account activity, newest first, including fills, settlements, redeems, and a summary. It also explicitly distinguishes the tool from get_positions, so an agent can identify it without opening the 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?

It establishes clear usage context by emphasizing PAST activity and explicitly redirecting open-position queries to get_positions. It does not discuss other potentially related siblings such as get_pnl, but the primary exclusion is 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?

With no annotations, the description carries the full burden, and it only partially does so: it discloses the returned metrics (fills, premium paid/received, settled PnL), which is genuinely useful. It says nothing about read-only semantics, whether data is public or account-scoped, result ordering behavior, or result volume — all relevant for a ranking tool.

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 compact sentence with the grouping dimension front-loaded and no filler. The telegraphic style borders on under-specification, but nothing is wasted.

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?

Three undocumented parameters, no annotations, and no output schema mean the description must do more than it does. It omits sorting/pagination semantics and default behavior, so an agent cannot confidently call it for anything beyond the default case.

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 0%, so the schema gives only bare titles. The description explains `by` for the 'agent' case and implies the account default, but `limit` and `order` — including the fact that order defaults to settledPnlRaw — are never mentioned. One of three parameters is clarified.

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?

It names the resource (leaderboard) and the two grouping dimensions (per account or per ERC-8004 agent id), plus the metrics surfaced (fills, premium paid/received, settled PnL). That is enough for an agent to see it is a ranking/aggregate view rather than a single-account report like get_pnl or get_positions. No explicit verb and no direct sibling callout keeps 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 pick this over get_pnl, get_positions, or get_history, and no prerequisites or exclusions. The only routing hint is the inline '(by=\'agent\')' parenthetical, which is parameter syntax, not usage guidance.

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?

With no annotations, the description carries the full burden. It usefully discloses that the output is a model rather than a live quote and lists the returned fields, but it does not state whether the operation is read-only, whether it has side effects, or what permissions are required.

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 a compact sentence plus a concrete example, with the output fields front-loaded and no wasted wording.

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 simple one-parameter read-like tool with no output schema, the description is nearly complete: it names the returned values and gives an instrument format example. The main missing context is explicit routing versus get_quote and read-only behavior.

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 0%, so the description must compensate for the single parameter. The example 'NVDA-20261016-200-C' adds meaningful format guidance that the empty schema does not provide.

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 clearly states that the tool models bid, ask, mid, delta, and quote availability for an instrument, which is more specific than restating the name. It does not explicitly distinguish itself from the sibling get_quote tool, so it stops short of 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?

The description gives no explicit guidance on when to use get_mark versus get_quote or other sibling tools. The implied use case is modeling a mark, but neither conditions nor alternatives are 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?

With no annotations, the description carries the burden and does well: it discloses units (USDG raw, 1e6), sign convention (signed from the account's side), which position states are included, and the cost/realized breakdown, plus the presence of a `summary` field. What it omits is whether the call is read-only/cheap, whether it needs auth, and how large the response can get for accounts with many positions.

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 sentence with the resource front-loaded and then the return contents, units and sign convention, all of which earn their place. Slightly run-on, 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 read tool with no output schema, no annotations and one parameter, the description explains the return payload and its units well enough to call and interpret it. The missing pieces are the account identifier format and any hint about cost/size of the response.

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 0% for the single `account` parameter, so the description should define the identifier format (address, account id, subaccount?) and does not. The parameter's meaning is at least obvious from context, so it is not a total gap, but it fails to compensate for the empty schema.

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 resource (PnL of an account) and enumerates exactly what is returned: every position in any state, mark, unrealized/realized PnL, fees, total, plus a summary line. It does not distinguish itself from the closest sibling, get_positions, leaving the agent to infer the difference.

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?

No statement of when to use this versus get_positions (which presumably returns the same positions without PnL) or get_history. Usage is only implied by the resource name; there are no exclusions or alternative routing.

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?

With no annotations the description carries full burden; 'get' plus 'ACTIVE positions' implies a read, and it describes the content returned (cost basis, leaderboard row, agent id). It says nothing about auth/prerequisites for the account, whether a zero-position account returns empty vs error, or freshness of marks.

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?

Front-loaded with the resource and scope, then three tight routing clauses; nothing is wasted. The telegraphic 'marks / PnL are get_pnl' phrasing is compressed nearly to the point of ambiguity but still parses.

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?

No output schema and no annotations, yet the description sketches the return content and disambiguates the neighborhood well. The remaining gap is the account parameter format and empty-result behavior, which an agent would want before calling.

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 0% for the single `account` parameter, so the description must compensate. It conveys that the account is the lookup subject and that its ERC-8004 agent id is surfaced, but never states the expected format (address vs agent id vs handle), which is the key ambiguity for this param.

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 resource and scope: 'ACTIVE positions: open positions, cost basis and leaderboard row of an account', plus the ERC-8004 agent id nuance. The 'ACTIVE' qualifier immediately separates it from the historical sibling get_history.

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 routes three related intents to alternatives: 'Past activity is get_history; marks / PnL are get_pnl; exit before expiry with close_quote.' The conditions selecting each sibling are named, not implied.

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?

With no annotations, the description carries the full burden and does well: it discloses that nothing is sent (no side effects), that the quote is time-limited (seconds), that it returns exact calldata rather than executing, and that a session_key triggers live TRADE-session, spendLeft and riskLeft checks. It doesn't state permission/auth prerequisites beyond the session-key case or describe error shapes beyond the close_only:* marker.

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?

No sentence is wasted, but it is a single dense run-on paragraph with nested parentheticals and inline backticks, making it hard to scan. The core quote/return facts are front-loaded, while the session-key parenthetical buries useful detail mid-sentence.

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 5-parameter, no-annotation, no-output-schema tool, the description covers what the tool is, what it returns, its safety profile (nothing sent) and its error routing. Only the parameter format details (quantity units, instrument format) and any auth preconditions remain underspecified.

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 0%, so the description must compensate, and it does for all five parameters: `side` is buy or sell, `quantity` is shares, `account` is the addressed owner, and `session_key` is optional and changes the validation performed. It doesn't clarify the string encoding of quantity (decimals/units) or what `instrument` identifiers look like, which are the main gaps.

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 and resource (a signed, fillable quote for `quantity` shares on an `instrument`) and enumerates what the caller gets back: calldata for fillOrderAs, fee, decay and a canFill preview. It also distinguishes the tool from the sibling `close_quote` in the same breath, so an agent can route 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?

It clearly frames the buy path and gives an explicit exclusion with a redirect: sells are close-only against a long `account` holds, otherwise you get close_only:* and should use `close_quote` instead. What's missing is any guidance on how this differs from the borrow_*/lend_*/vault_* quote siblings, but those are distinct domains an agent can infer from their names.

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?

With no annotations, the description carries the full behavioral burden and does well: it declares read-only behavior, a 48-hour lookback, newest-first ordering, and a row cap. It does not mention permissions or rate limits, so it stops short of the highest transparency level.

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 compact and front-loaded: the primary question (why refusals occurred) comes first, followed by returned fields and operational constraints. Every clause adds useful information with 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?

Given no output schema and no annotations, the description supplies the key return contents (code, reason, instrument, side, quantity, counts, remediation guidance), time scope, ordering, and limit behavior. An agent has enough to invoke and interpret the tool 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 0%, so the description must compensate, and it does: `taker` is identified as the caller's account, and `limit` is bounded at 500 rows. It does not explain the default limit of 50 or the exact taker identifier format, but the core semantics are covered.

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 resource and scope: refused quotes to the caller's account in the last 48 hours, with the exact fields returned. An agent can immediately tell this is a diagnostic refusal-history query, distinct from sibling quote and status tools.

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 diagnostic framing (why quotes were refused), but there is no explicit guidance on when to choose this over related tools or when not to use it. It lacks sibling routing or prerequisite 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?

With no annotations, the description still discloses key behavior: mainnet answers carry `onramp`, the human KYC/payment requirement, geographic restriction (not New York or Canada), and the testnet faucet/wallet path. It also explains `authorizeSession` maxShortRisk/maxSpend semantics, though it does not explicitly say the tool is read-only or describe failure behavior.

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 opening sentence front-loads the main purpose, but the description becomes a dense run-on with parentheticals and a session-key tangent. It is informative but not as tight as it could be.

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?

No output schema exists, and the description only partly explains the returned answer: it names `onramp` on mainnet and the faucet/wallet path on testnet, but leaves the direct deposit path and full return shape under-described. For a tool with two undocumented optional parameters, this is adequate but incomplete.

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 0%, so the description must compensate. It explains that `amount` is in USDG and ties `account` to the onramp delivery destination, but it does not document parameter formats, optionality, or how `amount` affects the returned instructions.

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 informational operation: how to fund a market balance with USDG via x402 and the direct deposit path, and it distinguishes mainnet vs testnet behavior. The scope is slightly muddied by adding session-key authorization, which is adjacent rather than core deposit instructions.

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 gives clear usage context: on mainnet, the onramp is for an agent that holds no USDG yet; on testnet it points to the faucet/wallet path. It does not explicitly state when not to use this tool or name an alternative, so it is not 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?

With no annotations, the description carries the full burden and does most of it: it discloses the operation is read-only, that the caller's own wallet sends the faucet call rather than the server, that the faucet pays a fixed amount once per cooldown, that next-draw-time is only returned "when readable", and that mainnet yields a not_on_mainnet error. It stops short of giving the actual cooldown duration or stating whether the balance/draw time is null when absent, so a small gap remains.

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?

Front-loads the two most decisive facts (TESTNET only, what is returned) and every clause carries information. It is dense and slightly run-on in the middle, with the onboarding chain and mainnet fallback packed into single sentences, but there is no filler to cut.

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 must describe returns, and it does: the faucet call fields (to, data), balance, next draw time, and the ordered onboarding steps. It also covers the failure mode on mainnet, leaving nothing an agent needs in order to call this 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 0% for the single optional `account` parameter, so the description must compensate. It partially does by framing the output as "the account's balance and next draw time", implying `account` selects whose balance/draw time is read, but it never says the parameter is optional or that it defaults to the caller's own address, leaving the default behavior to inference.

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 concrete verb+resource: it tells the agent how to obtain the test settlement token (TestUSD, hUSD-test) and enumerates exactly what the response contains (faucet call, balance, next draw time, onboarding steps). It also positions itself against the sibling how_to_deposit by naming the mainnet counterpart, so an agent can pick between them 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?

"TESTNET only" and "Mainnet answers not_on_mainnet (see how_to_deposit)" give an explicit when-to-use and an explicit when-not plus the alternative to use instead. The embedded onboarding chain (connect -> faucet -> deposit -> session key -> quote -> fill) further tells the agent where this sits in the workflow.

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?

With no annotations, the description carries the full burden and does most of it well: it discloses that the server never signs or broadcasts, that the caller must supply gas, that an approve is conditionally prepended when allowance is short, and it enumerates the failure reasons (cap_exceeded, insufficient_balance, paused, not_eligible). What is missing is explicit confirmation that nothing is mutated on the server side and whether preview values can go stale before broadcast.

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?

Front-loaded with the outcome (unsigned calldata for a lend deposit) and information-dense with no filler sentences. The single run-on construction with inline code tokens and parenthetical error lists is harder to parse than it needs to be, but almost every clause carries real signal.

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 must describe the return shape, and it does: `txs` ordered approve-then-deposit, plus share preview, APY estimate, and {error, reason} outcomes. Combined with the gas/keys note this is enough to invoke the tool correctly; the remaining gap is only the amount/address formatting of the two inputs.

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 0% and both parameters are bare strings, so the description must compensate. It partially does — 'account' is clarified as the owner whose key signs and whose balance is checked, and `usdg` appears inside deposit(usdg, account) — but it never clarifies whether `usdg` is a raw amount or a token identifier, nor the units/decimals or address format expected.

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?

It states a specific verb and resource (produce unsigned calldata to lend USDG into an ERC-4626 vault) and spells out what comes back: approve tx, deposit tx, share preview, APY estimate, and error codes. That is far more than a restated name, though it never names how it differs from close siblings like vault_deposit_quote or lend_withdraw_quote, leaving the agent to infer which quote tool targets which product.

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 by the 'quote' framing and by the operational note 'You send every tx with the account's own owner key … this server holds no keys and sends nothing.' There is no explicit statement of when to choose this over lend_withdraw_quote, vault_deposit_quote, or lend_status, and no prerequisites or exclusions are given.

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?

No annotations exist, so the description carries the full burden and does most of it: it states the tool is read-only ('nothing is sent'), discloses that deposits mint shares and earn immediately, that withdrawals depend on unborrowed liquidity, and that the supply APY is approximate and net of a 10% performance fee. Missing are auth/rate-limit behavior and any indication of how the APY approximation is derived.

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 well-ordered paragraph: side and instrument first, then enumerated return contents, then behavioral caveats (fee, liquidity, read-only, eligibility). Every clause carries information an agent would otherwise have to guess.

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 annotations, the description usefully enumerates what comes back (vault, total assets, cap and room, utilization, borrow rate, approximate APY, my position), which is the right burden to shoulder. Minor gap: no units or formatting for the numeric fields and no pagination/refresh semantics for 'live market' data.

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 single `account` parameter has 0% schema description coverage, so the description must compensate — and it does, defining `my` as 'the account's vault shares, their USDG value and its wallet USDG', which tells the agent the parameter is the account whose position is reported. It does not specify the expected address/identifier format.

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-and-resource framing: 'Share Lending, LEND side' plus a concrete scope list (vault, total assets, cap and room, utilization, borrow rate, supply APY, my position). It clearly separates the LEND side from the borrow_* siblings, but never distinguishes itself from the closely named vault_status sibling, so an agent could still hesitate between those two.

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 context is clear — it is a read-only status read, and the note that 'a withdrawal needs unborrowed liquidity' signals when the cap/room and utilization fields matter. It stops short of explicitly routing the agent (e.g., 'to preview a deposit use lend_deposit_quote'), and the 'Not for US persons' line is a eligibility caveat rather than a when-to-use rule.

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?

With no annotations, the description carries the full burden and does well: it declares the output is unsigned calldata, that the server never submits the transaction, that 'all' is exact with no dust, and what the two error codes mean. It stops short of stating the tool is a pure read/quote operation with no side effects, which would have closed the loop.

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?

Purpose is front-loaded in the first clause and every sentence adds information (mode selection, error codes, signing). The inline signature notations like withdraw(usdg, account, account) are slightly cryptic and the paragraph runs long, but there is 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 2-parameter quote tool with no annotations and no output schema, the description covers return form, mode branching, failure modes and signing responsibility. Remaining gaps are minor: the calldata target contract and whether any state is read or changed are left to inference.

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 0%, so the description must compensate, and it largely does: it defines 'all' as the default that triggers redeem(all shares) versus an explicit usdg amount, and frames account as the balance holder whose owner key signs. The account parameter's role is only implied via 'the account holds less' rather than defined outright.

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?

Opens with a specific verb+resource: 'The unsigned calldata to take lent USDG back', and immediately differentiates the two on-chain paths (withdraw(usdg,...) vs redeem(all shares,...)). An agent can tell this apart from lend_deposit_quote or lend_status without opening a 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 when each mode fires ('all' → redeem, otherwise withdraw) and enumerates the failure conditions (insufficient_balance, insufficient_liquidity) an agent should anticipate. It also states the signing requirement ('You send it with the account's own owner key; this server never sends'), though it never names a sibling such as lend_status for pre-checking balances.

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?

No annotations are provided, so the description carries the full burden. It hints at read-only listing and says the return includes on-chain ids, but it says nothing about whether unfiltered calls return all instruments, ordering, result size, or pagination — significant gaps for a list endpoint with zero annotation coverage.

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 compact sentences with the resource and return value front-loaded and the format detail second. Nothing is wasted, though the fragment style borders on terse under-specification.

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 annotations, no output schema, and 0% schema coverage, the description should do more: it omits the 'underlying' filter, default behavior when no filters are given, and any sense of return size or ordering.

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 0%, so the description must compensate. It does usefully specify the accepted expiry formats ('YYYYMMDD or unix seconds'), which the schema does not, but it never mentions the 'underlying' parameter at all, leaving one of two parameters undocumented.

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 the resource ('Instruments') and what is returned ('their on-chain ids'), and the parenthetical '(expiry x strike x call/put)' explains the instrument's identifying structure, which makes the object concrete. It doesn't differentiate from sibling list_markets, so it stops short of 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 explicit statement of when to call this versus list_markets or the quote tools, and no mention of whether filters are optional. Usage is only implied by the name and the mention of an expiry field.

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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read operation by listing fields but does not disclose permissions, pagination, ordering, rate limits, or response shape.

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 a single short line with no filler and the field list is front-loaded. However, its extreme terseness sacrifices clarity rather than achieving efficient completeness.

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 and no annotations, yet the description only names four fields without explaining their structure, ordering, or the overall response format. This leaves the agent without enough context to interpret the tool's output.

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 has zero parameters, so the baseline score is 4. There are no parameter semantics for the description to add beyond the empty schema.

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 is a noun phrase ('The option markets: underlying, addresses, version, open expiries') with no explicit verb, so it does not clearly state that this tool lists markets. It also gives no signal to distinguish it from sibling tools such as list_instruments.

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 guidance on when to use this tool versus alternatives like list_instruments or get_quote, and no conditions or exclusions are 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?

No annotations exist, so the description carries the full load and does substantial work: it declares 'Read-only; nothing is sent', notes NAV comes from the chain, and explains the queue behaviour (deposit queues, converts at the next epoch freeze up to a week later, redeemed in kind at a later freeze) and the deposit gate. Not a 5 because it says nothing about result size, pagination, or how many vaults come back.

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?

Front-loaded with the resource and its return contents, then the deposit/redeem timing model, then the explicit alternative. Dense but every clause adds information an agent would otherwise have to discover by calling the 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?

There is no output schema, so the description must describe the payload — and it does, naming the per-vault fields and the epoch sub-structure. Combined with the read-only declaration and the timing model, an agent has everything needed to call this and interpret the result.

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 and the schema is correspondingly empty, so there is nothing parameter-level for the description to compensate for. Baseline 4 applies; the field list in the description describes the response, not arguments.

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 (OptionVault v2 funds) and enumerates exactly what is returned: stock token, deposit cap/room, shares, NAV, epoch phase and deposit gate. What keeps it from a 5 is that it never separates itself from the close sibling vault_status, which by name also sounds like it reports vault state — an agent cannot tell from this text which one to call.

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 'passive weekly premium income held for weeks, not a trade ... use the options market for exposure you open and close in seconds' line gives a genuine when-not, but it distinguishes the vault product from options trading rather than this tool from its siblings (vault_status, vault_deposit_quote, vault_redeem_quote). Whether to call list_vaults first for discovery, or vault_status for a single vault, 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?

With no annotations, the description carries the full burden and does meaningful work: it declares the output is unsigned calldata, that the server never submits it, that the account's own owner key must sign, and it names the two return shapes (claim vs nothing_to_claim) plus the cutoff field. Missing only time-sensitivity/staleness of the quote and whether it is a pure read.

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 artifact, with no filler. Deductions only for the dense first sentence where the inline signature and stacked parentheses force a re-read.

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 and no annotations, so the description must cover everything, and it does explain the two response variants and the signing requirement. What remains unstated is precondition timing (when a redemption is claimable), parameter formats, and whether the quote can go stale — gaps an agent would likely hit in practice.

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 0% and both parameters are bare titles ('Vault', 'Account'). The description does add real meaning — `account` is the owner of the redemption and `vault` is the vault holding it — but it never specifies format (address vs id/symbol) or whether `account` must be the caller, so it only partially compensates for the coverage gap.

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 first sentence names a specific artifact (unsigned calldata) and a specific action (collecting what a redemption or refunded deposit in `vault` paid out for `account`), which is enough for an agent to distinguish this from vault_redeem_quote or vault_deposit_quote. The awkward inline `claim(account, account)` signature and the run-on parenthesis reduce crispness, but the resource and scope are clear.

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 gives one strong operational cue — 'You send it with the account's own owner key; this server never sends' — and indirectly signals this is a claim *after* a redemption. But it never states when to call this versus vault_status or vault_redeem_quote, nor what preconditions (matured/frozen redemption) select this tool over the alternatives.

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?

With no annotations, the description carries the full burden and does most of it: it discloses the two-step tx sequence (approve only when allowance is short, then requestDeposit), the non-instant settlement window (up to a week at cohort freeze), the checks performed (balance/cap/eligibility), and that the server holds no keys and sends nothing. It stops short of saying what happens when a check fails (error vs. field in response).

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?

Front-loaded with the purpose before the return payload, and the closing sentence about key custody is high-value. The single dense block is long and the mid-sentence list of returned artifacts is somewhat run-on, but each clause carries 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?

No output schema and no annotations, yet the description enumerates the response contents (approve + requestDeposit calldata, cohort epoch/cutoff, NAV share estimate, checks, cancelDeposit calldata). The remaining gap is parameter-level precision (usdg units, error semantics) for a 3-required-param quote 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?

Schema coverage is 0%, so the description must compensate. It does explain `vault` can be an address or a symbol like hhNVDA-CC and that `account` is the depositing account, but `usdg` is only described as 'USDG' — no units, decimals, or raw-vs-decimal convention — and account format is unspecified.

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?

Opens with a specific verb+resource: 'The unsigned calldata to deposit `usdg` USDG into `vault` ... for `account`'. It is clearly distinguished from siblings such as vault_redeem_quote, vault_claim_quote and vault_status by naming the exact operation (requestDeposit(0, usdg, account)) and the returned artifacts.

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 conveys the operating context well — the deposit is not instant, it prices at the cohort cutoff, and the caller must send txs with the owner key plus ETH for gas. But it never names an alternative sibling (e.g. vault_redeem_quote to exit, vault_status for balances) or states when NOT to call it, so routing is only implied.

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?

With no annotations, the description carries the full behavioral burden and does well: it discloses escrow, in-kind payout at the freeze NAV, the locked-epoch timing of up to a week, cancellation calldata, and the non-custodial signing requirement. It lacks some operational detail such as failure modes or post-freeze cancellation behavior, so it is strong but not exhaustive.

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 dense with useful information and front-loads the core purpose, but it is a long, awkward run-on sentence with unclear punctuation around `requestRedeem(...)`, the cohort timing, and the cancel calldata. The content earns its place, but the structure makes it harder to parse than necessary.

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?

Given no annotations and no output schema, the description provides substantial context: what calldata is produced, escrow and payout timing, the later claim step, and signing requirements. It could more explicitly describe the returned payload shape, but it is complete enough for an agent to understand the tool's role.

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 0%, so the description must compensate. It adds useful meaning for `shares` (decimal or 'all') and `account` (signed with the account's owner key), and maps them into `requestRedeem(shares, account)`, but `vault` remains largely underspecified beyond being the vault whose shares are redeemed.

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 clearly states that the tool returns unsigned calldata to redeem `shares` of a `vault` for an `account`, which is a specific verb-and-resource purpose. It also mentions the downstream `vault_claim_quote` step, helping distinguish it from sibling tools, though the fragmented phrasing slightly muddies whether it produces one calldata payload or several pieces of redemption-related 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?

The description provides clear usage context: shares enter escrow now and are later collected via `vault_claim_quote` when the cohort freezes, and the caller must send with the account's owner key because the server never sends. It does not explicitly state when not to use this tool or compare it to other redemption/cancel alternatives, but the sequencing guidance is strong.

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?

With no annotations, the description carries the full burden and does disclose meaningful behavior: frozen deposits affect credited/owed shares, pending requests have cohort epochs and cutoffs, and requests are never instant. It stops short of explicitly stating read-only safety, permissions, or error behavior, but the lifecycle context is substantial.

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 tool's purpose and then adds the lifecycle context in a second sentence. It is dense but appropriately sized for the complexity, though the first sentence is a long field list rather than tightly structured prose.

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?

Given no output schema, the description does a good job enumerating what the status returns and explaining the epoch/claim lifecycle. The main remaining gap is the account parameter format, plus no explicit note about permissions or invalid-account behavior.

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 single account parameter has 0% schema description coverage, so the description should compensate. It identifies the account as the subject whose standing is returned, but does not specify expected format (address, ID, etc.) or constraints.

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 that the tool returns an account's standing in every fund and names the key status fields it covers, so the resource and scope are clear. It does not explicitly distinguish itself from sibling quote tools such as vault_claim_quote or vault_deposit_quote, which keeps 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?

The description implies usage by explaining the request -> freeze/settlement -> claim cycle and the possible next steps (wait / claim / redeem). However, it never explicitly says when to call this instead of the quote or action tools, leaving alternatives to inference.

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