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

Beyond the readOnlyHint annotation, the description discloses that this is a heuristic economic assessment based on DeFiLlama and CoinGecko, and explicitly lists what it does not audit. It also tells the agent what kind of output to expect (a branched verdict with supporting evidence), which is rich behavioral context that the annotation alone does not provide.

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 well-structured with front-loaded purpose, followed by Use when, Limitations, and Alternatives. Every sentence adds distinct value, and the section headers make the information easy to scan for an agent. There is no repetition of schema or annotation 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?

Given one parameter, a fully descriptive schema, an output schema, and readOnlyHint annotation, the description supplies the remaining operational context: when to delegate the check, what the verdict branches are, what evidence sources back it, and what it cannot guarantee. Nothing essential is missing for an agent to decide whether and how to invoke this 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?

The input schema already fully describes pool_id as a DeFiLlama yield pool UUID with an example, and schema_description_coverage is 100%. The description adds some contextual framing that pool_id refers to a DeFi yield pool or staking opportunity, but it does not substantially extend the parameter meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description opens with a specific verb and outcome ('Return a decision-ready yield-opportunity verdict') and names the exact decision branches: sustainable, caution, unsustainable, or insufficient_data. It clearly distinguishes this from sibling data-fetching tools like get_yield_rates and get_protocol_tvl by framing it as an independent decision check rather than a raw data lookup.

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 'Use when' section gives an explicit trigger: before deploying capital when an independent sustainability and liquidity decision is needed. The 'Alternatives' section names the relevant sibling tools, giving the agent concrete routing options, and the 'Limitations' section implicitly tells the agent what this tool should not be used for, such as auditing smart contract bytecode or governance.

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