Server Quality Checklist

Tool Scores

• ranking_cnaeB
  3.4/5.0
  Behavior2/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 of behavioral disclosure. It mentions ranking criteria ('capital' and 'filiais') and default ordering, but lacks details on permissions, rate limits, data freshness, or what the output looks like (e.g., format, fields). For a tool with no annotations, this leaves significant gaps in understanding its behavior.

  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 into clear sections (purpose, usage guidelines, ordering) with bullet points, making it easy to scan. It is appropriately sized with no redundant information, though the use of all caps in 'RANKING' and 'QUANDO USAR' is slightly informal.

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

  Completeness3/5

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

  Given no annotations and no output schema, the description provides basic purpose and usage but lacks details on behavioral traits, output format, and error handling. It is adequate for a simple ranking tool but has clear gaps, such as not explaining what data fields are returned or potential limitations.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameters well. The description adds minimal value by mentioning default ordering ('capital: Por capital social (padrao)') and the optional 'filiais' criterion, but does not provide additional context beyond what the schema specifies. This meets the baseline for high schema coverage.

  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 purpose: 'RANKING das maiores empresas de um setor' (ranking the largest companies in a sector). It specifies the verb (ranking) and resource (largest companies in a sector), but does not explicitly differentiate it from sibling tools like 'estatisticas_por_cnae' or 'buscar_por_cnae', which might provide similar sector-based data without ranking.

  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 includes a 'QUANDO USAR' section that provides clear contexts for usage: identifying market leaders and Account-Based Marketing (ABM). This offers explicit guidance on when to use the tool, though it does not specify when not to use it or name alternatives among sibling tools.

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

• buscar_avancadoA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the tool performs searches and lists available filters, it doesn't describe important behavioral aspects like whether this is a read-only operation, what permissions might be needed, rate limits, pagination behavior, or what format results are returned in. The description provides basic functionality but lacks operational context.

  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 clear sections (purpose, usage guidelines, available filters) and uses bullet points effectively. Every sentence earns its place, and the information is front-loaded with the core purpose stated first. No wasted words or redundant information.

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

  Completeness3/5

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

  For a search tool with 8 parameters and no output schema, the description provides adequate purpose and usage context but lacks important behavioral information. Without annotations or output schema, the description should ideally explain what kind of results are returned, any limitations, or operational considerations. It's minimally viable but has clear gaps in completeness.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly with descriptions and one enum. The description lists the available filters but doesn't add meaningful semantic context beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting for parameter documentation.

  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 performs a search with multiple combined filters, which is a specific verb+resource combination. It distinguishes itself from simpler search tools by emphasizing 'MULTIPLOS FILTROS combinados' and complex queries. However, it doesn't explicitly name which sibling tools it's different from.

  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 'QUANDO USAR' section provides clear context: use when needing filters other tools don't offer and for complex multi-criteria queries. This gives good guidance on when this tool is appropriate versus simpler alternatives. It doesn't explicitly name specific sibling tools to avoid or provide exclusion criteria.

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

• buscar_por_cnaeA
  3.6/5.0
  Behavior3/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 of behavioral disclosure. The description indicates this is a listing/query tool ('Lista empresas'), which implies a read-only operation, but it doesn't explicitly state whether it's safe, whether it requires authentication, or any rate limits. The 'CNAES COMUNS' section provides helpful examples of common CNAE codes, adding practical context, but behavioral traits like pagination, response format, or error handling are not 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 well-structured with clear sections (purpose, usage guidelines, common examples) and uses bullet points for readability. It's appropriately sized at about 50 words, with no redundant information. However, it could be slightly more front-loaded by integrating the 'QUANDO USAR' insights into the opening sentence for faster scanning.

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

  Completeness3/5

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

  Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description provides a solid foundation with purpose, usage guidelines, and examples. However, it lacks details on behavioral aspects (e.g., what the output looks like, error cases) and doesn't fully leverage the context of sibling tools to guide selection. For a listing tool with no annotations or output schema, more completeness on results format would be beneficial.

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

  Parameters3/5

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

  Schema description coverage is 100%, meaning the input schema already fully documents all three parameters (cnae, uf, limite) with descriptions and examples. The description does not add any parameter-specific details beyond what's in the schema (e.g., it doesn't explain CNAE code structure or UF filtering logic). With high schema coverage, the baseline score is 3, as the description doesn't compensate but also doesn't detract.

  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 purpose: 'Lista empresas de um SETOR especifico (por CNAE)' which translates to 'Lists companies from a specific SECTOR (by CNAE).' This provides a specific verb ('Lista') and resource ('empresas') with the key constraint of using CNAE codes. It distinguishes from siblings like 'buscar_por_nome' (search by name) or 'buscar_por_cep' (search by zip code), but doesn't explicitly differentiate from all sector-related tools like 'estatisticas_por_cnae' (statistics by CNAE).

  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 'QUANDO USAR' section provides clear context for when to use this tool: 'Quer todas empresas de uma atividade economica' (when you want all companies in an economic activity) and 'Prospeccao por vertical/segmento' (prospecting by vertical/segment). This gives practical scenarios, but it doesn't explicitly state when NOT to use it or mention specific alternatives among the many sibling tools (e.g., vs. 'buscar_avancado' for advanced search).

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

