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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds meaningful context: prepaid credit consumption per query, no platform credentials required, non-confidential official data, and LGPD accountability. This goes beyond the schema and annotations, though it doesn't mention rate limits or response format.

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, using three short sentences to convey purpose, payment model, and legal context. There is slight repetition of 'official source' and 'official bodies', but overall it is front-loaded and efficient.

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?

There is no output schema, no parameter descriptions, and no mention of return type or expected response. While it provides high-level purpose and legal/payment context, an agent would be uncertain about what the tool returns and how to map the required inputs to their real-world meaning.

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 3 required string parameters with 0% coverage, and the description never explains login_usuario, login_senha, or numero_instalacao. It mentions credentials generically but doesn't clarify that these are Cemig professional login credentials or that numero_instalacao is the electricity installation number, leaving the agent with no parameter understanding.

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 identifies the tool as a Cemig bill download/query service for professionals, using official sources. This distinguishes it from the generic siblings (authenticate, connect, marketplace, etc.), though it could be more explicit by stating the exact action and return type in a verb-driven sentence.

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?

It implies when to use: to query official Brazilian data without platform credentials, paying with prepaid credits, under LGPD responsibilities. However, it doesn't explicitly name alternatives or exclusions, leaving the use case implied rather than fully specified.

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