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

With no annotations, the description carries the behavioral burden and it does disclose an important non-obvious behavior: in 2026 it returns test rates (CBS 0.9%/IBS 0.1%) and notes the definitive rate depends on the RFB/TCU/Senado process. It does not describe output shape or error handling, but the central caveat is present.

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?

Thedescription is compact and well organized: main statement, parameter list, then a prominent warning. It earns its place with useful caveats and has no filler.

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?

For a simple reference-rate lookup with no required params and no output schema, the description covers invocation semantics and the key 2026 behavioral caveat. A minor gap is that it does not state explicitly what the return value look like (percentage, decimal, object), but the singular 'aliquota' and test-rate examples sufficiently imply a rate value.

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. It explains all four parameters: esphera values, the dependencies between esphera and the code fields, and the data format/default. It could add more detail about the expected coding system for UF/municipality, but it is well above the schema alone.

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 clearly identifies the resource: the official reference rate valid on the consulted date, and explains the three sphere variants (uniao/uf/municipio). It does not use an explicit verb like 'returns' or 'gets', and it does not explicitly contrast itself with sibling tools, but its purpose is unmistakable.

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 explicit parameter-level guidance: 'uf' requires codigo_uf, 'municipio' requires codigo_municipio, and 'data' defaults to today when omitted. It also flags a crucial temporal condition for 2026. No alternative-tool routing is provided, but the usage context for this lookup is clear.

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

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

With no annotations, the description must carry the safety and behavior burden. 'Conferir a montagem da base' conveys a non-mutating, verification-like behavior and 'antes do cálculo' clarifies it does not produce the final tax amount. However, it does not disclose response content, side effects, auth, or error behavior, so transparency is only partial.

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?

Two sentences, no filler, and the core identifier (base de cálculo CBS/IBS mercadorias) is front-loaded before the endpoint and use case. Every sentence earns its place.

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 no annotations, no output schema, and a required nested 'operacao' object with no parameter documentation, the description is not complete enough for correct invocation. It provides selection context but not the structural contract needed to call the tool.

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?

The schema gives 0% description coverage and the only parameter, 'operacao', is an open object (additionalProperties: true). The description's 'operação com mercadorias' hints at the parameter's domain but does not say what fields the operation object must contain, so an agent has too little information to build a correct request.

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 names a specific resource — the CBS/IBS tax base for goods operations — and gives the intended use ('conferir a montagem da base antes do cálculo do tributo'). It is not a tautology and leaves little doubt about the domain, though it does not explicitly contrast with rtc_nfse_base_calculo or rtc_calcular_tributos.

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?

It explicitly positions the tool as a pre-calculation check ('antes do cálculo do tributo'), which tells an agent when it is relevant. It does not give exclusions or name an alternative, so it stops short of a 5.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does this well by identifying the observability endpoint and the fact that it returns a step-by-step apuração. It does not disclose rate limits, idempotency, or explicit read-only status, but the observability framing and output description provide meaningful behavioral context.

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?

The description is two sentences with no filler. The main behavior is stated first, followed by clear usage guidance, making it easy to scan and act on.

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?

The tool is complex enough with six parameters and no output schema, yet the description explains purpose and use cases but not how to fill the parameters or interpret the response. An agent would struggle to invoke it correctly without additional information.

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% and the description provides no parameter details. The six parameters, including required itens and municipio, are left unexplained, and the phrase 'same calculation' does not compensate for the lack of parameter semantics.

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 clearly states it performs the same calculation as rtc_calcular_tributos but through the RFB observability endpoint, returning the step-by-step calculation audit. This distinguishes it from its sibling and names the specific resource and behavior.

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?

It explicitly says when to use the tool: 'Use quando o número precisar ser defendido' with concrete examples such as internal review, client disagreement, and tax authority inquiries. It also implies the alternative rtc_calcular_tributos for non-audit calculations.

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

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