• estatisticas_por_cnaeA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what the tool returns (sectors with most companies in ranking format) and mentions a default parameter value, but doesn't disclose important behavioral aspects like whether this is a read-only operation, potential rate limits, authentication requirements, or what format the ranking data takes. The description adds some value but leaves significant gaps.

  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 clear sections (purpose, usage guidelines, parameters) and every sentence earns its place. It's appropriately sized for a single-parameter tool and front-loads the core purpose. The Portuguese formatting with clear section headers makes it easy to parse.

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

  Completeness3/5

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

  For a single-parameter read operation with no annotations and no output schema, the description provides adequate but incomplete coverage. It explains what the tool does and when to use it, but doesn't describe the return format, potential limitations, or how the ranking is calculated. Given the tool's relative simplicity and good parameter documentation, it's minimally viable but could benefit from more behavioral context.

  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 description includes a 'PARAMETROS' section that explains the 'limite' parameter as 'Top N CNAEs (padrao: 20)' which adds semantic meaning beyond the schema's 'Quantidade de CNAEs no ranking (padrao: 20)'. The schema description coverage is 100%, so the baseline would be 3, but the description's framing of the parameter as 'Top N CNAEs' provides additional context about how the parameter affects the ranking output.

  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 purpose: 'Retorna SETORES com mais empresas (ranking de CNAEs)' which translates to 'Returns SECTORS with most companies (CNAE ranking)'. This specifies the verb (returns), resource (sectors/companies), and scope (CNAE ranking). However, it doesn't explicitly differentiate from sibling tools like 'ranking_cnae' which appears to be a similar tool.

  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 includes a 'QUANDO USAR' section with two clear use cases: 'Identificando mercados maiores' (identifying larger markets) and 'Analise de oportunidade por vertical' (opportunity analysis by vertical). This provides good contextual guidance, though it doesn't specify when NOT to use this tool or mention alternatives like the 'ranking_cnae' sibling tool.

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

• buscar_por_cepA
  4.1/5.0
  Behavior3/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 describes the tool's behavior (searching companies by ZIP code with filters) and mentions default values for 'situacao' and 'limite', which adds useful context. However, it doesn't disclose important behavioral traits like rate limits, authentication needs, pagination, or what happens with invalid inputs.

  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 clear sections (purpose, usage guidelines, parameters). Each sentence earns its place: the first states the purpose, the 'QUANDO USAR' provides context, and 'PARAMETROS' lists parameters efficiently. No wasted words or redundancy.

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

  Completeness3/5

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

  Given no annotations and no output schema, the description is moderately complete. It covers purpose, usage, and parameters well, but lacks details on return values (format, structure), error handling, or system constraints. For a search tool with 4 parameters, this leaves gaps in understanding the full behavior.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description's 'PARAMETROS' section repeats information already in the schema (e.g., 'cep: CEP de 8 digitos' vs schema's 'CEP de 8 digitos (so numeros)'). It adds minimal value beyond the schema, maintaining the baseline of 3.

  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: 'Busca empresas por CEP' (Search companies by ZIP code). It specifies the verb ('busca') and resource ('empresas'), and distinguishes from siblings like 'buscar_por_nome' (search by name) or 'buscar_por_cnae' (search by CNAE) by focusing on geographic search.

  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 'QUANDO USAR' section explicitly provides usage scenarios: when wanting companies in a specific region or for geographic prospecting. This clearly distinguishes it from alternatives like 'buscar_empresa' (general company search) or 'buscar_por_nome' (search by name), though it doesn't explicitly name those alternatives.

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

