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

Annotations already mark readOnlyHint=true; the description reinforces this by explicitly stating the server never holds keys, signs, or broadcasts. Adds the quote-expiry behavior and designates the caller as the signer. No contradiction with annotations.

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

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

Four clear sentences, each adding distinct information: purpose, unsigned/safety model, signer responsibility, and timing. No redundant or filler wording; important constraints are front-loaded.

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

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

For a two-parameter tool with annotations, the description covers the output type (unsigned transaction), the security boundary (no signing/broadcasting), the prerequisite (quoteId), and the freshness requirement. Although no output schema exists, the description discloses the essential return information, making it complete enough for correct invocation.

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

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

Schema already describes both quoteId and userAddress with 100% coverage. The description adds a small clarification that quoteId originates from get_quote, but this largely mirrors the schema. Baseline 3 applies because the schema carries the parameter documentation.

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

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

States a specific action ('Turn a quoteId... into transaction data') and identifies the resource (swap transaction). Clearly distinguishes from sibling tools like get_quote by referencing it as the input source and by specifying the unsigned-transaction output.

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

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

Provides clear context: use after get_quote and before quote expiry. Mentions the prerequisite quoteId and that the transaction is subsequently signed/submitted by the caller. Does not explicitly name sibling alternatives or negative conditions, but the context is sufficient.

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

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

The description discloses important behavior beyond annotations: the server never signs, never submits, never holds keys or funds, and returns an unsigned transaction with an empty witness set plus a summary. This clarifies the exact execution boundary and what the agent must do next.

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

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

The description is compact and front-loaded with the core operation, then covers identification, return value, safety boundary, and prerequisites. Every sentence carries useful information without filler.

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

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

There is no output schema, so the description appropriately explains the return payload: CBOR-hex unsigned transaction, empty witness set, and human-readable summary. It also names required environment variables and the CIP-30 signing handoff, making the full call context complete.

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

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

Schema description coverage is 100%, and the schema already documents that txHash and outputIndex come from cdpOutRef in get_position and that address is the Bech32 CDP owner. The description reinforces this provenance but does not add meaning beyond the schema.

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

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

The description states a specific action and resource: building a transaction that closes an Indigo CDP, with concrete sub-effects (burn iAsset debt, withdraw ADA collateral). This clearly distinguishes it from siblings like open_cdp and build_swap_tx.

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

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

It explicitly ties the CDP to an out-ref from get_position with protocol "indigo", giving the agent a clear input source and workflow. It does not explicitly say 'use this only when closing an Indigo CDP, not for other operations', but the close-specific wording makes the intended use clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds two genuinely new behavioral facts: the BLOCKFROST_PROJECT_ID requirement and the fact that unseen addresses return zero balance. This goes beyond annotation coverage and helps the agent anticipate side effects and requirements.

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

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

Two sentences, no filler. The core action is front-loaded, followed by the read-only nature, the environment requirement, and the notable zero-balance behavior. Every clause earns its place.

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

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

For a simple one-parameter read tool with readOnlyHint and openWorldHint already provided, the description covers the essential usage requirements (env var, zero-balance edge case). It does not describe return format or error handling, but with no output schema and a trivial operation, that is a minor gap. It is adequate for an agent to invoke correctly.

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

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

The schema covers the single parameter fully with its own description ('Bech32 Cardano address (addr1... / addr_test1...)'). The tool description does not add anything beyond the schema for the parameter, so the baseline of 3 applies. It correctly points to the address parameter but adds no new syntax or format details.

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

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

The description states a specific verb ('Read') and a clear resource ('ADA and native-asset balance of a Cardano address from Blockfrost'). It unambiguously distinguishes this from sibling tools like get_venue, get_quote, or open_cdp, which target different domains. No ambiguity remains about what this tool does.

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

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

The description implies when to use it (for reading balances) and provides practical context: it requires BLOCKFROST_PROJECT_ID and explains the zero-balance behavior for unseen addresses. It does not explicitly exclude alternatives, but siblings are so different in purpose that no confusion is likely. It clearly frames this as a read operation.

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

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

