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

The annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false, but the description adds meaningful context: prepaid per-query cost ('pague por consulta com crédito pré-pago'), that data is not confidential ('não é dado sigiloso'), and LGPD compliance responsibility ('O cliente é o controlador dos dados'). This goes well beyond the structured 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 three sentences long, with the core purpose front-loaded in the first sentence and the remaining sentences adding relevant operational/compliance details. No wordy filler, though the LGPD clause could be seen as slightly verbose for tool-selection purposes.

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?

For a simple read-only tool with 2 parameters and no output schema, the description covers purpose, official source, payment model, credential expectations, and legal responsibility. It does not explicitly describe the return value, but 'Lista de Instalações' strongly implies the output, so the context is adequately complete.

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 only indirectly addresses the two login parameters by saying 'sem credenciais da plataforma'. While the parameter names login_email and login_senha are self-explanatory, the description does not explicitly state that these are Enel/RJ credentials or explain their format and purpose, leaving a partial gap.

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 opens with 'Enel RJ: Lista de Instalações, consulta em fonte oficial', clearly stating the action (consultar/lista) and the resource (Enel RJ installations). It also distinguishes itself from the generic platform siblings (authenticate, connect, marketplace) by naming a specific domain and official source.

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 usage context: it queries official Brazilian sources, uses prepaid credit, and requires no platform credentials. However, it does not explicitly state when not to use this tool or name alternative tools for similar queries, so it lacks exclusions but is otherwise clear.

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