yieldoracle

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

No annotations provided, so description must carry full burden. It does not disclose behavioral traits such as data freshness, rate limits, or side effects. The description only states what the tool does, not how it behaves or any constraints.

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

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

Two sentences, no unnecessary words. Each sentence provides meaningful information: first states core function, second adds context. Perfectly concise for the complexity.

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

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

Given no output schema, the description usefully mentions return elements (top pools, TVL, average APY). It misses details like pagination or sorting but is sufficient for a simple query tool. With no annotations, this is reasonably 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 coverage is 100%, so baseline is 3. Description loosely references parameters ('chain', 'limit', 'min_tvl') but adds no additional meaning or examples beyond what the schema already provides in the chain parameter's explicit listing of chains.

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

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

Description clearly states the tool shows 'best yields on a specific chain' with specific outputs (top pools, total chain TVL, average APY). It distinguishes from siblings by focusing on chain-specific data, providing a clear verb-resource pair.

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

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

Explicitly suggests use for 'chain-specific farming strategies,' giving clear context. However, it lacks explicit when-not-to-use guidance or alternatives, though the sibling list provides context.

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

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

No annotations are present, so the description carries full burden. It lists topics but does not disclose whether the operation is read-only, authentication needs, rate limits, or any side effects. This lack of transparency is a significant gap for a tool with no 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 a single sentence listing items, which is efficient. However, it could be better structured (e.g., bullet points) to improve readability and clarity. It earns its place without redundancy.

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

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

Given no parameters and no output schema, the description is the sole source of information. It lists categories but lacks detail on the depth or format of each category (e.g., what statistics are included). It is adequate but could be more complete for a general-purpose info tool.

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

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

There are zero parameters, so the description's role is to explain what information the tool returns. It adds meaning beyond the empty schema by describing the categories of information provided (health, stats, status, etc.). Baseline is 4 for 0 params.

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 lists specific categories (server health, data stats, API status, tool list, pricing), indicating a broad status overview tool. This distinguishes it from sibling tools that focus on specific yield data.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. However, the sibling tool names imply this is for general status checks versus specific yield queries, so context offers partial guidance.

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

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

No annotations are provided, so the description carries the burden. It discloses the premium nature and free units for new wallets, but does not mention behavior like idempotency, error handling, or rate limits. The description focuses on features rather than operational traits.

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

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

The description is a single sentence but includes promotional language and payment instructions. It is somewhat concise but could be more focused on functionality without the marketing elements.

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

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

Given 4 parameters and no output schema, the description provides enough for core understanding but lacks details on output format, error messages, or how the risk adjustment interacts with parameters like min_tvl.

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% with brief descriptions for each parameter. The tool description does not add additional context or constraints beyond what the schema provides, so it meets the baseline for high coverage.

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

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

The description clearly states the tool's function: 'APY adjusted for risk — pools ranked by real expected return after factoring liquidity, volatility, IL, and sustainability.' It distinguishes from siblings by focusing on risk adjustment, which is not mentioned in other sibling tool names.

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 mentions payment requirements and suggests using the tool via a specific URL with a header, but does not explicitly state when to use this tool versus alternatives like top_yields or yield_compare. No exclusion criteria are provided.

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

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

No annotations are provided, so the description carries the full burden. It transparently discloses the premium nature, payment requirement, and free units for new wallets. This is sufficient behavioral context.

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

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

The description is reasonably concise for the information it conveys, but the call instructions could be considered implementation detail. It is well-structured with an emoji and clear separation of concepts.

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

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

Given the tool has only one optional parameter and no output schema, the description covers the essential aspects: purpose, access method, and payment. It could mention the expected output format, but it's acceptable.

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% for the single 'limit' parameter, so baseline is 3. The description does not add extra meaning beyond the schema's description ('Results (default: 15)').

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's purpose: it provides tokenized treasury and Real World Asset yields, listing specific providers (BlackRock, Ondo, etc.). The emoji and 'institutional DeFi layer' further clarify its focus, distinguishing it from siblings like 'chain_yields' or 'stablecoin_yield'.

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

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

The description explicitly states that the tool is premium and requires payment via x402, along with call instructions. It mentions a free allowance for new wallets. However, it does not directly compare to sibling tools or provide when-not-to-use guidance.

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

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

