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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses that the tool returns an unsigned transaction (CBOR hex) for client-side signing, conveying that no on-chain submission occurs. It also explains the adjustment direction and the optional max-price update, which are meaningful behavioral details.

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 two sentences with no filler. The primary action is front-loaded, followed by optional behavior and a clear statement of the return value. Every sentence contributes useful 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 transaction-building tool with no annotations and no output schema, the description adequately covers the main inputs, optional parameters, and return format. It could further clarify whether max price numerator and denominator must be provided together, but the required UTxO identification fields are already defined in the schema.

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 input schema has 100% parameter description coverage, so the baseline is 3. The description adds minimal semantic value beyond the schema, mainly echoing the positive/negative adjustment behavior and optional numerator/denominator fields already documented in the 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 clearly states the specific action: adjusting the ADA amount in an existing ROB buy order, with direction semantics (positive/negative) and an optional max-price update. It clearly names the target resource (ROB buy order) and the verb (adjust), which distinguishes it from sibling tools like open_rob and cancel_rob.

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 clear context: use this tool when you want to change the ADA amount or max price of an existing ROB buy order. It does not explicitly name alternatives or exclusions, but the intended scenario is well implied by the action and required inputs.

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 provided, the description carries the behavioral disclosure burden. It explicitly discloses that the tool returns an unsigned transaction (CBOR hex) for client-side signing, which is a critical behavioral trait distinguishing it from an on-chain mutation. It does not disclose failure modes or prerequisites, but the 'existing account' qualifier and the return-format disclosure provide strong transparency for a transaction-builder 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?

Two sentences convey the purpose, direction convention, scope, and return format with no filler. The most important information (deposit/withdraw, existing account) is front-loaded, and every sentence 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?

Given the lack of annotations and output schema, the description provides the key missing context: the operation returns an unsigned CBOR transaction rather than executing on-chain. It also clarifies the scope to existing accounts. It could go further by explicitly routing users to create_sp_account for new accounts, but for a five-parameter tool with full schema documentation, the description is largely complete.

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 input schema already fully documents all five parameters. The description adds no parameter semantics beyond what the schema states; the positive/negative amount convention is already present in the schema's amount description. This matches the baseline of 3 for a fully covered 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 uses a specific verb phrase ('Deposit to or withdraw from') and a clear resource ('an existing stability pool account'), and it distinguishes the tool from siblings like create_sp_account and close_sp_account by emphasizing 'existing'. It also removes ambiguity about the direction of the operation via the positive/negative convention.

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 when to use the tool: it is for existing stability pool accounts, so it is not for opening or closing one. However, it does not explicitly name alternative tools such as create_sp_account or close_sp_account, and it gives no exclusions or conditions for when not to use it. The usage context is clear but only implied, not 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 provided, the description carries the full burden. It excellently discloses that the tool returns an 'unsigned transaction (CBOR hex) for client-side signing,' which is critical behavioral context indicating the operation is not automatically finalized. It could improve by noting this is a mutating blockchain transaction requiring fees.

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 consists of two highly efficient sentences. The first covers purpose and operation type; the second covers the critical return format. There is no redundancy or extraneous information—every word serves the agent's decision-making or invocation process.

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 the tool's complexity (Cardano blockchain staking) and lack of output schema, the description adequately compensates by specifying the CBOR hex return format. However, it omits mention of transaction fees, UTxO consumption behavior, or the specific prerequisite that the positionTxHash/outputIndex must reference an existing valid UTxO.

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%, establishing a baseline of 3. The description adds minimal semantic value beyond the schema, though it reinforces the 'add or remove' concept which aligns with the amount parameter's positive/negative logic. No additional parameter context (e.g., address format details) is provided.

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 the specific action ('Adjust'), resource ('existing INDY staking position'), and mechanism ('add or remove INDY'). It effectively distinguishes from siblings like 'open_staking_position' (creation) and 'close_staking_position' (termination) by emphasizing 'existing' and partial modification.

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 prerequisites by specifying 'existing' position, suggesting an open position must exist first. However, it lacks explicit guidance on when to use this versus 'close_staking_position' (e.g., whether removing 100% requires this tool or the close tool) and doesn't mention prerequisite validation.

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 present, so the description carries the full transparency burden. The verb 'Analyze' implies a read-only, non-destructive operation, and 'accounting for accrued interest' discloses a specific computational behavior that affects results. However, it does not explicitly state that no state is modified, nor mention permissions or output side effects, so it is only partially transparent.

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 sentence, about 14 words, front-loaded with the main purpose and ending with the important accrued-interest qualifier. No filler or 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?

The tool is simple (one parameter, no output schema), and the description correctly identifies the input and analytical scope. Yet it omits what the output looks like (e.g., risk score, per-CDP breakdown) and how to handle edge cases like an owner with no CDPs, so the agent is not fully prepared for 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?

The single parameter `owner` is already fully described in the input schema ('Owner payment key hash (56-char hex) or bech32 address'), giving 100% schema coverage. The description only restates that the analysis is 'for an owner' without adding new formatting or semantic details, 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 ('Analyze') and resource ('collateral ratios and liquidation risk of CDPs') for a given owner, with the additional qualifier 'accounting for accrued interest'. This distinguishes it from sibling tools like get_cdps_by_owner or get_all_cdps, which merely retrieve CDP data. No ambiguity about what the tool does.

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?

Does not provide any when-to-use guidance or name alternatives, such as get_cdps_by_owner or liquidate_cdp. The only usage signal is the description's inherent purpose, so an agent is left to infer when to select it over other CDP-related 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?

Discloses critical execution pattern: returns an 'unsigned transaction (CBOR hex) for client-side signing'. This compensates for lack of annotations by clarifying the tool builds but does not submit transactions. Missing details on side effects (what happens to the request state after annulment).

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, zero waste. Front-loaded with action ('Cancel'), followed by return value specification. Every word 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?

Adequate for a 3-parameter tool with no annotations: describes return format (compensating for missing output schema). However, lacks authorization context (who can annul?) and state transition details given this is a financial mutation operation.

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% (all 3 parameters have descriptions), establishing baseline 3. Description adds no parameter-specific semantics beyond what schema provides, but none needed given complete schema coverage.

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 'Cancel' + specific resource 'pending stability pool request' clearly identifies the operation. Distinguishes from siblings like 'process_sp_request' and 'cancel_rob' by explicitly scoping to stability pool requests.

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 explicit guidance on when to use this tool versus alternatives like 'process_sp_request'. Does not state prerequisites (e.g., request must be pending) or authorization requirements (e.g., must be request owner).

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 provided, the description carries the full burden of behavioral disclosure. It states that the tool burns iAssets, which signals a destructive effect on those assets, and explicitly clarifies that it only builds an unsigned transaction for client-side signing, meaning it does not submit or execute anything itself. This is meaningful behavioral context beyond the tool name and schema.

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 front-loaded sentence that conveys the core action, the purpose, the output format, and the signing flow with no filler. Every segment earns its place, and the most important differentiator ('unsigned transaction') is placed prominently.

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, but the description compensates by stating the return form: a CBOR hex unsigned transaction. It also makes clear that the transaction is for client-side signing, which is essential context for an agent deciding to invoke it. It is not fully exhaustive regarding error cases or prerequisite CDP state, but it is sufficiently complete for correct invocation given the parameter schemas.

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 80%, so the schema already documents all but one parameter. The description does not add new meaning to any parameter beyond what the schema provides. It reinforces that 'amount' and 'asset' relate to burning, but that is already evident from the schema and tool purpose, so the description adds minimal value here.

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 opens with a specific action and resource: 'Burn iAssets to reduce CDP debt'. It also adds the distinguishing behavioral detail that it 'builds an unsigned transaction (CBOR hex)' rather than executing an on-chain action. This clearly separates it from sibling CDP tools like deposit_cdp, withdraw_cdp, or redeem_cdp.

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 phrase 'to reduce CDP debt' implies the intended use case, and 'for client-side signing' indicates it is for off-chain transaction preparation. However, there is no explicit guidance on when not to use it or which alternative tool should be chosen instead, such as withdraw_cdp or redeem_cdp. The usage context is present but 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 provided, the description carries full burden and successfully discloses the critical behavioral trait that it returns an unsigned transaction (CBOR hex) requiring client-side signing rather than executing directly. It does not mention reversibility or fee implications.

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 with zero waste: first states the action, second discloses the return format and signing requirement. Perfectly front-loaded and appropriately sized.

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 adequately covers the return value (unsigned CBOR hex) and operation type. With 100% schema coverage, it provides sufficient context for a blockchain mutation tool, though explicit prerequisites would strengthen it further.

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% (all three parameters documented), establishing baseline 3. The description implies the need to identify a specific position but does not add parameter semantics beyond what the schema already 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 uses specific verb 'Cancel' with clear resource 'ROB position', clearly distinguishing it from sibling operations like adjust_rob, claim_rob, open_rob, and redeem_rob. The scope 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?

