Arc Flash Platform — Estudos Elétricos

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

Read-only annotations already cover the safety profile, and the description adds real behavioral context beyond them: the response warns when fator_c=1.0 with aplicar_kt=False is used outside §7.1.2, and it discloses 'Gratuito (uso limitado)'. It does not describe the result payload shape, but the warnings and the metering note are non-trivial disclosures.

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?

Dense and front-loaded: purpose first, then the input-selection rules, then the accuracy caveat. Some IEC section citations (§6.3.3, §6.6.1, §7.1.2) add authority but also weight; the text is long, though nearly every clause carries decision-relevant information.

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 19-parameter, no-output-schema tool the description covers the critical input logic but leaves several defaulted parameters (transformer kVA/voltage/impedance, cable material, conductor count) undescribed, so an agent cannot confidently change them. Adequate, but with a clear gap given the schema's zero description coverage.

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 coverage is 0% across 19 parameters, so the description carries the full burden and does well: it explains the mutually exclusive network inputs, the trafo_* group, xr_rede/xr_trafo's physical role (κ, peak ip, asymmetry, breaker making), the aterramento/Rn_ohm pair driving Icc_1φ, and the fator_c/aplicar_kt base. trafo_kVA, trafo_V2_kv, trafo_Vcc_pct, cabo_material and cabo_num_condutores are only implied by 'trafo_*'/'cabo_*' and never given units or meaning.

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?

States a specific verb+resource with scope: short-circuit calculation per IEC 60909 producing Icc 3φ/2φ/phase-earth, X/R and peak. The output set is listed up front, which cleanly separates it from siblings such as calcular_energia_incidente or dimensionar_cabo without needing their schemas.

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?

Gives explicit alternatives for the network source ('potencia_curto_mva OU icc_rede_kA') and conditional guidance for branches (com_transformador=True, com_cabo=True, generator source → xr_rede≈6,7). It never states when to prefer this tool over a sibling (e.g. when peak current rather than incident energy is wanted), so no explicit exclusion is present.

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

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

Annotations only declare readOnlyHint=true, so the description carries the behavioral load and does so: it discloses the validity-range extrapolation behavior (`fora_da_faixa_do_modelo`, `validado`, `faixa_do_modelo`), the `avisos` entries for the 2 s time cap and low power, the `criterio_ibf` provenance marker, and that the call is free with limited usage. An agent knows what it will get back and what caveats to relay.

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?

Purpose and primary outputs are front-loaded in the first sentence, and subsequent paragraphs each carry distinct operational information (two-tier timing, enclosure dimensions, validity range, Ibf provenance). It is dense and long for a description, but almost no sentence is redundant.

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 11 parameters, 0% schema coverage and no output schema, the description compensates fully: it explains input meaning, the response fields worth relaying (`categoria_epi` vs. NR-10/NFPA 70E categoria, `avisos`, `faixa_do_modelo`, `criterio_ibf`), and even the wording to use with the end user. Nothing an agent needs to call and interpret this correctly is missing.

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 coverage is 0%, so the description must compensate and largely does: it enumerates `config` ∈ {VCB, VCBB, HCB, VOA, HOA}, explains `larg_mm`/`alt_mm`/`prof_mm` as the REAL enclosure dimensions subject to the §4.8 size correction (default 508³ reference box), and distinguishes the two arc-duration parameters by full vs. reduced current. `gap_mm` is only referenced obliquely in the 4× gap rule and `api_key` is never mentioned, leaving minor gaps.

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?

States a concrete verb and resource (incident energy, arc-flash boundary and NBR 17227 PPE table from an electric arc) plus the governing algorithm (IEEE 1584:2018 / NBR 17227:2025) and the 208 V–15 kV applicability window. That window implicitly separates it from calcular_energia_incidente_hv, but the sibling is never named, so an agent must infer the split.

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?

Gives concrete conditional guidance: supply both `t_arc_s` and `t_arc_reduzido_s` when an inverse-time device exists, otherwise both tiers use the same time and the larger Ei governs; also warns that the reduced tier can govern even at >0.6 kV. It names the upstream alternatives for Ibf provenance (calcular_curto_circuito / montar_rede) but does not explicitly state when NOT to use this tool versus the HV sibling.

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

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