Annotations already establish readOnlyHint and openWorldHint, so the read-only claim is expected; however, the description adds meaningful context by stating 'no API key needed,' specifying 'live Liqwid v2' data, and naming the exact data fields returned. No behavioral contradictions with the annotations.

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

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

The description is two sentences with no filler. The main purpose is front-loaded, followed by authentication context, then the parameter behavior with examples. Every sentence earns its place.

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

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

For a simple read-only getter with one optional parameter, the description is complete: it states what data is returned, that it is live, that no API key is needed, and how to filter. The absence of an output schema is mitigated by explicitly listing the returned metrics.

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

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

Schema coverage is 100% and already documents asset as a case-insensitive display-name filter, so the baseline is 3. The description adds value by giving concrete examples ('ADA', 'iUSD') that illustrate valid asset values, which the schema alone does not provide.

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

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

The description opens with a specific verb and resource: 'Read live Liqwid v2 money-market data,' then enumerates exactly what is returned (supply APY, borrow APR, utilization per market). This makes it easy to distinguish from sibling tools like get_quote or get_balance.

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

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

The description implies the tool is for read-only market data and notes that no API key is needed, but it never explicitly states when to prefer this over alternatives or when not to use it. Usage context is clear, but exclusion/alternative guidance is missing.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces this with 'Read-only.' Beyond that, it details what data is returned for each protocol (e.g., collateral, debt, health factor), which gives the agent concrete expectations about the operation's behavior without contradicting the annotations.

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

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

The description is two sentences with no redundant phrasing. It front-loads the core purpose, then provides concise protocol-specific details, all in an efficient and structured manner.

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

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

Since there is no output schema, the description appropriately explains the return values for both protocols, including the CDP out-ref that close_cdp needs. It covers everything an agent needs to know to invoke the tool and interpret its result.

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

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

Schema coverage is 100%, so both parameters (address and protocol) are fully documented in the schema. The description does not add additional meaning to the parameters beyond what the schema already provides, so it earns the baseline score of 3.

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

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

The description clearly states the tool reads open positions for a Cardano address, and then enumerates the exact types (Indigo CDPs and Liqwid loans) with their key fields. It also distinguishes itself from siblings like get_balance by focusing on positions, making its purpose unambiguous.

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

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

The description provides clear context on when to use the tool (to read positions from specific protocols), and the protocol parameter selects the type. It does not explicitly mention alternatives or exclusions, but the sibling set and the explicit protocol choice make the intended usage evident.

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

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

Annotations already declare readOnlyHint and openWorldHint. The description adds value beyond that: it explains the racing behavior, the ~25-second latency, that it returns both the best route and all routes sorted by net output, and the relationship to build_swap_tx. No contradictions with annotations.

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

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

Four sentences, all carrying weight: purpose, read-only safety, amount units, and quoteId integration / timing. Purpose is front-loaded; no filler or repetition.

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

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

With no output schema, the description explains the return shape at a high level (best route + all routes sorted, quoteId) and covers latency and safety. It could detail the route object structure or error cases, but given the strong annotations and 100% schema coverage, only a minor gap remains.

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

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

