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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable context: it is hosted by the platform, requires no platform credentials, is paid per query with prepaid credit, and the data is not confidential (same as available to citizens). It also mentions LGPD compliance and data controller responsibilities, which is useful for legal/ethical considerations. This goes beyond the 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 concise, with three sentences covering purpose, hosting/payment, and data/LGPD aspects. It is front-loaded with the main purpose. However, it includes some legal boilerplate that might be less critical for tool invocation, but it is still relevant 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 tool's simplicity (two optional parameters, no output schema), the description covers the main aspects: what it does, how it's accessed, and legal considerations. However, it lacks details on parameter usage (which one to provide, format) and what the response contains. The annotations cover safety, but the description could be more complete for a tool that requires payment.

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 two parameters (cpf and cnpj) with no descriptions, and the description does not explain them. It mentions 'consulta informação' but does not clarify that either CPF or CNPJ is required, nor does it explain the format or that they are mutually exclusive. With 0% schema description coverage, the description should compensate, but it fails to provide any parameter-level guidance.

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 negative certificate (Certidão Negativa) from the MPF (Ministério Público Federal) through an official source. It specifies the resource (MPF certificate) and the action (consult). It distinguishes from siblings by focusing on this specific certificate type, though it doesn't explicitly name alternatives.

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 context on when to use the tool: to consult information from official Brazilian sources, with payment via prepaid credit. It implies usage for obtaining a negative certificate but does not explicitly state when not to use it or mention alternative tools. The sibling tools are mostly unrelated (authentication, marketplace, etc.), so differentiation is less critical, but explicit guidance is lacking.

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