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

With readOnlyHint=true and idempotentHint=true in annotations, the safety profile is already established. The description adds legitimate value by clarifying the data is not confidential ('não é dado sigiloso'), the payment model (prepaid credits per query), and the LGPD compliance context where 'o cliente é o controlador dos dados'. However, the description doesn't indicate what happens on insufficient credit or malformed requests, and it's cluttered with legal disclaimers that dilute the behavioral disclosure.

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 a single, densely packed run-on paragraph mixing purpose, commercial terms, privacy, and legal liability in one breath. It blurs distinct types of information (what it does, what it costs, who's responsible) into one unstructured block, which would benefit from separators. It's not concise — it's just under-specified and unfocused.

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 3 parameters with 0% schema coverage and no output schema, the description needed to compensate for parameter semantics and return-value expectations, but it never does. The description covers the commercial model and LGPD obligations reasonably well but leaves out critical invocation details like response format, expected error handling, and how cpf/cnpj/ie interplay. It's also unclear from the description how the platform 'hosting' maps to the actual API you're calling.

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 0% and the description never mentions cpf, cnpj, or ie — the three parameters. There is no guidance on identifier format, whether they're mutually exclusive, or which combination is valid (e.g., ie for state registration vs. cpf/cnpj for national IDs). The description carries zero explanatory burden for the parameters, forcing the agent to rely purely on Brazilian domain knowledge.

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 'SEFAZ RR: Certidão Negativa de Débitos, consulta em fonte oficial,' which clearly states the resource (SEFAZ RR negative debt certificate) and the action (consulta). The verb matches the tool name's 'consultar', and the resource is specific enough to distinguish from the heterogeneous sibling tools. Minor deduction because the purpose could be more prominent before delving into commercial and legal details.

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?

No explicit when-to-use or when-not-to-use guidance is provided relative to sibling tools. The description mentions 'sem credenciais da plataforma' (no platform credentials) and 'pague por consulta' (pay per query), which implies a cost consideration but doesn't serve as a usage criterion. No mention of alternatives, prerequisites, or exclusions, leaving the agent to infer when to prefer this tool.

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