With no annotations, the description carries the full behavioral burden. It clarifies the read-style computational nature and describes the response shape per tax (valor, alíquota, memoriaCalculo, legal framework). However, it does not disclose potential errors, external dependencies, rate limits, or side effects beyond the implied calculation.

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?

The description is well structured and front-loaded with the main purpose, followed by a useful parameter list. It is appropriately sized for a tool whose schema provides no descriptions, and it avoids fluff.

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?

For a 7-parameter tool with no output schema and no annotations, the description covers the required inputs and return shape, but it does not explain all optional parameters or how to choose this tool over related calculators. This leaves meaningful gaps for an agent deciding how to invoke it correctly in varied scenarios.

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?

The schema has 0% description coverage, so the description must compensate. It documents the core parameters itens, municipio, and data_hora_fato_gerador with types and examples, but omits uf, versao_roc, identifcador, and compra_governamental, leaving part of the parameter surface undocumented.

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 states a specific action and resource: it calculates CBS, IBS, and Imposto Seletivo for an operation, item by item. This distinguishes it from validation/status siblings, though it does not explicitly contrast it with rtc_calcular_com_trilha.

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?

No guidance is given about when to use this tool versus the many siblings, and no alternatives or exclusion criteria are mentioned. The description gives invocation details, but an agent must infer when this is the right calculator among the sibling set.

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

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

With no annotations, the description carries the burden. It usefully discloses a behavioral constraint—the path must be relative to the base and start with /calculadora—and points to the OpenAPI spec for further discovery. It does not describe the response shape, error behavior, or the possibility of side effects for non-GET endpoints, so transparency is partial.

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?

Two compact sentences and a short example list; every clause serves a purpose and the key routing rule is front-loaded. No filler.

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?

As a fallback for an arbitrary endpoint, it gives the essential base-relative path rule and delegates full route discovery to {base}/api-docs. It still leaves the agent to infer response/error behavior and how optional method/body/query params map onto the request, and there is no annotation or output schema to fill that gap.

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?

The description adds real meaning to the required caminho parameter: relative to base, must start with /calculadora, with examples. However, none of the optional parameters (metodo, params, corpo) are explained in prose; only their schema names/defaults carry the meaning.

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 precise, actionable statement: it calls any official calculator API endpoint that lacks a dedicated tool, and gives three concrete route examples. This makes its purpose immediately distinguishable from the sibling tools.

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?

It explicitly says to use this tool when no dedicated tool exists, which is a clear selection rule against the sibling set. It also tells the agent where the complete endpoint list can be found, so the decision can be resolved at the point of use.

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

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

With no annotations, the description carries the full burden, and it does disclose the main behaviors: unfiltered table, CST filtering, and document-specific classification lookup. It also warns that this is the highest operational-risk table in the transition. It does not explain the role of data or tributo or describe the return shape, but the core behavior is transparent.

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?

The description is short, front-loaded with the resource and general behavior, then organized by increasing filter specificity. The final risk sentence adds useful context without 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?

For a tool with five optional parameters and no output schema, the description covers the common lookup paths and signals operational risk. However, it does not explain the data parameter, the tributo parameter's effect, or what fields the returned classifications contain. An agent could call it correctly in simple cases but would lack guidance for the full parameter space.

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. It adds meaning for cst and for the sigla_dfe + c_class_trib pair, but leaves data and tributo essentially unexplained beyond tributo's default value in the schema. That is partial, not complete, parameter coverage.

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 identifies the exact resource ('Tabela oficial de cClassTrib/Classificação Tributária'), uses a concrete verb ('devolve'), and explains three distinct query modes. The final line ('É a tabela que decide alíquota, redução e crédito') differentiates it from sibling tax-reference tools.

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?

