IndigoProtocol/indigo-mcp
OfficialServer Quality Checklist
Latest release: v0.4.1
- Disambiguation2/5
Multiple query tools have unclear boundaries, e.g., get_redemption_queue and get_order_book both return open ROB order-book entries, and get_cdps_by_owner/get_cdps_by_address or get_staking_positions_by_owner/get_staking_position_by_address are near-duplicates. get_assets/get_asset/get_asset_price and get_oracle_price/get_pyth_price also overlap, so agents must read descriptions carefully to avoid misselection.
Naming Consistency4/5The vast majority follow a consistent snake_case verb_noun pattern (get_*, open_*, close_*, adjust_*). Minor inconsistencies exist: singular get_staking_position_by_address vs plural get_staking_positions_by_owner, and sp/stable_pool abbreviation mixing (get_sp_account_by_owner vs get_stability_pool_accounts).
Tool Count1/569 tools far exceeds the well-scoped range and crosses the 50+ extreme threshold. Even though the protocol has many subdomains, the count overwhelms agent tool selection and includes many redundant query variants.
Completeness4/5Core lifecycle coverage is strong: CDPs, stability pool accounts, staking positions, ROB orders, stableswap orders, and oracles all have open/read/adjust/close equivalents. Minor gaps exist around governance (only temperature checks and polls are readable, no vote/proposal creation) and external DEX actions are query-only, but these are workable.
Average 3.6/5 across 69 of 69 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 2 community issues answered or closed in the last 6 months
- 15 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
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.
Conciseness4/5Is 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.
Completeness2/5Given 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.
Parameters3/5Does 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.
Purpose3/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior2/5
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.
Conciseness3/5Is 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.
Completeness2/5Given 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.
Parameters4/5Does 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.
Purpose3/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior2/5
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 access through the verb 'Get'. It lacks disclosure of return format, authentication requirements, rate limits, or side effects that agents need for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The three-word description is efficiently structured without redundancy, but it is inappropriately terse given the complete absence of annotations, output schema, and parameter definitions that would otherwise provide necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description fails to explain what distinguishes a 'temperature check' from regular polls (likely informal vs. formal governance) or what data structure is returned, leaving critical gaps for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters, establishing a baseline score of 4 per evaluation rules. No parameter semantics are required from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get temperature check polls' identifies the resource (temperature check polls) and uses a specific verb, but critically fails to distinguish from the sibling tool `get_polls`. Given the similar naming and likely overlapping functionality in what appears to be a governance domain, this lack of differentiation creates ambiguity for tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus the sibling `get_polls`, nor are there any stated prerequisites, conditions for use, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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.
Conciseness4/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior2/5
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 'estimate' implies a read-only simulation, the description doesn't confirm this, nor does it disclose what the estimate includes (price, slippage, fees), latency characteristics, or 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with no redundant words. However, it lacks the richness expected for a financial calculation tool—one additional sentence explaining the return value or behavior would improve utility without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter DEX tool with no output schema and no annotations, the description is insufficient. It fails to describe the return value format (what constitutes the 'estimate'), safety profile, or how to interpret results, leaving critical gaps in the agent's understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage ('Input token identifier', 'Output token identifier', 'Amount of input token'), so the description doesn't need to compensate. The description adds no parameter-specific context, meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States the core action (get swap estimate) and specific domain (Steelswap DEX), distinguishing it from sibling get_steelswap_tokens. However, it doesn't specify what the estimate represents (e.g., expected output amount, price impact, or gas costs), leaving some ambiguity despite the contextual clues from parameter names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (such as validating token pairs exist), or post-conditions. The agent must infer appropriate usage solely from the parameter schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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. While 'retrieve' implies a read-only operation, the description fails to specify return formats (bytes vs. string), error handling for invalid/missing CIDs, size limits, or timeout behavior for IPFS network retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief at five words and front-loads the key action. Every word earns its place, though given the complete absence of annotations and output schema, this borders on under-specification rather than optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a retrieval tool with no annotations and no output schema, the description is insufficient. It fails to indicate what format the retrieved content is returned in, how errors are communicated, or any constraints on the content size or retrieval timing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the parameter 'cid' is already well-documented as 'IPFS content identifier (CID)'. The description adds minimal semantic value beyond the schema, merely reinforcing that retrieval is performed 'by CID' without adding format constraints, validation rules, or usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (retrieve), resource (content from IPFS), and mechanism (by CID). However, it does not explicitly differentiate from the sibling tool 'store_on_ipfs' within the description text itself, relying instead on the tool name contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, prerequisites for valid CIDs, or when retrieval might fail. There is no mention of the complementary 'store_on_ipfs' operation or read-only vs. write contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose critical behavioral details: what gets returned (presumably a CID/hash), whether storage is permanent, if pinning is handled, or error conditions. The agent cannot infer the result format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at four words. The sentence earns its place with a clear action statement, though the brevity leaves significant gaps given the absence of annotations and output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must communicate what the tool returns (the CID/reference), but omits this entirely. For an external storage operation, this is a critical omission; the agent won't know how to reference the stored content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, documenting the 'text' parameter fully. The description repeats 'text content' from the schema without adding format constraints, examples, or size limits, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Store), resource (text content), and target system (IPFS). It implicitly distinguishes from sibling 'retrieve_from_ipfs' through the opposing verb, though it doesn't explicitly mention that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this versus 'retrieve_from_ipfs' or other storage methods. No mention of constraints like text-only limitation (though enforced by schema) or when storage might fail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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.
Conciseness4/5Is 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.
Completeness2/5Given 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.
Parameters4/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior2/5
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.
Conciseness4/5Is 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.
Completeness2/5Given 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.
Parameters4/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior2/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior2/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior2/5
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.
Conciseness4/5Is 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.
Completeness3/5Given 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.
Parameters4/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior2/5
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.
Conciseness4/5Is 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.
Completeness3/5Given 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.
Parameters4/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior2/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior2/5
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 indicates a non-mutating 'Get' operation over historical data, but it does not disclose output format, time range, granularity, units, or whether the value is denominated in ADA, fiat, or another token.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly-scoped sentence with no filler. The action and resource are front-loaded, making it immediately parseable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 should explain what the response contains, but it does not. It also omits the time range, unit denomination, and how 'protocol TVL history' differs from get_protocol_stats or get_dex_yields, leaving the agent to infer key call semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description has no parameter semantics to explain. With 100% schema coverage and no parameters, the baseline of 4 applies; the description does not need to compensate for any parameter documentation gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('protocol TVL history'), making the primary purpose unambiguous. It does not explicitly differentiate itself from sibling tools like get_protocol_stats or get_dex_yields, but 'history' adds a meaningful temporal scope that the name alone does not convey.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_protocol_stats, get_dex_yields, or get_asset_price. There are no stated exclusions or conditions that would help an agent decide between these related read-only tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters4/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior3/5
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.
Conciseness4/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior2/5
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 fails to mention whether authentication is required, if the operation is idempotent, pagination behavior for 'all' tokens, or rate limits. The verb 'Get' implies a read operation but lacks explicit confirmation of safety or 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It immediately communicates the resource and scope without filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description adequately identifies the resource scope (Steelswap DEX tokens) but leaves gaps regarding the return value structure (e.g., token metadata, addresses, symbols) and operational constraints. Sufficient for basic selection but incomplete for full invocation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters. According to calibration rules, 0 params equals a baseline score of 4. The description appropriately does not invent parameters, maintaining alignment with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get') and specific resource ('all tokens available on Steelswap DEX'), identifying the exact domain. However, it does not explicitly differentiate from the sibling tool 'get_steelswap_estimate', which also involves Steelswap but returns different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but provides no guidance on when to use it versus alternatives (e.g., when to query Steelswap tokens versus general assets or other DEX data). No prerequisites, filtering guidance, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior2/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose4/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior2/5
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.
Conciseness5/5Is 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.
Completeness2/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters4/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters4/5Does 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('all open INDY staking positions'), specifying the scope (global 'all') and status filter ('open'). However, it does not explicitly differentiate from siblings like `get_staking_positions_by_owner` or `get_staking_position_by_address` to clarify when to use this global variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 filtering alternatives (e.g., `get_staking_positions_by_owner`). It does not mention prerequisites, authentication requirements, or performance considerations for retrieving 'all' positions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose4/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters4/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Get' implies read-only access, the description fails to confirm idempotency, disclose return value structure, or explain error cases (e.g., invalid owner formats, empty results).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single, dense sentence that front-loads the action and resource, with parenthetical elaboration on input formats. No redundant or wasted language—every word serves the description's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema), the description adequately covers the basic invocation contract. However, lacking annotations and return value documentation, it omits important operational context that would help an agent handle responses and errors appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 parenthetically repeats the schema's explanation of acceptable input formats (payment key hashes or bech32 addresses) but adds no additional semantic depth, syntax examples, or validation rules beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (Get), resource (INDY staking positions), and filtering mechanism (for specific owners), effectively distinguishing it from siblings like get_staking_positions (all positions) and adjust/close_staking_position (mutations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clarifies acceptable input formats (payment key hashes or bech32 addresses), but does not explicitly state when to choose this tool over siblings like get_staking_positions or get_staking_position_by_address, nor does it mention prerequisites or array size limits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose4/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior2/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It reveals an important behavioral trait: the tool does not sign or submit; it returns an unsigned CBOR-hex transaction for client-side signing, which clarifies what 'process' means in practice. It does not detail downstream effects (e.g., whether the pending request is removed upon submission), but the key non-obvious 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and resource, then states the crucial output format with zero filler. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a protocol-maintenance tool with four fully documented parameters and no output schema, the description is largely complete: it explains what the tool does, the return format and serialization (CBOR hex), and the need for client-side signing. It could add how to locate the pending request or what happens after signing, but the current description is enough for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter already has a clear meaning (address, asset enum, accountTxHash, accountOutputIndex). The description adds no new parameter-level information, so it meets the baseline 3 expected when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation—processing a pending stability pool request—and characterizes it as a protocol maintenance operation that returns an unsigned transaction for client-side signing. This is distinct from read-only sibling tools and from create/close/adjust/annul operations, though it does not explicitly name the alternative it is not, so it stops short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Process a pending stability pool request' implies the tool is appropriate when a pending request exists and should be executed, but there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives such as annul_sp_request for cancellation. The maintenance-operation note adds context but no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 clearly states the tool returns an unsigned CBOR hex transaction for client-side signing, which implies no on-chain execution and is a meaningful behavioral trait. It does not mention prerequisites or eligibility of ROB positions, but the core non-submitting 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler: it front-loads the verb and resource, then states the output format and signing context. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key runtime behavior that is not captured by the schema: the tool returns an unsigned transaction rather than executing a redemption. Combined with 100% schema parameter coverage, an agent can call it correctly. Minor gaps remain around eligibility of ROB positions and explicit rules for combining multiple positions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 adds only loose context such as 'one or more ROB positions' for the redemptionRobs array and 'for a given iAsset' for the asset parameter, without enriching the schema-provided parameter definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Redeem'), names the resource ('iAssets against one or more ROB positions'), and states the output (unsigned CBOR hex transaction). It differentiates from CDP-related siblings like redeem_cdp by targeting ROB positions, though it does not explicitly name alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for redeeming iAssets against ROB positions and returning a transaction for client-side signing, which gives clear context. However, it provides no explicit when-not-to-use guidance and does not mention related alternatives such as claim_rob or redeem_cdp, leaving an agent to infer the boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses the key non-obvious trait: the tool only builds an unsigned CBOR hex transaction for client-side signing, so it does not broadcast or mutate chain state itself. It does not cover constraints such as whether the amount is validated against available collateral or what happens on insufficient collateral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero waste. The action ('Withdraw ADA collateral from a CDP') leads and the em-dash clause earns its place by conveying the unsigned-transaction signing flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-required-param tool with no output schema and no annotations, the description covers the operation and output format but leaves gaps: the ambiguous asset parameter, withdrawal limits relative to available collateral, and any indication of what the caller must do with the returned CBOR hex beyond 'client-side signing.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80% and the description adds little beyond it: 'ADA collateral' aligns with the Lovelace amount parameter, but the asset enum (iUSD, iBTC, etc.) is left undescribed and its role in an ADA collateral withdrawal is ambiguous. The description does not clarify how cdpTxHash and cdpOutputIndex jointly identify the CDP UTxO.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Withdraw ADA collateral from a CDP') plus a distinguishing clause ('builds an unsigned transaction (CBOR hex) for client-side signing') that identifies it as a transaction builder, not an executor. This cleanly separates it from siblings like deposit_cdp (deposit collateral) and close_cdp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied — withdraw collateral to reduce a CDP's collateral exposure — but no alternative tools or exclusion conditions are named. The description does not explicitly route the agent to deposit_cdp for adding collateral or close_cdp for full closure, nor does it warn against withdrawing so much that the CDP becomes undercollateralized.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
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 explicitly reveals that the tool does not submit a transaction but returns unsigned CBOR hex for client-side signing, a critical operational trait. It does not mention prerequisites like existing ROB positions, but the core non-broadcasting 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action first and the output format second. It contains no filler or redundant phrasing, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description usefully specifies the return value (unsigned CBOR hex) and the client-side signing workflow. It lacks details on preconditions such as holding ROB positions or the leverage math, but the essential user-facing behavior is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for address, leverage, and baseCollateral, covering 75% of parameters. The description adds general context about the redemption mechanism but no new per-parameter semantics beyond what the schema contains. The asset parameter remains undocumented but is self-explanatory via its enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open a leveraged CDP'), the mechanism ('by redeeming against ROB positions'), and the output ('unsigned transaction (CBOR hex)'). This distinguishes it from siblings like open_cdp and redeem_rob by specifying the leveraged redemption path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the intended use case—opening a leveraged CDP via ROB redemptions—but does not explicitly contrast it with alternatives such as open_cdp or redeem_rob, nor does it state when not to use it. An agent must infer when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Critically discloses the key behavioral pattern: it 'builds an unsigned transaction (CBOR hex) for client-side signing' rather than executing on-chain. This is essential safety information. Missing minor details about what happens to source CDPs post-merge.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single, dense sentence with zero waste. Front-loaded with the action (merge), followed by critical implementation detail (unsigned CBOR hex). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 100% schema coverage and no output schema, the description adequately covers the tool's purpose and return type implication (CBOR hex). However, given the complexity of CDP merging and lack of annotations, it could briefly mention the output format explicitly or state that the transaction requires submission after signing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage with clear definitions for 'address' (bech32 format) and 'cdpOutRefs' (minimum 2). Description does not add parameter-specific semantics beyond the schema, which is acceptable given the high schema quality. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb ('Merge') and resource ('CDPs') with scope ('into one'). Distinguished from siblings like burn_cdp, close_cdp, or deposit_cdp by specifying the consolidation action. The additional clause about building an unsigned transaction further clarifies the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage through the 'client-side signing' note (indicating this is for transaction preparation, not direct execution), but lacks explicit when-to-use guidance or comparison to alternatives like close_cdp. The minimum 2 requirement is only in schema, not description text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 return format (unsigned transaction, CBOR hex) and signing requirement (client-side). However, it omits details about idempotency, lockup periods, or fees that would help agents understand 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first establishes the action, second clarifies the return value for signing. Perfectly 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema exists, the description adequately compensates by specifying the CBOR hex return format. With 100% schema coverage and clear action description, it covers the essential contract, though it could note whether this requires an existing staking position or is truly net-new only.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage (bech32 address format, smallest unit clarification for amount), establishing baseline 3. The description mentions staking INDY tokens which aligns with the amount parameter but does not add semantic details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (stake) + resource (INDY tokens) + scope (creating a new position). The phrase 'creating a new' effectively distinguishes this from sibling tools adjust_staking_position (modification) and close_staking_position (removal).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage context through 'creating a new' which suggests this is for initial staking vs. modifying existing positions, but does not explicitly name adjust_staking_position as the alternative for existing positions or state prerequisites like minimum stake amounts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 clearly discloses that the tool builds an unsigned transaction in CBOR hex and explains the maximum-redemption behavior. It stops short of stating what the tool does not do, such as submitting the transaction or enforcing ownership checks, but the client-side signing framing provides strong transparency for the core behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. It front-loads the tool's purpose and output type, then adds the one usage tip that matters for correct invocation. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, output format (CBOR hex), and the critical max-redemption usage detail, which is enough for a 5-parameter tool with self-explanatory schema fields. It could be slightly more complete by explicitly saying the transaction is not submitted on-chain, but 'for client-side signing' already conveys that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for most parameters (80% coverage), including the tip to pass the total minted amount for maximum redemption. The description restates that tip but does not add meaningful meaning beyond the structured schema, so it neither strongly compensates for gaps nor introduces confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Redeem iAssets from a CDP') and clearly distinguishes the tool from sibling tools by explaining that it builds an unsigned transaction (CBOR hex) for client-side signing rather than directly executing on-chain. This makes the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context that this tool produces a client-side signing payload, which implies it is for offline/unsigned transaction construction rather than submission. However, it does not explicitly state when to prefer this over related CDP mutation tools like burn_cdp, close_cdp, or withdraw_cdp, nor does it name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
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 explicitly reveals that the tool builds an unsigned transaction for client-side signing, meaning it does not submit or execute on-chain actions. It also names the stability pool mechanism, providing useful context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. It front-loads the primary action and resource, then adds the crucial implementation detail about building an unsigned CBOR hex transaction. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description conveys the core action, the output format, and the signing workflow. It is adequate for a four-parameter tool, though it could briefly clarify which asset is being liquidated or the relationship between asset and CDP.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so most parameters are already documented in the schema. The description does not add specific parameter-level detail, but it provides enough context to infer that address is the signer and cdpTxHash/cdpOutputIndex identify the CDP UTxO. The asset parameter's role remains somewhat ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Liquidate'), a clear resource (undercollateralized CDP), and the exact mechanism (through the stability pool). It further clarifies the deliverable as an unsigned CBOR hex transaction for client-side signing, which distinguishes it from related CDP operations like redeem_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.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Liquidate an undercollateralized CDP' clearly implies the tool should be used when a CDP is undercollateralized and liquidation is desired. It does not explicitly name alternatives or provide exclusion criteria, but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It explicitly discloses that this is a mutation (increases debt) and that it does not execute on-chain, instead building an unsigned transaction (CBOR hex) for client-side signing. It could add prerequisites like CDP health requirements, but the core 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-structured sentence that front-loads the action and debt consequence, then states the output format. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's purpose, side effect, and return format, which matters because there is no output schema and no annotations. Minor gaps remain around prerequisites, CDP health, and authorization, but nothing prevents an agent from understanding what the tool does and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80% and most parameters are already documented, so the baseline is 3. The description adds no per-parameter nuance beyond echoing that an existing CDP is referenced by its UTxO and that iAssets are minted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Mint additional iAssets'), a specific target ('an existing CDP'), and the key effect ('increases debt'). This differentiates it from siblings like open_cdp (creating a new CDP) and burn_cdp (reducing debt).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'from an existing CDP' clearly implies this tool is for increasing an already-open CDP's debt, not opening a new one. It does not explicitly name alternatives like open_cdp or state exclusions, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and handles it well: it states the tool returns an unsigned transaction (CBOR hex) for client-side signing, making clear no on-chain effect occurs at call time. It also explains the rational-number constraint on max price. It stops short of covering prerequisites, fees, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: action and acronym expansion front-loaded, then max-price semantics, then return format. No redundant or filler phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-param, annotation-free tool with no output schema, the description covers the essential invocation loop: input semantics, the rational max price, and the CBOR hex return format. Minor gaps remain around prerequisites (e.g., required account state) and error scenarios, but nothing that would block a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80% (asset relies on its enum). The description adds genuine meaning by explaining that maxPriceNumerator/maxPriceDenominator form a rational number and by contextualizing lovelacesAmount as the ADA deposit and asset as the iAsset being purchased — relationships absent from the individual schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Open a new ROB buy order'), expands the acronym (Redemption Order Book), and explains the core mechanics: deposit ADA to buy an iAsset up to a max price. This clearly differentiates it from lifecycle siblings like adjust_rob, cancel_rob, claim_rob, and redeem_rob.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
'Open a new' implies this is the creation entry point in the ROB lifecycle, which contrasts with adjust/claim/redeem/cancel siblings. However, no alternative tool is named explicitly and there is no when-to-use or when-not-to-use guidance, so usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior5/5
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 states the tool does not produce an on-chain execution but 'builds an unsigned transaction (CBOR hex) for client-side signing', which is critical safety-relevant behavior. This exceeds what the name or schema alone would communicate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that front-loads the core purpose, then adds the key behavioral detail after an em dash. Every word earns its place; there is no padding or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 is remarkably complete: it explains what action is performed, the collateral requirement, and what the caller receives (unsigned CBOR hex transaction for signing). Combined with the schema, an agent has enough context to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes address, mintAmount, and collateralAmount, giving 75% coverage. The description adds no new parameter-level detail beyond the phrase 'with ADA collateral', which the schema already makes explicit. The asset parameter remains only an enum with no additional explanation, but the description does not need to compensate heavily given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Open a new CDP position'), the resource (CDP), and the collateral type (ADA). It also distinguishes the tool's nature by noting it 'builds an unsigned transaction (CBOR hex) for client-side signing', which clearly separates it from on-chain execution tools like close_cdp or mint_cdp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool when opening a new CDP position with ADA collateral and when an unsigned client-signed transaction is needed. It does not explicitly mention alternatives or exclusions, but the purpose is specific enough that an agent can infer when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/IndigoProtocol/indigo-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server