Input schema has 100% description coverage, so the baseline is 3. The description repeats the amount-unit detail already in the schema ('Amounts are in the source token's smallest unit') and adds no new meaning for parameters like slippage, fromChain, or userAddress.

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

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

The description opens with a specific verb and resource: 'Race the BazaarSwap routing backend for cross-chain swap quotes' and states the exact output (best route plus every route, sorted by net output). It differentiates from build_swap_tx by noting the returned quoteId feeds that tool.

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

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

The description gives clear context: read-only, no funds moved, quoteId feeds build_swap_tx, and a ~25s race duration. However, it does not explicitly name alternatives or state when NOT to use this tool, so it stops short of the 'explicit when/when-not/alternatives' bar.

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

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

The description repeats the read-only annotation but adds value by detailing what the record contains. It does not cover error cases or rate limits, but given the simple read-only nature and annotation coverage, the provided details are sufficient.

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

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

Two sentences with no filler. The first sentence front-loads the purpose and output contents, the second confirms read-only. Every word serves a purpose.

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

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

For a simple one-parameter read tool with no output schema, the description adequately explains what is returned. It lacks explicit error behavior or a pointer to list_venues, but those are minor gaps given the tool's simplicity and the read-only annotation.

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

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

Schema description coverage is 100%, so the schema already describes the id parameter. The description adds multiple concrete examples ("minswap", "liqwid", "indigo") and the phrase "by id" clarifies the expected input context, going slightly beyond the schema.

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

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

The description states a specific verb and resource (Get the full taxonomy record) and differentiates from list_venues by focusing on a single venue by id. It also enumerates the fields included (category, url, assets, capabilities, integration level, caveats), which makes the purpose unambiguous.

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

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

The description implies usage: call this tool when you have a known venue id and need the full record. It does not explicitly mention alternatives like list_venues for discovering ids or when not to use this tool, leaving the usage context to be inferred.

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

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

The readOnlyHint annotation already signals safety, and the description adds meaningful context by stating 'Read-only: returns index data, not live chain state.' This clarifies that results are from the index, not a live chain query, which is valuable beyond the annotation.

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

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

Two tight sentences, front-loaded with the core purpose, then filter options, then an important read-only qualifier. No wasted words or redundant repetition of schema details.

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

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

For a simple list tool with 4 optional parameters, full schema coverage, and a readOnlyHint, the description provides enough to invoke it correctly: what it lists, which filters exist, what free-text query searches, and what the data scope is. No output schema exists, but the nature of a venue list makes the return shape largely predictable.

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

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

Schema coverage is 100%, so the baseline is 3, and the description adds value by expanding on the parameter meanings: it lists venue category types, explains what 'asset' refers to, and specifies that 'query' searches id, name, description, and assets. This complements rather than repeats the schema.

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

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

The description states a specific verb and resource: 'List the indexed Cardano DeFi venues' with concrete category examples. This clearly distinguishes list_venues from singular sibling tools like get_venue.

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

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

The description conveys clear usage context: it is the collection-listing tool with optional filters for category, asset, capability, and free-text query. It does not explicitly name alternatives or exclusions, but the list-oriented framing makes when-to-use unambiguous.

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

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

Annotations provide only readOnlyHint=false, openWorldHint=true, and destructiveHint=false. The description adds substantial behavioral disclosure: the server never signs, never submits, never holds keys or funds, the returned tx is unsigned and must be signed by the agent, and Pyth-priced txs expire and fail on-chain if stale. No contradiction with annotations.

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

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

Four dense sentences, each earning its place: the first states the main purpose and return value, the second covers the critical timing caveat, the third clarifies the security/trust model, and the fourth lists prerequisites. There is no filler or redundancy.

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

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

Despite having no output schema, the description fully specifies what the agent receives, what to do next, what can fail, and what environment prerequisites are needed. It covers return format, signing/submission workflow, expiry behavior, collateral type, and required configuration, making the tool safe and actionable.

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

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

Schema description coverage is 100%, so all four parameters are already documented with units and formats. The description reinforces that ADA collateral is used and gives 'iUSD' as an example iAsset, but it does not meaningfully extend parameter semantics beyond the schema. Baseline 3 is appropriate.

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

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

The description names a specific verb ('build') and resource ('transaction that opens an Indigo CDP'), with concrete actions ('lock ADA collateral and mint an iAsset') and the precise return type ('UNSIGNED transaction as CBOR hex with an empty witness set, plus a human-readable summary'). This clearly distinguishes it from sibling tools like close_cdp and build_swap_tx.

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

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

The description gives clear context for use: it is for opening a CDP and the caller must sign and submit the result. It also provides a critical timing guideline with the ~280-second price-validity window and instructs to rebuild if the tx goes stale. It does not explicitly name sibling alternatives, but the usage context is unambiguous.

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