Server Quality Checklist

Tool Scores

• calcular_dasA
  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 explains the return values (faixa, bandeiras for sublimite and regime exit), the meaning of the calculated rate, and a key caveat about consulting carga_fora_do_das. It also sets expectations by stating it calculates legal tables and is not tax advisory, though it does not describe edge-case handling or validation 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 reasonably concise and front-loaded with the core purpose, followed by return values, parameter-mode guidance, and caveats. Each sentence adds information, though the final disclaimer about not being tax advisory could be seen as slightly tangential. Overall, it is dense without being bloated.

  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 that no annotations exist and schema coverage is 0%, the description does a good job of covering the main inputs, outputs, and one sibling relationship. However, it omits the incluir_reparticao parameter, does not clarify how conflicts between rbt12 and receita_acumulada should be handled, and does not explain how this tool relates to siblings like resolver_anexo_fator_r or comparar_anexos.

  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 0%, so the description must compensate for the schema. It does explain the distinction between rbt12 and receita_acumulada/meses_de_atividade, and it mentions anexo and the monthly revenue implicitly via 'DAS do mês'. However, the parameter incluir_reparticao is not described at all, and receita_do_mes is only implied, leaving meaningful gaps in parameter understanding.

  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 specific verb and resource ('Calcula o DAS do mês e a alíquota efetiva') and names the key inputs (anexo, RBT12). It also differentiates itself from the sibling 'carga_fora_do_das' by clarifying that the returned rate is only the DAS portion, so the agent can distinguish the 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 context for when to call the tool and gives explicit conditional guidance for companies with less than 13 months of activity, telling the agent to use receita_acumulada and meses_de_atividade instead of rbt12. It also directs the agent to consult the sibling tool carga_fora_do_das before making claims about total tax burden, but it does not explicitly state when not to use this tool versus other siblings.

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

• ressalvas_setoriaisA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the disclosure burden and does so reasonably: it states that the tool 'Calcula as tabelas publicadas em lei', warns that a missing sector does not mean DAS covers its burden, and explicitly disclaims tax-advisory scope. It does not mention potential errors or output limits, but the output schema helps fill that gap.

  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 compact and front-loads the core action, then adds brief scope, legal-basis, and disclaimer sentences. Each sentence adds information, though the final disclaimer is slightly long relative to the rest.

  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 one-parameter tool with an output schema, the description covers invocation behavior, legal calculation basis, and a key caveat about DAS coverage. It is complete enough for an agent to select and call the tool correctly, though a more explicit allowed-value list for 'setor' would raise this further.

  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 coverage is 0%, so the description must compensate. It effectively explains the optional 'setor' parameter by listing example sector values and stating that omitting the argument lists registered sectors. It does not define exact accepted string formats, but the examples and default behavior are enough for a single optional parameter.

  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 opens with a specific verb and resource: 'Lista as ressalvas de um setor' and enumerates the affected sectors such as bebidas alcoólicas, medicamentos, and combustíveis. It clearly conveys the tool's domain, though it does not explicitly distinguish it from sibling tools like carga_fora_do_das.

  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?

  It gives a clear scope of use: sectors under special PIS/COFINS or ICMS regimes, and explains the no-argument behavior ('Sem argumento, lista os setores registrados'). It also sets an exclusion by noting it is not tax advisory, but it does not refer to any alternative tool.

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

