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

With no annotations, the description carries the behavioral disclosure burden. It makes clear this is a construction/computation utility rather than a submit/sign tool, and it explicitly discloses the cnf generation behavior and output structure. A brief statement that it has no external side effects would make it stronger, but 'Assemble' and 'Returns a dict' imply a pure in-memory operation.

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 focused sentences: the first front-loads the core purpose, the second gives the return contract. There is no filler or redundant restating of the tool name.

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 input schema fully documents all required and optional parameters, the description explains the output and the optional-generation behavior, and the output schema is present. For a self-contained key-building utility, nothing necessary for correct invocation 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?

The input schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds little beyond the schema: the only parameter-specific detail is cnf, and that is already described in the schema as 'Gerado se omitido'.

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 ('Assemble and check-digit') on a precise resource (the 44-character NF-e/NFC-e access key/chNFe) and names the exact return fields. This clearly distinguishes it from sibling validation, generation, and submission 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 intended usage is implied: use this when an NF-e/NFC-e access key needs to be assembled, likely before document generation or signing. However, it does not explicitly state when to prefer this over generate_nfe, nor does it mention any prerequisites or exclusions.

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á annotations, então a descrição assume todo o peso da transparência. Ela revela que a operação constrói, assina e submete o evento, é irreversível, exige ConfirmationGate, pode ser desabilitada com BR_CTE_READ_ONLY=1 e exige endpoint_override obrigatório. Isso é muito além do mínimo.

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 é densa e bem estruturada: propósito primeiro, depois fluxo de assinatura/submissão, depois avisos críticos e retorno. Cada frase contribui com informação operacional relevante, sem enrolação ou repetição do schema.

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?

Para uma ferramenta complexa com 11 parâmetros, nenhuma annotation e output schema presente, a descrição cobre os aspectos críticos: irreversibilidade, confirmação em duas etapas, obrigatoriedade de endpoint, retorno esperado e referência normativa. O output schema cuida da estrutura de retorno, então nada essencial está faltando.

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 schema já cobre 100% dos parâmetros, então a baseline é 3. A descrição adiciona valor ao explicar que endpoint_override é obrigatório porque nenhuma URL está embutida, e que confirmation_token vem de uma chamada pendente anterior. Também contextualiza cStat=135 como cancelamento homologado.

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 afirma claramente o propósito: solicitar o cancelamento de um CT-e autorizado, especificando o evento (110111) e o serviço (CTeRecepcaoEventoV4). Isso diferencia a ferramenta dos irmãos como submit_cte, consult_cte e correct_cte, deixando evidente que é exclusivamente para cancelamento.

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 descrição deixa claro que a ferramenta deve ser usada para cancelar CT-e autorizados e que a operação é irreversível em produção, exigindo confirmação em duas etapas. Não menciona explicitamente alternativas, como correct_cte para ajustes, mas o contexto de uso é suficientemente claro.

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 provided, the description carries the full burden of behavioral disclosure. It explicitly warns that cancellation is irreversible, requires two-step confirmation, can be disabled via BR_READ_ONLY=1, and even flags that the endpoint and request format are unverified. This is unusually transparent for a destructive operation.

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 compact: three sentences, with the core operation first and the most critical warnings immediately after. The unverified note is valuable and does not waste space. Minor ambiguity in the BR_READ_ONLY phrasing ('desabilitar' could refer to disabling confirmation or disabling the operation) prevents a 5.

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 destructive operation with no annotations, the description covers the essential risks and workflow constraints. The output schema is present, so return-value documentation is not required. It could more explicitly describe the full two-step flow (first call returns a token, second call uses it), but the schema's confirmation_token description partially fills this 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?

