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

Sem annotations, a descrição carrega todo o peso e o faz bem: declara determinismo (mesma semente devolve os mesmos casos), reprodutibilidade por terceiros, ausência de autenticação chave, limite de teto 100 e ausência de custo. Também descreve o conteúdo do retorno (campos do caso, onde procurar no CSV do zip da CVM) e o protocolo de auditoria.

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 descrição é longa e usa caixa alta, mas cada bloco agrega informação necessária: propósito, regra da semente, campos retornados, parâmetros e condições de acesso. É mais extensa que o mínimo, sem desperdício significativo; a estrutura com parágrafos e “Parâmetros:” facilita leitura.

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?

A descrição cobre todos os pontos necessários para invocar a ferramenta: o que ela retorna, como escolher a semente, como interpretar os campos e qual o protocolo de conferência. Não há output schema e não há annotations; mesmo assim, nenhuma lacuna funcional relevante fica em aberto.

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?

A cobertura do schema é 0%, e a descrição compensa totalmente: define semente como inteiro escolhido pelo usuário, n como quantidade de casos, padrão 25 e teto 100. Acrescenta significado ao schema que lista apenas nomes e default.

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?

A descrição afirma claramente o propósito: auditar a base por sorteio de casos e devolver os dados necessários para conferência contra os arquivos originais da CVM, diferenciando-se dos demais tools de rankings e indicadores. O verbo e recurso são específicos (“audite esta base” e “sorteia casos”), e a frase “não contra nós” deixa explícito o diferencial em relação aos irmãos.

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?

A descrição define o contexto de uso: auditoria reprodutível com semente escolhida pelo agente, e menciona explicitamente restrições (semente escolhida por você, não aceitar sugestão). Não nomeia alternativas entre os irmãos, mas o contexto é claro o suficiente para quando usar; faltam exclusões mais formais de ferramentas alternativas.

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

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

With no annotations, the description carries the full burden and does well: it discloses the free-key requirement and the single free ticker (AAPL34), enumerates the fields returned (rentabilidade com/sem proventos, proventos, desdobramentos), and explicitly scopes out what is absent (código lá fora, proporção BDR:ação). It also clarifies the non-advisory nature.

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?

Front-loaded with the resource identity, then split into two clearly delineated mode paragraphs, with a final caveat sentence. Length is justified by the two operating modes, and backticks aid scanability; only slightly long.

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 3-optional-param, no-output-schema tool, the description covers both modes, access/auth requirements, and the per-mode return contents. Reasonably complete for correct invocation; pagination or list size limits for the empty-ticker listing are not addressed.

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% (titles only, or default), so the description must compensate and largely does: it explains `ticker` (empty=list, filled=cadastro), `tipo` (filter, e.g. "DRE"), and `chave_api` (required except AAPL34). Only minor gaps remain around accepted `tipo` values, which are partially implied by DRN/DR1/DR2/DR3/DRE.

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?

States a specific resource (BDRs negociados na B3 – recibos de ações/ETFs listados lá fora) with concrete examples (AAPL34, NVDC34, IVVB39) and two clear operating modes. It is easy to tell what the tool does, though it does not explicitly distinguish itself from the sibling bdr_precos.

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?

Gives explicit mode-selection guidance: `ticker=""` lists all BDRs that traded in the last year, while a concrete `ticker` returns the cadastro detalhado. It also states the access condition (AAPL34 is open; the rest require chave_api). It lacks any when-not-to-use or named alternative among the many siblings.

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

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

With no annotations, the description carries the full burden and does disclose meaningful traits: source (COTAHIST da B3), unadjusted data ('sem ajuste'), and a behavioral limitation—no key yields only a 30-session sample with an `aviso` field. It omits rate limits or error behavior, 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?

One dense paragraph, front-loaded with the resource and fields before the key/date mechanics. Every clause adds information, though the sample/key explanation could be tightened.

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 output schema and no annotations, the description compensates by naming the returned fields and the sample-vs-full behavior. It is complete enough to call correctly, with only minor gaps around ticker format and error handling.

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 description coverage is 0%, so the description must compensate and it largely does: it specifies the AAAA-MM-DD format for `de`/`ate` and explains that `chave_api` is a free key that unlocks the full series. The `ticker` parameter is only implied by context rather than explicitly defined.

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?

States a specific resource and granularity—'Série DIÁRIA de um BDR'—and enumerates the fields returned (fechamento, abertura, máxima, mínima, volume, negócios). The BDR-specific framing implicitly separates it from the sibling 'precos' without needing the schema.

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 explains the key-vs-no-key behavior (sample of 30 sessions vs full series), which is useful context, but gives no explicit routing telling the agent when to prefer this over siblings like 'precos', 'bdr', or 'indice_precos'. Usage is implied by the BDR resource name only.

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

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

With no annotations the description carries the full burden and does well: it discloses that everything is computed server-side, that the price series is adjusted for corporate events with total return (dividends/JCP reinvested at data-ex) when there are proventos, that there are no costs and that 'premissas' ship in the response, plus a past-not-recommendation disclaimer. It omits operational traits like rate limits, caching, or error behavior, keeping it short of 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, front-loaded with the core 'what it returns' before methodology and parameter notes. Every clause adds information, though the density of domain terms (proventos, JCP, data-ex) makes it slightly heavy.

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 no annotations, no output schema and 5 params at 0% coverage, the description supplies metrics returned, parameter formats, methodology assumptions and disclaimers, which is comprehensive. Minor gaps remain around empty-default behavior and response field specifics beyond retorno_total_pct.

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 largely does: it specifies de/ate use AAAA-MM-DD and that media_curta/media_longa change the moving averages, while stating the defaults (21x100 and last-5-years). It does not explain what an empty de/ate (default "") or a 0 media value resolves to, which is the remaining gap for a zero-coverage 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?

