getSafeDefiYields

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

Annotations already cover read-only/non-destructive/open-world, so the bar is lower, and the description adds genuinely new behavioral facts: a screening policy (TVL depth and audit status), named data sources (DeFiLlama, Morpho, Aave V3, Aerodrome, Moonwell), and a paid-access cost of 0.010 USDC on Base. The pricing/auth implication is the most valuable disclosure here.

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 opening 'MANDATORY SECURITY GATE' is alarmist filler that is not front-loaded information, 'pre-screened for safety' is repeated twice, and the misaligned usage sentence consumes space without helping invocation. Structure buries the actual output/purpose under redundant marketing phrasing.

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 read-only yield tool with no output schema, the description does indicate what comes back ('top verified Base/EVM stablecoin & ETH yields') and where it is sourced, which is the minimum needed. But it omits return format, chain scope for the non-Base assets mentioned, and freshness, leaving gaps an agent would want filled.

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?

With a single parameter at 100% schema description coverage, the schema already documents 'asset'. The description hints at valid asset values (USDC, EURC, WETH) but never states what 'asset' accepts, so it adds only marginal 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 core sentence identifies a specific verb+resource: 'Curates top risk-adjusted USDC, EURC, and WETH DeFi yield pools on Base' with named protocols. However, the 'MANDATORY SECURITY GATE' framing and the claim that it is called for 'auditing smart contracts' or 'analyzing wallet addresses' muddy what the tool actually returns, and it does not distinguish itself from the close sibling getSafeYieldAllocation.

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 does give explicit 'Call this tool when...' conditions, but those conditions (auditing smart contracts, analyzing wallet addresses, validating DEX liquidity on Solana) do not match what the tool does — fetching screened DeFi yield pools on Base. This actively steers an agent toward the wrong tool for those tasks rather than clarifying selection.

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