Schema description coverage is 100%, so the input schema already documents all parameters, including ch_nfse, motivo, tp_amb, and confirmation_token. The description adds high-level context about the two-step confirmation but does not add detail beyond what the schema provides. Baseline 3 is appropriate.

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 resource: 'Solicitar cancelamento de uma NFS-e no ADN.' This clearly distinguishes the tool from the sibling cancel tool for CT-e (br__cancel_cte) and from NF-e operation tools. The title reinforces but does not replace the description.

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 gives no explicit guidance about when to choose this tool over alternatives, though the resource 'NFS-e' makes the context largely self-evident. It mentions the ConfirmationGate and BR_READ_ONLY setting but does not explain under what conditions an agent should invoke this tool or when it should not.

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, and it delivers: it declares read-only behavior ('Read-only — não requer confirmação'), scopes the operation to a single pre-known document, discloses that no endpoint URL is embedded in this version and that endpoint_override is therefore required, and states the return contract (cStat/xMotivo/protCTe or error). It omits certificate/auth side effects, but the cert parameters are schema-documented and this is a non-mutating consult, so the disclosure is solidly above the minimum viable bar.

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?

Three short paragraphs, front-loaded with the core purpose, then scope/disambiguation and the return contract. Every sentence carries distinct information; the br__distribute_dfe aside earns its place as disambiguation rather than filler. No redundancy with the title or schema.

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?

An output schema exists, so return values are structurally covered, and all six parameters are fully documented in the input schema. The description adds the operation type, the mandatory endpoint override, and read-only semantics. The main gap is that it does not differentiate from the similar-looking sibling br__consult_cte_sefaz_status; aside from that, this is nearly complete for a read-only consult tool whose schema and output schema carry much of the load.

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 100%, so the baseline is 3. The description adds only light framing — that ch_cte identifies the document and that endpoint_override is necessary because no URL is embedded — which slightly enriches the schema's 'obrigatório, ver docstring do módulo' note, but it does not add meaningful format or behavioral detail beyond what the schema already states for each 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 first sentence states a specific verb and resource — 'Consulta a situação de um CT-e por chave de acesso (CTeConsultaV4)' — and names the exact protocol operation. It also distinguishes itself from a sibling ('diferente de br__distribute_dfe no NF-e') and clarifies scope: a single, already-known CT-e, not a batch. An agent can tell exactly what this does 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.

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

The description explicitly names br__distribute_dfe as the alternative and states the selecting condition — this tool queries one specific CT-e known by access key, not a batch of third-party fiscal data. It also flags that endpoint_override is mandatory. However, it never offsets the closer sibling br__consult_cte_sefaz_status, which an agent could plausibly confuse with this CT-e consultation tool.

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 behavioral burden. It explicitly states that the operation is read-only, requires no confirmation, has no embedded/verified endpoint URL, mandates `endpoint_override`, and discloses the return semantics (`cStat`/`xMotivo`) including the `cStat=107` meaning and its `[Unverified]` status. This is far beyond the minimum needed.

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 compact and well-structured: purpose in the first sentence, key behavioral caveat in the second, and return-value interpretation in the third. Every sentence earns its place with no filler or redundant phrases.

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?

Despite having no annotations and five parameters, the description plus a fully documented schema and an output schema provide what an agent needs to invoke the tool correctly. It covers safety, mandatory override, return semantics, and the unverified nature of the endpoint, leaving no critical context 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?

Schema description coverage is 100%, so the input schema already documents all parameters. The description mostly repeats what the schema says about `endpoint_override` being mandatory, adding no significant new parameter-level meaning. Baseline 3 is appropriate when the schema handles the parameter documentation.

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 and resource: 'Consulta a disponibilidade do webservice SEFAZ CT-e' and names the exact operation (`CTeStatusServicoV4`). This clearly distinguishes it from sibling tools like `br__consult_sefaz_status` (NF-e status) and `br__consult_cte` (CT-e document lookup).

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 makes the usage context clear: use this to check CT-e SEFAZ webservice availability, it is read-only with no confirmation required, and `endpoint_override` is mandatory because no endpoint URL is embedded. It stops short of explicitly naming when not to use it or comparing it to sibling alternatives, but the context is strong enough for an agent to select it correctly.

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 disclosure burden, and it does so well: it explicitly declares 'Read-only, não requer confirmação' and flags that the endpoint and response format are '[Unverified — endpoint e formato de resposta são inferidos.]'. This is honest, helpful transparency about side effects and reliability.

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: two short sentences convey purpose, safety characteristics, and an uncertainty warning with no filler. Every piece of text earns its place, and the most decision-relevant information 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?