States a specific verb+resource: it computes past performance metrics (return, max drawdown with peak/trough dates, volatility, moving-average crossover) for a single stock, buy-and-hold vs the crossover. The explicit focus on 'uma AÇÃO' distinguishes it from the sibling desempenho_fii and desempenho_etf, so an agent can route correctly without opening the schema.

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?

Gives usable context ('ABERTO para qualquer ticker, sem chave', 'Medida do passado, não recomendação'), so the agent knows it needs no auth and returns a historical measure. But it never names when to prefer this over desempenho_fii/desempenho_etf or states any exclusions, leaving the routing condition (asset class) implicit.

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

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

With no annotations, the description carries the burden and does so reasonably: it discloses the auth status ("Aberto, sem chave"), the data treatment (price only, no split adjustment), and how anomalous jumps are reported ("saltos_suspeitos"). It omits read-only/return-format detail, but the key behavioral traits are surfaced.

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 tight two-clause parenthetical with no filler; the ETF scope and the anomaly note are front-loaded. Slightly dense but every clause carries information.

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?

No annotations and no output schema, yet the definition delegates behavior and parameters to a sibling ("O mesmo de `desempenho`") rather than being self-contained. It notes one output field, but five undocumented parameters leave the definition materially incomplete for direct invocation.

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?

Five parameters with 0% schema description coverage, and the description explains none of them (de, ate, ticker, media_curta, media_longa). The only compensation is the implied "same as desempenho" parameter set, which the agent cannot verify from this definition itself.

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 identifies the resource as an ETF performance tool and explicitly distinguishes it from its sibling `desempenho` ("O mesmo de `desempenho`, para um ETF"). The action is defined by reference to that sibling rather than stated outright, but since both tools are co-present the agent can route correctly. It also narrows scope with "só preço, sem ajuste de desdobramento".

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?

Use with ETFs (as opposed to `desempenho` for equities) is implied through the sibling contrast, and it hints where anomalies surface ("salto diário acima de 35% vem em `saltos_suspeitos`"). There is no explicit when-to-use/when-not statement or an outright list of alternatives, so guidance remains inferential.

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

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

With no annotations, the description carries the full burden and delivers substantive behavioral context: prices are not split-adjusted, daily jumps over 35% are surfaced in `saltos_suspeitos` with `confiavel: false`, and amortization is excluded. It also discloses the 'no key' auth condition. It stops short of describing return format/pagination, but the data-semantics disclosure is unusually rich.

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?

Four dense sentences, each carrying distinct information, with the sibling reference and scope front-loaded. No filler; it is compact given how much behavioral detail it conveys.

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?

The tool has 5 params, no output schema, and no annotations. The description usefully discloses output-field semantics and auth, but with zero parameter documentation and no return-shape description, it leaves meaningful gaps for an agent calling it.

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% across 5 parameters, yet the description explains none of them. It names output fields (`saltos_suspeitos`, `confiavel`, `retorno_total_pct`) but says nothing about `de`, `ate`, `ticker`, `media_curta`, or `media_longa`, so it fails to compensate for the coverage gap.

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 states the resource (performance for a real estate fund) and explicitly scopes it as the FII variant of the sibling tool `desempenho`, which distinguishes it from `desempenho_etf` and the equity version. The verb is implied by the reference rather than stated directly, so it falls short of a fully self-contained 5.

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?

Usage is implied by naming the domain (FII) and noting it is 'aberto, sem chave' (open, no key required), but there is no explicit when-to-use/when-not or a direct routing to the sibling it diverges from. An agent can infer the use case but gets no explicit selection criteria.

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

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

The description notes that the tool has no parameters and is free (no API key required), which are important behavioral traits. It does not explicitly mention that the tool has no side effects, but for a read-only dictionary lookup this is implicit.

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 concise and well-structured. It provides essential information, including the exact output content and the distinction from a sibling tool, without unnecessary verbosity.

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 that the tool has no parameters and the output is a JSON dictionary, the description sufficiently explains what the tool returns and how it differs from the alternative. No critical context is missing.

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 has no parameters, so there is nothing to misinterpret or clarify. The description correctly states 'Sem parâmetros' and the schema confirms an empty properties object.

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: it provides a technical dictionary of indicators, including formulas, CVM account codes, and the profit line used. It also distinguishes this JSON definition from the 'metodologia' alternative.

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 contrasts this tool with 'metodologia', indicating that this one returns JSON definitions for programmatic consumption while the other provides readable explanatory text. This gives clear guidance on when to choose this tool over the sibling.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the data source (B3), rate limits per address (60/hour, 150/day) versus with a key (2,000/hour, 20,000/day), the environment-variable fallback, and the fact that the original declared type is preserved. It also explains the crucial semantic distinction between 'B3 answered no dividend' and 'we could not query', which prevents an agent from misreading empty results as zeros.

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?

Front-loaded with purpose and return shape before the parameter block, and every paragraph carries information. The indented parameter list is readable but slightly verbose in restating limit numbers inline; a tighter form would preserve the same content.

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?

No output schema exists, yet the description enumerates the returned fields (valor por ação, data-com, data de aprovação), the yearly summary, and the trailing-12-month yield, plus error-versus-empty semantics. For a 2-parameter read tool this is complete enough to call correctly without further discovery.

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 description coverage is 0%, so the description must compensate, and it does: `ticker` is specified as uppercase with class digit and three concrete examples, and `chave_api` is documented as optional with its default behavior (empty string → DADOS_B3_API_KEY) and its rate-limit consequences. Both parameters gain meaning well beyond their bare string types.

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?

States a specific verb+resource: cash proventos (dividendos or JCP) paid by a B3-listed company, plus a 12-month dividend yield. The qualifier 'em dinheiro' implicitly narrows scope away from other corporate actions handled by siblings like eventos, but no sibling is named explicitly, so an agent must infer the boundary.

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?

