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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safe, read-only nature is covered. The description adds key behavioral context: it is hosted by the platform, does not use platform credentials, requires prepaid credits per query, and is based on official sources accessible to citizens. It also clarifies data privacy responsibilities under LGPD. This is valuable context beyond annotations, without contradiction.

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 with two sentences, but it packs a lot of information: purpose, source, payment model, data nature, LGPD note. It is concise and front-loaded with the core action. It earns its length, though the LGPD note is somewhat tangential for tool usage but adds compliance context. No wasted words.

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 moderate complexity (3 optional parameters, no output schema), the description provides adequate context: official source, payment requirement, data controller responsibilities DRY and LGPD. It doesn't explain the return format, but no output schema exists. It could mention that cpf/cnpj/nome_completo are alternative filters, but the nature of CEAT consultation is clear enough for an agent to attempt invocation.

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%, and the description does not explain the parameters (cpf, cnpj, nome_completo) beyond their names. The description mentions the certificate consultation but does not specify whether these parameters are alternative identifiers, required formats, or how they relate. With 3 params and no explanation, the description fails to add meaning beyond the schema, which is minimal (just names and types). Baseline for high coverage would be 3, but here coverage is 0%, so the description must compensate — it does not.

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 performs a consulta de Certidão Eletrônica de Ações Trabalhistas (CEAT) from TRT9, an official source. It is specific about the resource and action, and while it doesn't explicitly distinguish from sibling tools (which are unrelated generic tools like authenticate, marketplace), the purpose is clear enough given the context.

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 implies usage for checking labor lawsuit certificates, and mentions payment with prepaid creditholly, but does not explicitly state when to use this vs. alternatives or any exclusions. It provides context about hosting and payment but lacks direct guidance on when to choose this tool over others, though sibling tools are mostly unrelated. The note about LGPD and controller responsibility adds context for appropriate use.

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