Read-only annotations are already declared, yet the description still adds real behavior: the output is a conservative PPE band (≤4/5/8/12 or >12 cal/cm²) rather than a point value, lee is an upper theoretical bound, and the service is free with limited usage. It stops short of stating numeric limits of the free tier or failure modes, so not a 5.

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 scope constraint and the triage disclaimer before the method breakdown, and the bulleted method table is scannable. It is dense but nearly every clause (out-of-scope standards, band-vs-point, per-method requirements) prevents a misinvocation.

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?

No output schema exists, and the description compensates by describing the returned PPE band, the upper-bound nature of the lee result, and the triage-level confidence. Units for ibf_ka/t_ms are only implied by field names, which is the one residual gap for an eight-parameter tool.

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 property titles ('T Ms', 'Ibf Ka') carry no meaning, so the description does the heavy lifting: it enumerates metodo values with their OSHA table mappings, tipo_trabalho enums with voltage ranges, and flags dist_trabalho_mm/comprimento_arco_m as conditionally required. It leaves tensao_kv, ibf_ka, t_ms and api_key entirely unexplained, which keeps it from a 5.

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?

States a specific verb+resource ('Energia incidente para sistemas > 15 kV') and immediately scopes it away from the IEEE 1584:2018 / NBR 17227 regime handled by the sibling calcular_energia_incidente. An agent can pick this tool over that sibling from the description alone.

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?

Gives explicit when-to-use (>15 kV, outside IEEE 1584), when-not ('É TRIAGEM, NÃO laudo', IEEE 1584 algorithm not used, gap/electrode config not applicable) and a per-method routing table for osha/lee/epri including the parameters each requires. That is a full decision procedure.

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

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

Annotations only declare readOnlyHint=true, so the description carries real weight and delivers: it discloses the derating behavior (Q∝V²), the overcorrection alert triggered by carga_min_pct, the short-circuit/inrush design current (1,5·In per IEEE C37.012), and that the call is free. It stops short of describing the full output shape (e.g. required kvar), so a 4 rather than 5.

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 core purpose and meta, then one clause per optional parameter. Dense but every sentence carries engineering meaning; the capitalization and backticked parameter names aid scanning, though the paragraph is long for a single block.

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 8 parameters, 0% schema coverage and no output schema, the description supplies the missing semantics for the non-obvious inputs and indicates what extra results (nominal current, standard, overcorrection alert) appear under certain inputs. Remaining gap is the exact shape of the primary result (capacitor bank kvar).

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 must compensate and largely does: it explains tensao_kV, Un_cap_kV, carga_min_pct, scc_MVA and the fp_meta default in domain terms. potencia_kW, fp_atual and api_key are left implicit, but their meaning is evident from the names.

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?

States a specific verb and resource ('Dimensiona o banco de capacitores para corrigir o fator de potência'), the target regulation (REN ANEEL nº 1.000) and the default meta (0,92). Distinct from siblings like dessintonia_capacitor, which sizes a detuning reactor rather than the correction bank itself.

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?

Gives clear conditional guidance for optional parameters ('Com tensao_kV também dá a corrente nominal', 'informe para não superestimar'), effectively telling the agent when each input matters. It doesn't explicitly compare against sibling tools or state when-not to use it, keeping it short of a 5.

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

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

Annotations only declare readOnlyHint=true, and the description adds real context beyond that: the governing standards, the free-tier usage limitation ('Gratuito (uso limitado)'), and the multipliers applied when `ligacao` references the other winding. It does not say anything about the shape or units of the returned curve.

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 purpose and standard come first, then parameter notes, then the ligação factors and the cost note — a sensible front-loaded order with little filler. The ligação multiplier sentence is terse to the point of being cryptic, but it earns its space.

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 10-parameter engineering calculation with no output schema and minimal annotations, the definition covers the domain and several inputs but omits the units/meaning of the required nameplate values and any indication of what the curve returns. An agent could call it but would likely need a retry to get the required inputs right.

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 coverage is 0%, so the description must carry the load; it does well on the enum-like inputs (fases, frequencia_falta, tipo, ligacao with explicit ×0.58/×0.87/×1.0 factors) and t_inrush_ms. However, the three required parameters Sn_kVA, Vn_kV and Vcc_pct are never explained, and k_inrush and api_key are undocumented, leaving half the inputs to inference.

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?