While the verb 'Cancel' implies usage for terminating positions, there is no explicit guidance on when to choose this over adjust_rob (modification) or redeem_rob (redemption), or prerequisites like ownership requirements.

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 provided, the description carries the full burden and does a solid job: it discloses that the tool produces an unsigned transaction in CBOR hex for client-side signing, which is critical behavioral information for an agent. It misses some details like prerequisites or failure modes, but the key non-obvious behavior is clearly stated.

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 concise sentences with no filler. The core action is front-loaded, and the important return behavior is included compactly without 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 simple 3-parameter cancellation tool with no output schema and no annotations, the description provides the essential context: what it cancels, what happens to funds, and the format of the returned transaction. It is slightly incomplete in not mentioning broadcasting requirements or prerequisite conditions, but it is sufficient for an agent to use 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 description coverage is 100%, so the schema already documents all three parameters (address, orderTxHash, orderOutputIndex) clearly. The description adds no parameter-specific nuance beyond the overall purpose, so the baseline of 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?

The description clearly states the action ('Cancel'), the resource ('an outstanding stableswap order'), and the effect ('reclaim funds'). The domain-specific resource name distinguishes it from sibling tools like cancel_rob, making the tool's identity 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?

The intended use is implied: use this when you have an outstanding stableswap order you want to cancel and reclaim funds. However, it offers no explicit when-to-use guidance, exclusions, or alternatives, relying on the tool's name and description to convey the context.

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 provided, description carries full burden. It successfully discloses the return format (unsigned CBOR hex transaction requiring client-side signing), which is critical for integration. However, it omits side effects (what state changes occur), failure modes, and whether the operation is idempotent.

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 with zero waste. First sentence states purpose; second states return value. Front-loaded and appropriately sized for the complexity.

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 description adequately compensates by specifying the unsigned transaction return format. However, lacks context on ROB lifecycle stage, error conditions, and relationship to the claiming protocol. Adequate but with clear 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 100%, providing detailed param semantics (bech32 format, UTxO references). Description adds minimal parameter context beyond the schema, mentioning 'ROB position' generally. Baseline 3 appropriate when 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 specific action (Claim) and target (received iAssets from an ROB position). Distinguishes from sibling ROB operations (open, adjust, cancel, redeem) by specifying the 'claim received assets' phase of the lifecycle. Does not expand 'ROB' acronym, though contextually clear among 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?

Provides no guidance on when to use this tool versus alternatives like redeem_rob or cancel_rob. Does not mention prerequisites (e.g., requiring an existing ROB position with claimable assets) or workflow sequencing.

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 provided, the description carries the full burden of behavioral disclosure. It does this well by clarifying that the tool does not submit the transaction but builds an unsigned CBOR-hex transaction for client-side signing, and that it reclaims collateral. It does not mention fees, prerequisites, or whether additional inputs are needed, but the key behavioral trait is disclosed.

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, front-loaded sentence that states the action first and then clarifies the important output format with a dash. There is no filler or redundant restatement of the tool name.

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, the description covers the essential context: what the operation does, what the user must provide at a high level, and what the tool returns (CBOR hex for signing). It does not explain details like repayment of full debt or stability fees, but these are secondary given the schema and clear operation name.

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 75%, and the asset parameter is fully constrained by an enum, so the schema already documents most parameter meaning. The description adds general context about CDPs and collateral but does not explain individual parameters 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 operation: 'Close a CDP and reclaim collateral', and names the exact deliverable: 'builds an unsigned transaction (CBOR hex)'. This clearly distinguishes it from related CDP siblings like liquidate_cdp, withdraw_cdp, and open_cdp.

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 explicit guidance is given about when to choose close_cdp versus alternatives such as redeem_cdp, liquidate_cdp, or close_sp_account. The intended use is implied by the name, but the description does not state conditions, exclusions, or context that would help an agent select it confidently.

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 provided, the description carries the full burden and successfully discloses critical behavioral traits: it specifies the operation returns an 'unsigned transaction (CBOR hex)' requiring 'client-side signing', indicating this is a write operation that doesn't execute immediately. It also clarifies that all iAssets are withdrawn. Minor gap: no mention of error conditions or idempotency.

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 consists of two efficiently constructed sentences with zero redundancy. It is front-loaded with the primary action and effect, followed by the return format specification. Every word 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?

Despite no output schema existing, the description adequately covers the return value (unsigned CBOR hex transaction). For a blockchain mutation tool with 3 well-documented parameters and no annotations, it provides sufficient context for invocation, though it could mention prerequisites like account ownership verification or request status requirements.

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%, documenting all three parameters (address, accountTxHash, accountOutputIndex). The description provides no additional parameter semantics beyond the schema (e.g., explaining the UTxO reference pattern or address ownership requirements), warranting the baseline score of 3 for high schema coverage.

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 the specific action ('Close a stability pool account'), the resource affected ('stability pool account'), and the outcome ('withdraw all deposited iAssets'). It effectively distinguishes from siblings like create_sp_account (inverse operation) and adjust_sp_account (modification vs termination).

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?

While the verb 'Close' implies terminal usage, the description lacks explicit guidance on when to use this versus adjust_sp_account (for partial withdrawals) or prerequisites (e.g., whether pending requests must be processed first). No alternative tools or exclusion criteria are mentioned.

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 provided, so description carries full burden. Valuably discloses return format ('unsigned transaction CBOR hex') and signing requirement ('client-side signing'), which is critical behavioral context not in schema. Could improve by mentioning transaction fees or irreversibility.

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, zero waste. Front-loaded with action and scope, followed by output format. Every word 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?

Compensates well for missing output schema by describing return value (unsigned CBOR hex). Parameters are fully documented via schema. Minor gap: could mention Cardano blockchain context or error conditions (e.g., position not found).

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% (all 3 params well-documented). Description adds no parameter-specific semantics beyond what's in schema, meeting baseline expectations when schema is comprehensive.

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 ('Close') + specific resource ('INDY staking position') + specific scope ('unstake all INDY'). The phrase 'unstake all' clearly distinguishes this from sibling 'adjust_staking_position' (partial changes) and 'open_staking_position' (creation).

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?

Provides clear context that this is for complete exit ('close', 'unstake all'), implicitly distinguishing it from partial adjustments. However, lacks explicit 'when-to-use' guidance naming the sibling alternative for partial unstaking.

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 provided, the description carries the behavioral disclosure burden. It transparently states that the tool builds an unsigned transaction (CBOR hex) for client-side signing, which is a critical behavioral trait—it does not submit anything on-chain directly. It could additionally mention prerequisites or that the signed transaction must be submitted separately, but the core non-submitting behavior is clear.

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 well-structured sentence front-loads the core action ('Batch-collect accrued interest') and then delivers the essential behavioral detail (unsigned transaction CBOR hex). Every phrase earns its place; there is no filler or 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?