• quantificar_segregacaoA
  4.1/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 transparency burden and does a good job: it reveals the calculation logic (segregated tax percentages are disregarded), the three returned values, and that the difference is recoverable. It also disclaims tax-advisory scope, which helps set agent expectations.

  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 dense but organized: the main purpose comes first, followed by input guidance, outputs, target user, and a safety disclaimer. It is somewhat long, but each sentence adds useful information and no filler is present.

  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 calculation context, required revenue segmentation, outputs, intended user, and important boundary conditions. Given the tool's tax complexity and the presence of an output schema, it is reasonably complete, though it could further clarify how the optional revenue parameters should be filled relative to the month total.

  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 0%, so the description must compensate. It gives meaning to the segregation categories by explaining monofásica and ICMS-ST revenue, but it does not explain required parameters like 'anexo' and 'rbt12' beyond their self-explanatory names. This is partial compensation, not complete.

  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 specific verb+resource statement ('Quantifica o efeito da segregação de receitas no DAS') and goes on to define the exact outputs: DAS sem segregar, DAS segregado, and the difference. This clearly separates it from the generic calcular_das sibling by describing a specialized calculation.

  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?

  It explicitly says when to use the tool ('Use para quem REVENDE mercadoria já tributada na origem') and when not to ('quem produz é o responsável... não abaixo'). It does not name an alternative sibling, but the target audience and exclusions are clearly stated.

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

• comparar_anexosA
  4.5/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full disclosure burden and does so thoroughly: it reveals the calculation basis (total load vs DAS rate), the folha dependency and its exact mechanism (only Annex IV; 20% employer contribution plus 1%-3% RAT adjusted by FAP), and the misleading result when folha is omitted. It also sets expectations that it computes legal tables and does not address classification.

  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 long (six sentences) but each sentence earns its place: load-vs-rate distinction up front, then the folha caveat, sibling routing, scope limits, and disclaimer. It is front-loaded with the core purpose, though it could be tightened slightly without losing the essential caveats.

  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 5-parameter tool with no annotations and 0% schema coverage, the description covers purpose, the critical parameter trap, sibling differentiation, and scope limits; the output schema covers return values. The remaining gap is the absence of any prose meaning or constraints for the two required inputs, rbt12 and receita_do_mes.

  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 0%, so the description must compensate. It explains folha well (only affects Annex IV, employer contribution at 20%, RAT/FAP mechanics) and indirectly clarifies fap and rat_pct, but the two required parameters, rbt12 and receita_do_mes, receive no prose explanation and rely on self-evident names. Compensation is partial, not complete.

  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 states a specific verb and resource: compares the five annexes by TOTAL LOAD rather than by DAS rate. It explicitly differentiates from the sibling calcular_das ('use this tool, not repeated calcular_das') whenever the question is which annex costs least, so an agent can select it without opening the schema.

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

  Usage Guidelines5/5

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

  Gives an explicit when-to-use rule ('quando a pergunta for qual anexo custa menos') and a when-not-to (not repeated calcular_das), plus the condition to pass folha so the comparison is not misleading. It also states what the tool does not do — it compares costs, does not define annex classification, and is not tax advisory — which prevents off-scope use.

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

• carga_fora_do_dasA
  4.6/5.0
  Behavior5/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 — and it delivers. It discloses the qualitative nature of the output (directional effects ACRESCENTA/REDUZ, never values), the two underlying structural causes, the legal basis ('Calcula as tabelas publicadas em lei'), and the authority boundary (enquadramento, regime, and obrigações acessórias left to accountants). This is rich behavioral context the schema could never express.

  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?

  Front-loaded with the core purpose statement, followed by the usage trigger, then concrete examples that double as parameter semantics. Each sentence earns its place; the elaboration of the two exclusion reasons is the longest stretch, but it adds conceptual value the schema lacks rather than padding.

  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 zero annotations and zero schema coverage, this is remarkably complete: it covers tool selection, invocation timing, parameter semantics, output expectations (directions, not values), and professional boundaries. An output schema exists, so documenting return values is not the description's job. The only gap is the edge case of receita_monofasica and receita_com_icms_st both being true, which the description treats as alternatives ('ou').

  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 compensate and does so thoroughly. It explains posicao via the chain-position rule ('para quem produz ACRESCENTA, para quem revende REDUZ'), gives meaning to receita_monofasica and receita_com_icms_st through the 'segregação de receita' concept, and contextualizes anexo with the Annex IV employer-contribution example. Every parameter gains meaning beyond its raw name and enum.

  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 specific verb+resource: 'Diz o que a alíquota efetiva do anexo NÃO cobre, e em que direção cada item altera a carga.' It explicitly distinguishes itself from quantifying tools by stating 'Não quantifica valores... isso exige a repartição do DAS por tributo', so an agent can tell it apart from calcular_das and quantificar_segregacao without inspecting either.

  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?

  Gives an explicit invocation trigger: 'Chame esta ferramenta antes de afirmar qual é a carga tributária de alguém: a alíquota efetiva é a carga do DAS, e não a total.' It also states clear non-goals ('Não quantifica valores', 'Não é assessoria fiscal') that function as when-not-to-use signals. However, it never names sibling tools as concrete alternatives, so routing between options is implicit rather than explicit.

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