States a specific deliverable: the transformer through-fault damage curve per IEEE C57.109/C57.12.59, listing the points produced (ANSI point, inrush point, max through-fault current). An agent can distinguish it from k_factor_transformador or tempo_de_atuacao by the referenced standard and the damage-curve output. It stops short of naming which sibling it replaces for coordination studies.

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 phrase 'para coordenar a proteção a montante' implies the coordination-study context, and the `ligacao` explanation gives the reason to reference the other side. There is no explicit when-not guidance and no named alternative (e.g. versus k_factor_transformador or tempo_de_atuacao), so usage must still be inferred.

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

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

Annotations declare only readOnlyHint. The description adds rich behavior: the detuning thresholds (p >= 5.67% detuned, 4-5.67% tuned near the 5th, <4% above the 5th), the 1.10·Un continuous check, the >24 kV fallback where no class is suggested, and parallel-resonance evaluation with scc_MVA.

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?

Dense but front-loaded: it states what it computes, then the either/or input, then the outputs, then edge-case rules. Every sentence carries technical content; the only cost is a slightly run-on middle section.

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?

No output schema exists, but the description enumerates the returned quantities (elevated capacitor voltage V/(1−p), reactor current, effective reactive Q/(1−p), tuning frequency, IEC 60831 voltage class), so an agent knows what comes back. Required params Q_kvar and tensao_kV are the remaining gap.

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?

With 0% schema description coverage, the description must carry parameter meaning, and it explains p_pct (XL/XC factor, e.g. 7 or 14), the L_mH alternative, Un_cap_kV, and scc_MVA's role. It leaves Q_kvar, tensao_kV, and api_key unexplained, so coverage is strong but not complete.

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?

Opens with a precise verb+resource: it sizes a detuned bank or tuned filter (series reactor with capacitor), which is clearly distinct from siblings like corrigir_fator_potencia. It does not name an alternative sibling, but the technical scope is unmistakable.

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?

Gives useful invocation guidance ('Informe p_pct ... OU L_mH'), and conditional behavior for Un_cap_kV above 24 kV and scc_MVA. However, it never says when to choose this tool over alternatives like corrigir_fator_potencia, so usage is implied rather than framed against siblings.

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

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.

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

With readOnlyHint=true already covering the safety profile, the description goes far beyond annotations: it explains the asymmetric-fault saturation criterion, the real burden basis, what happens when Rct_ohm is None (estimation plus disclosure of the formula), and precisely what the IEEE PSRC simulation returns (instant of saturation, minimum fundamental ratio, pickup delay). It even discloses the free/limited-use constraint – rich behavioral context.

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 core purpose, then organized by parameter families and by operating mode. Given 20 parameters and zero schema descriptions, the length is justified and no sentence is filler. Readability is dented by dense jargon and a single unbroken block, but nothing is wasted.

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, and the description compensates by naming what the evaluation mode returns (tensão de saturação, ALF efetivo, margem, Ks, tempo até saturação) and what the time simulation returns. The main omission is authentication/api_key behavior and a fuller definition of the four required electrical inputs, but overall an agent could call this correctly.

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% across 20 parameters, so the description must carry the load, and it mostly does: xr, I_load_A+Fter, Ith_A/Idyn_A, t_curto_s/tth_s, Rct_ohm, primario_A, primario_pleno_A, ALF/burden_VA, classe_abnt, pickup_sec_A and remanencia_pct all get meaning and units. Gaps remain for required parameters such as secundario_A, Icc_A, relay_ohm and cable_ohm (only indirectly implied by 'burden REAL (relé+fiação)'), and api_key is never mentioned.

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?

Opens with a precise verb+resource: 'Dimensiona o TC de proteção (IEC 61869-2 / NBR 6856)'. It states the exact engineering objective (menor primário comercial que não satura na falta) and leaves no ambiguity about what the tool returns. No sibling tool covers CT sizing, so differentiation is implicit but the scope is unmistakable.

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?

Gives clear mode selection rules: 'AVALIAR O TC INSTALADO' when primario_A is supplied, versus searching for the smallest adequate ratio otherwise; and simulation mode requires primario_A plus xr. It also states the class can be given either as ALF+burden_VA or classe_abnt. It never names a sibling alternative, which is the only missing piece.

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

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

