Br Correct Cte

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.