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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It explains that the tool returns an assessment and recommendation, and it requires an api_key, but it never explicitly states that the tool is read-only or that it does not execute on-chain transactions. This is important context for a DeFi tool, though the word 'assess' and phrase 'before making any moves' do imply a non-executive advisory role.

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: a concise purpose statement, usage guidance, a clear args list, and a return-value summary. It is somewhat longer than necessary because the args list repeats parameter names already in the schema, but each line adds valuable semantic detail. Overall, the organization is logical and front-loaded, earning a slightly above-average score.

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 tool with 7 parameters, no output schema, and no annotations, the description covers the essential aspects: it explains parameters thoroughly, describes the return value structure (chain viability, ranked opportunities, gas analysis, break-even calculations, and recommendation), and states when to use it. It lacks details on error behavior or data freshness, but these are not critical for understanding the tool's primary function.

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 provides no per-property descriptions (0% coverage), but the description compensates fully by explaining each parameter with concrete examples and constraints. It gives allowed values for action ('supply' or 'borrow'), strategy ('yield_farming', 'active_trading', 'idle_capital'), chain ('ethereum', 'arbitrum', 'any'), and clarifies that trades_per_day applies only to 'active_trading' with a default of 10. This adds meaning far 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 clearly states the tool's purpose: 'Assess the best DeFi opportunity for a given capital amount and strategy.' It also frames it as the 'cold start' tool, distinguishing it from more granular sibling tools like get_ranking or gas_timing. The mention of delivering chain viability, ranked opportunities, gas impact, and a recommendation makes its role specific and immediately understandable.

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 says to 'call it first' and frames it as the entry point before making moves, which provides clear when-to-use guidance. However, it does not mention specific when-not-to-use scenarios or name alternative tools for particular follow-up checks, so it falls short of full exclusionary guidance.

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