The description is mostly complete for a moderately complex transaction-building tool: it explains the action, the inputs implied by the schema, and the output format (CBOR hex). Since there is no output schema, the note about unsigned CBOR helps, though it could go slightly further by clarifying that no on-chain submission or signing is performed by the tool itself. Overall it gives an agent enough context 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 coverage is 67%, with address and cdps described in the schema and asset covered by an enum. The description adds only general context like 'one or more' and 'accrued interest' but does not explain parameter-level semantics beyond what the schema already provides. This is roughly the baseline for partial schema coverage.

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 ('Batch-collect'), the resource ('accrued interest from CDP positions'), and the destination ('into the interest collector'). It also distinguishes this from related tools like distribute_interest by framing the direction of funds, and adds the key detail that it builds an unsigned transaction rather than performing a direct action.

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: when you want to batch-collect accrued interest from one or more CDPs. It implies the appropriate scenario but does not explicitly state when not to use it or mention alternatives such as distribute_interest. Still, the purpose is clear enough for an agent to decide when to invoke 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?

With no annotations, the description carries the full burden and it delivers a critical behavioral disclosure: the tool does not execute the account creation but 'returns an unsigned transaction (CBOR hex) for client-side signing.' This tells the agent the operation has no immediate on-chain effect. It omits failure modes (e.g., account already exists) and fee prerequisites, but the signing requirement is the most important behavior and is clearly disclosed.

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, zero filler. The main purpose is front-loaded and the critical return-behavior detail follows immediately. Both sentences earn their 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?

For a simple 3-parameter create tool with a fully documented schema and no output schema, the description covers the essentials: what it does, what it requires, and what it returns (unsigned CBOR transaction). The signing-flow disclosure compensates for the missing output schema. Minor gaps remain around post-signing steps and error conditions, but nothing an agent needs to invoke it correctly is absent.

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, asset, and amount, including units and the enum. The description adds modest context by framing asset/amount as the deposit that opens the account, but it does not enrich parameter meaning beyond the schema. 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?

The description uses a specific verb ('Create') tied to a distinct resource ('stability pool account') and the mechanism ('by depositing iAssets'). It clearly differentiates from siblings like close_sp_account, adjust_sp_account, and the get_sp_account_by_owner read tools, leaving no ambiguity about what this tool does.

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 verb and resource: use this when creating a new stability pool account. However, the description never explicitly states when not to use it or names alternatives such as adjust_sp_account for existing accounts. The guidance is inferred 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?

With no annotations, the description carries the behavioral disclosure burden. It usefully reveals that the tool returns an unsigned CBOR-hex transaction for client-side signing, which tells the agent the tool does not broadcast the transaction. It does not mention fees, side effects, or failure conditions, but the key output behavior is disclosed.

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 core action and immediately followed by the critical output behavior. Every phrase earns its place and there is no redundant 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?

The definition provides the essential call context: the action, the direction logic, and the return format since there is no output schema. It is slightly ambiguous whether 'Submit' means broadcast or construct, though the unsigned-transaction detail mostly clarifies this.

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 baseline is 3. The description repeats the minting direction already present in the schema and adds no new parameter-level detail 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 and resource: 'Submit a stableswap order', and clearly defines the two supported directions via the minting flag. This distinguishes it from related order tools like cancel_stableswap_order and other protocol 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?

The description gives clear directional usage by explaining minting=true for collateral-to-iAsset and minting=false for iAsset-to-collateral. It does not explicitly name alternatives or state when not to use this tool, so it stops 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?

With no annotations provided, the description carries the full burden. It clearly discloses that the tool builds an unsigned transaction and does not finalize or submit anything, since signing happens client-side. It could mention more about preconditions or side effects, but the core behavioral trait is well communicated.

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, tightly worded sentence with no wasted words. The main action is front-loaded, followed by the key output detail (unsigned CBOR hex), making it easy for an agent to parse quickly.

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 has 5 required parameters, no output schema, and no annotations, so the description needs to compensate. It explains the output format (CBOR hex) but does not clarify what the asset parameter represents, how the unsigned transaction should be delivered, or what prerequisites exist (e.g., the CDP must exist and belong to the address). This leaves notable gaps for an agent to safely invoke the 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 description coverage is 80%, so the baseline is 3. The description adds little beyond the schema: 'additional ADA collateral' reinforces the amount unit but does not clarify the meaning of the asset enum relative to the CDP, nor does it add detail beyond the existing descriptions for cdpTxHash and cdpOutputIndex.

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: 'Deposit additional ADA collateral into a CDP.' It further clarifies the exact nature of the tool by noting it 'builds an unsigned transaction (CBOR hex) for client-side signing,' which distinguishes it from other CDP operations like open_cdp, withdraw_cdp, or close_cdp.

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 phrase 'additional ADA collateral' implies the CDP already exists and this tool is for increasing collateral, which gives clear context for when to use it. It does not explicitly name alternatives or exclusion criteria, but the intended use case is reasonably clear from the wording.

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 explicitly discloses the non-executing nature: it 'builds an unsigned transaction (CBOR hex) for client-side signing,' preventing the misconception that funds move immediately. It also names the artifact format, though it doesn't cover every edge behavior or auth requirement.

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 entire definition is one focused sentence that front-loads the action and appends the critical output/output-mode qualifier. No filler or redundant restatement; every element 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?

For a 3-parameter transaction-builder with no annotations and no output schema, the description gives the core purpose, source, destination, and return artifact, which is enough to infer the basic call. However, it omits when to prefer this over the similar collect_interest sibling and does not fully specify the response shape beyond 'CBOR hex'.

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 all three parameters. The description adds only loose context—'collector UTxOs' maps to the hash/index arrays and the admin collector is the recipient—without introducing meaningful new syntax or relationships beyond the schema's 'same order' note.

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?

Description states a specific verb ('Distribute'), source ('collector UTxOs'), destination ('admin interest collector'), and key artifact ('unsigned transaction (CBOR hex)'). It doesn't explicitly contrast with the sibling collect_interest, but the core action and resource are 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?

Usage context is implied: call this when accumulated interest in non-admin collector UTxOs should be moved to the admin collector and the caller needs an unsigned transaction. There is no explicit when/when-not guidance or mention of alternatives such as get_collector_utxos or collect_interest.

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 provided, the description carries the full burden. It successfully discloses the return format (CBOR hex unsigned transaction) and permissionless access. However, it omits mutation details (whether collector UTxOs are consumed), fee implications, or idempotency characteristics that would help an agent predict side effects.

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 with zero waste: action definition, operational context, and return value specification. Information is front-loaded with the core verb, and each sentence provides distinct, non-redundant information essential for tool invocation.

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 the absence of annotations and output schema, the description adequately compensates by specifying the CBOR hex return format and signing requirements. For a blockchain transaction tool, it could be improved by mentioning fee responsibilities or transaction validity periods, but it covers the critical 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 100%, establishing a baseline of 3. The description adds domain context by mapping 'collectorTxHashes' to 'collector UTxOs' and implying the address parameter relates to staking positions, but does not add syntax constraints, validation rules, or format details beyond the 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 clearly states the specific action ('Distribute collected ADA rewards'), the source ('collector UTxOs'), and destination ('staking positions'). It distinguishes itself from sibling staking tools by framing this as a 'protocol maintenance operation' rather than a user position adjustment.

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 effectively signals the permissionless nature ('anyone can call') and critical output handling requirements ('unsigned transaction... for client-side signing'). However, it lacks explicit guidance on when to use this versus 'get_collector_utxos' or how to obtain the collectorTxHashes parameter values.

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 of behavioral disclosure. It transparently states that the tool builds an unsigned transaction (CBOR hex) rather than submitting it, and that owner-key signing is required. It also explains the fixed-at-deployment constraint of oracleBiasTime and oracleOwner.

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 sentences with no filler. The ADMIN/MAINTENANCE label is front-loaded, followed by the core action and the essential constraints. Every sentence 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?

