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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description goes beyond this by explaining that it queries public-access information (not private/confidential), that no credentials are required, and that the client is the LGPD data controller. This adds meaningful context about data sensitivity, authentication, and legal responsibility.

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 three-sentence description is efficient: it covers purpose, payment model, data sensitivity, and legal compliance without fluff. The LGPD sentence, while somewhat legalistic, adds essential governance context. It earns a 4 for being appropriately concise while slightly dense with auxiliary information.

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 description addresses query inputs, data classification, cost, and compliance, but it does not describe the response format or possible error conditions (e.g., invalid CPF/NIS, not found). Since there is no output schema, this missing information leaves the agent uncertain about what to expect from the call, making completeness only adequate.

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?

With 0% schema description coverage, the description must explain parameters. It identifies CPF and NIS as the identifiers used for the query, but it does not explain the optional 'completo' boolean parameter, nor does it provide format or validation details. It partially compensates for the schema gap, leaving one parameter ambiguous.

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 uses the specific verb 'Verifica' (checks) with the resource 'recebimento do Auxílio Emergencial' (receipt of Emergency Aid), explicitly naming the inputs CPF and NIS. This clearly distinguishes it from unrelated sibling tools like authenticate, connect, or marketplace, making its purpose 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 gives clear context on when to use this tool: to verify Emergency Aid receipt via CPF/NIS, with notes on prepaid credit and no credentials needed. It does not explicitly state alternatives or exclusions, but the siblings are so distinct that usage intent is obvious, meriting a 4 rather than a 5.

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