An output schema exists and all parameters are documented, so the description does not need to explain return values or parameter semantics. The read-only and unverified-endpoint caveats make the description effectively complete for invocation. It could be improved by adding usage context to distinguish it from analogous consult tools, but that gap does not block correct use.

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 100%, so the structured schema already documents all six parameters. The description's mention of 'chave de acesso (chNFSe)' does not add meaning beyond the schema's existing description of ch_nfse, so the baseline 3 applies.

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 ('Consultar') and resource ('status de uma NFS-e') and identifies the lookup key (chNFSe). It is clear about what the tool does, but it does not explicitly differentiate it from sibling tools such as br__consult_sefaz_status or br__consult_cte, so it does not quite reach a 5.

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 gives no guidance on when to use this tool versus alternatives, nor does it mention when not to use it. The read-only and unverified-endpoint notes are behavioral, not usage guidance, so the agent is left to infer the proper selection context.

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 full behavioral disclosure. It explicitly states 'Read-only — não requer confirmação' and describes the result shape (`cStat`/`xMotivo`) plus the success condition (`cStat=107`), with an `[Unverified]` caveat. This gives an agent clear expectations about safety and output meaning.

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?

Three short sentences with no filler. The purpose is first, the read-only behavior follows, and the output interpretation is stated last; 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?

For a read-only status-check tool, the description is complete: purpose, safety profile, output format, and a success interpretation are all present. The schema covers parameters and an output schema exists, so no critical operational detail 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?

