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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds valuable operational context beyond that: it is hosted by the platform but requires no platform credentials, it is paid via prepaid credit, and it exposes non-confidential official data with LGPD controller responsibilities. This goes beyond the annotations and helps the agent understand side effects (cost) and access requirements.

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 compact and front-loaded with the core purpose, then provides contextual details about hosting, payment, data source, and LGPD in a few short clauses. It avoids redundancy and is appropriately sized, though the legal compliance sentence is somewhat boilerplate. Every part contributes useful information for an agent considering the tool.

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?

While the description covers business and legal context (payment model, official data, data controller), it does not explain how to invoke the tool correctly: parameter semantics, authentication flow (whether login_senha or pkcs12_cert is required in practice), or what the response looks like (no output schema). The tool has moderate complexity with six parameters and no output schema, so the description is insufficient for correct invocation.

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 input schema has six parameters with zero descriptions, and the tool description does not explain any of them. The agent is left to infer the meaning of placa, renavam, login_cpf, login_senha, pkcs12_cert, and pkcs12_pass solely from their names. Critical details like parameter formats, required vs optional authentication fields, and how the certificate/password are used are completely absent, which is a severe gap for a tool with this many 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 function: consulting DNIT infractions from an official source. The phrasing 'DNIT: Infrações, consulta em fonte oficial' conveys a specific verb ('consulta') and resource ('Infrações'), and it is obviously distinct from the generic sibling tools like authenticate or connect. The purpose is unambiguous and well-scoped.

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 clear context that this is a pay-per-query service from official Brazilian sources, with no platform credentials required, and that the client is accountable for LGPD compliance. This helps an agent decide when to use it, though it does not explicitly exclude alternative tools. Since the sibling tools are unrelated system tools, the context is sufficient to guide selection.

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