list_registered_farms

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

With no annotations, the description carries the full disclosure burden. It usefully states this is a read-only snapshot ('at one block') and declares what it does not compute (yield, liquidity), but it says nothing about permissions, freshness/staleness of the block, or whether the set can change between calls.

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?

A single tightly constructed sentence with the resource and scope front-loaded, followed by an appended negative constraint. Every clause carries information and none is wasted.

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 parameterless read with no output schema and no annotations, the description adequately conveys the returned domain (farm addresses and enabled asset addresses) and the excluded domain (yield, liquidity). Only the shape/format of the response is left unstated, which is a minor gap for a simple list.

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 schema has zero parameters, which earns the baseline 4. The description introduces a conceptual notion ('at one block') that is not represented in the schema, but since there is nothing to invoke, no parameter-level detail is missing.

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 gives a specific verb ('Read') and a precise resource ('registered Ethereum mainnet farm addresses and enabled asset addresses'), plus a scope qualifier ('at one block'). It is clear on its own, but it never names or contrasts with its siblings (get_farm_state, get_token_supplies), so an agent must infer the distinction rather than being told.

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?

There is no explicit when-to-use or when-to-choose-an-alternative statement, but 'does not infer current yield or liquidity' functions as an implicit boundary, steering agents away from expecting analytics. The sibling that would actually serve those needs (get_farm_state) is never mentioned, so guidance remains implied rather than actionable.

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