The description clearly states when to use each parameter combination: no cst returns the whole table, cst filters by CST, and sigla_dfe + c_class_trib returns a specific classification. It also gives context for why this tool matters (it drives rate, reduction, and credit). It does not name explicit alternatives or exclusions, so it stops short of a 5.

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

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 indicates a non-destructive translation behavior, but does not disclose what happens with invalid or unknown codes, nor the exact return format. This is a notable gap for a tool with no structured annotations.

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?

The description is a single, front-loaded sentence with no filler. Every word contributes to explaining the tool's purpose and core input/output.

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?

For a simple one-parameter translation tool with no output schema, the description conveys the essential input and output concepts. It lacks explicit alternative guidance and invalid-input behavior, but the complexity is low enough that the description is largely sufficient.

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?

The schema has 0% description coverage and only a bare parameter name ('codigo'). The description compensates by clarifying the parameter is an error code returned by the calculator, giving meaningful context beyond the schema. It stops short of specifying exact formats or examples.

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 uses a specific verb ('Traduz') and a clear resource ('código de erro devolvido pela calculadora') with a defined output ('descrição legível'). This clearly distinguishes it from sibling tools like validation or tax-calculation functions.

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?

The description implies usage when the calculator returns an error code, but it does not explicitly state when to use this tool versus siblings or mention any exclusions. The context is enough to infer the basic trigger, but not fully explicit.

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

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

Annotations are absent, so the description carries the full burden of behavioral disclosure, yet it reveals almost no behavior: no statement of what input triggers what action, no indication of side effects (it is likely a read but that is never stated), no error behavior, and no return format. The value proposition ('what makes a number defensible') does not compensate for missing operational facts.

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?

Two sentences, front-loaded with the core substance (the LC 214 legal basis) before the rhetorical closer. The second sentence adds tone rather than facts, but the definition stays short enough that this is a minor deduction rather than a serious bloat problem.

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?

For a tool with a single optional parameter and no output schema, the complexity bar is low, and the description does communicate the tool's domain purpose well. However, both operational unknowns — what to pass in `data` and what the response contains — are left unresolved, making the definition minimally viable but not reliably callable without further inference.

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?

With 0% schema coverage, the description is the sole source of parameter documentation, but it never explains `data`. The phrase 'um número' hints that a classification code is expected, yet the description does not state the format, the accepted values, or the fact that the parameter is optional with a null default. This leaves the agent guessing at invocation time.

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 names a concrete deliverable — the legal basis (fundamentação legal) for tax classifications, tied to a specific statute (LC 214) — which distinguishes it from siblings that list classifications, compute rates, or validate codes. It falls short of a fully crisp verb+resource statement like 'returns the LC 214 provision supporting a given classification', and the closing metaphor 'transforma um número em posição defensável' is evocative rather than exact.

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?

No guidance on when to use this tool versus its 16 siblings. The description never states a selection condition such as 'use this when you need the legal citation behind a classification,' nor names any alternative to avoid. The use case must be inferred entirely from the purpose wording.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure and only minimally meets it. The mention of a POST endpoint hints at a server-side action, but the description does not disclose side effects, prerequisites (e.g., whether tributos must be calculated first), quotas/costs, or failure behavior. This is a thin disclosure for a tool with zero annotation coverage.

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?

The description is a single front-loaded sentence that opens with the verb, names the deliverable, and appends the endpoint in parentheses. Every element earns its place and there is zero wasted wording.

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?

For a tool with one undocumented free-form object parameter (0% schema coverage), no annotations, and no output schema, the description leaves critical unknowns: what the operacao object must contain, what the generated XML looks like, and what error conditions exist. An agent cannot reliably construct a valid call from this definition alone.

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%, and the sole parameter 'operacao' is a free-form object (additionalProperties: true) with no field documentation. The phrase 'a partir da operação' essentially restates the parameter name and adds no meaning about the object's expected structure, required sub-fields, or examples. With such a large schema gap, the description needed to compensate and failed to do so.

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 states a specific verb and deliverable: 'Gera o XML de um documento fiscal' (generates the XML of a fiscal document), plus the input source ('a partir da operação') and the underlying endpoint (POST /calculadora/xml/generate). The generate-vs-validate contrast with the sibling rtc_validar_xml_dfe is immediately apparent, so the tool is distinguishable without opening schemas.

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?