Clear context for use and a direct pointer to `listar_empresas` for obtaining valid tickers, plus guidance on when to supply `chave_api` (rate-limit tiers) versus leaving it empty. It stops short of explicit when-not-to-use or alternative-tool routing (e.g., for splits/bonificações use eventos).

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It actively explains the analytical nuance that return by COTA is total return by construction (ETF reinvests) and that screen price can diverge from cotação, with ágio quantifying that divergence. It also discloses the API-key requirement through the 'BOVA11 é aberto como degustação' note. These go beyond the basic 'what it does' and provide meaningful behavioral context.

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 moderately long but every segment is purposeful: a comprehensive data list, an explanatory note on return types, and parameter definitions. It is front-loaded with the tool's scope and the analytical caveat is placed logically. While a bit dense, it does not contain filler and earns its length.

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 no output schema, the description does a strong job of enumerating what the agent will receive: cadastro, informe diário, ágio/deságio, taxa efetiva, carteira, sobreposição, and returns. Together with parameter semantics and access note, an agent has enough to call the tool correctly. It does not specify exact return formatting or error behavior, but the data scope is well covered.

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 provides no descriptions (0% coverage), but the description fully compensates: it defines ticker as 'código do fundo na B3' with examples (BOVA11, IVVB11), and chave_api as 'chave do Dados B3', including the access context of BOVA11 being open for trial. Both parameters are semantically enriched beyond the raw 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 identifies the resource (a single B3 ETF) and enumerates its contents: registration, daily report, agio/disagio, effective rate, portfolio, overlap, and returns. This distinguishes it from siblings like etfs_ranking (which implies ranking of multiple ETFs). It lacks an explicit action verb like 'returns' or 'fetches', but the list of data categories makes the purpose unambiguous.

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 implies usage for single-ETF data retrieval and notes that BOVA11 is available as a free sample, providing context on when to use it. However, it does not explicitly contrast it with sibling tools such as etfs_ranking or screener, nor state when not to use it. The usage context is clear but relies on inference.

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

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

Since no annotations are provided, the description carries the full burden, and it delivers extensively: it explains data sources, same-day pricing calculation, liquidity cutoff, fee annualization, and that no API key is required. It also clarifies the output is descriptive, not a recommendation.

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?

Every sentence contributes distinct information: ranking criteria, valuation definitions, data provenance, liquidity filter, the descriptive nature, and access requirements. The most important scope appears early, and there is no filler.

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 zero-parameter tool with no output schema and no annotations, the description is unusually complete. An agent knows what metrics are returned, how they are calculated, which funds qualify, which data sources back them, and that authentication is unnecessary.

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?

There are zero parameters and 100% schema coverage, so the baseline is 4 because there is essentially nothing to document. The description redundantly states 'Sem parâmetros' and 'Gratuito — não exige chave,' which adds no parameter meaning but is harmless.

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 unambiguously identifies the resource: 'ETFs listados na B3' and enumerates the specific ranking dimensions (mais negociados, maior patrimônio, maior deságio/ágio, retorno de 12 meses, menor taxa efetiva). This clearly differentiates it from siblings like fiis_ranking or etf without ambiguity.

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 provides clear context: this is a descriptive ranking tool for B3 ETFs, with a liquidity threshold and an explicit 'não é recomendação' caveat. It does not explicitly name alternative sibling tools or say when not to use it, but the use case is clear enough for an agent to select it.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses data provenance (events declared by B3 vs. found by the provider), the presence of a declared factor and a computed `efeito_liquido_do_dia`, and the authentication requirement per ticker. It stops short of describing error behavior, rate limits, or that the call is a read-only lookup, so it is strong but not exhaustive.

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 sentence that front-loads the returned event types before the provenance and net-effect details. It is dense with domain jargon but every clause (source, factor, `efeito_liquido_do_dia` semantics, auth) adds real information rather than padding.

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 two-parameter, no-output-schema retrieval tool, the description adequately conveys what the response contains (event types, source, declared factor, net daily effect) and what is needed to call it. The only remaining gap is the concrete shape of returned records, which is implied but not spelled out.

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 description coverage is 0%, so the description must compensate. It fully clarifies `chave_api` (only needed for non-WEGE3 tickers), which is the non-obvious parameter, but says nothing about `ticker` format beyond the implicit WEGE3 example. That is a real gap at this coverage level, keeping it at a baseline-plus rather than a 4 or 5.

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 specific resource — corporate events (splits, reverse splits, bonuses, spin-offs) for a single company — so an agent knows exactly what data comes back. It does not explicitly contrast itself with adjacent siblings like `dividendos`, but the resource is concrete enough to distinguish it in practice.

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 one real precondition (WEGE3 is open, all other tickers require `chave_api`), which is actionable usage guidance. However, it never states when to reach for this tool versus siblings such as `dividendos` or `reapresentacoes`, so the routing guidance is only partial.

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

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

With no annotations, the description carries the full burden and does well: it discloses the anonymous rate limits (60/hour, 150/day), the elevated AI-assistant limits (2,000/hour, 20,000/day), the API-key fallback to DADOS_B3_API_KEY, and that annual data comes from DFP forms while quarterly comes from ITR. It does not cover error behavior for invalid tickers or data freshness/caching.

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?

Front-loaded with what is returned and how provenance works, then a clearly delimited `Parâmetros:` block per argument. It is long, but the length is justified by the complete absence of schema descriptions; wording is tight with no filler.

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 no annotations, no output schema, and 0% schema coverage, the description supplies return contents, provenance metadata, all three parameters, and access limits. Remaining gaps are minor: historical coverage start and error/empty-result behavior are unstated.

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 fully compensate, and it does: ticker format is pinned down with uppercase and class digit plus concrete examples (WEGE3, PETR4, SANB11), `trimestral` is explained as a granularity switch sourced from DFP vs ITR rather than a filter, and `chave_api` is documented with default-empty semantics and environment-variable fallback.

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?