For a 5-parameter admin tool with no output schema, the description covers the tool's purpose, input constraints, required signing context, and output form (unsigned CBOR hex). Minor details like submission/fee handling are outside the tool's direct scope and not necessary for correct invocation.

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 schema already documents 4 of 5 parameters, and the description adds critical context beyond the schema: oracleBiasTime and oracleOwner are fixed at deployment and must be supplied by the protocol admin, and newInterestRate uses a scaled integer encoding with a concrete example. This compensates for the undocumented asset enum.

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 ('Update'), a precise resource ('interest rate stored in an interest oracle UTxO'), and an explicit ADMIN/MAINTENANCE scope. This clearly distinguishes it from read-oriented siblings like get_interest_oracle and from feed_price_oracle, which targets price rather than interest.

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 clearly frames when the tool should be used: by protocol admins performing maintenance, and it notes the unsigned transaction must be signed by the oracle owner key. It implies that only admins with the owner key can validly invoke it, though it does not explicitly name alternative tools or exclusion 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 provided, the description carries the full behavioral burden and does so well: it discloses that the tool builds an unsigned transaction rather than signing or submitting one, and it explains the OracleNft-versus-Pyth distinction. It does not describe edge-case behavior or error conditions, but the core operational behavior is transparent.

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 two sentences with no filler. It front-loads the primary action, immediately states the output format, and then gives the critical applicability constraint. Every clause 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?

For a mutating/administrative tool with no output schema, the description sufficiently explains the output (CBOR hex), the intended signer, and the eligibility constraint. It could add a bit more detail on how the result is returned or what makes an asset OracleNft-backed, but the essential information for correct invocation is present.

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 input schema already describes address, priceNumerator, and priceDenominator, and the asset enum is self-evident from its values. The description does not add parameter-specific meaning beyond the schema, which is acceptable given 75% schema coverage, but it also does not provide extra guidance such as the relationship between numerator and denominator.

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 action ('Feed a new price'), identifies the precise resource ('OracleNft-backed price oracle'), and clarifies what the tool produces ('an unsigned transaction (CBOR hex) for admin signing'). It also differentiates itself from Pyth-priced assets, making the tool's scope unambiguous relative to its 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 explicitly defines when the tool applies ('Only applicable to assets whose priceInfo is OracleNft') and when it should not be used ('Pyth-priced assets are updated via signed Pyth messages, not this tool'). It also signals the intended workflow by mentioning admin signing, giving an agent clear selection and invocation context.

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 discloses the most important trait: the tool does not execute the freeze itself but produces an unsigned CBOR-hex transaction for client-side signing, which meaningfully shapes agent expectations about side effects. However, it omits preconditions (CDP must exist and be unfrozen), what occurs once the signed transaction is submitted, and any failure or validation 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?

A single sentence that front-loads the operation and consequence, then appends the crucial delivery detail (unsigned CBOR hex) after an em dash. No filler words; every element contributes either to what the tool does or how it behaves.

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 must supply safety, return, and workflow context on its own. It provides the return format at a high level (CBOR hex) and the signing workflow, but stops short of validation behavior, error cases, preconditions, and the full response shape. For a state-affecting operation on a Cardano CDP, a single sentence is adequate but leaves identifiable 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?

The schema already describes 3 of 4 parameters (address, cdpTxHash, cdpOutputIndex), so the description adds little parameter-level meaning beyond signaling that they identify the target CDP. The one parameter without schema coverage, 'asset', is equally unexplained in the description — nothing clarifies that it selects the CDP's denomination from the enum values. Near the 80% coverage baseline, the description neither compensates nor detracts.

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 ('Freeze'), resource ('a CDP'), and outcome ('prevent further operations until unfrozen'). Among the 60+ siblings, no other tool is a freeze operation, so it is plainly distinct from close_cdp, liquidate_cdp, and merge_cdps. The em-dash clause ('builds an unsigned transaction (CBOR hex) for client-side signing') makes the purpose fully 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?

The purpose clause 'to prevent further operations until unfrozen' implies the condition for use, and 'for client-side signing' implies a multi-step signing workflow. However, there is no explicit statement of when not to use it or which alternatives apply — for permanent termination, close_cdp, liquidate_cdp, and redeem_cdp all exist in the sibling list and are never distinguished from a temporary freeze. Guidance is implied, not 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 provided, so description carries full disclosure burden. States 'current' implying real-time data but fails to specify data source (oracle, DEX, aggregator), staleness tolerance, error conditions (e.g., oracle failure), or confirmation that this is read-only.

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?

Seven words with zero redundancy. Immediately front-loaded with action and subject. No filler or unnecessary elaboration.

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?

Minimally adequate for a zero-parameter tool, but lacks critical financial context: return value structure (number, string, object?), precision/decimals, and whether the price includes fees or is spot. Absence of output schema and annotations leaves significant gaps for a price oracle.

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?

Tool accepts zero parameters (empty schema), establishing baseline of 4. Description correctly implies a simple configuration-free getter requiring no inputs, consistent with the 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?

Clear verb ('Get') and resource ('ADA price') with specific currency (USD). Unambiguously identifies the target cryptocurrency, distinguishing it from siblings like get_indy_price and generic get_asset_price, though it doesn't explicitly clarify the Cardano context or protocol source.

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?

Provides no guidance on when to use this specific tool versus the generic get_asset_price (which could theoretically fetch ADA) or get_indy_price. No mention of caching, rate limits, or prerequisites for accurate price data.

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 alone must disclose behavior. 'Get all CDPs' implies a read-only query, but it does not mention pagination even though the schema includes limit/offset, nor does it describe the response shape or potential scale/cost of fetching all CDPs. No contradiction exists, but meaningful behavioral context is missing.

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 conveys the core operation and its main optional modifier with no filler. It is concise without being a tautology.

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 low tool complexity, the description is incomplete for a paginated getter with no output schema and no annotations. The claim 'Get all CDPs' is at odds with the limit/offset parameters (default limit 50, max 500), and no guidance is given about response format or distinguishing this from sibling getters. An agent could easily mistake this for returning every CDP in one call.

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 description adds the meaning that the asset parameter is an optional iAsset filter, which is useful. However, schema description coverage is 0% and the description does not explain limit/offset or the implications of 'all' combined with pagination, so it only partially compensates for the lack of parameter documentation.

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 uses a specific verb and resource ('Get all CDPs') and adds an optional filter by iAsset, making the tool's scope clear. It also distinguishes this from sibling owner/address-specific getters like get_cdps_by_owner and get_cdps_by_address.

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 a use case: list all CDPs rather than CDPs for a specific owner/address, and optionally filter by asset. However, it does not explicitly state when to prefer this over get_cdps_by_owner or get_cdps_by_address, leaving routing mostly 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?

No annotations are provided, yet the description adds no behavioral context beyond the basic read operation. Does not disclose whether data is cached or real-time, error handling for invalid keys, or idempotency characteristics.

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?

Extremely brief with zero redundant words or filler. However, the brevity borders on underspecification given the lack of output schema and the need to distinguish from similar tools.

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?

Critical gaps remain: no output schema exists, yet the description fails to indicate return value structure or type. Also omits relationship to sibling APR tools and domain-specific context (stability pools vs staking).

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 100% schema description coverage including specific examples (sp_iUSD_indy, stake_ada), the schema carries the semantic burden. The description mentions 'key' but adds no additional meaning regarding format, validation rules, or key taxonomy 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?

States the basic action (getting APR by key) but offers no domain context about what APR represents or what the key signifies. Fails to differentiate from sibling tool 'get_apr_rewards'. Marginally expands the function name but remains generically vague.

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?

Provides no guidance on when to use this tool versus the related 'get_apr_rewards', nor does it indicate prerequisites for the key parameter or valid usage contexts. No alternatives or exclusions mentioned.

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 full disclosure burden. It fails to explain what data the records contain, pagination behavior, freshness of APR data, or performance implications of retrieving 'all' records.

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?

Extremely brief at four words, and front-loaded with the action. While appropriately sized for a parameter-less tool, the brevity leaves behavioral questions unanswered given the lack of annotations or output schema.

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 this is a read operation in a complex DeFi protocol ecosystem (with CDPs, staking, and stability pools), the description is insufficient. It lacks explanation of what constitutes an 'APR reward record' and omits return value details since 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?