Usage context is only implied through the clear purpose — an agent can infer it is called when a fiscal-document XML must be produced from an operation. However, no when-to-use / when-not-to-use guidance is given, and no alternative tools (validation, calculation, error description) are named. There are no explicit exclusions or selection conditions.

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

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

No annotations are present, so the description carries the disclosure burden. It usefully warns that IS rates depend on ordinary law and remain undefined, which is important behavioral context. It does not disclose authentication, side effects, or response/error behavior, but the rate-status caveat is meaningful.

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?

Two short sentences: the first front-loads the purpose and endpoint, the second adds the critical legal limitation. There is no filler or redundant information.

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?

The tool has a nested required parameter with no schema descriptions, no output schema, and no annotations, so the description must compensate by explaining request construction and expected behavior. It does not, leaving the agent with only purpose, endpoint, and the rate-undefined caveat.

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?

The only required parameter, 'operacao', is an opaque object with additionalProperties: true and zero schema description coverage. The description does not explain what fields the operation object should contain, what operation types are valid, or how goods values should be represented. An agent cannot construct a correct payload from this definition.

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 clearly identifies the resource: base de cálculo do Imposto Seletivo em mercadorias, and provides the exact endpoint. This distinguishes it from sibling tools like rtc_base_calculo_mercadorias and rtc_nfse_base_calculo, though it lacks an explicit verb such as 'calcula' or 'retorna'.

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?

Usage is implied by the domain: this tool is for calculating the IS basis on goods. However, the description never names alternative tools or explicitly says when not to use it; the reminder about undefined rates is a legal caveat, not a usage guideline.

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

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

Não há anotações, então a descrição assume o peso. Ela informa o endpoint e um datá de contexo regulatório, mas não dize se há efeitos colaterais, se exige autenticação, como lida com entradas inválidas ou qual é o formado do resultado. A informação sobre a obrigatoriedade é útil, mas não é comporameno da ferramenta.

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?

A descrição é curta, com o propósito e o endpoint na primeira frase. A segunda frase acrescena contexo regulatório relevante sem redundância. Nada é desnecessário, embora pudesse ser expandido.

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?

Considerando a complexidade do parâmetro aninhado opaco e a ausência de esquea de saída e anotações, a descrição não é suficiente para que um agente invoque a ferramenta corretamente: não explica campos obrigatórios dentro de 'operacao', nem o retorno, nem as condições de aplicação. Fornece algum contexo, mas não o suficiente.

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?

O únic parâmetro, 'operacao', é um objeo sem restrições (adioalProperties true) e com 0% de cobertura no esquea. A descrição não menciona 'operacao' nem explica quais campos devem ser enviados, deixando o agente sem qualque orientação para construir o payload.

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?

A descrição identifica o recurso (NFS-e), a operacao (base de cálculo) e o endpoint exato (POST /calculadora/nfse/base-calculo). A menção a 'Serviços' e ao endpoint dítingue implicitamente de ferramentas como rtc_base_calculo_mercadorias, embora não use um verbo explícito como 'calcula'.

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?

A nota sobre a 2ª onda de obrigatoriedade de IBS/CBS para serviços em 01/10/2026 sinaliza quando o uso é relevante, mas não afirma explicitamene quando usar esta ferramenta em vez de rtc_base_calculo_mercadorias ou rtc_calcular_tributos, nem cita alternativas.

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

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

No annotations are present, so the description must carry the full burden of behavioral disclosure. It states only that the table is 'official' and valid as of a date, and hints at the tributo parameter. It does not disclose whether the operation is read-only, what the response looks like, how errors are surfaced, or how date/tributo affect the actual result.

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?

