Server Quality Checklist

Tool Scores

• metodologiaA
  4.2/5.0
  Behavior4/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters5/5

  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.

  Purpose4/5

  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.

  Usage Guidelines4/5

  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.

• multiplosA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It reveals the critical behavioral choice of using the first trading session after publication date to eliminate look-ahead, and it details authentication via the `chave_api` parameter, including the fallback to an environment variable. This goes well beyond the schema and covers key safety and data-integrity aspects, though it does not explicitly state read-only nature or error handling.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded, stating the returned data first, and then explains the important point-in-time methodology that justifies the tool's use. The parameter section is clear and directly addresses the API key ambiguity. While slightly verbose due to the methodology explanation, that length is justified given the conceptual subtlety and its importance for correct usage in backtesting contexts.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the tool's purpose, the exact financial metrics returned, the crucial look-ahead-free price methodology, and both parameters with examples and fallback behavior. Although there is no output schema and the description does not specify the response format (e.g., array vs. object), the data content is sufficiently described for an agent to invoke the tool correctly. The API key handling is fully explained, addressing a common pitfall.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema offers no parameter descriptions (0% coverage), so the description must compensate. It thoroughly defines `ticker` with concrete B3 examples and a reference to `listar_empresas`, and fully explains `chave_api` including optionality for WEGE3, the requirement for other tickers, and the empty-string fallback to the environment variable. This completely compensates for the missing schema documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: returning point-in-time valuation multiples (P/L, P/VP, EV/EBITDA) per fiscal year and P/L TTM per quarter for a B3 company. It includes the specific verb 'Devolve' and resource, and naturally distinguishes itself from siblings like `indicadores_anuais` by emphasizing the look-ahead-free methodology.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides implicit usage context by highlighting the point-in-time methodology as suitable for backtests and instructs users to consult `listar_empresas` for ticker formatting. However, it does not explicitly compare this tool to sibling tools like `indicadores_anuais` or `fatos_contabeis`, nor does it state when to avoid this tool. The guidance on API key usage is explicit but tool-selection guidance is weak.

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

• reapresentacoesA
  4.2/5.0
  Behavior4/5

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

  With no annotations supplied, the description bears the full burden of disclosing behavior, and it does well: it explicitly explains that the originally published numbers that normally disappear from databases are retained here, and it says what will be returned for each affected account. It could add operational details such as pagination, limits, or whether no results are returned for tickers without restatement, but the writing already communicates the tool's distinctive behavior clearly.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded: the introductory sentence conveys the essence immediately, followed by behavioral notes, use cases, and parameter definitions. It is somewhat longer than necessary, but every sentence adds meaningful information for a potential data-retrieval tool, and the parameter section is highly useful. The structure is logical, with no filler or repetition that would harm an agent's parsing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that there is no output schema, the description does enough by summarizing the return content (original and new values with publication dates, per affected account) and by explaining scenarios suited to the tool. Missing pieces include formal response format, behavior on tickers with no restatement, and explicit guidance on when this tool is not the one to use. As a whole, an agent can invoke the tool correctly with confidence, and an essential data is present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 0% description coverage, so the entire semantic weight is on the description. It fully compensates: `ticker` is clarified as a B3 code, uppercase, with class digit and examples; `chave_api` explains when it is optional, when required, which ticker works as a free sample, and how the environment variable fallback behaves. This is exactly the kind of parameter guidance agents need when the schema is unhelpful.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: it returns restated financial statements with both the original and reissued versions ('Devolve, por conta afetada, o valor da versão original e o da versão nova, com as datas das duas publicações'). The resource is identifiable as 'Balanços que a empresa republicou depois', and the emphasis on old numbers staying visible distinguishes it from standard financial-report tools, even though it does not explicitly name a sibling. A 4 is appropriate because the objective is clear, but sibling differentiation is implicit rather than explicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear contexts: it 'Serve para auditar mudança de histórico e para saber se um backtest rodou sobre números que depois foram revistos'. This gives an agent an actionable sense of when to invoke the tool. However, it does not state when not to use it or mention alternatives such as `fatos_contabeis` or `indicadores_anuais` for current data, so it falls short of the explicit when/not/alternatives standard.

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