• buscar_por_socioA
  4.1/5.0
  Behavior3/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 mentions the minimum character requirement for 'nome' and default value for 'limite', which adds useful behavioral context. However, it doesn't disclose important aspects like rate limits, authentication requirements, error conditions, or what happens when no results are found.

  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 clear sections (purpose, usage guidelines, parameters) and every sentence earns its place. It's appropriately sized and front-loaded with the core purpose, making it easy to scan and understand quickly.

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

  Completeness3/5

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

  For a search tool with no annotations and no output schema, the description provides good purpose and usage guidance but lacks important behavioral context. It doesn't describe the return format, pagination behavior, or error handling. Given the complexity and lack of structured metadata, it should do more to be complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description repeats the same parameter information without adding meaningful semantic context beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting.

  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: 'Busca empresas por NOME DE SOCIO' (Search companies by PARTNER NAME). This is a specific verb+resource combination that distinguishes it from siblings like 'buscar_empresa' (search company) or 'socios' (partners). The title being null doesn't affect this clarity.

  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 'QUANDO USAR' section explicitly provides two concrete use cases: finding all companies of a businessperson and mapping an investor's portfolio. This gives clear guidance on when to use this tool versus alternatives like 'buscar_empresa' or 'socios'.

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

• buscar_similaresA
  4.3/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses the similarity algorithm (CNAE, size, region), which adds valuable behavioral context beyond basic functionality. However, it doesn't cover aspects like performance characteristics, error handling, or output format, leaving gaps in behavioral understanding for a tool with no annotations.

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

  Conciseness5/5

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

  The description is well-structured with clear sections (purpose, usage guidelines, algorithm), front-loaded with the core purpose. Every sentence adds value: the first states what it does, the second provides usage scenarios, and the third explains the similarity criteria. No wasted words or redundancy.

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

  Completeness3/5

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

  Given no annotations and no output schema, the description is moderately complete. It covers purpose, usage, and algorithm well, but lacks details on output format, error cases, or performance limits. For a tool with 4 parameters and complex similarity matching, more behavioral context would be beneficial to fully guide the agent.

  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 100%, so the baseline is 3. The description adds meaningful context by explaining the multi-dimensional scoring approach (CNAE, capital, region), which helps interpret the 'score_minimo' parameter's significance. This elevates the score above baseline, though it doesn't provide detailed syntax beyond what the schema offers.

  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 with a specific verb ('Encontra') and resource ('empresas SIMILARES'), distinguishing it from siblings like 'buscar_empresa' (find specific company) or 'buscar_por_cnae' (find by activity code). It specifies 'scoring multi-dimensional' for similarity matching, making the purpose distinct and well-defined.

  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 'QUANDO USAR' section explicitly provides two scenarios for when to use this tool: for lookalike analysis of good clients and for portfolio expansion with similar companies. This gives clear, actionable guidance that differentiates it from alternatives like 'benchmark_empresa' or 'buscar_avancado' without needing to list exclusions.

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