The description is short and front-loads the core purpose. Both sentences serve useful purposes: the first defines the resource and date scope, and the second clarifies the tributo values. It is appropriately compact, though the parameter line reads more like a schema note than a full usage explanation.

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?

For a tool with no output schema, no annotations, and 0% schema coverage, this description is incomplete. It does not describe what the returned table contains, the expected date format, the effect of choosing each tributo value, or error behavior. The core idea is clear, but an agent would lack enough context to confidently interpret or validate the result.

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. It does add meaning to the 'tributo' parameter by listing the allowed values 'cbs-ibs' or 'imposto-seletivo', which is absent from the schema. The 'data' parameter semantics are only weakly implied by 'vigente na data', and its format and null behavior are not clarified.

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 clearly identifies the resource as the official CST (Código de Situação Tributária) table and adds a date-scope qualifier ('vigente na data'). It is not a mere restatement of the tool name, but it lacks an explicit action verb such as 'consulta' or 'retorna', and it does not differentiate from sibling rtc_classificacoes_tributarias.

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?

There is no guidance about when to use this tool versus alternatives such as rtc_classificacoes_tributarias, rtc_calcular_tributos, or rtc_imposto_seletivo. The description implies the tool provides CST data, but it never states use cases, prerequisites, or when-not-to-use conditions.

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

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

With no annotations, the description carries the behavioral disclosure burden. It conveys a read-only status operation rather than a mutation, and it surfaces a key behavioral dependency: the database version is part of the result trail, so the tool must be called before delivery. It does not mention auth or rate limits, but those are minor for a zero-parameter status check.

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?

Two short sentences: the first states what the tool reports, the second gives the invocation rule and rationale. Every word earns its place and the main idea is front-loaded.

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?

For a zero-parameter status tool with no output schema, the description tells an agent exactly what information it will receive (calculator, mode, app and DB versions) and when to call it. Nothing required to invoke it correctly is missing.

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?

There are zero parameters and schema coverage is 100%, so the baseline is 4. The description correctly adds no parameter details because none exist or are needed.

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 names a specific resource (server status) and the concrete information it exposes: which calculator is active, local vs public mode, and application/RFB database versions. This clearly distinguishes it from the sibling calculation/validation tools, none of which are status or metadata tools.

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?

It gives an explicit trigger: call before any delivery ('Chame antes de qualquer entrega') and explains why — the database version is part of the result trail. For a parameterless status tool with no relevant alternatives among siblings, this is sufficient guidance.

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

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. 'Lista' suggests a read-only operation, and the 'acao' value hints at some behavioral variation, but the description does not explain what 'validate' versus 'generate' changes, what the output looks like, or any side effects or restrictions.

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?

The description is extremely concise and front-loads the primary purpose before introducing the parameter. Every phrase earns its place, and there is no redundant or filler content.

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?

This is a very simple tool, but the central 'acao' parameter is left ambiguous and no output schema exists to clarify return values. The description says the tool 'Lista' types, but it never explains what the returned list represents for each action, making it incomplete for an agent that needs to invoke it correctly.

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?

The schema provides only a default value and no descriptions, so the 'acao: validate ou generate' text adds meaningful allowed-value information absent from the schema. However, it does not clarify how each action value affects the returned list, leaving the parameter semantics only partially explained.

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 uses a specific verb 'Lista' and a clear resource, 'os tipos de documento fiscal aceitos', so the core purpose is understandable. It does not explicitly distinguish itself from sibling tools, but the name and phrase are specific enough to avoid obvious confusion.

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?

The description implies the tool should be used when the agent needs to know which fiscal document types are accepted, but it gives no explicit guidance on when to prefer this tool over siblings such as rtc_validar_xml_dfe or rtc_gerar_xml_dfe. There are no exclusions or alternative-routing cues.

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

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

