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 discloses: only unflagged values are included, an API key is required (free or Pro), survivorship bias is acknowledged and declared in the response, as_of results include 'disponivel_em', and recibo freezes the response with an sha256. It also notes that 'ano' and 'as_of' are mutually exclusive. This is an exceptionally rich behavioral description for a tool with no annotations.

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?

Although long, every sentence carries operational information. It is front-loaded: purpose and differentiation first, then parameter semantics, then behavioral caveats. No fluff or repetition. The length is justified by the tool's complexity (5 parameters, nested dict, multiple time-related options). It reads as a compact but complete manual.

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 the absence of an output schema, the description gives some output cues (each row includes 'disponivel_em' for as_of; survivorship bias is declared in the response). It covers the main call semantics, filters, and edge cases. Missing details like pagination or result ordering are minor, but for a tool with no output schema and this many parameters, a 4 is appropriate—it could have specified expected output fields more explicitly, but it already provides a solid mental model.

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 coverage is 0%, so the description must compensate, and it does comprehensively. It defines 'filtros' with concrete examples and a full list of valid indicators plus the _min/_max suffix convention. It explains the role of 'ano' (defaults to last year per company), 'as_of' (public info as of a date), and 'recibo' (permanent snapshot). Even 'chave_api' is mentioned as a requirement. The description adds substantial meaning beyond the bare 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 opens with a specific verb and resource: 'Filtra as AÇÕES do universo por faixas de indicadores' (filters stocks by indicator ranges). It explicitly distinguishes itself from the sibling screener_fiis by scope ('só ações' vs REITs) and names the alternative filter fields. This is a textbook example of clear purpose with sibling differentiation.

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 gives explicit when-to-use and when-not-to-use guidance: use for stocks, use screener_fiis for REITs. It also explains the semantic distinction between 'ano' and 'as_of' (past public data vs. current report), and when to set 'recibo=True' (when citing results). These are beyond generic advice and tell the agent exactly which tool/option to pick in which situation.

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