The input schema has zero parameters, which per guidelines sets a baseline of 4. With no parameters to describe, the description meets the minimum requirement but cannot score higher without parameter context to enrich.

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 (Get) and resource (APR reward records) with scope (all). However, it fails to distinguish from sibling tool 'get_apr_by_key', which likely retrieves specific records rather than all records.

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?

Provides no guidance on when to use this tool versus alternatives. Should explicitly mention using 'get_apr_by_key' when looking up specific reward records, as opposed to fetching the complete list.

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 disclosure burden. The verb 'Get' clearly indicates a non-destructive read operation, which is useful and accurate. However, it does not disclose what the returned 'details' contain, whether the data is live or cached, or how failures (e.g. an invalid or unlisted asset) behave. This is adequate for a simple read but not rich.

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, front-loaded sentence with no filler or redundant restatement. Every word contributes to identifying the operation without requiring the reader to parse extra context.

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-parameter read tool with an enum, the description is minimally sufficient to invoke it: the agent knows it needs to supply one of the listed iAssets. However, there is no output schema and no annotations, so the description should clarify exactly what 'details' means and how the response differs from get_asset_price. That missing context prevents the definition from being fully complete.

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 the context that the asset is an 'Indigo iAsset', tying the enum values to the protocol's asset family. The enum values (e.g. iUSD, iBTC) are already self-explanatory, and the single parameter is constrained, so the lack of deeper parameter explanation is not severely damaging. Still, the description does not explain what each value represents or how the parameter maps to the returned details.

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 concrete action ('Get details') and a concrete resource ('a specific Indigo iAsset'). It also sets scope via 'specific', which helps separate it from the plural sibling get_assets. However, it does not explicitly contrast itself with get_asset_price or explain whether 'details' includes price, so the distinction is clear but not fully spelled out.

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 usage guidance is provided. The description does not say when to choose this tool over get_assets, get_asset_price, or the broader family of read-only asset tools. An agent must infer when this is the right tool from the name and one-line description alone.

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 provided, the description carries the full burden. The verb 'Get' honestly signals a read-only operation, and 'current' plus 'per collateral asset' convey that the result is a fresh, multi-entry price set rather than a single number. However, it does not disclose the return shape, units, freshness guarantees, or behavior for unsupported assets, though the absence of those is less critical for a simple getter.

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 15-word sentence that front-loads the verb and resource, states the key scoping constraint, and contains zero filler or repetition of the tool name. Every clause 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?

For a one-parameter getter with no output schema and no annotations, the description conveys the core operation and the conceptual return ('price(s) per collateral asset') but stops short of describing the response structure. Since there is no output schema to fill that gap, an agent cannot fully anticipate whether the result is a map, a list, or a nested object — a notable but modest omission for such a simple 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 description coverage is 0%, so the description must compensate, and it partially does: 'for a specific Indigo iAsset' gives semantic meaning to the bare enum values (iUSD, iBTC, etc.) in the schema. However, it never names the 'asset' parameter explicitly, leaves 'ADA and others' vague about which collateral assets are valid, and does not clarify what the output looks like for each collateral asset.

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 uses a specific verb ('Get') with a precise resource ('current price(s) for a specific Indigo iAsset') and a distinctive scoping detail ('per collateral asset (ADA and others)'). This clearly differentiates it from price-related siblings like get_ada_price, get_indy_price, get_oracle_price, and get_pyth_price, which target different assets or price-feed sources.

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 use this tool versus alternatives such as get_oracle_price, get_pyth_price, get_ada_price, or get_indy_price. Given over 70 siblings including several price-fetching tools, the lack of any exclusion or alternative routing leaves the agent to infer selection purely from the tool name and the phrase 'Indigo iAsset'.

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 of behavioral disclosure. It communicates a read-only getter that returns all assets and their prices, but it does not disclose return format, pagination, ordering, or whether prices are current snapshots. For a zero-parameter read operation, the basic behavior is clear, but richer context is absent.

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 sentence with no filler. The verb, resource, scope, and key data element are all front-loaded, and every word 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?

For a simple zero-parameter read-only tool with no output schema, the description names the resource, scope, and included data, which is nearly sufficient to call correctly. A small gap remains: it does not describe the return shape or any enumeration limits, and since no output schema exists, slightly more detail would make it fully self-contained.

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 there is no semantic burden for the description to carry. The baseline of 4 applies because the input schema already communicates that no arguments are needed.

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 uses a specific verb ('Get'), identifies a concrete resource ('Indigo iAssets'), and specifies scope ('all') plus included data ('with their prices'). This clearly differentiates it from sibling tools like get_asset (single asset) and get_asset_price (price lookup) without requiring schema inspection.

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 'all' qualifier implies this tool is for retrieving the complete set of iAssets with prices, and the contrast with singular get_asset/get_asset_price hints at the boundary. However, it never explicitly states when to prefer this over alternatives or when not to use it, such as when only one asset's price is needed.

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 provided, the description carries the full burden of behavioral disclosure. While it mentions 'via Blockfrost' indicating an external API dependency, it fails to disclose critical behaviors such as rate limiting, authentication requirements, error handling, or what the return structure contains.

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, efficient sentence with no redundant words. It is appropriately front-loaded with the verb and immediately identifies the resource and method.

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-parameter tool, the description covers the basic invocation requirements. However, given the lack of output schema and annotations, it could be improved by describing the expected return value (e.g., 'returns a list of assets including ADA and native tokens').

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 input schema has 100% description coverage ('Cardano bech32 address'), so the schema adequately documents the parameter. The description adds no additional semantic context beyond the schema, meeting the baseline expectation for well-documented schemas.

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 the action ('Get'), resource ('token balances'), and scope ('for a Cardano address via Blockfrost'). However, it doesn't explicitly differentiate from sibling tools like 'get_assets' or clarify whether this retrieves all native assets or just ADA, preventing a perfect score.

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 no guidance on when to use this tool versus alternatives. Given the numerous sibling 'get' tools (get_assets, get_cdps_by_address, etc.), it fails to specify that this is for general blockchain balances versus protocol-specific positions.

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 of behavioral disclosure. It conveys a read operation through 'Get all', but does not mention pagination, empty result behavior, invalid address handling, or network implications. This is minimal disclosure for a tool with no annotation support.

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 sentence with no filler, front-loading the action ('Get all CDPs') and then narrowing the scope. Every word contributes meaning, making it highly efficient.

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 one-parameter read tool with no output schema, the description states the core operation adequately. However, it does not describe the return format, whether multiple results are paginated, or how edge cases are handled, so it is minimally viable but not rich.

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%; the schema already documents 'address' as a Cardano bech32 address with addr1... or addr_test1... examples. The description adds no additional parameter meaning beyond what the schema provides, 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?

The description states a clear verb ('Get'), resource ('all CDPs'), and scope ('specific Cardano address'). It is distinguishable from 'get_all_cdps' (no filter) and 'get_cdps_by_owner' (filter by owner), though it does not explicitly name these 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?

No guidance is given on when to use this tool versus alternatives like 'get_cdps_by_owner' or 'get_all_cdps'. The description only implies the address filter and does not provide exclusions or conditions for selecting this tool.

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 provided, the description carries the full burden. 'Get all CDPs' implies a read-only query, and the accepted input forms are disclosed, but the description does not explicitly state that no state is changed, nor does it describe output shape, error behavior, or any rate/authorization 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?