With no annotations, the description must carry behavioral disclosure. 'Valida se...' signals a validation/read operation but does not state whether it returns a boolean, what happens when 'data' is null, or any error conditions. It adds only the date-of-event context and no side-effect or return-behavior details.

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?

A single, front-loaded sentence that contains the subject, action, and key temporal condition with no filler. Every phrase earns its place.

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 the low tool complexity and schema listing all parameters, the description conveys the core purpose. But with no annotations and no output schema, it omits the return value, null-data behavior, and any caveats about what 'aplicável' means, leaving some inference to the agent.

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 clarify parameters. It glosses NBS as 'serviço' and links 'data' to the date of the taxable event, giving c_class_trib its role implicitly. However, it does not specify formats, allowed values, or the meaning of the nullable/default data parameter beyond that.

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 uses a specific verb ('Valida') with a clear resource (NBS/service) and target (cClassTrib) plus a temporal qualifier (date of taxable event). It is immediately distinguishable from sibling rtc_validar_ncm because it names NBS, not NCM, and adds the cClassTrib applicability angle.

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?

The intended use is implied by mentioning NBS (service) vs the sibling rtc_validar_ncm, but no explicit when-to-use or when-not-to-use guidance is given. It does not name alternatives or exclusion conditions like 'use rtc_validar_ncm for goods.'

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

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

With no annotations, the description carries the full burden. It discloses that this is a validation, that it is date-sensitive, and that incompatible NCM contaminates the chain. However, it does not describe return values, errors, or whether it mutates anything.

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?

Two concise sentences with no filler. The first states the core validation, and the second gives practical usage guidance. Front-loaded and easy to parse.

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?

The description covers purpose, parameters, and when to use. However, there is no output schema and no annotation, so the lack of return/error behavior disclosure is a notable gap; an agent cannot predict what 'valida' yields in invalid cases.

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. It does so by explaining the relationship between NCM and cClassTrib and interpreting 'data' as 'data do fato gerador', giving domain meaning beyond the raw schema. It lacks format constraints but covers all three parameters meaningfully.

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 uses a specific verb 'Valida' and clearly states the resource relationship: NCM aplicável a um cClassTrib na data do fato gerador. This distinguishes it from sibling rtc_validar_nbs, since it explicitly targets NCM rather than NBS.

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?

The description explicitly instructs 'Use antes de emitir', giving a clear when-to-use context and the consequence of not validating. It does not name alternatives or when-not-to-use condition, so it falls just short of a 5.

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

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

No annotations are present, so the description carries the behavioral burden. It discloses that this is a rule-based validation to auditar IBS/CBS preenchimento, which implies a non-mutating audit. It does not state whether invalid XML produces errors, what the return format is, or whether there are side effects, leaving clear gaps.

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?

Two sentences, front-loaded with the primary action and followed by a concrete use case. Every sentence earns its place; there is no filler, repetition, or unnecessary detail.

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?

With no annotations and no output schema, the description leaves important gaps: it does not define the return value or error behavior, and it leaves 'tipo_dfe' undocumented. It gives a solid high-level purpose but is not complete enough for an agent to reliably call it correctly without additional assumptions.

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. It tells the agent that XML refers to an electronic fiscal document, which helps understand the 'xml' parameter conceptually. But it does not explain the expected format of the xml string or the meaning and accepted values of the optional 'tipo_dfe' parameter.

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 uses a specific verb ('Valida') and a specific resource ('XML de um documento fiscal eletrônico'), and scopes the action to 'regras da calculadora'. It clearly conveys the core purpose, but it does not explicitly differentiate itself from sibling validation tools like rtc_validar_ncm or rtc_validar_nbs.

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?

The second sentence gives an explicit intended use: auditar preenchimento de IBS/CBS antes que o erro vire base da apuração assistida. This provides clear context for when to invoke the tool. However, it does not mention exclusions or alternative tools, so the when-not guidance is absent.

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