• benchmark_empresaA
  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 the full burden. It discloses behavioral traits: the tool returns comparative data (company data, sector statistics, relative ranking position) as outlined in the 'RETORNA' section. However, it doesn't mention potential limitations like rate limits, authentication needs, or data freshness, which would be helpful for a tool with no annotations.

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

  Conciseness5/5

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

  The description is well-structured with clear sections (purpose, usage guidelines, returns) and front-loaded key information. Each sentence earns its place: the first states the purpose, the second and third specify when to use, and the last three detail what is returned. There's no wasted text, and it's appropriately sized for the tool's complexity.

  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 the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is mostly complete. It covers purpose, usage, and return values, which is sufficient for a comparative analysis tool. However, without annotations or an output schema, it could benefit from more behavioral context (e.g., error handling or data sources) to be fully comprehensive.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both parameters ('cnpj' and 'uf') documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides (e.g., it doesn't explain how 'uf' affects sector filtering or CNPJ format). With high schema coverage, the baseline is 3, and the description doesn't compensate with extra semantic details.

  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: 'Compara empresa com a MEDIA DO SETOR' (Compare company with SECTOR AVERAGE). It specifies the verb 'compara' (compare) and the resource 'empresa' (company) against 'media do setor' (sector average), distinguishing it from siblings like 'buscar_empresa' (search company) or 'estatisticas_por_cnae' (statistics by CNAE).

  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 includes a dedicated 'QUANDO USAR' (WHEN TO USE) section with explicit guidelines: 'Quer saber se empresa esta acima ou abaixo da media' (Want to know if company is above or below average) and 'Analise comparativa de porte/capital' (Comparative analysis of size/capital). This clearly indicates when to use this tool versus alternatives like 'empresa_completa' (complete company) or 'estatisticas_por_cnae' (statistics by CNAE).

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

• empresa_completaA
  4.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a read operation ('Retorna dados') and specifies what data is returned, but doesn't mention potential limitations like rate limits, authentication requirements, or error conditions. The behavioral information is adequate but not comprehensive.

  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 clear sections (purpose, usage guidelines, return values) and every sentence adds value. It's appropriately sized for the tool's complexity, front-loading the core purpose and efficiently communicating essential information without unnecessary elaboration.

  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 the tool's moderate complexity (single parameter, no output schema, no annotations), the description provides good coverage of purpose, usage, and return values. It explains what data is returned in detail, though it doesn't specify format or structure. The description is mostly complete for helping an agent understand when and how to use this tool effectively.

  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 input schema has 100% description coverage for its single parameter (cnpj), so the schema already documents this parameter well. The description doesn't add any parameter-specific information beyond what's in the schema, but with only one parameter and high schema coverage, a baseline of 3-4 is appropriate. The description focuses appropriately on what the tool does rather than parameter details.

  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 with specific verbs ('Retorna dados COMPLETOS') and resources ('empresa'), explicitly listing the three data components returned (cadastro, socios, regime tributario). It effectively distinguishes this tool from sibling tools like 'buscar_empresa' by emphasizing it provides more comprehensive data.

  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 includes a dedicated 'QUANDO USAR' section with three explicit scenarios for when to use this tool (due diligence, checking socios, verifying tax regime). This provides clear guidance on appropriate contexts, though it doesn't explicitly mention when NOT to use it or name specific alternatives.

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

• estatisticas_por_ufA
  4.4/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 burden. It discloses key behavioral traits: returns active companies only, returns a list sorted by quantity (descending), and returns UF (state) codes with company counts. However, it doesn't mention potential limitations like data freshness, source constraints, or error conditions.

  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 clear sections (purpose, usage guidelines, return format). Each sentence adds value: the first states the core function, the second provides use cases, the third details the return format. No wasted words, and information is front-loaded appropriately.

  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 zero-parameter tool with no output schema, the description provides good completeness: it explains what the tool does, when to use it, and what it returns. However, without annotations or output schema, it could benefit from more detail about return format (e.g., exact field names, data types) or any constraints on the data.

  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 0 parameters with 100% schema description coverage. The description appropriately doesn't discuss parameters since none exist, earning a baseline 4. It focuses instead on what the tool returns and when to use it.

  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: 'Retorna QUANTIDADE de empresas por estado brasileiro' (Returns QUANTITY of companies per Brazilian state). It specifies both the verb (returns) and resource (companies per state), and distinguishes itself from siblings like 'estatisticas_por_cnae' by focusing on state-level statistics rather than industry classification.

  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 includes a 'QUANDO USAR' section with two clear use cases: market analysis by region and prioritizing states for expansion. This provides good contextual guidance, though it doesn't explicitly state when NOT to use this tool or name specific alternatives among siblings.

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

• regime_tributarioA
  4.4/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 burden and does well by specifying what information is returned (simples_nacional, mei, dates). However, it doesn't mention potential limitations like rate limits, authentication requirements, or error conditions that would be helpful for a production agent.

  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 perfectly structured with clear sections (purpose, usage guidelines, return values) and every sentence earns its place. It's front-loaded with the core purpose and uses bullet points efficiently without any wasted words.

  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 single-parameter lookup tool with no output schema, the description provides excellent context about what the tool does, when to use it, and what it returns. The only minor gap is lack of information about error handling or edge cases, but overall it's quite complete for this complexity level.

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

  Parameters3/5

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

  Schema description coverage is 100% with the single 'cnpj' parameter well-documented in the schema. The description doesn't add any additional parameter information beyond what's in the schema, which is acceptable given the high coverage. Baseline 3 is appropriate.

  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 with specific verbs ('verifica regime tributario') and resources ('Simples Nacional ou MEI'), distinguishing it from siblings like 'buscar_empresa' or 'empresa_completa' which have broader scopes. It explicitly identifies the two specific tax regimes it checks.

  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 'QUANDO USAR' section provides explicit guidance on when to use this tool: for checking if a company can issue simplified invoices or filtering companies by tax regime. It clearly distinguishes use cases from other tools that perform general searches or lookups.

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

• sociosA
  4.4/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 of behavioral disclosure. It clearly describes what the tool returns (a list of partners with specific fields), which is helpful behavioral context. However, it doesn't mention potential limitations like rate limits, authentication requirements, or error conditions. The description doesn't contradict any annotations since none exist.

  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 clear sections (purpose, usage guidelines, return values) and every sentence adds value. It's appropriately sized for the tool's complexity - not overly verbose but comprehensive enough. The information is front-loaded with the core purpose stated first.

  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 single-parameter read-only tool with no output schema, the description provides good contextual completeness. It explains what the tool does, when to use it, and what it returns. The main gap is the lack of output schema, but the description compensates by detailing the return structure. Some additional behavioral context (like limitations or error handling) would make it more complete.

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

  Parameters3/5

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

  Schema description coverage is 100% with the single parameter 'cnpj' already documented in the schema. The description doesn't add any additional parameter information beyond what the schema provides. With high schema coverage, the baseline score of 3 is appropriate since the description doesn't compensate but also doesn't need to given the schema's completeness.

  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: 'Lista o quadro societario completo de uma empresa' (Lists the complete corporate structure of a company). This is a specific verb ('Lista') + resource ('quadro societario') combination that distinguishes it from sibling tools like 'buscar_empresa' or 'empresa_completa' which likely provide broader company information rather than focused ownership data.

  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 includes an explicit 'QUANDO USAR' (WHEN TO USE) section with two clear scenarios: when you want to identify owners/partners and when you need their CPF/CNPJ for other searches. This provides specific guidance on when this tool is appropriate versus alternatives, though it doesn't explicitly name sibling tools as alternatives.

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

• bulk_lookupA
  4.6/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 of behavioral disclosure. It successfully communicates the batch operation nature and includes a critical 'LIMITES' (limits) section specifying the maximum of 100 CNPJs per request. However, it doesn't mention authentication requirements, rate limits, or what format the results will be returned in.

  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 extremely well-structured with clear sections (purpose, usage guidelines, limits) and uses bullet points for readability. Every sentence earns its place - the first establishes purpose, the second provides usage context, and the third sets critical constraints. No wasted words.

  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 single-parameter tool with no output schema, the description provides excellent context about when to use it and operational limits. However, it doesn't describe what information will be returned about each CNPJ or the response format, which would be helpful given the lack of output schema.

  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 input schema has 100% description coverage, so the baseline is 3. The description adds value by reinforcing the parameter semantics in the 'LIMITES' section, explicitly stating the maximum of 100 CNPJs per request, which provides important usage context beyond the schema's basic parameter 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 purpose with a specific verb ('Consulta' - query/lookup) and resource ('MULTIPLOS CNPJs' - multiple CNPJs), distinguishing it from sibling tools that appear to query single entities or use different search criteria. The batch/lot nature is explicitly mentioned, making 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.

  Usage Guidelines5/5

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

  The description includes explicit 'QUANDO USAR' (when to use) guidelines with two specific scenarios: having a list of CNPJs to enrich and importing data from spreadsheets/CRM. This provides clear context for when this batch tool is appropriate versus the many single-entity search sibling tools.

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

• buscar_empresaA
  4.6/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 burden and does well by specifying what data is returned (detailed fields in 'RETORNA' section) and providing a concrete example. It doesn't mention rate limits, authentication requirements, or error conditions, but provides substantial behavioral context for a lookup tool.

  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?

  Excellent structure with clear sections (description, usage guidelines, returns, example). Every sentence earns its place - the purpose statement is front-loaded, usage guidelines are bulleted for clarity, returns are organized, and the example is specific and helpful. No wasted words.

  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 single-parameter lookup tool with no output schema, the description provides comprehensive context: clear purpose, usage guidelines, detailed return values, and an example. It doesn't specify error cases or rate limits, but given the tool's simplicity and the detailed return specification, it's nearly complete.

  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 schema has 100% description coverage with clear parameter documentation, so baseline is 3. The description adds value by providing a concrete example with Banco do Brasil's CNPJ, which helps users understand the expected format and provides a real-world reference point beyond the schema's technical specification.

  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 specific verb ('busca' - searches) and resource ('dados cadastrais de uma empresa brasileira' - registration data of a Brazilian company) with the specific identifier ('pelo CNPJ' - by CNPJ). It explicitly distinguishes this tool from siblings like buscar_por_nome, buscar_por_cep, and buscar_avancado by focusing exclusively on CNPJ-based lookup.

  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 'QUANDO USAR' section provides explicit guidance on when to use this tool: when you have a specific CNPJ, need to validate CNPJ existence/status, or want specific company details. This clearly differentiates it from alternative tools like buscar_por_nome (name-based search) or bulk_lookup (multiple records).

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

• buscar_por_nomeA
  4.6/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 of behavioral disclosure. It effectively communicates this is a search/read operation (not destructive), mentions the 3-character minimum requirement for the nome parameter, and specifies default behavior (limite defaults to 50). However, it doesn't mention rate limits, authentication needs, or pagination behavior for large result sets.

  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 perfectly structured with clear sections (purpose, usage guidelines, parameters), each containing only essential information. Every sentence earns its place: the first states the core function, the second provides use cases, and the third explains parameters concisely. No wasted words or redundancy.

  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 search tool with 3 parameters, 100% schema coverage, and no output schema, the description provides excellent context about purpose, usage, and parameters. The main gap is the lack of information about return format (what fields are included in results, structure of response). However, given the tool's relative simplicity and excellent parameter documentation, it's mostly complete.

  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?

  With 100% schema description coverage, the baseline is 3. The description adds meaningful context by grouping parameters in a dedicated section, clarifying that 'nome' is a search term with minimum length, 'uf' is optional state filtering, and 'limite' has a default value of 50. This organization helps the agent understand parameter relationships beyond what the schema provides individually.

  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: 'Busca empresas pelo NOME (razao social ou nome fantasia)' - it specifies the verb (busca/search), resource (empresas/companies), and scope (by name including both legal and trade names). It distinguishes from siblings like buscar_por_cnpj, buscar_por_cep, and buscar_avancado by focusing specifically on name-based search.

  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 includes an explicit 'QUANDO USAR' section with two clear use cases: when you know the name but not the CNPJ, and when you want to find all units of a network. This provides specific guidance on when to use this tool versus alternatives like buscar_empresa (likely for CNPJ-based lookup) or buscar_avancado (likely for more complex queries).

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

• filiaisA
  4.6/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 of behavioral disclosure. It effectively describes the tool's behavior by specifying what it returns (list of branches with CNPJ, address, status) and implies it's a read-only operation through 'Lista'. However, it lacks details on potential limitations like rate limits or error handling, which would be beneficial for a tool with no annotations.

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

  Conciseness5/5

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

  The description is well-structured with clear sections (purpose, usage guidelines, returns), each sentence is necessary and front-loaded with key information. There is no wasted text, and it efficiently communicates the tool's function and context in a compact format.

  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 the tool's low complexity (1 parameter, no output schema, no annotations), the description is mostly complete. It covers purpose, usage, and return values adequately. However, without annotations or output schema, it could benefit from more behavioral details like pagination or error cases, but it's sufficient for this simple list operation.

  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 input schema has 100% description coverage for its single parameter 'cnpj', so the baseline is 3. The description adds value by clarifying the parameter's purpose in context ('CNPJ base' for listing branches) and implicitly reinforcing it through 'mesmo CNPJ base', but it doesn't provide additional syntax or format details beyond the schema's description.

  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 specific action ('Lista todas as filiais') and resource ('de uma empresa'), distinguishing it from siblings like 'buscar_empresa' or 'empresa_completa' by focusing on branch locations rather than company details. It explicitly mentions the scope constraint 'mesmo CNPJ base', which clarifies the tool's unique function.

  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 'QUANDO USAR' section provides explicit guidance on when to use this tool: for mapping geographic presence or counting company units. This directly addresses alternative scenarios without naming specific siblings, making it clear when this tool is appropriate versus others like 'buscar_por_cep' or 'empresa_completa'.

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