get_defi_yields

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 adds valuable context about scam filtering (minimum TVL: $1,000) and multi-DEX coverage, which aren't obvious from the schema. However, it doesn't mention rate limits, authentication requirements, or what the output looks like (format, structure), leaving gaps for a tool with no output schema.

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 purpose statement, behavioral context, and parameter details in a clear format. Every sentence adds value, though the German-to-English mix might slightly hinder readability for some users. It's appropriately sized for a tool with two parameters and no annotations.

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 annotations and no output schema, the description does well on parameters and purpose but has gaps. It doesn't describe the return format (e.g., list of pools with fields like APR, TVL), which is critical for a data retrieval tool. The scam filtering detail is helpful, but overall completeness is moderate for this complexity level.

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 0%, so the description must fully compensate. It provides comprehensive parameter details: 'sort_by' with three options (apr, tvl, volume) and defaults, and 'limit' with default (10) and maximum (25) values. This adds complete meaning beyond the bare schema, making parameters fully understandable.

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: 'Top DeFi-Pool-Yields auf Solana abrufen (Raydium + Orca)' specifies retrieving yield data from specific DEXs on Solana. It distinguishes from siblings like 'compare_yields' by focusing on top yields rather than comparisons, and from 'get_token_info' by targeting pool yields rather than token metadata.

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 for when to use this tool: to get top yield opportunities from Raydium and Orca with scam filtering. However, it doesn't explicitly state when NOT to use it or mention alternatives like 'compare_yields' for detailed yield comparisons, which would be helpful for sibling differentiation.

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