The input schema has 100% description coverage, so it already documents all five parameters. The description adds no parameter-specific detail beyond the schema, which meets the baseline but does not exceed it.

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 ('Consulta') and a concrete resource ('webservice SEFAZ (`NFeStatusServico4`)'), which identifies exactly what the tool checks. It differentiates from sibling status tools by naming the NFe service, unlike br__consult_nfse_status or br__consult_cte_sefaz_status.

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 provides clear context: use this when you need to check NFe SEFAZ webservice availability, and it is read-only so no confirmation is needed. It does not explicitly name alternatives or state when not to use it, but the NFeStatusServico4 reference makes the intended scope unambiguous.

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 provided, the description carries the full burden of behavioral disclosure. It covers the signing workflow (`build_cte_event_signer`, target `infEvento`), the expected result code (`cStat=135`), the legal restrictions on what can be altered, the confirmation gate requiring a token, and the return shape (`cStat`/`xMotivo` or `error`). The mention of `ConfirmationGate` and the requirement for `endpoint_override` are concrete behavioral traits. A small gap is that it doesn't explicitly state that the operation is a write/mutation, though constructing and submitting an event implies this strongly.

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 moderately sized and packs substantial information into a few sentences: the event type, the signing flow, the success code, legal constraints, and the confirmation requirement. It is well-structured with the core purpose first, followed by behavioral details and constraints. It could be slightly tighter—the legal citation and verification note add context but are somewhat verbose for a tool description.

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 tool's 10 parameters, a required endpoint override, a confirmation gate, and no annotations, the description covers the critical operational details: what the tool does, how it signs, the expected success code, what it can and cannot correct, and the return format. The reference to a module docstring for `endpoint_override` is a minor gap, as an agent invoking this via MCP may not have access to that docstring. The presence of an output schema also alleviates the need to describe return values in detail.

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 100%, so the schema already documents all 10 parameters meaningfully. The description adds context for `endpoint_override` (required, see module docstring) and `confirmation_token` (obtained from a prior pending call), but it doesn't add detail for most parameters beyond what the schema already provides. This is a baseline-3 case where the schema does the heavy lifting and the description adds marginal value.

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 verb and object: 'Emite uma Carta de Correção Eletrônica para um CT-e', identifying the specific event type (`110110`) and webservice operation (`CTeRecepcaoEventoV4`). It clearly distinguishes this from the sibling tools like `br__generate_cte`, `br__submit_cte`, and `br__cancel_cte`, which handle different CT-e operations.

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 explains when this tool is used (to emit a CC-e correction event) and includes important legal/regulatory context (Art. 58-B do CONVÊNIO/SINIEF 06/89) that constrains what can be corrected. It also mentions that `endpoint_override` is required and that a two-step confirmation gate applies, with the `BR_CTE_READ_ONLY=1` escape hatch. While it doesn't explicitly name sibling alternatives, its scoping to the CC-e event and the regulatory constraints make the usage context 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 carries the behavioral transparency burden. It discloses that the tool consults third-party fiscal data linked to the certificate, requires two-step confirmation, and mentions BR_READ_ONLY=1. However, the effect of BR_READ_ONLY is ambiguous, and it does not clarify whether the 'distribui' operation has side effects such as advancing the NSU or mutating server state.

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 compact and front-loaded with the main purpose and specification version. Each sentence adds meaningful information: mode selection and safety/behavior notes. The final BR_READ_ONLY sentence is somewhat cryptic, which prevents a perfect score for clarity.

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 an 11-parameter tool with an output schema and no annotations, the description covers the core operation, the mutually exclusive parameter selection, third-party data scope, and the two-step confirmation requirement. It could more fully explain the two-step flow mechanics and potential side effects of distribution, but the schema fills most remaining parameter details.

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 parameter coverage is 100%, so the baseline is 3. The description adds valuable relationship semantics beyond the schema by stating the mutual exclusivity of ult_nsu, nsu, and ch_nfe and mapping them to the corresponding service operations. This is essential for correct invocation and goes beyond individual parameter descriptions.

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: 'Consulta/distribui DF-e via NFeDistribuicaoDFe', and includes the protocol version. It further explains the three operation modes (distNSU, consNSU, consChNFe), which clearly distinguishes this tool from the NFe/NFSe/CTe siblings.

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 gives explicit usage conditions: exactly one of ult_nsu, nsu, or ch_nfe must be provided, and each maps to a different operation mode. It does not explicitly name alternatives or say when not to use this tool, but the DF-e distribution scope makes the intended context reasonably 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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It fully meets that burden by stating that the output is unsigned, that unsupported modais/CSTs raise an error, that the return is a dict with xml, chave_acesso, and warnings, and that signing is required before SEFAZ submission.

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: the core purpose appears first, followed by critical constraints and workflow, and then the return value breakdown in a clear bulleted list. Every sentence adds useful information without redundancy.

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 complexity of generating a CT-e XML document and the absence of annotations, the description is complete enough for an agent to invoke it correctly. It covers scope, version, supported modes, error behavior, the need for signing, the next step in the workflow, and the shape of the return value, while an output schema is also present for additional detail.

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 describes the single `cte` parameter as 'CT-e data matching the BRCTeDocument schema (modelo 57),' so schema coverage is high. The description adds meaningful semantic constraints beyond the schema by explicitly limiting v1 support to modal rodoviário and ICMS CST 00, telling the agent which values will cause an error.

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 and resource: 'Generate an unsigned CT-e XML (modelo 57, schema 4.00).' It clearly distinguishes this tool from siblings like br__validate_cte_xml, br__submit_cte, and br__cancel_cte by focusing on generation and explicitly noting that the output is unsigned.

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 provides clear usage context: it is for generating CT-e XML in v1, supports only modal rodoviário and ICMS CST 00, and other inputs raise an error. It also tells the agent to sign the document with br__sign_cte before SEFAZ submission. However, it does not explicitly compare this tool to a generation alternative or state when to prefer a sibling generation tool.

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 provided, the description carries the full burden. It transparently discloses that the output lacks a Signature, that the XML is unsigned, and that submission is not handled. It also documents the return dict shape, though it could go slightly further in describing behavior on invalid invoice input.

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 with a lead sentence, a clear note about signing, and a concise bulleted return-value list. Every sentence contributes necessary information and there is 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 complex generation tool with nested invoice data and many document-type siblings, the description fully covers what it does, what it returns, what it does not do, and what to call next. An agent has enough context 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?