States a specific verb and resource — returns standardized accounting accounts for a B3 company, with the CVM account code behind each number — and enumerates the fields returned (revenue, EBIT, net income, equity, cash, gross/net debt). It differentiates weakly from close siblings such as indicadores_anuais or multiplos, but the provenance/audit framing gives it a distinct identity.

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?

Usage is largely implied: it points to `listar_empresas` for valid tickers and explains that `trimestral` is not a filter, but it never says when to choose this tool over `indicadores_anuais`, `multiplos`, or `trimestres`. No explicit when-not-to-use guidance is offered.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses the data provenance (informes mensais entregues à CVM, not an aggregator), the point-in-time construction of the P/VP series (preço do 1º pregão após entrega do informe ÷ valor patrimonial da cota), and explicit rate limits (60/hora and 150/dia without a key; 2.000/hora and 20.000/dia for AI assistants). The main gap is that it does not say what happens for an unknown ticker or how errors surface.

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?

Front-loaded with the resource, followed by a return-value block, a crucial interpretation warning about yield, then a clearly delimited 'Parâmetros' section. Nearly every sentence earns its place, though 'com o histórico auditável' is a promotional fragment that adds little operational meaning.

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?

No output schema and no annotations exist, so the description must cover both payload and behavior — and it names the returned fields, the provenance, the rate limits and the yield caveat. What remains missing is sibling differentiation and error/invalid-ticker behavior, which are the only material holes for a two-parameter lookup tool.

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 description coverage is 0%, so the description must compensate and largely does: 'ticker' gets concrete B3 examples ("MXRF11", "HGLG11"), and 'chave_api' is explained as optional with the consequence of omitting it spelled out via per-address limits. It stops short of format constraints (6-character alphabetic prefix + digits, case) which the examples only imply.

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?

States the resource precisely: a single B3 real-estate fund (FII) record, then enumerates the returned payload (CNPJ, segmento, mandato, tipo de gestão, público-alvo, série de P/VP, dividend yield 12m, vacância, rendimentos). That is far more specific than a name restatement. However, it never distinguishes itself from siblings such as 'fiis', 'fiis_ranking' or 'desempenho_fii', so an agent must infer that this is the single-ticker lookup.

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?

Usage is implied rather than stated: the required 'ticker' parameter makes clear this is a per-fund lookup, and the parameter block implies 'use when you have one ticker'. But there is no explicit when-to-use / when-not-to-use guidance and no routing to alternatives like 'fiis' (likely the list) or 'desempenho_fii' (likely performance).

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

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

With no annotations, the description carries the full burden and does so thoroughly: mandatory chave_api, full-universe scan, defaults/caps, exact segment matching, the dirty-number policy, and the investment disclaimer. This is well beyond a minimal read-filter description.

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 main purpose is front-loaded, followed by a tight parameter list and a single caveat paragraph. Each sentence adds information—there is no filler or repetition of schema titles.

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 an 8-parameter tool with no output schema and no annotations, the description covers behavior, defaults, required key, matching exactness, and disclaimers. The only minor omission is explicit return-shape details, but 'devolve o universo ordenado' gives enough context for correct invocation.

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%, but the description documents every parameter with units, defaults, examples (pvp_max=1.0, dy_min=0.10, 'Shoppings'), and edge semantics such as dy being a fraction. It fully compensates for the schema's bare defaults.

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 opening sentence states a specific verb and resource: filters real estate funds (FIIs) by P/VP and dividend yield ranges. It also clarifies that with no parameters it returns the full ordered universe, preventing confusion with single-fund lookup tools like fii.

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 clearly defines when to use the tool: filtering FIIs by P/VP, dividend yield, segment, and liquidity, including the no-params behavior. It does not explicitly contrast it with sibling tools (e.g., fii or screener), so a small alternative-routing gap remains.

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

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

With no annotations supplied, the description carries the full burden and does well: it discloses data provenance (CVM monthly report plus COTAHIST), the filtering rules (only unflagged/clean values, only liquid funds), the interpretive caveat that it is descriptive and not investment advice, and the rate-limit behavior tied to the key. It stops short of describing the response shape or whether results are paginated or cached.

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?

Front-loaded with the ranking content before the parameter note, and every clause adds information: metrics, data sources, filters, disclaimer, auth behavior. Slightly dense as a single paragraph in two languages-of-register, but nothing is redundant.

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 zero-required-parameter, read-only ranking endpoint with no output schema, the description supplies what the agent needs to decide to call it and what it will get back conceptually (three ranking views plus per-segment medians). The only real gap is the concrete return structure, which matters little given the tool takes no meaningful input.

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% and the single property has no description, so the prose must compensate. It does: 'chave_api' is explained as optional, the tool works without it under a per-address limit, and supplying one applies that key's limit — meaning the agent cannot glean from the schema alone. Full marks withheld only because the expected key format/where to obtain it is not stated.

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 concrete resource and three distinct outputs: most discounted FIIs (lowest point-in-time P/VP), largest payers (12m DY), and median P/VP, DY and vacancy per segment. An agent can distinguish this from the sibling tools 'fiis', 'desempenho_fii' and 'etfs_ranking' because the ranked metrics and the unit of aggregation (segment) are spelled out.

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?

Usage is only implied: the agent can infer this is the tool for cross-sectional FII rankings, and the parameter note explains when to pass a key. But the description never states when to prefer this over 'fiis' or 'desempenho_fii', and there are no explicit exclusions beyond the note that it is descriptive rather than a recommendation.

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

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

