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

Annotations already indicate read-only, idempotent, and non-destructive behavior, and the description is consistent with them. It adds meaningful context: no credentials required, prepaid usage, official public-sourced data, and the client's LGPD data-controller responsibility. It does not disclose rate limits or failure modes, but the core behavioral profile is transparent.

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 compact, using a few sentences without rambling. It front-loads the purpose and then adds relevant payment, credential, and LGPD context. It is efficient given the amount of background information it conveys.

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?

The tool has five parameters, no output schema, and no parameter-level documentation, yet the description does not explain how to build a valid request or what the returned certidão would look like. It is richly contextual about pricing and legal posture but insufficient, for independently invoking the call, especially because required tipo_certidao is never documented.

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 any of the five parameters. It never clarifies what 'cpf', 'cnpj', 'orgao', 'birthdate' or 'tipo_certificacao' should contain, nor what values the required tipo_certificao should take. The description completely fails to compensate for the lack of parameter schema.

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 identifies the resource ('Tribunal TRF5', 'Certidão Negativa Cível e Criminal') and the operation ('consulta em fonte oficial'), which is more specific than the bare tool name. It does not explicitly distinguish this tool from potential alternative court/certidade lookup tools, but the scope is still unmistakable.

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 provides useful usage context: it is a paid, prepaid-credit consultation, requireslement no platform credentials, and returns data available to citizens. However, it does not say explicitly when to use this tool instead of another, nor does it mention disallowed or alternative usage cases.

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