• resolver_anexo_fator_rA
  4.7/5.0
  Behavior5/5

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

  Sem anotações, a descrição carrega a transparência: explica o cálculo, define o caso-limite '28% ou mais', quantifica a consequência ('diferença de até 9,5 pontos') e declara o que não faz ('não é assessoria fiscal'). Isso é mais transparente que o esperado para uma calculadora pura.

  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?

  Quatro frases densas começam pela decisão e fórmula, seguidas do limiar e da ressalva; não há repetição do schema nem conteúdo supérfluo. Cada frase agrega informação para o agente.

  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?

  A definição cobre todos os elementos necessários para invocar corretamente: entradas, fórmula, limiar, escopo e limitações. Há output schema disponível, e os dois parâmetros simples já são explicados na própria descrição.

  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?

  Com 0% de cobertura no schema, a descrição compensa ao mapear folha_12m e rbt12 para 'folha de salários' e 'receita bruta', e especificar que ambas são dos 12 meses anteriores. Não detalha formato monetário ou de string, mas a semântica essencial está presente.

  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?

  A descrição abre com verbo específico e recurso: 'Decide entre Anexo III e Anexo V ... pelo Fator R', com limiar de 28% e escopo §5º-I. Isso separa claramente a ferramenta de calcular_das e das demais, tornando o propósito inconfundível.

  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?

  Há contexto claro de uso: atividades do §5º-I (serviços intelectuais) e decisão baseada em Fator R, com inputs dos 12 meses anteriores. Falta apenas nomear alternativas ou quando não usar em relação aos irmãos, embora a ressalva 'não é assessoria fiscal' funcione como limite de escopo.

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

• indebito_acumuladoA
  4.8/5.0
  Behavior5/5

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

  With no annotations present, the description carries the full burden and does so thoroughly. It discloses the DAS due date convention, the late-payment caveat, that administrative requests do not interrupt the limitation period, that tables are calculated as published in law, and that classification/regime decisions 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.

  Conciseness5/5

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

  Every sentence earns its place: purpose, input structure, timing assumption, legal nuance, and scope boundary. The description is front-loaded with the core purpose and avoids filler or redundant restatements of the tool name.

  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 complex tool involving legal deadlines and tax concepts, the description is remarkably complete. It explains the required inputs, the payment-reference rule, the limitation-period nuance, and the boundaries of the tool's responsibility. Since an output schema exists, the return-value details don't need to be described.

  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%, but the description compensates by specifying that each competência must include ano, mes, rbt12, and revenue split by category. This is essential because the schema's array items are completely open with additionalProperties: true. The anexo parameter is already constrained by its enum, so the description doesn't need to repeat 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 a specific verb and resource: it 'sums the undue payment' for those who resold without segregating monophasic revenue or ICMS-ST, and 'separates' amounts still within the five-year CTN limitation period from those already prescribed. This specificity distinguishes it from siblings like calcular_das and quantificar_segregacao without needing to name 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 clearly identifies the target use case (resellers who did not segregate monophasic revenue or ICMS-ST) and instructs the user to pass a list of competências. It also sets exclusions, such as 'não é assessoria fiscal,' but it does not explicitly name when to prefer this tool over an alternative sibling.

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