With no annotations, the description discloses key behaviors: ranking by APY, filtering for sustainability (<200% APY) and real TVL. It implies read-only operation. However, does not detail data freshness or edge cases.

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

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

Two concise sentences front-loaded with the core purpose and key filters. No fluff; every sentence adds value.

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

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

Given the tool has 3 parameters, no output schema, and 7 sibling tools, the description adequately defines its niche and filtering logic. Could mention result format or pagination, but sufficiently complete for agent decision-making.

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 covers all three parameters with descriptions (100% coverage). The tool description adds the sustainability filter context but does not enhance parameter meanings beyond what schema provides. 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?

Description clearly states it ranks stablecoin yields by APY with sustainability and real TVL filters, distinguishing it from sibling tools like chain_yields or top_yields by focusing on stablecoins and safety.

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?

Suggests 'treasury management' as a use case but does not explicitly compare to sibling tools or provide when-not-to-use guidance. Implicitly, it's for stablecoin-focused safe yields, but lacks exclusion criteria.

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

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions the data source ('19K+ DeFi pools via DeFiLlama') but fails to disclose other behaviors such as sorting order (highest APY assumed), update frequency, rate limits, or what happens if no data matches. Minimal transparency beyond source.

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

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

Two sentences, zero waste. The main purpose is front-loaded and the filtering options are clearly summarized. Efficient and well-structured for quick agent parsing.

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

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

Given no output schema, the description should ideally describe the return format or fields. It mentions 'highest APY' implying sort order, but lacks detail on what data is returned per pool. Given four parameters and eight sibling tools, the description is moderately complete but missing key behavioral and output context.

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 each parameter is already explained in the input schema. The description merely reiterates filtering options without adding new meaning or syntax details. Baseline of 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the verb 'Get' and the resource 'highest APY yield pools across all chains and protocols.' It is specific but does not explicitly distinguish from sibling tools like chain_yields or risk_adjusted, which may also cover all chains. Lacks sibling differentiation.

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 mentions filtering options (min TVL, chain, stablecoin-only), implying when to use it with those filters. However, it provides no explicit guidance on when not to use this tool or what alternatives exist among the eight sibling tools. Usage is implied but not clearly directed.

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

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

No annotations provided, so description carries full burden. It describes the comparison action and metrics, but does not mention side effects, permissions, rate limits, or data freshness. Adequate but minimal.

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

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

Two sentences plus example. No wasted words. Front-loaded with action and metrics.

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

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

Given no output schema, description specifies what metrics are returned (APY, TVL, chains, top pools). Could mention return format (e.g., table or JSON) but sufficient for an agent to understand output.

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

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

Schema covers 100% of parameters with descriptions. Description adds example values but not new semantic meaning. 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?

Description clearly states the tool compares two protocols side by side, lists specific metrics (APY, TVL, chains, top pools), and provides an example. Distinguishes from siblings like top_yields which are not pairwise.

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

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

No explicit 'when to use' or alternatives, but the name and description make the tool's purpose obvious. Example clarifies usage. Siblings are different (e.g., chain_yields, top_yields), so context helps.

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

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

With no annotations, the description fully discloses that the tool requires payment ($0.03 via x402), returns specific metrics, and provides free units for new wallets. It transparently explains the payment mechanism and search options.

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 plus a bulleted list, efficiently packing all key information. It starts with the premium indicator and payment details, followed by the tool's capabilities and search methods.

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

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

Given the moderate complexity (2 parameters, no output schema, no annotations), the description covers the essential behavioral aspects, payment requirements, and return values. It could benefit from an example call or clarifying parameter preference, but is largely complete.

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

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

The input schema already has 100% coverage with descriptions for query and pool_id. The description adds that search is by name, symbol, or pool ID, but confirms the schema's detail. No new constraints or relationships between parameters are added.

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 performs a deep scan of a specific pool or token, listing specific outputs (APY breakdown, TVL, risk score, IL exposure, 30d average). It distinguishes from siblings by its premium nature and detailed analysis focus.

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 explains the premium payment requirement and provides call instructions with X-PAYMENT header. However, it does not explicitly state when to use this vs. alternatives like top_yields or chain_yields, though the premium tag implies it's for deep analysis.

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