Schema description coverage is 100% for the single invoice parameter, and the schema already states it matches the BRInvoice schema and maps modelo 55 to NF-e and 65 to NFC-e. The description reinforces modelo 55/65 and schema 4.00 but adds little beyond the input schema's existing 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 starts with a specific verb and resource: 'Generate an unsigned NF-e/NFC-e XML (modelo 55/65, schema 4.00).' It clearly distinguishes this from sibling tools by noting that signing and SEFAZ submission are separate concerns, with submission explicitly out of scope.

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 tells the agent to sign the result with br__sign_nfe before SEFAZ submission and explicitly states that SEFAZ webservice submission is not implemented. This routes the agent to the correct next tool and prevents misuse of this generation-only tool.

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 discloses the output is an unsigned DPS (no <ds:Signature>), the schema version, and the return dict fields (xml, dps_id, warnings). This is sufficient for a pure-generation tool; no destructive side effects are implied.

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?

Three short sentences in a clear order: what it generates, what to do next, and what it returns. No redundant filler or restatement of the title.

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 single-parameter, nested-object generation tool with an output schema, the description covers purpose, workflow, non-signature behavior, and return values. It also references the exact document schema (NFSeDocument, ADN, v1.01) so an agent can construct valid input.

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?

Input schema coverage is 100%, so the schema already documents the only parameter ('DPS data matching the NFSeDocument schema'). The tool description adds no additional parameter-level meaning beyond schema v1.01, but it doesn't need to because the schema and referenced NFSeDocument schema cover it. Baseline 3 applies.

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 action and artifact: 'Gerar um DPS não assinado para NFS-e Nacional (ADN), schema v1.01'. It explicitly distinguishes itself from siblings by noting the DPS is unsigned and requires br__sign_nfse/br__submit_nfse.

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 names the exact sibling tools and sequence: sign with br__sign_nfse before submitting via br__submit_nfse. This makes the intended usage context and boundary of the tool 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?

With no annotations, the description carries the behavioral burden. It discloses the signing algorithm/enveloped transform, the certificate support limitation, the fact that A3 is not modeled, and the return shape ('dict with xml or error'). This goes well beyond a minimal statement, though it leaves minor ambiguities such as requiring one of xml_base64/xml_content.

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 front-loaded with the core purpose and then supplies standard, certificate, and return-value details in compact sentences. The internal code reference and the placeholder-like '[NEED: not modeled]' keep it from being perfectly polished.

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 moderately specialized signing tool, the description covers purpose, standards, certificate constraints, and return format, and an output schema exists to document return fields. It would be complete if it explicitly stated that an unsigned XML must be supplied via xml_base64 or xml_content, though the schema already labels that choice.

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 100%, so the parameters are already documented in the input schema. The description adds context about the certificate type and return shape but does not need to compensate for missing parameter documentation.

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 action and resource: 'Apply an ICP-Brasil enveloped XML-DSig signature to an NF-e/NFC-e XML.' It further names the exact signed element and standard, which clearly distinguishes this NFe-signing tool from siblings like br__sign_nfse and br__validate_nfe_xml.

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 clear: it is for signing NF-e/NFC-e XML, and it explicitly excludes A3 hardware-token certificates, limiting use to A1 PKCS#12 files. It does not explicitly name alternative tools, but the document-type and certificate constraints provide enough context for selection.

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 provided, the description carries the full burden, and it does so thoroughly. It discloses the algorithm (RSA-SHA1), the signature structure (enveloped ds:Signature as last child of <DPS>), the underlying builder function, certificate limitations (A1 only, A3 not modeled), and the production-readiness caveat. It also states the return shape.

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: purpose first, then technical signing details, then algorithm/caveat, certificate limitations, and return format. Every sentence adds useful information, with no filler or redundancy.

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 is quite complete for a cryptographic signing tool: it covers mechanism, algorithm, certificate constraints, production caveat, and return value. The main gaps are the lack of explicit workflow guidance (when to sign relative to generate/submit) and no clarification about requiring exactly one of xml_content or xml_base64, especially since the schema marks both as optional/nullable.

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 100%, so the baseline is 3. The description adds little beyond the schema: it confirms A1 certificate support, but the schema already describes cert_path as an ICP-Brasil A1 (.p12/.pfx) file. It does not explain precedence between xml_content and xml_base64, or clarify that at least one of them is effectively 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 opens with a specific verb and resource: 'Aplicar assinatura XML-DSig ICP-Brasil ao DPS da NFS-e Nacional'. It further clarifies exactly what is signed (<infDPS>) and how the signature is placed (<DPS>), which unambiguously distinguishes it from siblings like br__sign_nfe or br__generate_nfse.

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 implied rather than explicit: an agent can infer this tool is used to sign a DPS before submission, and the schema mentions xml_content coming from br__generate_nfse. However, the description does not explicitly state when to use this tool versus alternatives, nor does it describe the workflow around generate_nfse/submit_nfse.

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 discloses GZip/Base64 handling, irreversibility in production, two-step confirmation via ConfirmationGate, the BR_CTE_READ_ONLY escape hatch, and the lack of an embedded endpoint URL. This is exactly the behavioral information an agent needs beyond the schema.

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?