• fatos_contabeisA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full responsibility for behavioral disclosure. It explains that 'trimestral' changes granularity but not filtering, that APIs are optional for WEGE3, and how to fall back to an environment variable. It also clarifies the output includes period-level metrics with source codes. It does not describe the exact response structure or error behavior, but for a read-only data query, this is reasonable coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: a short purpose paragraph followed by a bullet-style parameter list. It is concise, each sentence adds value, and the most important information (purpose) is front-loaded. There is no fluff or repetition, and the formatting aids scanning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the tool's purpose, parameters, and output concept (list of period metrics with source codes). However, it does not specify the exact JSON response structure, pagination, or error handling (e.g., invalid ticker). Since there is no output schema, a bit more detail on the return format would make it fully complete. Still, it is sufficient for an agent to invoke correctly and interpret the results at a high level.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must fully compensate. All three parameters are explained with examples, defaults, and business context: 'ticker' includes format and examples, 'trimestral' is thoroughly explained, and 'chave_api' covers optionality, default, and environment variable fallback. This far exceeds what a bare schema provides, making it excellent.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific purpose: returning standardized accounting data for a B3 company with auditability (CVM account codes). It lists the specific metrics (receita, EBIT, etc.) and distinguishes from other tools by its focus on raw accounting figures with provenance. This is clear and specific, clearly apart from siblings like 'indicadores_anuais' or 'multiplos' which derive different metrics.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains parameter behavior in detail (tickercase examples, trimestral granularity semantics, chave_api requirements), which aids correct invocation. However, it provides no explicit guidance on when to choose this tool over alternatives (e.g., when to use 'indicadores_anuais' instead). It only references 'listar_empresas' for ticker format, not for selection criteria. Thus, usage guidance is present but lacks comparative context.

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

• scoresA
  4.3/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses that the tool returns detailed criteria (not just a score), that the API key is dispensable for WEGE3 but necessary for others, and that an empty string uses an environment variable. This is good behavioral context, though it doesn't mention potential errors or rate limits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a clear intro, a bolded statement of the output, and a parameter list. It's a bit long but every sentence adds value. The front-loading of the purpose and the explicit 'you see the account, not just the score' is effective.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 2 parameters, no output schema, and no annotations, the description covers the essential aspects: what it returns, how to format parameters, and the API key handling. It could mention error cases or the exact structure of the output, but it's largely complete for an agent to call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 does: it explains the ticker format (uppercase, with class digit, examples) and the chave_api parameter (optional, default behavior, environment variable fallback). This adds significant meaning beyond the schema's bare property names.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 returns quality and value scores for a B3 company, criterion by criterion, including the Piotroski F-Score with each of the nine criteria detailed and the Graham criterion. It explicitly says the goal is to allow disagreement with the score by showing the underlying calculations, which distinguishes it from a simple score lookup.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains when to use the tool (to see detailed scores and criteria for a B3 company) and provides clear parameter guidance, including examples and a reference to `listar_empresas` for finding tickers. It does not explicitly mention when not to use it or alternatives, but the context is clear enough for an agent to decide.

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

