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

Annotations already declare read-only, idempotent, non-destructive behavior; the description adds real context beyond that: it uses only the connected Gover account and its permissions, does not alter business records, must not receive credentials, and payment data belongs in the portal. These are meaningful behavioral constraints, though return/pagination behavior is left thin.

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-loads the purpose before constraints and the result-continuation pointer. A couple of clauses (payment data, credentials) read as boilerplate, but nothing is redundant enough to obstruct.

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 tool with nested objects, eight parameters, zero documented fields, and no output schema, the description does not explain how to build formData, what a successful result contains, or how pagination/resultadoId round-trips work. It is significantly under-specified for the tool's complexity.

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 eight parameters, a large nested formData object, and 0% schema description coverage, the description carries the full burden — yet it only says 'Os campos seguem o contrato da API', which explains nothing about termo, cidadeId, formData fields, or required-ness. It does not compensate for the coverage gap at all.

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+resource ('Pesquisar disponibilidade de voos'), so an agent knows this searches flight availability. However, it does not distinguish itself from close siblings like gover_buscar_voos_assincronos, gover_cotar_voos, or gover_iniciar_pesquisa_aerea, leaving the agent to guess which search entry point applies.

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 one concrete routing rule — for extensive results use gover_ler_resultado with the returned resultadoId — which is genuinely useful. But it gives no guidance on when to pick this tool versus the numerous other flight-search/cotacao siblings, so usage is only partially covered.

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