Annotations include readOnlyHint: true, and the description is consistent, describing a read-only calculation. It adds behavioral context: the tool is free but limited use (Gratuito (uso limitado)), and it explains how face exposure affects heating. No contradiction with 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 a dense paragraph that efficiently packs purpose and parameter guidance. It uses backticks for parameter names and lists allowed values. While mostly concise, it could be better organized (e.g., bullet points) and is slightly long but justified given parameter count.

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 has 15 parameters and no output schema. The description explains the calculation purpose and many parameters, but it does not describe the return value (e.g., temperature rise, pass/fail). This omission leaves the agent unsure of what the tool returns, lacking complete contextual information.

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?

With 0% schema description coverage, the description compensates well by explaining many parameters: perda_W, dimensions, face options, regime (BT/MT), tipo_instalacao, limite_equip_C, temp_ambiente_C, etc. However, it does not explain 'ventilado', 'n_particoes', or 'api_key', leaving some gaps.

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 it calculates the internal air temperature rise of a low-voltage panel per IEC 60890 and checks acceptance per IEC 61439-1. It specifies the main parameter (perda_W) and dimensions, distinguishing it from sibling tools like calcular_curto_circuito or dimensionar_cabo, which handle different electrical calculations.

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 on when to use: for temperature rise calculation in BT panels. It explains face exposure options (e.g., coberta means against wall, heats more) and installation type range 1–5, guiding parameter selection. However, it does not explicitly state when not to use this tool or mention specific alternatives, though siblings are distinct.

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

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

The annotations declare readOnlyHint=true, yet the description says a document is 'prepared in your account' and a label is issued, which reads as server-side state creation rather than a pure read. The valuable disclosure is that the tool never emits anything autonomously and requires human signature, but this creates a direct tension with the read-only annotation instead of resolving it.

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?

Two short sentences with the artifact and the critical non-autonomy constraint front-loaded; no filler. Slightly harmed by the awkward line breaks and the missing explicit verb at the start.

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 no output schema, the description should say what the agent receives back (a document link, an ID, a status) — it does not. It also leaves the only required parameter unexplained, so an agent would have to guess how to construct a valid call.

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 must carry the weight, and it does not. It never explains what referencia_calculo refers to (presumably a handle to a prior calculation on the platform) nor what api_key is for or whether it is optional despite the null default.

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?

States the concrete output: a signable memorial document plus an ANSI/NBR label, which clearly differentiates it from the calculation-only siblings (dimensionar_cabo, calcular_curto_circuito, etc.). The verb is inherited from the tool name rather than restated, but the resource and artifact are specific enough for an agent to identify it.

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 second sentence gives real context: the document is prepared in the user's platform account for review and signature by the technical responsible, implying this is the closing/documentation step after a calculation. It does not name a sibling alternative or state prerequisites (e.g., that a referencia_calculo from a prior calculation is needed), so it stops short of full routing guidance.

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

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

readOnlyHint=true already covers the safety profile, so the description's added value is the quota note ("Gratuito (uso limitado)") and the hard validation rule that dv_limite_pct is required for G4, both of which are behavioral facts not in the annotations. It stops short of describing what the response contains (dip magnitude vs. class limit comparison).

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?

Dense but economical: the method/source is front-loaded, then branch conditions, then parameter notes, then the quota line — no filler sentences. Some entries are terse to the point of opacity ("`XR` = X/R da X'd (ângulo da queda)"), a small cost against its compactness.

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 15-parameter calculation tool with no output schema, the description should say what comes back (ΔV result, pass/fail against the class limit) and sketch the class-limit semantics it references. It names them but leaves both the return shape and the ISO class limits implicit, so an agent can call it but cannot fully predict the result.

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 must carry parameter meaning, and it does explain the hard ones well: `modo` and which params each branch needs, `XR`, the `cabo_mm2`+`cabo_m` pairing, `dv_limite_pct`, and `motor_fp_rotor_bloqueado`. However, roughly half the 15 parameters (xd_pct, degrau_kVA units, motor_Ip_In, tensao_V/Sn_kVA base, api_key) remain undocumented in both schema and description.

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?

