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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds context about being hosted by the platform, not requiring platform credentials, and involving per-query costs with prepaid credits. It also mentions LGPD compliance and data ownership. These are useful behavioral details beyond the annotations, though it doesn't discuss rate limits or exact response behavior.

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 paragraph of about 3-4 sentences, which is concise. It front-loads the purpose and then provides operational details. No wasted words, though it could be more structured (e.g., bullet points) for clarity, but overall it is efficient.

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 the tool has no output schema and simple parameters, the description provides moderate context: it explains the data source, legal considerations, and payment model. It lacks explicit guidance on whether both CPF and CNPJ can be provided, what happens if none is provided, and what the response looks like. For a simple query tool, this is adequate but not complete.

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 0%, meaning the description does not explain the parameters at all. While the parameter names 'cpf' and 'cnpj' are self-explanatory (Brazilian tax identifiers), the description does not clarify that they are optional (required: 0) or that one of them must be provided for a query. It also doesn't explain formats (e.g., with or without punctuation) or constraints. Since the description carries the burden and fails to compensate, this scores low.

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 clearly states that the tool consults a negative debt certificate from SEFAZ PR in an official source. It uses a specific verb ('consultar') and resource ('Certidão Negativa de Débitos'), which is clear. However, it could be more explicit about distinguishing from potential sibling tools (e.g., other certidão tools), but none are present in the sibling list, so it stands 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?

The description indicates this is for consulting official Brazilian data and mentions it is not sensitive data, implying it is for legitimate purposes. It also notes payment requirements (prepaid credits). However, it does not explicitly state when to use this tool versus alternatives, nor when not to use it. Given the sibling list, no direct alternatives exist, but guidance on prerequisites (e.g., needing CPF or CNPJ) is implied but not explicit.

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