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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, lowering the bar. The description still adds real behavioral context beyond them: the liquidity filter (> R$ 1 mi/dia), the exact same-day convention for ágio/deságio, the 'total return by construction' basis for 12-month return, and the effective-fee formula plus the disclosure that no nominal fee exists publicly ('Gratuito' also signals cost). It does not disclose return format, hence not a 5.

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 dense paragraph that front-loads the resource and then defines each metric. Every clause carries load (definitions and eligibility rule), though the parenthetical formulas make it run-on and dense for a caller skimming. Efficient overall.

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?

With no parameters and no output schema, the description carries the burden of explaining what is returned, and it does explain the metrics and their computation caveats well. It is slightly incomplete on the shape of the response (sort order, field names), which matters more because no output schema exists.

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 tool takes no parameters (parameter count 0), so the baseline of 4 applies. There is nothing schema-side to document, and the description cannot add parameter meaning beyond that.

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 names a precise resource (ETFs listed on B3) and enumerates the exact rankings it produces: most traded, largest patrimônio, largest ágio, 12-month return, lowest effective fee. This clearly separates it from 'etf' (single ETF) and 'fiis_ranking' (FIIs, not ETFs) by implication. It stops short of explicitly naming a sibling to route against, so it falls just below the 5 bar.

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 metric definitions imply the use case (get a ranked view of liquid B3 ETFs), and the eligibility note 'Só ETF líquido (> R$ 1 mi/dia) entra em ágio, retorno e taxa' tells the agent which tickers are filtered. But there is no explicit when/when-not guidance or contrast with alternatives like 'etf' or 'fiis_ranking', so usage is only implied.

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