States a precise verb+resource: computes the transient voltage dip from a load step on a genset per ISO 8528-5 (voltage step), via X'd. The technical scope is unambiguous, but it never names or contrasts with the nearest sibling (partida_motor / tempo_partida_motor), which also deals with motor starting and could be confused with the `modo=motor` branch here.

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 does clarify the internal branch selection: `modo` ∈ {bloco (degrau_kVA+degrau_fp), motor (motor_kW, DOL)}, and flags `dv_limite_pct` as mandatory for classe_iso="G4". That is useful conditional guidance, but nothing says when to pick this tool over the sibling motor-starting tools — the choice is only implied.

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

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

Annotations include readOnlyHint=true, and the description adds that it is free ('Gratuito'), the input format, and the outputs. No contradictions. It provides useful behavioral context beyond the 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 very concise: one sentence with an example input. It is front-loaded with the purpose and outputs, with no wasted words.

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 has one required parameter (object) and no output schema, but the description lists all outputs. It is mostly complete, though it could mention that api_key is optional. Overall adequate for a calculation tool.

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 coverage is 0% with no parameter descriptions. The description partially compensates by exemplifying the 'espectro_harmonico' parameter format, but does not explain the 'api_key' parameter. Adds some meaning but not comprehensive.

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 specifically states the tool calculates K-factor, K-rating, F_HL, and THD from a harmonic spectrum input, with an example of the input format. It clearly distinguishes itself from sibling tools which cover other electrical calculations.

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 implicitly indicates use for transformer K-factor assessment but does not provide explicit guidance on when to use this tool versus alternatives, nor any exclusions.

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

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

Annotations already declare readOnlyHint=true, but the description adds real behavioral context: the default result set is restricted to MCCB/ACB with electronic trip and real In_A, and it discloses a cost/limit trait ('Gratuito (uso limitado)'). It does not describe pagination or return shape, but the added filtering semantics and rate-limit note go well beyond the annotation.

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 primary purpose, then layers parameter behavior in a dense but efficient passage with no filler sentences. Slightly packed, but every clause adds information.

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 3-param, zero-schema-coverage, no-output-schema listing tool, the description covers default behavior, filtering semantics, and its role in the tempo_de_atuacao workflow. The unstipulated `api_key` and unmentioned return structure are the only remaining gaps, and a list result needs little return explanation.

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 coverage is 0%, so the description carries the burden and largely does: `tipo` is documented with its valid values ('MCCB','ACB','Relay','MCB','Fuse','Transformer') and the nuance that it surfaces a type even outside catalog mode, and `todos=True` is explained as including all types. Only `api_key` is left undescribed, keeping it from a 5.

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?

States a specific verb+resource ('Lista o catálogo de dispositivos') and goes further by naming the downstream goal (discovering `device_id` for tempo_de_atuacao catalog mode). An agent can immediately distinguish this from computation-heavy siblings like calcular_curto_circuito.

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?

Clearly frames when to reach for it: to obtain a `device_id` consumed by tempo_de_atuacao's catalog mode, and it names that sibling explicitly. It lacks an explicit 'when not to use' or a contrast with other listing tools (e.g., listar_ferramentas), so it stays just short of a 5.

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

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

Annotations already declare readOnlyHint=true, and the description adds that it lists 'tier' of each tool. This is useful but does not provide extensive behavioral context beyond the 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 a single, concise sentence that is efficiently structured and front-loaded with the key verb and resource.

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 the basic purpose, it lacks details about the format of the list or what 'tier' means. Given the many sibling tools, a bit more completeness would help.

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?

With zero parameters and 100% schema coverage, the description adds meaning by specifying what is listed ('shelf' and 'tier'), which aids understanding of the tool's output.

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 it lists the 'shelf' of electrical engineering calculations and their tier, which is a specific verb and resource. It distinguishes from sibling tools which are individual calculations.

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 implies usage for browsing available tools but does not explicitly state when to use this tool versus alternatives. No exclusions or contexts are provided.

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

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

Annotations only declare readOnlyHint=true; the description adds substantial context beyond that: error taxonomy ('erro de FORMA' vs 'erro de FÍSICA' returning {"erro": ...}, nothing computed 'pela metade'), assumption disclosures (neutro sólido assumed if Rn_ohm absent, x0_pu default 0.06 with a warning), refusal cases, and cost ('Gratuito (uso limitado)').

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?

