IndigoProtocol/indigo-mcp
OfficialServer Quality Checklist
Latest release: v0.2.14
- Disambiguation4/5
Most tools have distinct purposes targeting specific resources (CDPs, ROB positions, staking, stability pools, etc.), but some overlap exists—e.g., multiple 'get_' tools for similar data (like CDPs by address vs. by owner) could cause minor confusion. However, descriptions clarify the distinctions, and transaction-building vs. querying tools are well-separated.
Naming Consistency5/5Tool names follow a highly consistent verb_noun pattern throughout, with clear action prefixes (adjust_, analyze_, cancel_, claim_, close_, create_, deposit_, distribute_, freeze_, get_, leverage_, liquidate_, merge_, mint_, open_, process_, redeem_, retrieve_, store_, withdraw_). No mixing of conventions like camelCase or inconsistent verb styles is present.
Tool Count2/5With 59 tools, the count is excessive for a single server, making it heavy and potentially overwhelming for agents. While the domain (DeFi protocol) is complex, this many tools suggests poor scoping—many could be consolidated or split into multiple focused servers, leading to usability issues.
Completeness5/5The tool set provides comprehensive coverage for the Indigo Protocol domain, including full CRUD/lifecycle operations for CDPs, ROB positions, staking, and stability pools, plus governance, analytics, and external integrations (IPFS, DEX). No obvious gaps are present; agents can perform all expected actions without dead ends.
Average 3.5/5 across 59 of 59 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
- 12 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 provided, so description carries full disclosure burden, yet fails to mention this is read-only (implied only by 'Get'), doesn't describe return format, pagination behavior, or maximum result limits. Omits that this queries protocol state which may change between calls.
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?
Single 9-word sentence is appropriately front-loaded with the core action, but given the complete lack of schema descriptions and annotations, it is underspecified rather than optimally concise. Omits essential context that cannot be found elsewhere.
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?
Inadequate for a complex DeFi protocol tool with no annotations, no output schema, and undocumented input parameters. Fails to explain what constitutes a CDP in this context, return data structure, or the necessity of pagination given the 500-item limit constraint in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description only partially compensates by mentioning the 'iAsset' filter (mapping to the 'asset' parameter) but completely ignores the critical pagination parameters 'limit' and 'offset' necessary for retrieving large datasets from this 'get all' operation.
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 specific verb 'Get' and resource 'CDPs/loans' with scope modifier 'all', distinguishing it from sibling tools like 'get_cdps_by_address' and 'get_cdps_by_owner' which target specific subsets. The synonym 'loans' adds clarity for domain terminology.
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 broad query versus the filtered siblings (get_cdps_by_address/get_cdps_by_owner). Mentions optional filtering by iAsset but doesn't explain pagination requirements or when results might be too large for single calls.
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, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure but only implies read-only safety through the verb 'Get'. It omits pagination behavior, default return limits, rate limits, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is front-loaded with the action verb and contains no redundancy. However, extreme brevity comes at the cost of omitting necessary contextual disambiguation and behavioral details.
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 absence of annotations and output schema, the description should clarify return structure and distinguish from similar sibling tools. As written, it is insufficient for an agent to confidently select this over 'get_redemption_queue' or understand the payload structure.
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%, so the structured data already documents both parameters ('timestamp' and 'in_range'). The description adds minimal semantic value by noting these are 'optional' filters, 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.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('redemption orders'), but fails to distinguish from the sibling tool 'get_redemption_queue', which creates ambiguity for agent selection in a DeFi context where orders and queues may be distinct concepts.
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 tool versus 'get_redemption_queue' or other redemption-related siblings. No mention of prerequisites or required context for the timestamp/price filters.
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 disclosure burden. While 'Get' implies read-only, the description omits safety details (idempotency, side effects), return value structure (what 'details' includes), and error behaviors. Lacks context on the Indigo protocol domain.
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 with no filler. Appropriately brief for a simple getter, though arguably too terse given the complete lack of schema documentation and the need to distinguish from numerous sibling tools.
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 lookup tool with no output schema, but incomplete given 0% schema coverage. The description should specify what constitutes 'details' (metadata, price, supply?) to distinguish from 'get_asset_price' and compensate for undocumented parameters.
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 0% description coverage. The description adds context that the parameter refers to a 'specific Indigo iAsset', which helps interpret the 'asset' parameter, but fails to document the four valid enum values (iUSD, iBTC, iETH, iSOL) or explain that these represent synthetic/indigo-wrapped assets.
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 ('details for a specific Indigo iAsset'), identifying it as a retrieval operation for Indigo protocol synthetic assets. However, it fails to differentiate from sibling 'get_assets' (plural) or 'get_asset_price', leaving ambiguity about what specific 'details' are returned versus price or list 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?
No guidance provided on when to use this single-asset lookup versus 'get_assets' (batch retrieval) or 'get_asset_price' (specific metric). No mention of prerequisites, required permissions, or error conditions (e.g., invalid asset symbols).
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 specifies the operation is 'current'. It lacks critical details: price denomination (USD/ADA), data source, freshness/caching behavior, return format, or error handling.
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 single sentence is front-loaded with the verb and contains no redundant words. However, extreme brevity comes at the cost of omitting useful behavioral and contextual details.
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 enum parameter, no nesting), the description is minimally adequate but incomplete. The absence of an output schema and annotations creates gaps regarding return value structure and operational side effects that the description fails to fill.
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 and the description only vaguely references 'specific Indigo iAsset' without explaining the enum values (iUSD, iBTC, etc.) or providing examples. However, the term 'iAsset' adds protocol-specific context missing from 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?
The description clearly states the action ('Get') and resource ('current price') and specifically targets 'Indigo iAsset', which distinguishes it from siblings like get_ada_price, get_indy_price, and get_asset (which likely returns metadata rather than pricing).
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 such as get_asset (for general metadata) or get_ada_price/get_indy_price (for native tokens). No prerequisites or contextual triggers 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?
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'open' status filtering but fails to disclose pagination behavior, rate limits, data freshness, auth requirements, or what happens when no filters are applied (full dataset vs error).
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 single-sentence structure is efficient and front-loaded with the core action. However, given the 0% schema coverage and lack of annotations, the brevity becomes a liability—additional sentences explaining return format or domain-specific terms ('limited redemption positions') would add value.
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 DeFi tool querying 'limited redemption positions,' the description lacks domain context and return value specification. With no output schema, no annotations, and 0% parameter documentation, the description should explain what constitutes a redemption position and the expected response structure.
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%, requiring the description to compensate. It successfully maps both parameters to their filtering purpose ('filtered by asset or owners') but doesn't clarify the data format for owners (addresses vs IDs) or explicitly mention that both are optional, though this is implied.
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 tool retrieves 'open limited redemption positions' from the 'order book'—specific verb and resource. However, it doesn't explicitly differentiate from similar siblings like get_redemption_orders or get_redemption_queue, which could confuse 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?
The description mentions optional filtering ('optionally filtered by asset or owners') but provides no guidance on when to use this tool versus alternatives like get_redemption_orders or get_redemption_queue, nor does it indicate prerequisites or optimal use cases.
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 full disclosure burden. It adds 'historical' indicating time-series data (distinguishing from current-state queries), but omits critical behavioral details: data range limits, update frequency, whether this requires external API calls, rate limits, or return format structure.
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 six words with no filler. Information is front-loaded immediately. However, the brevity borders on under-specification given the lack of supporting 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?
Without an output schema or annotations, the description must compensate but fails to specify: which protocol's TVL is returned (Indigo), time granularity, data availability range, or response structure. For a zero-parameter tool, these scope definitions are essential but missing.
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 baseline 4. No parameter description is required, though the description could have clarified why no protocol selector is needed (i.e., it queries the current protocol context).
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), resource (historical TVL data), and source (DefiLlama), distinguishing it from sibling price feeds like get_ada_price or get_dex_yields. However, it fails to specify this retrieves the Indigo Protocol's TVL specifically, which is implied by the zero-parameter schema and server context.
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 similar analytics tools like get_protocol_stats or get_dex_yields. Does not indicate whether this should be used for current snapshots versus time-series analysis, or data freshness considerations.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states it retrieves 'all' CDPs. It fails to specify error handling (e.g., invalid address format), return structure, pagination behavior, or whether the operation 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?
The description is a single, front-loaded sentence with no redundant words. It immediately conveys the core function without unnecessary preamble or filler.
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 string parameter with full schema coverage) and lack of output schema, the description is minimally adequate. However, it could be improved by clarifying what constitutes a CDP in this context or noting the relationship to the sibling 'by_owner' variant.
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, documenting the bech32 address format. The description mentions 'specific Cardano address' but adds no semantic details beyond what the schema already provides (such as examples or validation rules), warranting the baseline score.
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 (CDPs/loans) scoped to a specific Cardano address. However, it does not explicitly differentiate from the sibling tool 'get_cdps_by_owner', leaving ambiguity about when to use address versus owner lookup.
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 on when to use this tool versus alternatives like 'get_cdps_by_owner' or 'get_all_cdps'. The description lacks when-not-to-use conditions or prerequisites for the address parameter.
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 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.
- 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.
- 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 'Analyze' implies a read-only operation, the description fails to disclose computational complexity, what specific health metrics are returned (liquidation thresholds, ratio percentages), pagination behavior, 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of nine words with zero redundancy. Every word earns its place by specifying the action, target metrics, and target entity.
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 analytical tool, the description adequately covers the input domain. However, given the lack of output schema and the analytical nature of the tool, the description omits what analysis results are returned (e.g., risk ratings, numerical ratios), leaving a gap in contextual completeness.
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 input parameter 'owner' is fully documented in the schema itself (including format details for hex/bech32). The description adds no supplementary parameter semantics beyond what the schema provides, warranting the baseline score 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?
The description uses a specific verb ('Analyze') and clearly identifies the resource ('health and collateral ratios of CDPs') and scope ('for an owner'). It implicitly distinguishes from sibling getter tools like 'get_cdps_by_owner' by emphasizing analytical depth (health/ratios) rather than simple retrieval, though explicit differentiation is absent.
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 provides implied usage guidance through its specific focus on 'health and collateral ratios,' suggesting use for risk assessment rather than basic listing. However, it lacks explicit when-to-use guidance, prerequisites, or named alternatives (e.g., when to use 'get_cdps_by_owner' vs this tool).
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.
- 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 burden. It successfully discloses the sorting behavior (max price ascending) and aggregation, but lacks details on what constitutes a 'redemption queue', the return data structure, or any side effects/pagination.
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 with zero waste. Every word earns its place: 'aggregated' distinguishes the tool, 'sorted by max price ascending' reveals behavior, and 'specific iAsset' maps to the parameter. Front-loaded and 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 single-parameter getter without output schema or annotations, the description adequately covers the core function but lacks explanation of the return value or the domain concept of a redemption queue. Sufficient for basic invocation but incomplete for full comprehension.
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%, requiring the description to compensate. It references 'iAsset' which maps to the 'asset' parameter and implies the enum values (iUSD, iBTC, etc.), but does not explicitly describe the parameter name, format, or valid values beyond the implicit reference.
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 resource ('aggregated redemption queue'), and distinguishes itself from the sibling 'get_redemption_orders' through the 'aggregated' modifier. It also specifies the sorting behavior ('max price ascending'), providing clear scope.
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 term 'aggregated' implies a difference from 'get_redemption_orders', there is no explicit guidance on when to use this tool versus its sibling or other alternatives. No prerequisites 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?
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.
- 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?
With no annotations provided, the description carries the full burden. It adds value by disclosing the specific return fields (snapshotP, snapshotD, snapshotS, epoch, scale) which is critical given the lack of output schema. However, it omits other behavioral traits like data freshness guarantees, read-only safety confirmation, or error conditions. 'Latest' implies real-time data but doesn't specify caching 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 a single, efficient sentence that front-loads the action ('Get') and immediately specifies the resource and scope. The parenthetical listing of return fields adds information density without verbosity. No redundant or wasted language.
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 tool, the description adequately compensates for the missing output schema by enumerating the specific fields returned (snapshotP, snapshotD, snapshotS, epoch, scale). It successfully conveys what data the agent will receive. It could be improved by indicating whether this returns an array or object structure, but the field enumeration provides essential completeness.
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 (empty object), which per the scoring guidelines establishes a baseline of 4. The description correctly implies no filtering parameters are needed by stating it retrieves state 'for each iAsset', confirming the schema structure without needing to enumerate non-existent 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 states it retrieves the 'latest stability pool state for each iAsset' with specific technical fields (snapshotP, snapshotD, snapshotS, epoch, scale). This distinguishes it from sibling tools like get_stability_pool_accounts by specifying 'state' versus user accounts, though it could explicitly mention when to prefer this over account-specific queries.
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 like get_stability_pool_accounts or get_sp_account_by_owner. It lacks prerequisites, filtering capabilities (it retrieves 'each' iAsset suggesting no filtering), 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 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.
- 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 of behavioral disclosure. It successfully discloses that the tool returns an 'unsigned transaction (CBOR hex) for client-side signing,' which is critical behavioral context. However, it fails to describe the state changes (e.g., what happens to the ROB positions or iAssets during redemption) or any 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 consists of two highly efficient sentences. The first defines the action and target, while the second specifies the return format. There is no redundant or extraneous information; every word serves a distinct 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 complexity (6 parameters including oracle references and UTxO indices) and lack of output schema, the description provides the essential minimum by stating the return type (CBOR hex). However, for a complex DeFi mutation involving multiple UTxO references, the description is terse and lacks domain context (e.g., explaining the relationship between the oracle, iAsset UTxO, and redemption logic).
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, establishing a baseline score of 3. The description mentions 'one or more ROB positions,' which aligns with the array structure of 'redemptionRobs', but does not add semantic details, format constraints, or usage examples 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 ('Redeem'), the resource ('iAssets'), and the target ('one or more ROB positions'). By explicitly naming 'ROB positions', it distinguishes this tool from the sibling 'redeem_cdp', ensuring the agent selects the correct redemption mechanism.
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 explicit guidance on when to use this tool versus alternatives like 'redeem_cdp' or 'claim_rob', nor does it state prerequisites or conditions. While noting the return of an unsigned transaction implies a specific usage pattern (client-side signing), it does not constitute explicit selection criteria.
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 provided, so description carries full burden. Indicates comprehensive retrieval ('all'), but omits details on error handling (e.g., owner not found), pagination, rate limits, or authentication requirements.
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 efficient sentence with parenthetical detail. Front-loaded with action and resource, zero extraneous text. 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?
Adequate for a single-parameter retrieval tool with complete schema coverage. However, lacks description of return value structure since no output schema exists, which would help the agent understand what constitutes a successful 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?
Schema coverage is 100% and the parameter description in the schema already documents the owner formats. The description essentially repeats this information without adding syntax examples, validation details, or semantic context beyond 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?
States specific verb ('Get'), resource ('CDPs/loans'), and scope ('for a specific owner'). Differentiates from 'get_all_cdps' by specifying owner-filtering, though it does not explicitly clarify the distinction from sibling '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?
Implies usage context by specifying accepted input formats ('payment key hash or bech32 address'), but lacks explicit guidance on when to use this tool versus 'get_cdps_by_address' or other retrieval 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?
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.
- 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 indicates this is a read operation ('Get') and filters by 'open' status, but fails to disclose pagination behavior, response structure, or what distinguishes an 'open' account from other states.
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 single-sentence description is front-loaded with the primary action ('Get all open stability pool accounts') followed by the conditional clause ('optionally filtered by iAsset'). No redundant words or phrases present.
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 low complexity (one optional enum parameter, no nested objects) and absence of an output schema, the description adequately covers the input contract. It could be improved by briefly indicating the return type (e.g., array of account objects), but remains sufficient for tool selection.
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 has 0% description coverage. The description compensates by indicating the `asset` parameter is used for 'optionally filtered' filtering and implies optionality (consistent with the schema). It could further clarify that 'iAsset' refers to the synthetic assets listed in the enum values.
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 tool retrieves 'all open stability pool accounts' with specific filtering capability. However, it does not explicitly differentiate from sibling `get_sp_account_by_owner` (which retrieves a specific account by owner rather than listing all open accounts).
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 iAsset' implies when to use the parameter versus retrieving unfiltered results, but provides no explicit guidance on when to use this tool versus alternatives like `get_sp_account_by_owner` for owner-specific lookups.
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 critically discloses that the tool builds an unsigned transaction (CBOR hex) rather than executing on-chain, which is essential behavioral context for agent flow control. It could further improve by mentioning prerequisites (CDP must exist) or side effects (improves health ratio).
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, two clauses. Front-loaded with action ('Deposit additional collateral'), immediately followed by scope ('into a CDP'), then critical implementation detail ('builds an unsigned transaction...'). Zero redundant words; every segment earns its place by conveying distinct operational or behavioral 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?
Compensates effectively for the missing output schema by explicitly stating the return format (CBOR hex). Given the complexity of UTxO-based CDP operations (requiring txHash + outputIndex), the description provides sufficient context for invocation, though it could mention that the CDP must exist or reference the collateral asset type.
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% (high), establishing a baseline of 3. The description adds semantic context by identifying the 'amount' as 'collateral' and linking cdpTxHash/cdpOutputIndex to the target CDP, but does not add syntax details, validation rules, or format specifics beyond what the schema already provides.
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 ('Deposit additional collateral'), the target resource ('CDP'), and uses 'additional' to distinguish from open_cdp. The CBOR hex detail adds technical specificity. However, it does not explicitly name sibling alternatives like withdraw_cdp or burn_cdp to fully differentiate use cases.
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 term 'additional collateral' implies usage for existing CDPs versus creating new ones, and 'client-side signing' clarifies the execution pattern. However, it lacks explicit when-to-use guidance (e.g., 'use when increasing collateral ratio') or explicit contrasts with alternatives like withdraw_cdp.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It compensates partially by listing the specific return fields (slot, outputHash, totalStake, snapshotAda), providing transparency into what data is retrieved. However, it omits safety profile confirmation, auth requirements, or operational traits like idempotency that would be expected for a read operation without annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero waste. Every element serves a purpose: the verb establishes the operation, 'INDY staking manager state' identifies the resource, and the parenthetical list specifies the return structure.
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 an output schema, the description appropriately compensates by enumerating the returned fields (slot, outputHash, totalStake, snapshotAda). It adequately covers a zero-parameter read operation, though it could be improved by briefly defining what these fields represent (e.g., what snapshotAda means).
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, triggering the baseline score of 4. The description correctly omits parameter discussion since none exist, requiring no additional semantic clarification 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 uses a specific verb ('Get') and resource ('INDY staking manager state'), clearly distinguishing it from sibling tools like get_staking_positions or adjust_staking_position by targeting the global manager state rather than individual positions. The parenthetical field list (slot, outputHash, totalStake, snapshotAda) further clarifies the specific data returned.
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 the many sibling staking tools (e.g., get_staking_positions_by_owner vs. this global manager state). It lacks explicit prerequisites, filtering caveats, or alternative recommendations.
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 successfully discloses the critical pattern that it 'Returns an unsigned transaction (CBOR hex) for client-side signing'. This tells the agent the tool is a transaction builder requiring off-chain signing, not an immediate state mutator. It does not disclose idempotency, error states, or the exact on-chain effect of processing.
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 establishes purpose and domain context; second sentence explains return value behavior. Information is front-loaded and appropriately sized for the complexity level.
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 appropriately explains the return value (CBOR hex for signing). For a 4-parameter blockchain tool with no annotations, it covers the essential operational pattern. It could be improved by mentioning the relationship to 'annul_sp_request' or error conditions, but it is sufficiently complete for safe 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?
Input schema has 100% description coverage with clear types (bech32 address, iAsset enum, tx hash, output index). The description adds no parameter-specific semantics beyond the schema, but given complete schema coverage, the baseline adequacy is maintained without additional elaboration.
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 ('Process') and resource ('pending stability pool request'), and adds domain context with 'protocol maintenance operation'. However, it does not explicitly differentiate from sibling tool 'annul_sp_request' (which cancels requests), leaving ambiguity about whether 'process' means execute, approve, or fulfill.
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 'protocol maintenance operation' provides implicit contextual guidance about when to use this tool (maintenance scenarios). However, it lacks explicit when-to-use criteria, prerequisites, or contrast with alternatives like 'annul_sp_request' for handling rejected requests.
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 disclosure burden and performs well: it explicitly states the tool builds an unsigned transaction (CBOR hex) requiring client-side signing, which is critical behavioral context for blockchain operations. It notes collateral is reclaimed, but omits potential failure modes or fee structures.
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, efficiently structured sentence uses an em-dash to separate the primary action from the implementation detail (CBOR hex). Every word earns its place; front-loaded with the verb and object; no redundancy or fluff.
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 complexity of CDP closure (4 parameters, blockchain context, no output schema), the description adequately compensates by specifying the return format (unsigned CBOR hex transaction). However, it omits whether the operation is final, if debt repayment is required beforehand, or what happens to minted synthetic assets.
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 75% (3 of 4 parameters have descriptions). The description adds no specific parameter guidance (e.g., explaining that cdpTxHash and cdpOutputIndex identify the specific UTxO, or clarifying the asset enum values), relying entirely on the schema. This meets the baseline for high-coverage schemas.
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 CDP), the resource (CDP), and the outcome (reclaim collateral). It effectively distinguishes from siblings like liquidate_cdp (forced closure by others), withdraw_cdp (partial removal), and burn_cdp (asset destruction) by specifying the standard user-initiated exit that returns collateral.
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 term 'close' implies this is for exiting a position completely, the description lacks explicit guidance on when to use this versus alternatives like withdraw_cdp (partial) or redeem_cdp. No prerequisites are mentioned (e.g., whether debt must be repaid first), leaving some contextual gaps for the agent.
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 successfully discloses what data is returned (prices and interest data alongside assets), but omits safety properties (read-only status), rate limits, or pagination 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?
Single efficient sentence with no redundant words. Information is front-loaded (action verb first) and 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?
While the tool is simple (no input parameters), there is no output schema provided. The description mentions 'prices and interest data' which partially hints at return content, but lacks details on data structure, pagination, or error handling.
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. The description does not need to compensate for missing 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 specific verbs ('Get') and resources ('Indigo iAssets'), explicitly scopes the operation ('all'), and distinguishes from siblings 'get_asset' (singular) and 'get_asset_price' by specifying inclusion of both 'prices and interest 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 word 'all' implies bulk retrieval versus single-asset lookups, providing implicit usage guidance. However, it lacks explicit when-to-use guidance or named alternatives (e.g., 'use get_asset for single asset lookups').
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 unsigned transaction pattern, CBOR hex format, and client-side signing requirement. Does not mention idempotency, validation failure modes, or gas fee handling, leaving minor gaps.
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 efficient sentence uses em-dash to append critical behavioral detail without verbosity. Every clause earns its place: action, scope, and implementation pattern are all conveyed with zero 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?
Adequate for a complex financial operation given the lack of output schema and annotations. Covers the core transaction pattern but omits return value structure details, collateral health constraints, or error conditions that would aid an agent in handling the unsigned transaction output.
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 75% with clear descriptions (bech32 format, lovelace units, enum values). The description adds no parameter-specific semantics beyond what the schema provides, 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific action ('Open') and resource ('CDP position'), and distinguishes from siblings by clarifying it 'builds an unsigned transaction (CBOR hex)' rather than executing on-chain. The 'new' modifier clearly scopes it to creation vs. adjustment tools like adjust_rob or deposit_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?
Provides implicit context that this is a preparation step requiring 'client-side signing,' which guides usage toward transaction building flows. However, lacks explicit when-to-use guidance vs. similar minting tools (e.g., mint_cdp) or prerequisites like minimum collateral ratios.
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?
Strong disclosure of critical execution pattern: 'builds an unsigned transaction (CBOR hex) for client-side signing' explains this is a transaction builder, not an executor. With no annotations provided, this disclosure is essential. Missing: irreversibility warnings, prerequisite balance checks, or fee disclosures expected for DeFi mutations.
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?
Optimal density: single sentence with two precise clauses. Front-loaded with action ('Burn iAssets'), followed by purpose ('reduce CDP debt'), then execution model ('builds unsigned transaction...'). Zero redundancy or 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?
Without output schema, description partially compensates by specifying return format ('CBOR hex'). Adequate for a transaction-building tool, though could explicitly state return type (string) or mention that successful execution requires subsequent signing and submission.
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% (high), with clear descriptions for address format, asset enum, and amount units. Description adds contextual relationship between parameters (burning iAssets reduces debt) but does not supplement schema with additional format details or constraints. Baseline 3 appropriate given schema carries heavy load.
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?
Excellent specificity: 'Burn iAssets to reduce CDP debt' provides clear verb (burn), resource (iAssets), and outcome (debt reduction). Effectively distinguishes from sibling tools like close_cdp (full closure), mint_cdp (debt increase), and liquidate_cdp (forced closure).
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 implicit guidance through 'reduce' (suggesting partial repayment vs. full closure), but lacks explicit when-to-use guidance. Does not clarify when to choose burn_cdp over close_cdp or deposit_cdp for debt management, leaving agents to infer from the 'reduce' verb alone.
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 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 provided, the description carries full behavioral burden and successfully discloses the critical trait that it 'Returns an unsigned transaction (CBOR hex) for client-side signing'—alerting the agent that execution is deferred and requires cryptographic signing. Missing minor details like idempotency behavior or 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?
Two sentences with zero waste: first states purpose, second states return value. Front-loaded with the action verb and contains no filler or redundant 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?
Despite lacking an output schema, the description compensates by specifying the return format (unsigned CBOR hex transaction). All 3 required parameters are documented in the schema. Would benefit from mentioning error conditions (e.g., if account already exists) but sufficient for tool 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 100%, with all three parameters (address, asset, amount) fully documented including enums and formats. The description mentions 'depositing iAssets' which aligns with the asset parameter, but adds no syntax, validation rules, or format 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?
Description provides specific verb (Create), resource (stability pool account), and mechanism (depositing iAssets). The word 'new' effectively distinguishes this from sibling adjust_sp_account (modification) and close_sp_account (termination), while the depositing action distinguishes from read-only get_* 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 term 'new' implies this is for initial account creation versus modification, but there are no explicit when-to-use guidelines, prerequisites (e.g., requiring existing iAsset balance), or explicit references to alternatives like adjust_sp_account for existing accounts.
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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description carries full burden and successfully discloses critical behavioral trait: it builds an unsigned CBOR hex transaction for client-side signing rather than executing on-chain. This informs the agent that the tool is non-destructive and returns data requiring external signing. Minor gap: doesn't specify which operations are blocked during freeze 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?
Single sentence efficiently front-loads the purpose ('Freeze a CDP') and uses an em-dash to append the mechanism detail. No redundant words; every clause provides distinct value (purpose, effect, return format).
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, description adequately compensates by specifying the return format (CBOR hex for client-side signing). Missing minor details: specific prerequisites (ownership), exact scope of frozen operations, or whether an 'unfreeze' tool exists among siblings.
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 75% with clear descriptions for address, cdpTxHash, and cdpOutputIndex; the asset enum is self-documenting. Description adds no parameter-specific semantics, but given high schema coverage, baseline adequacy is acceptable without additional compensation.
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?
Description provides specific verb 'Freeze', resource 'CDP', and scope 'prevent further operations until unfrozen', clearly distinguishing from sibling operations like burn, close, or liquidate. It also identifies the mechanism ('builds an unsigned transaction'), which differentiates it from direct execution 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?
Implies usage context ('prevent further operations until unfrozen') suggesting temporary suspension, but lacks explicit when-to-use guidance versus alternatives like close_cdp or adjust_cdp. Does not mention prerequisites (e.g., ownership requirements) or how to unfreeze.
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?
Strong disclosure that it 'builds an unsigned transaction (CBOR hex) for client-side signing' — critical behavioral detail given no annotations exist. Explains the output format compensates for missing output schema. Could mention if ROB positions are consumed/locked in the process.
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. Structure flows logically: action → mechanism → output format. Every clause provides distinct value (what, how, return type).
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 zero annotations and no output schema, the description appropriately explains the return value (CBOR hex). For a 4-parameter DeFi mutation, it covers the essential interaction model, though could note side effects on ROB 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 coverage is 75% (3/4 params described). Description adds no parameter-specific semantics, but schema adequately documents address, leverage, and baseCollateral. Asset enum is self-explanatory though undescribed.
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?
Excellent specificity: 'Open a leveraged CDP' distinguishes from sibling open_cdp, and 'by redeeming against ROB positions' clarifies the unique mechanism. Clearly identifies the resource (CDP) and action (open/leverage).
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 prerequisite context (requires ROB positions to redeem against) but lacks explicit when-to-use vs open_cdp or when-not-to-use guidance. No explicit alternatives named, though the mechanism hints at the specific use case.
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 successfully communicates that the tool builds an unsigned CBOR transaction for client-side signing rather than executing the liquidation directly, which is critical for blockchain operations. It could improve by mentioning liquidator requirements or collateral distribution outcomes.
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, efficiently structured sentence using an em-dash to separate the core action from the technical implementation detail. Every phrase serves a distinct purpose, with no redundant or filler content, making it appropriately sized for quick comprehension.
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 complexity of DeFi liquidation and the absence of annotations or output schema, the description adequately covers the essential behavioral contract: it identifies the stability pool mechanism, the unsigned transaction output format, and the undercollateralized precondition. It could be more complete by mentioning liquidator eligibility requirements or error conditions.
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% (three of four parameters have descriptions), with the 'asset' enum lacking a description string. The description provides implicit context that the address belongs to the liquidator and the CDP references identify the target, but does not explicitly map or add semantic detail beyond what the schema already provides for the documented parameters.
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 ('Liquidate'), target resource ('undercollateralized CDP'), mechanism ('through the stability pool'), and output format ('builds an unsigned transaction'). It effectively distinguishes this from sibling tools like close_cdp or burn_cdp by specifying the undercollateralized state and stability pool pathway.
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 usage context by specifying 'undercollateralized CDP,' indicating when liquidation is appropriate. However, it lacks explicit guidance on prerequisites (e.g., requiring iUSD or a stability pool account) and does not mention alternatives like close_cdp for healthy positions or explicit when-not-to-use 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?
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, the description carries full behavioral burden. It excellently discloses the critical return format (unsigned CBOR hex transaction requiring client-side signing), but misses lifecycle context—such as whether the position can be cancelled via cancel_rob, how long it remains open, or gas 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. Front-loaded with the action and resource, followed immediately by the critical return type information. Every word serves a purpose for a blockchain developer integrating this endpoint.
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, the description adequately explains the return value (unsigned transaction). However, for a 4-parameter financial operation with complex sibling interactions, it could mention the relationship to get_redemption_orders or the redemption queue mechanism.
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 75% (3/4 params described). The description mentions 'ADA' and 'max price limit' which align with lovelacesAmount and maxPrice, but doesn't add semantic meaning beyond the schema's existing descriptions. The 'asset' enum parameter is not contextualized in the description text.
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 (Open), resource (ROB/Redemption Order Book position), and key inputs (ADA, max price limit). It distinguishes itself from siblings like adjust_rob, cancel_rob, and redeem_rob by specifying this creates a 'new' position.
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 word 'new' implies this is for initial creation (vs. adjust_rob for modifications), there are no explicit when-to-use guidelines, prerequisites, or named alternatives. It doesn't clarify when to use this versus redeem_rob or how it interacts with the redemption queue.
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?
No annotations provided, so description carries full burden. It excellently discloses the critical pattern that this 'builds an unsigned transaction (CBOR hex) for client-side signing' rather than executing immediately. However, it omits side effects (CDP state modification), validation constraints (minimum collateral ratios), or reversibility.
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 with zero waste. Front-loaded with the core action ('Withdraw collateral from a CDP') followed immediately by essential behavioral context ('builds an unsigned transaction...'). 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?
Given no output schema and no annotations, the description appropriately identifies the return format (CBOR hex) and signing requirement. Could be improved by noting the CDP state change (collateral reduction) and any protocol-specific constraints, but covers the critical execution pattern.
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 high at 80% with clear descriptions for address, cdpTxHash, cdpOutputIndex, and amount. The description adds minimal semantic detail beyond the schema (e.g., doesn't clarify 'asset' enum relationship to collateral type), but the schema does the heavy lifting sufficiently.
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?
Description provides a specific verb ('Withdraw') + resource ('collateral from a CDP') and clearly distinguishes from siblings like deposit_cdp, close_cdp, or liquidate_cdp. The scope is precisely defined.
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 action is clear, the description lacks explicit guidance on when to choose this over close_cdp (which also removes collateral but closes the position) or redeem_cdp. Usage is implied by the verb but not contextualized against 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 and successfully discloses the critical behavioral trait that this returns 'an unsigned transaction (CBOR hex) for client-side signing,' indicating it is a transaction builder requiring external signing rather than immediate execution. It does not mention idempotency, reversibility, or specific auth requirements beyond the signing implication.
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 front-loads the core action with parenthetical mechanics, while the second clearly states the return format. There is no redundant information; every clause provides necessary context for tool selection or 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 return value format (unsigned CBOR hex transaction). With 100% schema coverage and clear parameter semantics covered in the description, it provides sufficient context for an agent to invoke the tool, though prerequisites (e.g., requiring an existing ROB position) are not explicitly stated.
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?
While the schema has 100% coverage (baseline 3), the description adds valuable semantic context beyond the schema: it explains the business logic for lovelacesAdjustAmount (increase vs decrease), clarifies that newMaxPrice is optional ('Optionally update'), and frames robTxHash/robOutputIndex as identifying the 'ROB position' rather than just raw UTXO coordinates.
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 ADA amount'), the resource ('ROB position'), and distinguishes from siblings like adjust_sp_account and adjust_staking_position by specifying the ROB context. It includes the directional mechanics (positive/negative) in the same sentence.
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 provides implicit usage guidance for the lovelacesAdjustAmount parameter ('positive to increase, negative to decrease') and notes the optionality of the max price update. However, it lacks explicit comparison with sibling ROB tools (cancel_rob, redeem_rob, claim_rob) to clarify when to adjust versus close or redeem a position.
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 disclosure burden and successfully communicates the critical behavioral trait that it 'Returns an unsigned transaction (CBOR hex) for client-side signing,' indicating the operation is not immediately executed. It could improve by mentioning error conditions if the account doesn't exist or minimum balance requirements.
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 three efficient sentences with zero waste: purpose declaration first, mechanism clarification second, and return format third. Every sentence earns its place without redundancy or fluff.
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 an output schema, the description appropriately explains the return value (unsigned CBOR hex transaction). With 100% input schema coverage and five well-documented parameters, the description provides sufficient context for invocation, though it could explicitly state the prerequisite that the account must already exist.
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?
While the schema has 100% coverage (baseline 3), the description adds essential semantic meaning by clarifying 'Positive amount deposits, negative withdraws,' which explains the sign convention for the amount parameter beyond the schema's technical description.
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 tool 'Deposit[s] to or withdraw[s] from an existing stability pool account,' using specific verbs and clearly identifying the resource. The word 'existing' effectively distinguishes this from sibling create_sp_account, while 'deposit/withdraw' differentiates it from close_sp_account.
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 prerequisite context by specifying 'existing' stability pool account, hinting that create_sp_account must be used first. However, it lacks explicit guidance on when to choose this over close_sp_account (e.g., partial vs. full withdrawal) or decision criteria for depositing versus withdrawing.
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?
No annotations provided, so description carries full burden. Successfully discloses critical behavioral traits: mutation type (debt increase), transaction format (unsigned CBOR hex), and execution model (client-side signing required). Does not mention collateral requirements or liquidation risks.
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 core action, parenthetical for financial implication, em-dash for technical implementation details. 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?
Appropriate for complexity level. Without output schema, explicitly states return type (CBOR hex). Covers debt mechanics and signing requirements. Could enhance with collateral health warnings or prerequisite checks, but sufficient for safe 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?
Schema coverage is 80% (4/5 params described). The 'asset' parameter lacks schema description but the description compensates by specifying 'iAssets', giving semantic context to the enum values (iUSD, iBTC, etc.). Baseline 3 raised to 4 for gap compensation.
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 specific verb 'Mint' with resource 'iAssets from an existing CDP', distinguishing from open_cdp. Parenthetical '(increases debt)' clarifies financial effect. Em-dash section clarifies output format (unsigned CBOR hex) and signing requirement.
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 through 'existing CDP' (suggests not for new positions) and 'increases debt' (suggests opposite of burn_cdp). However, lacks explicit when-to-use guidance or named alternatives versus siblings like leverage_cdp or deposit_cdp.
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. Effectively discloses the unsigned transaction pattern ('CBOR hex for client-side signing'), which is crucial behavioral context preventing mistaken assumptions about direct chain submission. Could improve by describing state change effects (what happens to collateral/CDP after redemption).
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 core action, followed by mechanism (CBOR hex), followed by usage tip. Efficient structure where 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?
Given no output schema, description adequately covers the tool's purpose and mechanism. Missing explicit clarification of redemption economics (burning iAssets to unlock collateral) and return value structure, but sufficient for an AI agent to invoke correctly given the high-quality input schema.
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 high (80%), establishing baseline context. Description adds valuable semantics for the 'amount' parameter specifically (explaining the 'total minted amount' pattern for max redemption), which is not obvious from the schema's 'smallest unit' description alone.
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 ('Redeem') + resource ('iAssets from a CDP') clearly stated. Distinguishes from siblings (mint_cdp, burn_cdp, close_cdp) by specifying redemption action. Includes critical mechanism detail ('builds an unsigned transaction (CBOR hex)') that clarifies this is a transaction builder, not direct submission.
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 specific usage tip for the amount parameter ('To redeem the maximum possible, pass the total minted amount'), but lacks explicit when-to-use guidance versus siblings like close_cdp or withdraw_cdp. No mention of prerequisites (e.g., needing sufficient iAssets to burn) or workflow context.
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