The description is a single, efficient sentence that front-loads the action and resource, then adds the key input format constraint in a parenthetical. There is 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 single-parameter getter, the description covers the input and purpose adequately. However, with no annotations and no output schema, it leaves the return shape and safety profile implicit, and it does not clarify how this tool relates to get_cdps_by_address or get_all_cdps.

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 input schema already fully describes the owner parameter with 100% coverage, including both accepted formats. The description essentially restates the schema rather than adding new semantic detail, which meets the baseline for high schema coverage.

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 identifies a specific verb ('Get'), a resource ('all CDPs'), and a filtering scope ('for a specific owner'). It is unambiguous about what the tool returns, though it does not explicitly differentiate itself from the sibling tool get_cdps_by_address, which could overlap since 'owner' accepts a bech32 address.

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 phrase 'for a specific owner' implies when to use this tool, but the description gives no explicit guidance about alternatives such as get_all_cdps or get_cdps_by_address. There are no when-not-to-use conditions or exclusions.

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 provided, so description carries full burden. 'Get' implies read-only but doesn't confirm lack of side effects. 'Fee distribution' provides domain context but description omits auth requirements, error conditions (e.g., no collector found), or whether results are cached.

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?

Single sentence, six words with zero redundancy. However, extreme brevity sacrifices necessary behavioral context for a domain-specific concept (collector UTXOs). Appropriately front-loaded but undersized for complexity.

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?

Adequate for a single-parameter getter with no output schema. 'Fee distribution' contextualizes the 'collector' concept within this DeFi protocol, though domain jargon remains unexplained. Minimum viable for intended use.

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 has 100% description coverage ('Maximum number of UTXOs to return'), establishing baseline 3. Description doesn't mention parameters, but none are required and the schema fully documents the optional 'length' parameter semantics.

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?

Uses specific verb 'Get' with resource 'collector UTXOs' and context 'for fee distribution'. The mention of 'collector' and 'fee distribution' distinguishes this from sibling getters like get_assets or get_blockfrost_balances, though it doesn't explicitly contrast with them.

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?

Provides no guidance on when to use this tool versus alternatives (e.g., get_blockfrost_balances), no prerequisites mentioned, and no indication of whether this should be called before distribute_staking_rewards or similar operations.

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 provided, the description carries the full burden of behavioral disclosure but only implies read-only safety through the word 'Get'. It fails to specify which DEX(s) are queried (IRIS, SteelSwap, or both), whether data is real-time or cached, what 'yields' specifically represents (APR, APY, claimable tokens), or any rate limiting concerns.

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, efficient sentence of seven words with no redundancy or filler. It leads with the action verb and maintains tight focus, though the extreme brevity comes at the cost of necessary context given the complex DeFi domain.

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 the complex DeFi domain (farming yields, iAssets) and the absence of both an output schema and annotations, the description is insufficiently complete. It should specify the return structure, which DEX platforms are covered, and what yield metrics (annualized rates, reward tokens) are returned.

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 input schema contains zero parameters, which establishes a baseline score of 4 according to the evaluation rubric. With no arguments to document, there are no semantic gaps to fill between the description and 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 provides a clear verb ('Get') and resource ('DEX farm yields'), and narrows scope with 'for iAsset pairs' indicating specific yield data for Indigo synthetic asset liquidity pools. It distinguishes from sibling CDP, staking, and basic price tools, though it could better differentiate from related yield tools like 'get_apr_by_key' or 'get_iris_liquidity_pools'.

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 offers no guidance on when to use this tool versus alternatives such as 'get_apr_rewards' or 'get_iris_liquidity_pools'. It lacks prerequisites, filtering guidance (it returns all iAsset pairs), or conditions when this data source is preferred.

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 of behavioral disclosure. It only specifies 'current' (implying real-time data), but fails to disclose if the operation is read-only, if it requires authentication, rate limits, or the return data structure.

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 efficient sentence with no redundant words. Every term ('current', 'INDY token', 'ADA and USD') contributes essential information about the tool's function.

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 zero-parameter tool of low complexity, the description adequately conveys the core functionality. While an output schema would improve completeness, the description is sufficient for an agent to understand what data (INDY price in two currencies) will be returned.

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 input schema contains zero parameters. According to the rubric, zero parameters establishes a baseline score of 4, as there are no parameter semantics to clarify beyond what the schema (empty object) already indicates.

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 explicitly states the action ('Get'), resource ('INDY token price'), and scope ('in ADA and USD'). It clearly distinguishes this tool from siblings like 'get_asset_price' or 'get_ada_price' by specifying the INDY token specifically.

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?

While the specific naming implies usage (when you need INDY specifically), the description lacks explicit guidance on when to use this versus the generic 'get_asset_price' sibling or what prerequisites might exist for accessing this data.

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 provided, the description carries the full behavioral disclosure burden. It explicitly identifies the operation as a read ('Read the current...') and discloses what the caller will receive, including on-chain rate, accumulator, and timestamp. It does not mention failure modes or side effects, but for a read-only state query the key behavioral trait is clearly conveyed.

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, efficient sentence that front-loads the action and resource, then lists the returned fields. Every phrase earns its place and there is no redundant or boilerplate 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?

For a one-parameter read-only tool with no output schema, this description is sufficiently complete. It names the entity being queried, the accepted parameter scope, and the exact return fields. The annotation and schema gap are adequately covered because the description communicates the essential invocation context and expected 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 single 'asset' parameter is not described in the schema, and the description only says 'for an asset' without elaborating on valid values. However, the schema provides an explicit enum of asset identifiers, which makes the allowed inputs self-documenting. The description adds marginal meaning by indicating the resulting state is asset-specific, but it does not substantially compensate for the lack of schema description coverage.

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 precise verb ('Read') and a specific resource ('interest oracle state for an asset'), and enumerates the exact data returned: interest rate, unitary interest accumulator, and last-updated timestamp. This clearly distinguishes it from sibling tools like feed_interest_oracle, which writes oracle state, or get_oracle_price, which reads price 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 read-only nature of the tool is clear from 'Read the current interest oracle state,' so an agent can infer when to call it. However, it does not explicitly mention alternatives or state when not to use it, such as pointing to feed_interest_oracle for updating the oracle or get_oracle_price for price queries. The usage guidance is implied rather than explicit.

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. While 'Get' implies read-only access, the description fails to disclose return value structure (critical since no output schema exists), pagination behavior, rate limits, or authentication requirements. It also does not explain what Iris represents.

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, efficient sentence with no wasted words. It front-loads the primary action ('Get liquidity pools from Iris') and appends the filtering capability, making it easy to scan and understand immediately.

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 three-parameter tool with simple string inputs, the description is minimally adequate. However, the lack of an output schema creates a significant gap—the description should ideally describe what data structure is returned (e.g., pool volumes, token pairs, APRs) to help the agent validate results.

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 100% schema description coverage, the baseline is 3. The description maps 'tokens' to tokenA/tokenB and 'DEX' to the dex parameter, providing minimal semantic grouping, but adds no additional syntax details, example values, or clarification on whether token identifiers are symbols, IDs, or addresses.

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 the verb (Get), resource (liquidity pools), and source (Iris). It distinguishes from siblings like get_dex_yields and get_steelswap_tokens by specifying the Iris source. However, it assumes the user knows what Iris is (likely a DEX/protocol in this domain) without clarifying.

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 phrase 'optionally filtered by tokens or DEX' implies the parameters are optional and indicates their purpose, but it provides no explicit guidance on when to use this tool versus similar data retrieval tools like get_dex_yields or get_order_book, nor does it mention prerequisites like token identifier formats.

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 provided, the description carries the full burden of behavioral disclosure. It discloses that OracleNft reads the oracle UTxO datum, Delisted assets return the delisted price, and Pyth/DeferredValidation delegates to get_pyth_price. This is rich behavioral context beyond what the schema shows, though it does not mention error cases or return format.

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 two tightly written sentences. The core purpose is front-loaded, and the parenthetical breakdown of oracle modes adds detail without bloat. Every clause contributes useful 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?

The tool is simple: one enum parameter and no output schema. The description covers the main action plus the important edge cases and delegation path. The missing return format or decimal precision is a minor gap for a price-query tool, but the description is otherwise complete enough for correct invocation.

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 the term 'iAsset' to clarify what the 'asset' parameter refers to, and the enum values are self-explanatory. However, it does not provide parameter-specific details such as units, decimals, or behavior differences across the enum values, so compensation is only partial.

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 the verb ('Get'), the resource ('on-chain price for an iAsset from its price oracle'), and the three handled oracle modes. It differentiates itself from siblings like get_pyth_price by explaining its broader delegation behavior and from get_asset_price by scoping to iAssets.

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: use this tool to retrieve iAsset prices from their oracle, including special handling for Delisted and delegation to get_pyth_price. It does not explicitly state when NOT to use it or name alternatives, but the oracle-specific framing is enough to guide correct selection among the many sibling 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does clarify that only 'open' positions are returned and that filtering is optional, which is useful. However, it does not state whether the operation is read-only, how filters combine, what the response shape is, or whether unfiltered calls return all 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?

