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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is a safe read operation. The description adds that it's hosted by the platform, requires pre-paid credit per query, and that it doesn't require platform credentials. It also mentions LGPD compliance. There's no contradiction. It doesn't detail return format or error handling, but given the annotations, the description adds some value beyond them.

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 about three sentences, but it's somewhat verbose with legal and compliance details that might be necessary but could be condensed. It's front-loaded with the main purpose, but the LGPD mention and controller clarification add bulk. It's not overly long, but it could be more concise.

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 is relatively simple with 2 parameters and no output schema. The description gives background on legal aspects and payment, but it doesn't explain what the result looks like or whether both parameters are alternatives. It doesn't specify that you must provide one identifier. Given the complexity, it's adequate but has gaps in parameter explanation. The lack of output schema means the description could have described the return format, but it's not mandatory if the result is obvious.

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. The description does not explicitly explain these parameters; it mentions consulta (consultation) but doesn't say that you need to provide either CPF or CNPJ. With 0% schema description coverage, the description should compensate by explaining parameter usage, but it doesn't. It's not completely absent, as the context of consulting official records implies you need an identifier, but it's insufficient.

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 that this tool performs a consultation of a negative certificate of records (Certidão Negativa de Feitos) from official sources. It distinguishes it from potential siblings by specifying it's for MPT GO and that it's a query, not a modification. However, it doesn't explicitly contrast with other similar query tools, but given the sibling list includes generic tools like authenticate, it's clear enough.

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 explains that the tool is for consulting official Brazilian sources, available to citizens, and that it's not confidential data. It also clarifies payment with pre-paid credit and that the client is data controller under LGPD. It doesn't explicitly say when NOT to use it, but it sets clear context. The phrase 'Consulta informação de fontes e órgãos oficiais brasileiros' implies use for official background checks. No explicit exclusions, but the context is adequate.

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