With no annotations, the description carries the full burden and does exceptionally well: it discloses source-specific lag, explains `dados_ate` and the difference between CVM and B3 publication delays, defines version>1 as re-submission semantics, and mentions that no API key is required. It also clearly implies a read-only operation by saying it 'devolve' data.

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 front-loaded with the main purpose and organized into content categories, data-freshness behavior, and invocation notes. It is slightly longer than strictly necessary due to a natural-language flourish, but each paragraph adds distinct operational value.

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 no-parameter, no-output-schema tool, the description is unusually complete: it lists every returned section, explains freshness and lag, and states invocation essentials. The only notable gap is that the example about 'empresa X' could imply company-level filtering, but the tool has no parameters and the description never clarifies whether a specific company can be requested.

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 is empty with 100% coverage, so there are no parameters to explain. The description reinforces this with 'Sem parâmetros' and adds the useful operational fact that it is free and requires no key, which is appropriate for a zero-parameter tool.

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 first sentence states a concrete purpose: report what changed in the Brazilian market in the last 30 days. The description then lists the exact categories returned — balanços, documentos reenviados, proventos, rendimentos e informes de FII, eventos societários e trocas de ticker — which clearly distinguishes it from historical/series-oriented sibling tools.

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 identifies the target question ('o que aconteceu com a empresa X esta semana') and explicitly says that annual series do not answer it, signaling use for recent-change discovery. It also notes the window is fixed and the tool has no parameters. However, it does not name the alternative sibling tools or state exactly when not to use them, only implies it.

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

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

With no annotations supplied, the description carries the full burden and does well: it discloses the historical coverage boundary, the anonymous rate limits per address (60/hora, 150/dia) versus keyed/AI-assistant limits, and the API-key fallback behavior. It omits what happens on an invalid ticker or an exhausted quota, and does not state the shape of the response beyond the metric list.

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?

Purpose and coverage are front-loaded in the first sentence, with a clearly delimited "Parâmetros" block for the per-parameter detail. The long parenthetical on rate limits is dense but load-bearing; overall there is little filler.

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?

No output schema exists, so the description appropriately lists the returned metrics and the time granularity (per year), and it covers both parameters plus quota behavior. Only the precise response structure (e.g., list of per-year objects) and error behavior are left implicit.

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 description coverage is 0%, so the description must compensate and it does: `ticker` is specified as uppercase B3 code with the class digit, with concrete examples for ordinária, preferencial and unit. `chave_api` is fully explained — optional, "" means fall back to DADOS_B3_API_KEY, and it changes which rate limit applies.

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?

States a specific verb and resource ("Série anual de indicadores fundamentalistas de uma empresa da B3") and then enumerates exactly which metrics come back per year (ROIC, ROE, margens, crescimento, dívida líquida/EBITDA). The word "anual" plus the explicit coverage window (2010 até o último exercício) separates it from quarterly siblings such as `trimestres`.

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?

Routes the agent to two named siblings: `metodologia` for how each indicator is computed and `listar_empresas` for discovering valid tickers. It does not, however, state when to prefer this over adjacent tools like `trimestres`, `multiplos`, or `fatos_contabeis`, so the alternative-selection guidance is partial.

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

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

With no annotations, the description carries the full burden and does well: it discloses no auth key required, the computed metrics (return, maximum drawdown, moving-average crossover), the default lookback (last 5 years), and an important semantic caveat that this is a PRICE index in points excluding dividends. Rate limits and error behavior are not covered, keeping it from 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?

Front-loads the purpose ('O benchmark: desempenho de um ÍNDICE da B3') before the supporting detail, and every clause contributes (metric set, auth, listing behavior, dividend caveat). It is dense and slightly cryptic but not padded.

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 5-parameter, no-output-schema, no-annotation tool, the description covers purpose, scope, auth, defaults, listing behavior, and a key return caveat, which is substantial. It falls short only on parameter formats, which is a real but contained gap.

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% with 5 undocumented parameters, so the description must compensate. It explains `codigo` (examples and empty-string listing behavior) and implies `de`/`ate` via 'num período' and `media_curta`/`media_longa` via 'cruzamento de médias', but supplies no date format or units, leaving syntactic gaps.

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?

States a specific verb and resource: computing B3 index performance ('desempenho de um ÍNDICE da B3'). Names concrete index codes (IBOV, IFIX, SMLL, IDIV, IBXX) and explicitly distinguishes the scope from the sibling 'desempenho' by framing it as the index equivalent, so an agent can separate the two without opening a schema.

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?

Gives clear context for when this applies (index performance over a period, same metric set as `desempenho`) and the operational precondition ('Aberto, sem chave'), plus the discovery path `codigo=""` to list indices and coverage. It does not state explicit when-not conditions or point away from `indice_precos`, so it stops short of full routing guidance.

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

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

With no annotations, the description carries the full burden and does disclose a meaningful behavioral trait: unauthenticated calls return only a 30-trading-day sample flagged with `aviso`, while `chave_api` unlocks the full history. It is silent on rate limits and anything beyond Keyth auth, but the tiered-response behavior is genuinely informative.

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?

Two tight sentences, front-loaded with what the tool returns and then the key-tier caveat. No filler.

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?

No output schema or annotations exist, and while the return shape is described conceptually (daily points, oldest to newest, `aviso` field), the date-range and index-code parameters remain unexplained. Adequate for the happy path but not complete for a 4-parameter tool.

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 description coverage is 0%, so the description must compensate. It clearly explains `chave_api` and implies temporal scoping, but never clarifies that `de`/`ate` are date bounds/format or what `codigo` selects (default IBOV), leaving two of four parameters effectively undocumented.

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 specific resource and granularity ("Fechamento DIÁRIO de um índice da B3, em pontos") plus the ordering of the series, so an agent knows exactly what is returned. It does not name any sibling (e.g. `indice`, `precos`) to disambiguate, so sibling differentiation is only implicit.

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 explains the access tier (sample vs. full series with a free key), which is useful context for deciding whether to call it, but gives no guidance on when to prefer this tool over `indice` or `precos`. Usage is implied rather than stated.

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

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