Section dividers and front-loaded purpose make a very long description navigable, and nearly every clause carries real semantics. It is nonetheless close to the ceiling of practical length, and the optional `lang` / `api_key` params get no mention at all, so a small amount of space goes unused.

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 no output schema, the description still names key response fields (projeto_json, operacoes, geradores with K_G/Z_GK, fonte_minima_declarada_kA, estudo) and the delivery instruction for the .json file. It stops short of describing the full Ik result structure per bar, which is the only remaining gap for a tool of this complexity.

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 all 9 params are untyped objects, so the description must carry the full burden — and it does, documenting field-by-field semantics for barras, elementos (transformer/cable/reactor), fonte, motores, geradores, cenarios and estudo. It even explains derived behaviour (k0_r/k0_x defaults, isolacao deciding NBR 5410 end-of-short-circuit temperature).

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?

States a specific verb+resource at a specific scope: 'Monta uma REDE MULTIBARRA ... e calcula o curto-circuito IEC 60909 em TODAS as barras de uma vez', and explicitly contrasts with the sibling 'calcular_curto_circuito (que é de UM ponto)'. An agent can distinguish the two without opening either schema.

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?

Gives an explicit trigger ('quando o usuário tem os dados de VÁRIOS equipamentos ... folha de dados, carta da concessionária ou memorial antigo') and names the alternative it replaces. Adds when-not/exclusion guidance ('isolado' é RECUSADO aqui) and a workflow requirement (conferência humana antes de laudo).

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

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

Annotations only declare readOnlyHint=true, and the description adds real behavioral context: conditional parameter requirements per fonte_tipo, the severity of dedicated transformer/GMG sources, the acceleration-gating role of C_load_pu, and the 'Gratuito (uso limitado)' licensing/usage limit. It does not describe the response, but that is a minor omission for a read-only calculator.

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 core model is front-loaded, and every clause is information-dense—enum expansions are necessary because the schema has no descriptions. It is a dense block rather than clearly sectioned prose, but there is little wasted text.

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 21-parameter, no-output-schema tool, the description covers the most complex parameter families well but omits several input meanings (cable, current, voltage-limit) and says nothing about the result. Adequate for the source/method mechanics, incomplete overall.

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. It does well on the hard cases—fonte_tipo's three modes and their associated fields (scc_MVA, trafo kVA/Vcc, gmg kVA/X'd), the six metodo values with aliases, fp_partida, Cp_Cn and C_load_pu—but leaves fp, eta, In_A, Ip_In, cabo_m, cabo_mm2 and dv_limite_pct undocumented, which are non-obvious and matter for the calculation.

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 states a specific physical calculation: voltage dip at motor start via a source→cable→motor phasor divider with C ∝ V². It is clearly more than a restatement of the name, though it never explicitly distinguishes itself from the adjacent sibling tempo_partida_motor or dimensionar_cabo.

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 explains which inputs belong to each fonte_tipo mode and flags dedicated transformer and GMG as the severe cases, plus the condition that acceleration is not evaluated without C_load_pu. However, it gives no explicit when-to-use-this-vs-an-alternative routing, e.g. against tempo_partida_motor, so usage is only implied.

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

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

With readOnlyHint=true already covering the safety profile, the description adds useful behavioral context: it states the calculation domain, notes that SWBP is zero when there are no curves, and gives the 500 kgf cap for malha attachment. It also says the tool is free but limited in use, though it does not detail rate limits or authentication despite the api_key parameter.

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 dense but front-loads the tool purpose and computed outputs before moving into parameter-specific notes. It is appropriately sized for a 16-parameter calculation tool, though the semicolon-heavy style makes it slightly harder to scan.

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 complex 16-parameter calculation tool with no output schema, the description names the main result categories and explains some key parameters. Still, it leaves many required inputs without description and does not explain the expected response structure or calculation assumptions in enough detail for full completeness.

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 must carry parameter meaning. It does explain several non-obvious parameters and enums, including n_cabos ∈ {1,3}, curvas_graus, curva_raio_m, attachment values, convencao, and swbp_classe/cabo_classe ranges. However, many parameters remain undocumented, including mu, material, incl_graus, api_key, and several required dimensional inputs.

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 a cable-pulling traction calculation under IEEE 1185/525 and lists the computed quantities: winch tension, SWBP, duct occupancy per NBR 5410, and maximum admissible tension. It is specific enough to separate this from sizing tools like dimensionar_cabo, but it does not explicitly name or contrast any sibling tool.

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 no explicit guidance on when to use this tool versus alternatives, nor when not to use it. The domain context implies it is for cable-pulling calculations, but the agent must infer that from the title and description rather than from stated usage rules.

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

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 genuinely useful non-obvious behavior: it does not consume the calculator quota and works even after the free daily usage is exhausted, plus the response channel is e-mail rather than an in-chat result. However it says nothing about response latency, whether a ticket/reference is returned, or what happens on invalid e-mail, so with annotations carrying the safety signal a 3 is fair.

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?

