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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered by structured data. The description adds the useful behavioral fact that required fields vary per receita (documento de origem, referência, valores, campos adicionais), but says nothing about what happens when Uf is omitted, environment-dependent behavior, or caching/latency. Modest value added on top of annotations.

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?

One front-loaded sentence with a parenthetical that enumerates the field groups; zero redundancy and no filler. It could have spent one more clause on the zero-required-parameter behavior without bloat, but nothing in it needs cutting.

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-structure explanation is correctly omitted, and annotations cover safety. But with zero required parameters and an undocumented TipoAmbiente, the agent cannot tell what a bare call returns or which combinations are valid — meaningful gaps for a configuration-lookup tool that an extra sentence would have closed.

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 only 33%: only Receita carries a description ("Opcional: só a regra desta receita."). The description implies Uf scoping and receita scoping but never explains TipoAmbiente at all — a critical GNRE concept (produção vs. homologação) — nor what an omitted Uf returns (all UFs? error?). With under half the parameters documented, the description fails to compensate for the gap.

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?

Specific verb ("Lista") plus a concrete resource: the receitas a UF accepts in GNRE and the required fields per receita, with examples of those field groups. This is clearly distinguishable from gnre_emitir/gnre_consultar, though the description never names a sibling to sharpen the boundary. Purpose is unmistakable 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?

Usage is only implied: because the tool returns "os campos que cada uma exige", an agent can infer it should be called before gnre_emitir to discover required fields. There is no explicit when-to-use, no when-not-to-use, and no mention of the gnre_consultar/gnre_emitir alternatives. Nothing is misleading, but the routing is left to inference.

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