Annotations are absent, so the description carries the full burden. It clearly states the tool is read-only (returns data, no side effects), free, and no key required. It also explains why the count is not hardcoded, adding behavioral context about dynamic data. This is more than a bare minimum.

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 with a clear opening sentence, then a list of outputs, usage context, and parameter/freemium info. It front-loads the core purpose and keeps sentences concise. The note about count is a bit extra but adds value.

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 zero-parameter tool with no output schema, the description is remarkably complete. It tells the agent what it returns, why it's useful, that it's free and keyless, and even points to 'saude' for dynamic count. An agent could call this tool without any further clarification.

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 and 100% coverage (empty schema is fully covered). The description explicitly states 'Sem parâmetros', reinforcing the schema. Since there are no parameters to explain, the description adds value by confirming the absence, making the agent confident it needs no inputs.

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 lists Brazilian publicly traded companies covered by Dados B3, with specific fields returned (nome, CNPJ, código CVM, ticker principal) and total count. It distinguishes itself by being the starting point for finding tickers for other tools, differentiating from siblings like 'saude' or 'indicadores_anuais'.

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 states it has no parameters and is free without API key, and positions it as the entry point for discovering tickers. It does not explicitly mention when not to use it, but the context of being the starting point implies alternatives are for deeper analysis.

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

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

With no annotations present, the description carries the full behavioral burden and largely delivers: it documents the mode-switching behavior (default list vs. explicit read), the parameter format with a concrete example, and the access properties ('Gratuito — não exige chave'). Missing edge-case behavior like invalid page identifiers, but the disclosed traits substantially outpace the annotation baseline.

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 front-loaded with the essential purpose and then breaks down behavior cleanly in a list-like structure. There is minor redundancy — the two-mode behavior is explained both in the intro bullets and again in the parameter documentation — but every sentence adds real information, and nothing is fluff.

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 low-complexity tool (1 optional parameter, no output schema, no annotations), this description is nearly exhaustive: behavior, usage trigger, parameter semantics, and access model are all covered. The only gaps are minor (error behavior for invalid page names, and the exact shape of the returned listing), which are acceptable given the simplicity.

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% — the schema only reveals the parameter name and default. The description carries the full semantic load and succeeds completely: it explains the default behavior ('' lists pages), the page-identifier contract ('exatamente como aparece na listagem'), and gives a realistic example ('roic'). The agent can call it correctly after reading only the description.

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 opening line clarifies the resource ('pública... por trás dos indicadores — como cada número é calculado'), which goes well beyond the terse name 'metodologia' by explaining the tool returns the public calculation methodology behind indicator numbers. The dual-mode behavior (list vs. read page) further sharpens the purpose. It doesn't explicitly differentiate from siblings by name, but the intent is unmistakable.

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?

Explicit guidance is provided: 'Use quando precisar auditar ou justificar um número devolvido pelas outras ferramentas.' This identifies a clear trigger condition and implies the siblings are the tools producing those numbers. Could give slightly more contrast with alternatives (e.g., raw data vs. methodology), but the direction is correct.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly: it discloses the point-in-time price convention, why it avoids look-ahead bias, the exact metrics returned, rate limits for anonymous and keyed access, AI-assistant-specific limits, and the environment-variable fallback. This is rich behavioral context beyond what the schema supplies.

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 front-loaded with the tool's core purpose, then structured into a clear methodology paragraph and a parameters section. Every sentence adds useful information about behavior, limits, or parameter handling, with no redundant restatement of the schema.

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 two-parameter tool without an output schema or annotations, the description covers purpose, methodology, returned metrics, parameter formats, rate limits, and authentication fallback. Nothing an agent needs in order to call it correctly appears to be missing.

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 description coverage is 0%, so the description must compensate entirely. It does: ticker format is specified as uppercase with class digit, examples are given (WEGE3, PETR4, SANB11), a reference to listar_empresas is provided, and chave_api is explained as optional with rate-limit consequences and an environment-variable default.

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 states a specific verb and resource: point-in-time valuation multiples for a B3 company, and enumerates the exact metrics returned (P/L, P/VP, EV/EBITDA by fiscal year, plus P/L TTM by quarter). This clearly distinguishes it from sibling tools such as indicadores_anuais or scores.

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 explains the intended use case (backtesting without look-ahead contamination) and provides operational guidance for the ticker parameter and API key. It does not explicitly state when to prefer a sibling tool, but the usage context is clear enough to select it correctly.

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

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

With no annotations, the description carries the full burden and discharges most of it: it discloses the unadjusted-price caveat, the 30-trading-day sampling for non-keyed non-WEGE3 tickers, the returned `aviso`, and the key requirement. It does not state rate limits or the exact response envelope, but the truncation/sampling behavior is the critical non-obvious trait and it is clearly disclosed.

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 core purpose is front-loaded in the first clause, followed by format, ordering, and access caveats in a tight sequence. It is dense but every sentence adds operational information; no filler.

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 annotations and no output schema, the description supplies the field list, ordering, adjustment caveat, date format, and key/sampling behavior. The main residual gap is the unexplained `limite` parameter, but an agent otherwise has enough to call it correctly.

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. It documents `de`/`ate` as YYYY-MM-DD and explains `chave_api` (free key) and `ticker`, covering 3 of 5 parameters, but leaves `limite` entirely undefined in both description and schema. Partial compensation warrants a middle score.

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?

States a specific resource and scope: the DAILY price series (open/high/low/close/average/volume/quantity/trades) plus corporate events of a stock, ordered oldest-to-newest. It contrasts with siblings by naming `desempenho` as the key-free alternative and restricting itself to a single 'AÇÃO', implicitly distinguishing it from the index/BDR price variants. However, it never explicitly routes to those sibling price tools.

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?