Four tight sentences, front-loaded with the action and the deliverable, then the required inputs, then the response channel and quota caveat. No filler or repetition.

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, and the description only partly fills that gap by saying the reply arrives via e-mail; it does not describe what the tool call itself returns (confirmation, protocol number, error). Combined with 5 parameters at 0% schema coverage, meaningful gaps remain, but the core behavioral facts an agent needs are present.

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% (bare titles only), so the description carries the burden; it explains the two most important inputs – e-mail (required contact) and escopo (with concrete examples: number of panels, voltage class, deadline, city). It says nothing about nome, empresa, or the api_key parameter, which an agent could easily supply wrongly or omit.

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?

States a specific verb and resource: forwards a request for a priced quote (orçamento) for an ART-signed study/report, and enumerates the covered study types (arc flash, short-circuit, selectivity, NR-10). It is clearly set apart from the calcular_* siblings as a commercial request rather than a calculation, though it never names an alternative tool explicitly.

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?

Gives concrete invocation guidance: supply the contact e-mail and the scope (panels, voltage class, deadline, city), and the team replies by e-mail. It also states when it is especially worth using – when the daily free calculator quota is exhausted – but offers no explicit 'do not use for X' exclusions.

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

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

Annotations only declare readOnlyHint=true, and the description is consistent with a pure computation while adding substantial context beyond it: the tolerance-band policy (fabricante/informada/nenhuma), how the instantânea moves to the upper band edge, that the reduced arc current falls on the thermal curve, and that tms maps to t1/tR in seconds for IEC 60947-2 I²t trip units. It also reveals default behavior (0,10 if tms omitted; only the inverse curve operates without 50 parameters) and that the call is 'Gratuito (uso limitado)'. It stops short of stating failure/error behavior or the full response shape, which keeps it at 4.

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 purpose and the workflow chain before any detail, and the mode-specific sections (MANUAL / CATÁLOGO / CURVA TÉRMICA TABELADA) are visually separated so an agent can jump to the relevant branch. It is dense and long — several clauses are packed per line — but for 13 parameters with zero schema documentation almost every sentence removes ambiguity, so the length is mostly earned.

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?

Given 13 parameters, no schema descriptions, and no output schema, the definition covers the mode-selection logic, defaults, unit traps (tms as t1/tR in seconds), and even names key response fields (banda, curva, curva_informada, curva_tabelada, tempo_s consumed as t_arc_s). Remaining gaps are the complete return payload and error/validation behavior, which matter somewhat more here precisely because there is no output schema.

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?

With 0% schema description coverage across 13 parameters, the description carries the entire burden and does so for nearly all of them: pickup_A (RTC×tap / Ir), curva with the full alias table (NI/SI, VI, EI, LTI, UI, DT/DTL, ANSI MI/VI/EI), tms semantics and default, instantaneo_A/t_disjuntor_ms, curto_tempo_A/t_curto_tempo_ms, device_id, curva_pontos format ([múltiplo, t_s] pairs, log-log interpolation) and obligatory curva_base ('Ir'/'In'), plus tolerancia_pct with the IEC 60947-2 ±20% reference. Only api_key and corrente_falta_A go unexplained, and the latter is self-evident as the required input; that small residual keeps it from a 5.

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 ('tempo de atuação de um dispositivo de proteção à corrente de falta') and pins the exact standards plus the 4-segment curve composition (51/50 curto-tempo/50 instantânea). It positions itself against siblings explicitly by naming the chain calcular_curto_circuito → tempo_de_atuacao → calcular_energia_incidente, so an agent can place it in the workflow without opening other schemas.

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?

