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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds real behavioral detail beyond that — the grouping factor from Tab. 42 that reduces ampacity, and the fallback behavior when disjuntor_In_A/curva are omitted. It stops short of describing the returned result or the calculation path, which would be the remaining behavioral surface.

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?

Front-loaded with the operation and standard, then dense per-parameter clauses in backticked shorthand. For 16 parameters it is efficiently sized, though the inline enumeration of every allowed value in prose makes it read more like a schema dump than a narrative.

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?

With 16 parameters, no output schema and no schema-level descriptions, omitting any hint of the return payload (cable section in mm², resulting voltage drop, whether a breaker is recommended) is a real gap for an agent that must decide what to do next. The input side is well covered; the output side is not.

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%, so the description carries the full burden, and it supplies the valid value sets for sistema, metodo, material, isolacao, arranjo and curva_disjuntor — information that appears nowhere in the schema (zero enums declared). It leaves fp, queda_max_pct and temp_ambiente_C unexplained, though their titles and defaults make them inferable, so it compensates well but not completely.

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?

Names a specific verb and resource ('Dimensiona a seção de um cabo BT') and anchors it to ABNT NBR 5410, then enumerates the four checks it performs (ampacidade, queda de tensão, coordenação de sobrecarga, neutro/PE). Nothing in the sibling list (puxamento_cabo, verificar_seccionamento, dimensionar_tc) overlaps, so an agent can route here without ambiguity.

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?

Usage is implied rather than stated: the agent infers this is the tool for sizing a cable from power, voltage and length. There is no explicit 'use this instead of X' routing and no statement of preconditions (e.g. that it is for low-voltage circuits only, or what to do when the circuit already has a breaker). The note about defaulting to the smallest MCB ≥ Ib when breaker data is absent is the closest thing to conditional guidance.

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