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

With annotations all false, the description carries full behavioral disclosure. It reveals batch semantics ('cada uma é emitida separadamente e uma falha não aborta o lote'), automatic resolution of optional API-required fields, the skipping of already-charged installments unless forcar=true, the scope of maximo_parcelas, the response structure, and the limitation that the API does not send notification emails. No annotation contradictions exist.

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 long but information-dense; nearly every sentence adds critical detail. It is logically structured from purpose to batch behavior, parameter specifics, return format, and related tools. A few clauses could be tightened (e.g., the separate mention of each installment being issued individually), but the overall economy is strong for a tool with 11 parameters.

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 complexity (batch generation, optional auto-resolution, nested objects, 11 params), a complete description must address input selection, output format, edge cases, errors, and related actions. This description covers all of these: it specifies the exact return tuple {solicitadas, emitidas, ignoradas, erros}, explains 'url' as the charge link, notes the notification email caveat, and points to related query/cancel tools. It is exceptionally complete for the provided schema/annotations.

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 no parameter descriptions (0% coverage), so the description must compensate. It explains tipo's exact accepted values and normalization, the semantic meaning and source of ids_parcelas, the auto-resolution and overrides for conta_bancaria, descricao_fatura, and data_vencimento, the purpose of forcar, and the conditional applicability of maximo_parcelas. However, the params `data`, `account`, `id_parcela`, and `desconto_antecipado` (nested object) are not explained, leaving some inference required.

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: 'Gera cobrança (boleto, pix ou link de pagamento) para uma ou mais PARCELAS de contas a receber.' It identifies the operation as generating charges for AR installments and lists the payable methods. This distinguishes it from sibling tools like contaazul_cancel_charge and contaazul_get_charge.

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 explicit usage context: it explains where installment IDs come from (contaazul_list_receivables or contaazul_get_installment), when to supply conta_bancaria (if multiple accounts, via contaazul_list_financial_accounts), and when to use forcar (to bypass existing active charges). It also names alternatives for follow-up: 'Para consultar depois use contaazul_get_charge e para cancelar contaazul_cancel_charge.' This gives actionable decision guidance.

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