• screenerA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full burden. It discloses key behaviors: it filters only values without flags (clean data), unknown indicator names are rejected with errors, and it implies the operation scans the entire universe (hence API key requirement). It also explains the 'ano' parameter's behavior (not same year for all companies). However, it doesn't disclose performance implications (e.g., slow because full scan) or rate limits, but the core behavioral aspects are covered.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is structured with sections for parameters and behavior. It is detailed but not excessively verbose; each sentence adds value. The front-loading of the main purpose is good, and the parameter list is formatted clearly. It could be slightly more concise in the parameter explanations, but the level of detail is necessary given zero schema coverage.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 4 parameters and no output schema, the description covers the input semantics comprehensively. It doesn't describe the output format, but since there is no output schema and the tool returns a list of companies, it might be helpful to mention the output structure. However, the tool's complexity is moderate and the missing output detail is a minor gap. The description sufficiently covers all operational aspects an agent needs to call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must fully document parameters. It does: explains 'filtros' with a dictionary format, provides an example, lists all 8 accepted indicators, and the 'ano' and 'limite' semantics are clear. It even documents the API key parameter's purpose and default behavior. This is exemplary compensation for the lack of schema documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool filters the entire B3 universe by indicator ranges. It specifies the resource (B3 universe) and the action (filter by indicator ranges). It distinguishes itself from siblings like listar_empresas and indicadores_anuais by focusing on filtering across the whole universe by indicators, and mentions that it returns a 'cardápio' when called without filters, which distinguishes its behavior from other tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear guidance on when to use the tool: to filter the full universe by indicator ranges. It includes a crucial instruction to call without filters to get the list of valid indicators and examples, which serves as a self-help mechanism. However, it doesn't explicitly state when NOT to use this tool versus alternatives like 'multiplos' or 'indicadores_anuais', but the scope (entire universe vs. specific company) is implicit. It also warns about API key requirements, which helps decide when to use it.

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

• dividendosA
  4.5/5.0
  Behavior4/5

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

  The description explicitly distinguishes between 'no dividend' and 'no information' in the response, clarifying a potential ambiguity. It also notes that the source is B3 and that the original type is preserved. However, it does not describe error handling or response format details beyond this distinction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-organized: a brief summary, a detailed return description, parameter explanations, and a note on response semantics. No redundant information, and each section serves a clear purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers both input parameters and the core behavior, including the crucial distinction between absence of data and absence of information. There is no output schema, but the description provides sufficient context about the return content. Minor gaps like explicit error scenarios or response format details are not critical for usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters are thoroughly explained: ticker includes format, case, and examples; chave_api explains its purpose, when it's dispensable, and how to use the environment variable fallback. This fully covers the input schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that the tool provides cash dividends from B3-listed companies, including dividend yield. It further elaborates on the output: each dividend with value per share, ex-dividend date, approval date, plus annual summary and trailing twelve-month yield. This is specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Parameter usage is well explained: ticker format with examples and reference to listar_empresas, and chave_api with instructions to leave empty for environment variable. However, it does not explicitly state when to prefer this tool over siblings or mention any prerequisites or limitations beyond parameter handling.

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

• indicadores_anuaisA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full behavioral disclosure burden and does it well: it states the time range, the annual output contents, the API-key requirement (optional only for WEGE3), the environment-variable fallback, and the `erro` field returned when no valid key is provided. It does not mention rate limits or exact response structure, but the essential authentication, scope, and error behaviors are disclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with purpose and output, followed by a one-line pointer to `metodologia` and a compact `Parâmetros` section. It is about 150 words, and every sentence adds needed information about scope, return contents, parameter syntax, or error handling. Nothing feels redundant or padded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no annotations and no output schema, the description covers selection, parameter syntax, data range, metric list, and error behavior. The only real gap is an explicit response shape, but the listed indicators and the mention of an `erro` field make the return contract reasonably predictable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description compensates fully. For `ticker`, it explains the B3 uppercase class-digit format and gives examples (WEGE3, PETR4, SANB11), plus points to `listar_empresas`. For `chave_api`, it explains the free WEGE3 option, the requirement for other companies, the empty-string environment-variable fallback, and the error behavior. This far exceeds the bare string types in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The first sentence defines the tool as an annual series of fundamental indicators for a B3 company, and the description explicitly lists the returned metrics per year: ROIC, ROE, margins, revenue/profit growth, and net debt/EBITDA. This is a specific verb/resource pairing that clearly differentiates it from sibling tools like multiplos or fatos_contabeis, even without naming them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear operational context: it covers 2010 through the last published fiscal year and returns per-year metrics, which implies use for historical fundamental analysis. It also explicitly routes users to `metodologia` for calculation details and to `listar_empresas` for ticker discovery. However, it does not explicitly contrast with sibling tools like `saude`, `multiplos`, or `fatos_contabeis`, so selection among those alternatives is only implicit.

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

• saudeA
  4.5/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• listar_empresasA
  4.6/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters5/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• dicionarioA
  4.8/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters5/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.