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

Annotations declare destructiveHint=true and non-idempotent, open-world behavior, and the description adds meaningful beyond-annotation context: it is a two-phase prepare/confirm flow, credentials must never be passed as arguments, and payment data is only editable in the Gover portal. The "prepares without executing" framing reconciles with the destructive annotation rather than contradicting it.

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?

Purpose and workflow are front-loaded, but the text drifts into tangential rules (payment data in the portal, extensive-result handling) that are loosely related to altering a unit. Several sentences could be trimmed or reordered for tighter focus.

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 output schema, the mention of using gover_ler_resultado with the returned resultadoId is a useful completion detail. However, given the 1-param deeply nested object at 0% coverage, the description leaves the agent without enough information on the payload structure to call the tool confidently.

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 is a single deeply nested `form` object with dozens of fields and 0% schema description coverage, so the description carries the full documentation burden. Instead it only says "Os campos seguem o contrato da API," which explains nothing about any field, and none of the nested properties (cnpj, unidadeId, tipoPagamentoId, etc.) are 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 states a specific verb+resource ("Alterar unidade") and the title clarifies it is a preparation step ("Preparar: Alterar unidade"), distinguishing it from gover_incluir_unidade and gover_consultar_unidade. The distinction is reasonably clear, though it relies partly on the title rather than the description alone.

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 explicit workflow guidance: prepare without executing, show parameters to the user, and only after explicit confirmation call gover_confirmar_operacao. This names the next-step alternative and a condition for invoking it, though it gives no guidance on when to choose this over other alterar_* tools.

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