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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context: it's hosted by the platform, requires no platform credentials, charges per query with prepaid credits, and clarifies data privacy (client is data controller, LGPD compliance). This goes beyond annotations and is useful for the agent.

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, reasonably concise, and front-loaded with the main purpose. It includes necessary legal and payment context. It could be slightly more structured, but it's not verbose. Every sentence adds value.

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 has no output schema and no parameter documentation, the description should provide more detail on what the query returns and how to use the parameters. It explains the source and legal aspects but lacks operational details like input format (e.g., CPF/CNPJ format) or output structure. For a tool with 2 parameters and no output schema, this is a moderate gap.

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' and 'cnpj' at all. The schema only shows they are strings, with no format or meaning. The description mentions the certificate but doesn't clarify that cpf/cnpj are the identifiers to query. This is a significant gap; the description should compensate for the lack of schema documentation but doesn't.

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: it queries the MPT RS (Ministério Público do Trabalho do Rio Grande do Sul) for a 'Certidão Negativa de Feitos' (negative certificate of court records) from an official source. It specifies the resource (certidão) and the action (consultar/query). It distinguishes from siblings by being the only tool related to MPT RS queries, 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 official Brazilian sources for information available to citizens, not confidential data. It also mentions payment via prepaid credits. However, it does not explicitly state when NOT to use it or mention alternative tools, though the sibling list shows no similar tools. The guidance is implicit rather than explicit.

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