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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by explaining the payment model (prepaid credit), that the platform hosts the service without requiring platform credentials, and that the data is non-confidential and subject to LGPD compliance. This goes beyond annotations, though it does not cover error handling or response format.

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 three sentences, each carrying distinct information: purpose, payment/hosting details, and legal responsibility. It is front-loaded with the core purpose and avoids fluff. However, it could be more concise while retaining the legal context; it is not padded but could be slightly streamlined.

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 high complexity (13 parameters, no output schema, no parameter docs), the description is incomplete. It provides legal and payment context but does not explain the request parameters or the nature of the response. Even with annotations, the agent cannot reliably construct a valid request without more parameter semantics. The lack of output schema and parameter guidance makes this insufficient.

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 schema has 13 parameters with zero description coverage. The description does not explain any parameter (email, finalidade, cpf, etc.) and only vaguely mentions 'finalidade legítima' in the LGPD context. It fails to compensate for the low schema coverage, leaving the agent without clues about how to populate the parameters.

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: consulting a 'Certidão Criminal de 1º Grau' (criminal certificate) from the TJSP (São Paulo court). It specifies it is a consultation from an official source, distinguishing it from generic sibling tools like authenticate or marketplace. The verb 'consultar' in the tool name is reinforced by the description, making action and resource unambiguous.

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 notes that payment is via prepaid credit and that the data is not confidential, but it does not provide explicit when-to-use vs. alternatives. It implies usage for requesting criminal certificates but lacks clear exclusions or comparison with other tools. Context is given (official source, LGPD responsibility), but no formal guidance.

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