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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context beyond these: the tool requires prepaid credit (costs money), involves no platform credentials, and the client is the data controller under LGPD. This enriches the agent's understanding of side effects and responsibilities, which is not covered by 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?

The description is a short paragraph of four concise sentences, front-loaded with the core purpose. It includes necessary practical details (payment, legal note) without excessive verbosity. Each sentence contributes value, though the legal and payment info could be seen as peripheral. Overall, it is efficient and well-structured.

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 low schema coverage, the description should compensate by explaining parameters and expected output. It clarifies purpose, source, and costs, but omits what the query returns (e.g., a certificate document) and how to correctly use cpf vs. cnpj. For a moderately complex query tool, this is a notable gap, so it is minimally 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?

The input schema has two parameters (cpf, cnpj) with 0% schema description coverage. The description does not explicitly explain that cpf is for individuals and cnpj for companies, nor does it clarify their optionality or format. It only implicitly suggests tax debt lookup but offers no parameter-specific guidance, leaving the agent uncertain about how to fill these fields.

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 the tool's purpose: 'SEFAZ ES: Certidão Negativa de Débitos, consulta em fonte oficial.' It specifies the verb (consulta) and the resource (certidão negativa de débitos from SEFAZ ES). It distinguishes itself from sibling tools (authenticate, marketplace, etc.) which are unrelated, leaving no ambiguity about its function.

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?

While there is no explicit 'use when' or 'do not use when' statement, the description provides clear context: it queries official Brazilian sources, is not confidential, and involves prepaid credit. This implicitly tells the agent when to use it (for official tax debt queries) and that it's not for confidential data. However, it lacks explicit alternatives or exclusions, so I score it 4.

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