carga_fora_do_das

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.

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.

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.

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.

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.

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.