Gives clear conditional guidance: WEGE3 always returns the full series, while other tickers without a key return only a 30-day sample plus a notice explaining how to get full access. It points to `chave_api` for a free key and notes `desempenho` works without one. It stops short of explicit when-not-to-use framing, but the key/no-key conditions are actionable.

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

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

With no annotations, the description carries the burden and does disclose meaningful behavior: the return is broken out per affected account with both the original and revised values and both publication dates, and the API key has a 200 queries/day free limit with WEGE3 usable without a key. It omits what happens when a ticker has no restatements and says nothing about ordering or result size.

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 purpose is front-loaded in the first sentence and the rationale follows before a clearly separated parameter block. It is longer than strictly necessary — the rate-limit and card-free details are somewhat verbose — but each sentence carries usable information.

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 two-parameter read tool with no output schema and no annotations, the description covers purpose, return shape, and both parameters' semantics well enough to call it correctly. The remaining gap is the empty-result case and any note on volume or pagination of restated accounts.

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 does: `ticker` is specified as the B3 code in uppercase with the class digit plus three concrete examples and a pointer to `listar_empresas`, and `chave_api` is explained including its free tier, rate limit, which ticker needs no key, and the environment-variable fallback for empty strings.

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 and shape: restated financial statements returned as old and new versions side by side, per affected account. It also implicitly separates itself from ordinary statement tools by stating that the old number usually disappears from the databases but is preserved here, which lets an agent distinguish it from siblings like fatos_contabeis.

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 clear usage contexts — auditing historical changes and checking whether a backtest ran on numbers later revised — plus a pointer to `listar_empresas` for obtaining tickers. It does not explicitly say when not to use it or name a competing sibling tool, so it falls short of full when/when-not guidance.

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

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

