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

With no annotations present, the description carries the full burden and does so: it discloses that each call consumes one credit with per-tier prices, that errors are not charged, that empty/sem_certidao/nao_contribuinte responses still count, and the free-tier limits. It also explains the confirmo_custo gate (without it the tool only explains cost and queries nothing) and that secundarias can add seconds of latency.

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, return shape, and the SP caveat are front-loaded before the cost/charging rules, which is the right order for an agent deciding whether to call. The per-plan price parenthetical (including recarga figures) is dense and could be compressed, costing some conciseness without breaking structure.

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 six-parameter, paid, cost-gated lookup tool with no annotations, the description covers what it does, what it returns, the one-document rule, the SP exception, billing behavior on non-results, and the confirmation prerequisite. An output schema exists, so return-value explanation is more than sufficient rather than missing.

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 coverage is 100%, so the baseline is 3; the description still adds real meaning beyond the schema by stating that only one document may be supplied and by attaching the SP restriction to the CPF parameter. The cost-gate semantics of confirmo_custo are also reinforced in prose, though the pricing detail is not parameter-specific.

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 and resource (query the Inscrição Estadual for a given UF) and enumerates the returned fields (número, razão social, situação, tipo, endereço, CNAE, regime, datas). It implies single-state scope, which distinguishes it from consultar_ie_todos_estados, but never names that sibling or validar_inscricao_estadual explicitly, so differentiation is left partly to inference.

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 clearly states the three accepted document types and exactly one per call, and gives a concrete routing rule: CPF does not work in SP, use CNPJ or IE there. It does not say when to prefer this over consultar_ie_todos_estados or validar_inscricao_estadual, so exclusions versus siblings are absent.

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