The description is a single, front-loaded sentence with no filler words. It conveys the core purpose and optional filters efficiently. It is appropriately sized for a simple read tool, though it could have added a bit more behavioral context without becoming bloated.

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 low-complexity read tool with two optional parameters, the description covers the basic purpose and filter dimensions. However, with no annotations and no output schema, the description does not fully round out the call contract: the return type, read-only guarantee, and filter behavior are missing, so an agent has to infer too much.

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 meaning by mapping 'asset' to the iAsset filter and 'owners' to the owners filter, and by indicating both are optional. However, it does not explain owner address format, matching semantics, or how the two filters interact, leaving significant ambiguity.

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 uses a specific verb ('Get') and identifies a concrete resource: open ROB (redemption order book) positions. It also clarifies the optional filtering dimensions (iAsset or owners). It does not explicitly distinguish itself from the sibling tools like get_redemption_orders or get_redemption_queue, so it falls 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 implies this tool is for retrieving open redemption order book positions but provides no guidance on when to use it versus the many related sibling tools such as get_redemption_orders, get_redemption_queue, or open_rob. There are no exclusions, alternatives, or context cues beyond the basic purpose.

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 full disclosure burden. While 'Get' implies read-only behavior, the description fails to clarify pagination behavior, data freshness, rate limits, or whether 'all' refers to active polls only or historical data as well.

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?

Extremely compact at four words with no redundancy. However, given the absence of output schema and annotations, the brevity borders on under-specification rather than optimal information density.

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 zero-parameter tool, the description minimally suffices to identify the resource. However, with no output schema provided, the description omits what data structure or fields to expect in the response, leaving a significant gap for the consuming agent.

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?

Input schema contains zero parameters, establishing a baseline score of 4 per evaluation rules. The description 'Get all' confirms no filtering is possible, which aligns with 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?

Uses specific verb 'Get' and resource 'governance polls', clearly identifying the operation's target. However, the scope modifier 'all' is vague regarding pagination or filtering limits, and it does not differentiate from sibling governance-related tools like 'get_temperature_checks'.

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?

Provides no guidance on when to use this tool versus alternatives, prerequisites for invocation, or expected data volume. With many sibling 'get_' tools available, the absence of selection criteria forces the agent to guess based on naming alone.

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 provided, the description carries the full burden of behavioral disclosure but only states 'latest' without clarifying data freshness, caching behavior, or what the governance parameters govern (e.g., fee structures, collateral ratios).

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?

Extremely brief at only four words with no waste, but verges on under-specification. Could benefit from one additional sentence clarifying the scope of 'governance parameters' without sacrificing clarity.

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?

Adequate for a simple read operation but leaves ambiguity about what specific governance parameters are returned (e.g., are these voting thresholds, fee parameters, or stability pool settings?) given the rich ecosystem of sibling tools handling CDPs, staking, and stability pools.

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?

Input schema contains zero parameters. Per evaluation guidelines, zero-parameter tools receive a baseline score of 4.

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 clear verb (Get) and resource (governance protocol parameters), distinguishing it from sibling 'get_' tools that target specific assets or accounts. However, it doesn't clarify what distinguishes 'governance' parameters from other protocol parameters like those in get_protocol_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?

Provides no guidance on when to use this tool versus alternatives like get_protocol_stats or get_staking_info, nor does it mention if this should be called before specific mutations.

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 provided, so description carries full burden of behavioral disclosure. While 'Get' implies read-only, the description does not explicitly confirm safety, idempotency, rate limits, or what data structure/format is returned despite the complex financial domain (CDPs, staking, liquidations).

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?

Extremely brief (3 words) to the point of under-specification. While not verbose, it fails to front-load critical information about return values or scope that would help an agent select this tool correctly.

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?

Tool lacks output schema and annotations, yet description does not compensate by explaining what aggregated statistics are returned (TVL, volumes, counts?). Given the rich sibling context suggesting complex DeFi operations, the description is 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?

Input schema contains zero parameters. Per calibration rules, 0 params establishes baseline 4. No parameter description is needed or 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?

States the basic action (Get) and resource (protocol statistics) but remains vague about what specific statistics are returned. Fails to distinguish from similar sibling tools like get_protocol_params or get_tvl, which also query protocol-level 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?

Provides no guidance on when to use this versus the numerous other data retrieval tools (get_tvl, get_protocol_params, get_staking_info). No mention of prerequisites, caching behavior, or query patterns.

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 provided, the description carries the full behavioral disclosure burden. It discloses the data source (Indigo analytics API), that the price is the latest signed Pyth update, and that it is only valid on-chain until validUntil. It stops short of stating read-only guarantees or error behavior, but this is adequate for a simple getter.

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 two sentences with no waste: the first sentence states the core purpose, and the second adds meaningful context about the signed payload and validity. Every clause 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?

For a single-parameter read tool with an enum schema and no output schema, the description gives enough high-level information to invoke the tool and interpret the result: current price, feed configuration, source, and on-chain validity. It does not enumerate exact response fields, but the context is sufficient for a straightforward getter.

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%, but the enum in the schema already enumerates the allowed asset values. The description adds that these are iAssets and that the price is a Pyth price, which helps interpret the parameter, though it does not specify units or output 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?

The description clearly identifies the tool's function with a specific verb and resource: it retrieves the current Pyth price for an iAsset plus on-chain feed configuration. This distinguishes it from sibling price tools like get_asset_price or get_oracle_price by emphasizing the Pyth-signed update and on-chain relevance.

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: this returns the exact signed Pyth payload that CDP write tools embed on-chain, so an agent knows to use it when on-chain validity matters. It does not explicitly name alternatives or exclusion conditions, but the context is strong enough to guide selection among the sibling price 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?

With no annotations, the description carries the behavioral burden. 'Get' implies a safe read operation and 'executed' adds useful status filtering, but the description does not disclose return format, pagination behavior, or ordering. It is not misleading, but it is minimal.

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 front-loaded sentence with no filler. It communicates the core action, the resource, and the optional filter in minimal words.

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 simple, has no output schema, and no annotations. The description covers the essential purpose and filter, but it does not mention return shape or clarify how it differs from the closely related get_redemption_queue tool, so the context is only minimally complete.

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 50%, and the description compensates by explaining that the asset parameter filters by iAsset. The limit parameter is already documented in the schema with a default and maximum. Together, all parameters have adequate semantic meaning.

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 the resource ('executed redemption orders') and the action ('get'), and adds an optional filter by iAsset. It is specific enough to be distinguishable from most sibling tools, though it does not explicitly contrast with get_redemption_queue.

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 guidance is given about when to use this tool versus alternatives such as get_redemption_queue. There are no preconditions, exclusions, or recommended contexts beyond the implicit fact that it returns executed orders.

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 provided, the description carries the full behavioral burden. The word 'Get' and the qualifier 'open' convey a read-only operation returning only open order-book entries, which is useful. However, it does not describe anything about the response format, ordering, pagination, or error 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?

A single concise sentence with no filler. The key action and resource are front-loaded, and the scope is stated efficiently. Every word 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?