Gives explicit alternatives and preconditions: use MANUAL mode with pickup_A/curva for relays, CATÁLOGO mode with device_id from listar_dispositivos for MCCB/ACB, and CURVA TÉRMICA TABELADA with curva_pontos for thermomagnetic devices whose thermal curve is not IEC/IEEE. It also states a hard exclusion ('Códigos de fabricante (como U1–U5 e C1–C5) NÃO são aceitos') and a data-entry rule ('Nunca leia pontos de um GRÁFICO: só de tabela'), which is exactly the kind of negative guidance agents need.

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

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

The description discloses the simulation method (RK4, J·dω/dt) and outputs (acceleration time, start/stall verdict, thermal rotor blocked verdict). The 'readOnlyHint' annotation is consistent with a simulation tool. However, limitations, assumptions (e.g., motor model), and output format are not detailed, which leaves gaps.

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 a single paragraph that starts with the main purpose and then lists some parameters. It is relatively concise but could be more structured (e.g., bullet points). The inclusion of 'Gratuito' adds no functional value and slightly detracts from conciseness.

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?

Given 17 parameters, no output schema, and the complexity of a motor start simulation, the description only partially covers expected outputs (three items) and omits many parameter details. Assumptions and typical use cases are not mentioned, leaving the tool underspecified.

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?

With 0% schema description coverage, the description explains 6 of 17 parameters: polos, inercia_kgm2, tipo_carga, conjugado_partida_carga_pu, conjugado_pleno_pu, and t_rotor_bloqueado_s. It provides meanings and allowed values for tipo_carga. However, key parameters like potencia_kW, tensao_V, scc_MVA, etc., are not described, making the description incomplete.

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 it simulates direct-on-line motor starting, computes acceleration time, determines if the motor starts or stalls, and evaluates thermal protection. The verb 'simula' and resource 'partida DIRETA no tempo' provide a specific purpose. However, it does not explicitly distinguish from the sibling tool 'partida_motor', missing some clarity.

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 no guidance on when to use this tool versus alternatives like 'partida_motor', nor does it specify prerequisites or exclusions. The context implies the tool is for direct-start simulation, but this is not stated explicitly.

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

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

Annotations already declare readOnlyHint=true, and the description adds genuinely new behavioral context: it discloses the free/limited-usage quota ("Gratuito (uso limitado)") and warns that omitting R_montante_ohm/X_montante_ohm yields an OTIMISTA (unsafe) verdict. That safety-critical caveat is exactly the kind of disclosure annotations cannot carry. It does not describe the response shape beyond the word "veredito".

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?

Extremely dense but zero waste: purpose and standard clause first, then the TN/TT formulas, then the parameters that alter the verdict, then the quota note. Parenthetical input hints are embedded inline rather than bulked into separate sentences.

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 17-parameter engineering calculation with no output schema and no schema descriptions, the description covers the decision-critical inputs but omits several that feed the Zs computation (comprimento_m, secao_fase_mm2, material, T_op) and never states what the result contains beyond a pass/fail "veredito". Adequate to call correctly in the common case, incomplete at the edges.

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% across 17 parameters, so the description must compensate and largely does: it explains Ia_A vs disjuntor_In_A/curva_mcb, i_dn_mA, RA_ohm, situacao (1 = dry/50 V vs 2 = wet/25 V with stricter Tab. 25 time), circuito_tipo's two enum values, secao_pe_mm2 (None → Tab. 58 minimum), and the montante impedance pair. It leaves T_op, material, secao_fase_mm2, comprimento_m, sistema and api_key undefined, which for a Zs calculation are non-trivial omissions.

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?

States a specific verb and resource with the governing standard clause: verifies shock protection by automatic disconnection per ABNT NBR 5410:2004 §5.1.2.2. It even names the two calculation regimes (TN: Zs ≤ U0/Ia; TT: RA ≤ 50/IΔn), so an agent knows exactly what computation is being performed and can distinguish it from siblings like calcular_curto_circuito or tempo_de_atuacao.

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?

Gives explicit input routing: for TN supply either Ia_A OR disjuntor_In_A + curva_mcb, for TT supply i_dn_mA + RA_ohm. This tells the agent which parameter path to take per system type, which is the main invocation decision. It stops short of naming when to prefer this tool over a sibling or what preconditions must already hold.

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