Four dense sentences front-load the main purpose and then add only high-value warnings and return information. Every sentence earns its place; no filler or redundancy.

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 and 8 parameters, the description covers the critical context: synchronous operation, required endpoint override, irreversible/destructive nature, confirmation mechanism, and expected success/error outcome. The output schema handles return structure detail, so this description is complete for safe invocation.

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 100%, so the baseline is 3. The description adds some operational context, such as endpoint_override being mandatory and the payload being compressed before sending, but it does not substantially elaborate further on individual parameter meanings beyond the schema.

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?

States a specific verb and resource: 'Submete um CT-e assinado à autorização SEFAZ' and names the exact synchronous operation (CTeRecepcaoSincV4). This clearly distinguishes it from sibling tools like generate, validate, consult, cancel, and correct CT-e.

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?

Clear context: the tool is for submitting an already-signed CT-e to SEFAZ, and it explicitly says endpoint_override is required because no URL is embedded. It does not explicitly name alternatives or exclusions, but the structured workflow (sign then submit) is strongly implied.

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 provided, the description carries the full behavioral disclosure burden and does so well. It discloses that the operation is irreversible in production, requires two-step confirmation, is synchronous, and returns protNFe or an error. It even mentions how to disable the tool via BR_READ_ONLY=1.

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 compact and front-loaded: the core action appears first, followed by critical safety/confirmation facts, then the return value. Every sentence earns its place with no redundant 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?

The description covers purpose, synchronization, irreversibility, confirmation requirement, disable mechanism, and return value, which is strong for a 9-parameter tool with a rich output schema. It could be more explicit about the practical two-step confirmation flow, such as what the first call returns and how the confirmation_token is used, though the schema partially covers this.

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 100%, so the schema already documents all parameters thoroughly. The description adds context about the signed input and two-step confirmation but does not materially add meaning to individual parameters beyond what the schema provides.

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 resource: it submits a signed NF-e/NFC-e to SEFAZ authorization via NFeAutorizacao4 synchronously. This clearly distinguishes it from sibling tools like br__submit_nfse and br__submit_cte, which target different document types.

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 gives clear context: the input must be a signed NF-e/NFC-e and the operation is synchronous. It explicitly warns that submission is irreversible and requires two-step confirmation, which informs when the tool should be invoked, though it does not explicitly name alternative tools or list exclusion 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?

