Server Quality Checklist

Tool Scores

• simular_impacto_rotaC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden. It reveals one behavioral trait: UFs are resolved automatically via BrasilAPI. However, it does not disclose whether the tool is read-only, destructive, or if it has rate limits, error behavior, or prerequisites like CNPJ validity. This is insufficient for an agent to safely invoke the tool.

  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?

  Description is a single sentence – concise and front-loaded. No superfluous words. However, it could afford to be slightly longer to cover parameter details and usage guidance without losing conciseness.

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

  Completeness2/5

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

  Given no output schema or annotations, and a moderately complex tool (external API call, tax impact calculation), the description is incomplete. It does not explain output structure, error handling, or what 'impacto tributário' means operationally. The agent lacks key information for correct invocation and result interpretation.

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

  Parameters2/5

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

  Schema has 0% description coverage, so description must compensate. It mentions CNPJs and implicitly valorFrete but does not explain CNPJ format (14 digits), that valorFrete can be number or string with decimal, or that the tool automatically resolves UFs (already stated). The added value beyond schema is minimal.

  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?

  Description clearly states it simulates tax impact of a freight route using origin/destination CNPJs. The verb 'simula' and resource 'rota de frete' are specific. However, it does not differentiate from sibling tools like 'calcular_carga_tributaria_frete', leaving ambiguity about when to choose this one.

  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?

  Description implies use for tax impact simulation given CNPJs and freight value. It provides no explicit guidance on when not to use this tool or alternatives (e.g., 'calcular_carga_tributaria_frete' for different scenarios). Usage context is implied but not fully clarified.

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

• calcular_carga_tributaria_freteA
  3.5/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 transparency burden. It states the calculation and comparison but does not disclose behavioral details such as idempotency, data persistence, authentication requirements, or rate limits. The description is not contradictory but lacks depth.

  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?

  A single sentence that is direct and front-loaded with the core action. No redundant words. Every part contributes to the purpose.

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

  Completeness2/5

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

  Given 5 parameters, no output schema, and no annotations, the description is too brief. It does not specify the return format (e.g., numeric value, comparison table), nor does it explain how input parameters like UF or NCM affect the calculation. The tool's complexity demands more context.

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

  Parameters2/5

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

  Schema description coverage is 0%, yet the description only mentions 'ano' and the regime comparison. It does not explain 'valorFrete', 'ufOrigem', 'ufDestino', or the optional 'ncm' parameter. The description adds minimal semantic value beyond the parameter 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 calculates the tax burden of freight, specifying the year range (2026–2033) and the comparison between new and old tax regimes. It distinguishes from sibling tools by focusing on freight tax calculation, not schedules, company lists, or route simulations.

  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 implies use for freight tax calculation but does not explicitly mention when to use this tool versus the siblings or provide exclusion criteria. No guidance on prerequisites or alternatives.

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

• listar_empresas_cadastradasA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It specifies the return fields (CNPJ, UF, último frete) but omits details like authentication requirements, performance characteristics, or what happens if no companies exist. The description is adequate but not fully transparent.

  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 a single sentence that is front-loaded with the action and resource, followed by output details. Every word contributes meaning without 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 simple list operation with no parameters and no output schema, the description provides sufficient context: what it lists and what data it returns. However, it lacks details on potential ordering or pagination, which would improve completeness.

  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?

  There are no parameters (schema coverage 100%), so the baseline is 4. The description adds value by specifying the fields returned, which compensates for the lack of an output 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 the action (listar todas as empresas), the resource (empresas cadastradas), and the specific data returned (CNPJ, UF, último frete). This distinguishes it from sibling tools which deal with tax, timelines, and route simulation.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives, nor any mention of prerequisites or limitations. It simply states what it does without contextual usage advice.

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

• consultar_cronograma_transicaoA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the burden. It discloses that the tool consults percentages for listed taxes and the year range, but doesn't mention error handling, authentication, or side effects. Adequate for a simple read operation but lacks depth.

  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 a single sentence that is clear and to the point. Every word adds value, with no unnecessary information.

  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 simplicity (one parameter, no output schema), the description is fairly complete. It states what is returned (percentages of each tax) and the valid year range. However, it could mention behavior for invalid years or return format.

  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 zero description coverage for the 'ano' parameter. The description adds meaning by specifying that it is for a year in the 2026–2033 range and that it is part of the 'Reforma Tributária'. This is helpful context beyond 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 description uses the specific verb 'Consulta' and identifies the resource as 'percentuais de cada tributo (ICMS, ISS, PIS, COFINS, IBS, CBS)'. It clearly distinguishes this tool from siblings (e.g., calcular_carga_tributaria_frete) by focusing on querying the transition schedule for a given year.

  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 implies usage for a year between 2026–2033 and focuses on tax percentages, but does not explicitly state when to use this tool over alternatives or provide exclusions. No guidance on prerequisites or context.

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