For a simple one-parameter getter, the description is minimally adequate, but it leaves gaps: 'ROB' is unexplained, the return structure is unspecified (no output schema), and the relationship to sibling tools is not clarified. An agent could call it, but may not understand the result or when it is the right choice.

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 schema has 0% description coverage, but the single 'asset' parameter is well-constrained by an enum. The description adds the domain context that the asset is an 'iAsset', which helps interpret the parameter, but it does not otherwise explain specific values or how the parameter is used.

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 clear verb ('Get'), a resource ('open ROB order-book entries'), and a scope ('for a specific iAsset'). However, it does not expand the 'ROB' acronym or explicitly differentiate itself from similar siblings like get_order_book and get_redemption_orders.

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 phrase 'for a specific iAsset' implies this tool is used per-asset, but there is no explicit guidance about when to choose this tool over alternatives such as get_order_book or get_redemption_orders. No when-to-use or when-not-to-use conditions 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 are provided, requiring the description to carry full behavioral disclosure burden. It only specifies input format variations but omits return structure, error handling (e.g., owner not found behavior), and performance characteristics.

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 consists of a single efficient sentence that front-loads the verb ('Get'), specifies the resource immediately, and appends input constraints without waste.

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 the tool's simplicity (single required parameter, read-only operation) and complete schema coverage, the description is minimally viable. However, it lacks return value documentation which would be valuable given the absence of an output schema.

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 schema has 100% description coverage and already documents that owners accepts 'payment key hashes or bech32 addresses'. The description largely repeats this information without adding validation rules, format examples, or semantic relationships between parameters.

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 identifies the action ('Get'), resource ('stability pool accounts'), and filtering scope ('for specific owners'), effectively distinguishing it from siblings like get_stability_pool_accounts (general query) and get_cdps_by_owner (different resource).

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?

While the parenthetical mentions acceptable input formats (payment key hashes or bech32 addresses), the description provides no explicit guidance on when to use this tool versus get_stability_pool_accounts or other query alternatives, nor any prerequisites.

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 of behavioral disclosure. It communicates that only open accounts are returned and that filtering by iAsset is possible, but it does not state whether results are paginated, what fields are returned, or explicitly confirm this is a read-only 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?

The entire description is one tight, front-loaded sentence with no filler. Every word adds value: 'all open' sets scope, 'stability pool accounts' names the resource, and 'optionally filtered by iAsset' covers the parameter.

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 low-complexity tool with one optional parameter and no output schema, this description gives the essential information an agent needs to invoke it. It could be more complete by naming sibling tools for single-account lookups, but that is a minor gap rather than a critical omission.

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 add meaning to the parameter. It does this by identifying 'asset' as an optional filter and relating it to iAsset values, which the schema enum already enumerates. This is sufficient compensation for the single optional parameter.

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 ('Get'), a resource ('stability pool accounts'), and a precise scope ('all open'), while also mentioning the optional filter by iAsset. This clearly distinguishes it from related sibling tools like get_stability_pools or get_sp_account_by_owner.

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 the main use case—listing open stability pool accounts, optionally filtered by asset—but does not explicitly say when to use this instead of alternatives such as get_sp_account_by_owner or get_stability_pools. No exclusions or alternative conditions are provided.

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 behavioral disclosure burden. 'Get' plus 'latest state' implies a read-only operation and names the returned data, but it does not mention response structure, potential staleness, or any operational caveats. This is adequate but minimal.

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 one concise sentence with the verb and resource front-loaded. The parenthetical adds useful specificity without wasting words.

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 convey the returned data; the parenthetical does so by naming snapshots, epoch-to-scale-to-sum, and asset states. It is largely complete for a zero-parameter getter, though it omits any caveats about data freshness or response formatting.

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 and the schema coverage is 100%, so there is nothing for the description to clarify. Per the baseline for zero-parameter tools, this is handled well.

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 a specific verb ('Get') and a concrete resource ('latest stability pool state for each iAsset'), then names the returned components. This distinguishes it effectively from siblings like get_stability_pool_accounts and other getters.

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 no guidance about when to use this tool versus alternatives such as get_stability_pool_accounts or other state getters. The intended use is inferable but not explicitly stated, and no exclusions or sibling comparisons 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 are provided, so the description carries the full burden. It does state the expected behavior: locate a pool UTxO and return its parsed datum. However, it does not disclose behavior when no pool is found, whether it queries chain data directly, or any freshness/error characteristics.

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, front-loaded sentence that states the action, the input relationship, and the output. Every part earns its place, with 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?

For a simple one-parameter lookup with no output schema, the description is reasonably complete: it specifies the input pairing and the return value. The only gap is lack of not-found or error behavior, which keeps it from a top score.

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%: the single 'asset' parameter is enum-constrained and described as an iAsset name. The tool description adds the ADA-collateral pairing context, which is useful. However, the schema's property description omits some enum values (iEUR, iJPY, iADA), so the semantic guidance is slightly inconsistent even though the enum itself is authoritative.

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 uses a specific verb ('Find') and a specific resource ('stableswap pool UTxO') with the exact pairing condition ('iAsset, ADA collateral pair') and the expected result ('return its parsed datum'). This clearly distinguishes it from order-management and other pool-related 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 clearly implies the use case: you need the pool UTxO and parsed datum for a given iAsset/ADA pair. It does not explicitly name alternatives or exclusion conditions, but the purpose is narrow enough that confusion with sibling tools is unlikely.

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 behavioral transparency burden. It effectively implies a read-only operation by saying 'Get' and refers to a state snapshot, which is helpful. However, it does not explicitly state that there are no side effects, no authorization requirements, or any other behavioral traits, leaving the agent to infer safety from the verb.

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, front-loaded sentence that immediately states the resource and the key returned fields. There is no filler or redundant 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 zero-parameter read-only state getter, the description covers the essential information: the resource and the returned values. With no output schema and no annotations, a bit more context about units, freshness, or side effects would improve completeness, but the tool's low complexity makes the current description reasonably adequate.

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 and the schema coverage is 100%, so parameter semantics are trivially satisfied. The description does not need to add parameter detail, and the 0-parameter baseline of 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?

The description identifies a specific verb and resource ('Get the current INDY staking manager state') and names the returned data fields (total stake, snapshot ada, output ref). It is clear and concrete, but it does not explicitly distinguish itself from siblings like get_staking_positions or get_sp_account_by_owner, so it does not fully earn 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 guidance about when to use this tool versus the many staking-related siblings, no stated conditions, and no exclusions. The description only implies that this tool is for reading the current staking manager state, which is weak given the large sibling set.

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?

Lacking annotations, the description carries the full burden of behavioral disclosure. While 'Get' implies read-only safety, the description omits return value structure, error cases (e.g., address not found), or pagination behavior. Just meets minimum for a simple read 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?

Single sentence of nine words with no redundancy. Verb-fronted structure ('Get...') places action first. Every word serves a 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?

Adequate for a simple single-parameter query tool, but lacks description of return values which would be helpful given the absence of an output schema. Does not leverage the opportunity to explain what constitutes an 'INDY' staking position.

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 100% schema description coverage ('Cardano bech32 address'), the baseline is established. The description adds the word 'single' which implies cardinality constraints not explicitly stated in the schema, providing marginal semantic value.

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 specific action ('Get') and resource ('INDY staking positions') with clear scope ('single Cardano address'). The 'single address' qualifier helps distinguish from sibling tools like 'get_staking_positions' (plural/bulk) and 'get_staking_positions_by_owner' (different identifier type).

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?

Provides no guidance on when to use this tool versus related query tools like 'get_staking_positions' or 'get_staking_info'. No prerequisites, error conditions, or filtering limitations are mentioned.

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 provided, the description carries the full burden. It adds valuable behavioral context by specifying 'open' (status filter) and 'INDY' (token specificity), but lacks disclosure on pagination, rate limits, authentication needs, or what constitutes an 'open' versus closed position.

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 extremely concise at six words with no redundancy. It front-loads the verb and key qualifiers ('all', 'open', 'INDY'), making efficient use of limited space.

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 the lack of output schema and annotations, the description is minimally adequate for a zero-parameter read operation but has clear gaps. It does not hint at the return structure (e.g., list of positions with IDs, amounts), pagination behavior, or data freshness expectations.

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 input schema contains zero parameters, establishing a baseline of 4. The description appropriately does not fabricate parameters, and the schema coverage is vacuously complete at 100%.

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