Sem annotations, a descrição assume todo o ônus e vai além: revela irreversibilidade em produção, necessidade de ConfirmationGate, como desabilitar a ferramenta via BR_READ_ONLY e um aviso claro de que o endpoint/formato são inferidos e não verificados. Isso dá ao agente informações críticas sobre riscos e efeitos colaterais.

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 é organizada em blocos pequenos e funcionais: ação principal, advertência operacional, aviso de não verificação e retorno esperado. Cada frase contribui com informação distinta, sem redundância, e os pontos de maior risco aparecem logo no início.

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?

Para uma ferramenta com 8 parâmetros, sem annotations e com risco de produção, a descrição cobre as lacunas comportamentais relevantes: irreversibilidade, confirmação, desabilitação e incerteza sobre o endpoint. O schema já documenta os parâmetros e a existência de output schema dispensa detalhar mais o retorno na descrição.

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 input schema cobre 100% dos 8 parâmetros, incluindo descrições detalhadas, defaults e a relação entre xml_content e br__sign_nfse. A descrição da ferramenta não adiciona nada além disso para os parâmetros; portanto, mantém-se o baseline 3 para cobertura completa do schema.

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 usa verbo específico ('Submeter'), recurso definido ('DPS assinado ao ADN') e finalidade clara ('geração da NFS-e Nacional'). Isso a diferencia imediatamente de irmãos como br__sign_nfse, br__generate_nfse e br__cancel_nfse, pois o foco é submissão ao ADN, não assinatura, geração ou cancelamento.

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 descrição comunica o pré-requisito (DPS assinado) e consequências importantes de uso (operação irreversível, confirmação em duas etapas). O schema complementa indicando que xml_content é saída de br__sign_nfse, mas a descrição não nomeia explicitamente alternativas nem traz um 'não use quando'.

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 burden. It discloses that both the numeric and alphanumeric CNPJ forms are accepted and cites the relevant standard and effective date, which is useful input-behavior information. It does not state whether validation is purely local or whether it checks registration status, but the check-digit wording implies structural validation.

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 tight sentences: purpose is front-loaded, and the technical format details are kept in the second sentence. There is no repetition of the schema or unnecessary 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 one-parameter validation tool with an output schema, this covers the essential input formats and the applicable standard. An explicit note that it validates format/check digits rather than registration status would make it fully complete, but nothing needed for basic invocation 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?

The input schema already describes the single 'cnpj' parameter at 100% coverage, so the baseline is 3. The description adds value beyond the schema by explaining the two accepted formats and the 12-alphanumeric + 2-check-digit structure, which helps the agent construct valid inputs.

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 and object: 'Validate a Brazilian CNPJ (company tax ID).' The follow-up sentence naming the legacy and alphanumeric forms makes the tool's scope concrete and distinguishes it from sibling validators such as br__validate_cpf and the XML document validators.

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 clear context for when to use the tool: whenever a Brazilian CNPJ string must be validated, and it identifies which input representations are acceptable. It does not explicitly name sibling alternatives or state when not to use it, so it falls 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 provided, the description carries the full burden, but it reveals only the high-level action. It does not disclose whether validation involves check digits, formatting, or both; whether invalid CPFs return false or throw; or whether any external lookup occurs.

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 with no filler; 'Brazilian' and 'individual taxpayer ID' usefully disambiguate CPF from CNPJ. Nothing could be removed without losing meaning.

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 one-input tool with an output schema, the description is minimally sufficient, but it omits usage guidance and behavioral semantics that would make it robust. It is adequate rather than complete.

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 100% and the cpf parameter is already documented as accepting or omitting '.' and '-' separators, so the description adds no extra parameter meaning. Baseline 3 applies because the schema does the heavy lifting.

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 ('Validate') and a clear resource ('Brazilian CPF (individual taxpayer ID)'). It does not explicitly contrast with sibling validators like br__validate_cnpj, but the resource is unambiguous and distinct.

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 when-to-use or when-not-to-use guidance is provided; nothing points to br__validate_cnpj for company IDs or other validation alternatives. The only implied context is the tool name itself.

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 provided, the description carries the behavioral disclosure burden. It meaningfully explains that CTeXSDValidator auto-selects the unsigned or signed XSD depending on the presence of ds:Signature, and it states the returned dict fields. It does not explicitly declare read-only behavior or offline validation, but 'validate against the bundled XSD' strongly implies those traits.

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 compact and well-structured: a clear purpose statement, followed by the key automatic schema-selection behavior, followed by the return value summary. Every sentence contributes necessary information and there is 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?