With no annotations, the description carries the full burden and does well: it discloses the auth profile ('Aberto, sem chave' – open, no key required) and the immutability/verifiability guarantee (sha256 proving the result hasn't changed). It does not spell out error behavior for an invalid or unknown id, which keeps it short of 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?

Front-loaded with the verb and resource, then progressively adds the receipt contents, the parameter origin, and the auth posture. Three dense sentences with no filler; slightly verbose in enumerating receipt fields but each clause contributes information.

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?

There is no output schema and no annotations, so the description must cover both, and it does: it lists the return payload (question, as_of, version, result, sha256) and the access model. Only minor gaps remain (invalid-id/error handling), which is acceptable for a single-parameter read tool.

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 description coverage is 0% (only a type/title for `id_recibo`), so the description must compensate. It does so meaningfully by telling the agent exactly where the parameter value comes from ('vem do campo do recibo na resposta de screener(recibo=True)'), which is the critical semantic an agent needs to supply a valid value.

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?

States a specific verb (lê/reads) and resource (RECIBO), then defines precisely what a receipt is: a frozen screener query with its question, as_of cutoff, data version, result, and sha256. It implicitly distinguishes itself from the sibling `screener` by explaining that the receipt is the frozen artifact produced by `screener(recibo=True)`. An agent can tell exactly what this returns without opening the schema.

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 clear context for use: the `id_recibo` originates from the receipt field in a `screener(recibo=True)` response, and the tool is meant for citation verification ('quem recebe a citação precisa conseguir conferir'). It does not state explicit when-not-to-use conditions, but the origin and purpose are unambiguous.

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

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

With no annotations provided, the description carries the full burden and does well: it discloses that no API key is required, that the tool returns counts and a timestamp, and that it is meant as a status check. It does not mention potential latency or caching behavior, but for a simple no-parameter status endpoint this is adequate.

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 concise and well structured: it states what the tool returns, why it is useful, and that it requires no parameters or key. Every sentence adds value, and the most important information is front-loaded.

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?

There is no output schema, but the description sufficiently explains the return content: counts per data type and the last-ingestion timestamp. For a zero-parameter health-check tool, this is complete enough for an agent to call it and interpret the result correctly.

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 has zero parameters, so the baseline is 4, and the description explicitly states 'Sem parâmetros', confirming that no arguments are needed. This adds clarity beyond the empty input schema and removes any doubt about invocation requirements.

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 clear subject, 'Estado atual da base do Dados B3', and then uses a concrete verb, 'Devolve', to state exactly what is returned: counts by data type and last-ingestion timestamp. This makes the tool's purpose obvious and distinguishable from data-retrieval siblings like listar_empresas or indicadores_anuais.

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 gives explicit context for when to use the tool: to know the current universe size and to verify data freshness before trusting a number. It does not explicitly name alternatives or state when not to use it, but the intended use case is clear enough for an agent to select it appropriately.

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

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

With no annotations supplied, the description carries the full burden and does well: it discloses the free-tier rate limit (200 queries/day, no card), the auth requirement (key needed for all tickers except WEGE3, which is open everywhere), and the env-var fallback DADOS_B3_API_KEY when the key is left empty. What it omits is failure behavior — e.g. what happens with an invalid ticker or an exhausted quota — but auth and quota disclosure is above average for a read-only tool.

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?

Front-loaded with the purpose and return shape, then a clearly delimited 'Parâmetros' block, which is the right structure for a tool whose schema is undocumented. Every line is informative; the only mild slack is the parenthetical marketing aside about the key being free with no card, which is useful but could be trimmed.

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 two-parameter read tool with no annotations and no output schema, the description supplies everything an agent needs: the ticker format and examples, the credential rules including the free-tier limit and env-var fallback, and a description of the returned structure (per-criterion pass/fail with numbers, plus Graham). Nothing material is missing.

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 description coverage is 0%, so the description must do all the work, and it does: ticker is specified as uppercase with the class digit plus three concrete examples and a pointer to `listar_empresas` for discovery, and chave_api explains its default empty string, its env-var fallback, and exactly when it is required versus optional. This adds substantial meaning that the bare schema (title-only properties) does not carry.

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?

States a specific verb and resource — quality/value scores for a B3 company, criterion by criterion — and specifies the concrete payload (Piotroski F-Score 0-9 with all nine criteria opened, plus the Graham criterion). It implicitly differentiates itself from a summary-style sibling ('você vê a conta, não só a nota'), but never names 'veredito' or 'metodologia' explicitly, so routing among the score-related siblings is left partly to inference.

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 / when-not-to-use section and no named alternative among the ~30 siblings. The sentence about being able to disagree with the score because the calculation is exposed implies the use case (auditing a score rather than just reading a grade), and the chave_api note gives conditional usage guidance, but the agent must infer the rest.

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

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

No annotations, so the description carries the full burden and does: unknown indicator names error out rather than being ignored, flagged/suspect values silently drop out of filtering, the universe retains survivorship bias (stated and disclosed in the response), chave_api is mandatory here even for a single ticker because the query sweeps the whole universe, and recibo freezes a sha256-stamped snapshot. This is exactly the behavioral context annotations would otherwise supply.

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?

Purpose is front-loaded and parameters are cleanly sectioned, with the minimum-viable call (no filtros) surfaced early. The block is long, but with 0% schema coverage most sentences carry information that exists nowhere else; only minor tightening is possible.

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 6-param tool with no annotations and no output schema, the description covers invocation, edge semantics, error behavior, auth, and the meaning of key response fields (disponivel_em, survivorship caveat). An agent has everything needed to call it correctly.

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% (bare titles only), so the description must compensate and does so for all six parameters: the _min/_max key convention, fractions-not-percentages normalization, the accepted indicator list, default-vs-explicit ano semantics, as_of's ~100-day CVM lag, limite default 100, recibo's freezing behavior, and chave_api's "" fallback to DADOS_B3_API_KEY.

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?

States a specific verb+resource+scope: filters the entire B3 universe by indicator ranges. The scope phrase 'universo inteiro' distinguishes it from the many per-company siblings (indicadores_anuais, multiplos, scores) that operate on a single ticker.

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?

Explicit when-to-use rules: call with no filtros to get the valid-indicator menu; use as_of instead of ano for point-in-time research and never combine them; use recibo when the list will be cited, then read it with the `recibo` sibling. Alternatives and exclusions are spelled out rather than inferred.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It does this well by listing what is returned per quarter, noting the price is from the first trading session after ITR publication, and explicitly warning that the 4th quarter is not included because it belongs to the annual DFP series. It stops short of a 5 because it does not address error cases, missing data, or API-key/auth behavior.

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 core content is well-structured and front-loaded: purpose first, then usage, then return details, then the important Q4 caveat, then an example. The tail is weaker, with redundant phrasing and placeholders like '[maybe]' and '[???]' that add noise rather than value, so it does not earn a 5.

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 lack of annotations and output schema, the description covers the most important decision and behavior points: quarterly scope, what data is included, the missing 4th quarter, and the call example. It is not fully complete because parameter semantics are thin and the broken tail leaves some guidance unfinished, but an agent can still invoke and interpret the tool correctly in most cases.

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 description shows the call signature 'trimestres(ticker, chave_api)' and an example 'trimestres('WEGE3')', which conveys argument order and that chave_api is optional in practice. However, schema coverage is 0%, and the description does not explain what chave_api is, when it is required, or how ticker should be formatted beyond the example. This is partial compensation, not full.

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 first sentence states the exact deliverable: a TRIMESTRAL series for one B3 company containing ITR accounts, price, and indicators. It also distinguishes itself from the annual series by saying the annual series only answers after the fiscal year closes, so an agent can tell this tool apart from sibling annual-data tools.

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 explicitly says to use this tool when the question is about the current year or the most recent quarter, and gives concrete examples like 'como foi o 2T' and 'a margem melhorou este ano?'. It also clearly states the alternative: 'Para o ano fechado, use a série anual.' This is strong when/when-not guidance.

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

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

With no annotations the description carries the full burden and does well: it discloses the no-key/any-stock access model, the deliverable content (confidence flag green/yellow/red, restatement/recency/checks, citation, 25-word headline), and an explicit behavioral constraint (factual, no judgment adjectives, no recommendation). It omits error behavior, rate limits, and latency characteristics, so a 4 rather than 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?

Front-loaded with the core promise ('Resumo DESCRITIVO de uma ação da B3 em seis números e três perguntas') and then organized by the three questions with parenthetical metric names; capitalization is used to segment output elements. It is dense and somewhat longer than necessary, but each clause maps to real content an agent needs.

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 single-parameter analytical tool with no output schema and no annotations, the description covers what the result contains, its constraints, and its access model well. The remaining gap is the ticker input format, which nothing else in the structured data supplies.

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?

One parameter with 0% schema coverage, so the description must compensate. 'Aberto para qualquer ação' loosely signals that the sole parameter is a B3 stock ticker, but it never specifies format, casing, or accepted variants, leaving the schema's bare 'ticker' string largely unexplained.

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 states precisely what the tool returns: a descriptive summary of a B3 stock in six numbers (net margin, ROIC, net debt/EBITDA, P/L, P/VP) plus a confidence flag and a headline sentence. The verb+resource is unambiguous and the enumerated metrics make it identifiable without opening the schema. It loses a point only because it never names or contrasts with the obviously related siblings (multiplos, scores, saude).

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 when-to-use / when-not-to-use guidance and no alternative tool is named, despite many overlapping siblings (scores, multiplos, saude, desempenho). 'Aberto para qualquer ação, sem chave' establishes accessibility but not the condition that should make an agent pick this tool over the others.

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