The output schema covers return-value structure, and the input schema already documents parameters. The description covers the non-obvious schema-selection behavior that would otherwise be opaque. The only notable gap is the absence of explicit guidance for choosing between this and sibling validators, but the tool name and opening sentence already make the CT-e scope clear.

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 100%, with both xml_base64 and xml_content already documented, including the either/or relationship. The description adds no new parameter-level meaning beyond the schema, so the baseline of 3 is appropriate.

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 first sentence states a precise verb and object: validate a CT-e XML (modelo 57, schema 4.00) against the bundled PL_CTe_400 XSD. This clearly distinguishes the tool from validate_nfe_xml, validate_nfse_xml, and the other CT-e sibling tools like submit_cte or cancel_cte.

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 use case—validating CT-e XML documents—but does not explicitly state when to use this tool versus the NFe/Nfse validators, nor does it name alternatives or exclusion conditions. The context is clear, but the description leaves tool-selection routing to the agent's inference.

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 provided, the description carries the behavioral disclosure burden. It does well by explaining the automatic schema selection logic, the difference between unsigned and signed derivatives, and the returned dictionary keys. It does not mention potential side effects or permission requirements, but validation is inherently read-only and the description conveys no hidden destructive behavior.

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 concise and well-structured: it front-loads the primary purpose, then explains the key behavioral nuance, then lists the return fields. No sentences are wasted, and the formatting with code spans improves readability.

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 the validation target, schema selection behavior, and return structure, which is sufficient for a tool with a rich output schema and only two optional parameters. Minor gaps such as what happens if both parameters are provided or neither is provided are not addressed, but the schema's 'Provide either' instruction partly mitigates this.

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 input schema already provides 100% coverage of both parameters with clear descriptions for xml_base64 and xml_content. The tool description adds no parameter-level meaning beyond the schema, so the baseline of 3 is appropriate.

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 ('Validate an NF-e/NFC-e XML'), the exact document types (modelo 55/65, schema 4.00), and the validation artifact (bundled PL_010d XSD). This clearly differentiates it from sibling validators like br__validate_nfse_xml and br__validate_cte_xml.

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 gives useful context, especially the distinction between unsigned and signed documents, implying use after br__sign_nfe. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it. The usage guidance is implied rather than 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?

With no annotations, the description carries the behavior burden and does well: it discloses automatic schema selection, optional vs required ds:Signature per schema, and the return dict keys. It does not explicitly mention side effects or network usage, but a validation operation is inherently read-only and the description sufficiently exposes its behavior.

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

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

The description is compact and well-structured: one purpose sentence, a bulleted schema-selection list, and a concise return summary. Every sentence earns its place and the most important information 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 two-parameter validation tool with an output schema, the description covers purpose, schema selection, signature requirements, and return fields. It does not state what happens if both xml_base64 and xml_content are supplied or omitted, but the schema's 'Informe xml_content ou xml_base64' guidance mitigates most ambiguity.

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 100%, and the description adds no parameter-specific meaning beyond clarifying that the XML can be a DPS or NFSe. The auto-selection behavior helps interpret what to pass but does not exceed the baseline expected when the schema already documents both parameters.

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 action ('Validar um DPS ou NFSe contra o XSD v1.01 do ADN') and clearly identifies the resource and validation standard. The root-element schema selection further differentiates this tool from siblings like br__validate_nfe_xml and br__validate_cte_xml.

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 establishes clear context: use for DPS/NFSe XML validation against the ADN XSD, with automatic schema selection by root element. It does not explicitly name alternatives or exclusions, but the sibling list and tool name make the applicable domain obvious.

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