Arc Flash Platform — Estudos Elétricos

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

Annotations declare readOnlyHint=true, which is consistent with a calculation tool. The description adds that it uses the IEC 60909 standard and includes transformer behavior, but does not detail computational complexity or accuracy. This adds moderate value beyond 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 brief and to the point, using a single sentence plus a code-like hint for the transformer option. No wasted words, though a more structured format could help clarity for non-experts.

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 the complexity (7 parameters, no output schema), the description partially covers the output by listing Icc types, X/R, and peak. However, it lacks explanation of required parameters, units, and valid ranges. The output is implied but not fully described.

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. It explains the effect of `com_transformador=True` and mentions the transformer-related parameters (trafo_*), but does not describe other parameters like tensao_kv or potencia_curto_mva beyond their names. Partial but not sufficient coverage.

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 short-circuit currents (Icc 3φ/2φ/fase-terra), X/R ratio, and peak current, following IEC 60909. It distinguishes itself from sibling tools like calcular_energia_incidente or dimensionar_cabo by specifying the exact electrical calculation.

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. It only describes the calculation function without any context about prerequisites, constraints, or preferred scenarios.

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 read-only hint is consistent with a calculation tool. The description adds that the motor is validated and usage is limited, providing helpful context beyond the annotation. No contradictions.

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 (3 sentences) and front-loads the core output. However, it mixes technical details in a single block; a structured list would improve scannability.

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 description mentions outputs (Ei, LAS, PPE category) which is good given no output schema. However, it lacks parameter explanations and does not cover how the input parameters interplay, which is necessary for correct invocation. Completeness is adequate but not thorough.

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%, meaning no property descriptions exist. The description only mentions config options and t_arc_s's importance, but fails to explain the other five required parameters (tensao_kv, ibf_ka, gap_mm, dist_trabalho_mm). This is inadequate for a tool with 7 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 explicitly states the tool calculates incident energy (Ei), arc flash boundary (LAS), and PPE category per IEEE 1584:2018/NBR 17227:2025, including voltage range and config options. This distinguishes it clearly from sibling tools 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?

The description notes that elimination time (t_arc_s) is critical and that the tool is free with limited use, but it does not specify when to use this tool versus alternatives such as calcular_curto_circuito or other arc flash tools. No explicit when-to-use or when-not-to-use 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?

Beyond the readOnlyHint annotation (which is appropriate for a calculation tool), the description adds behavioral details: it states the tool is free (limited use), and that providing 'tensao_kV' yields additional outputs (nominal current and applicable IEC standard). This adds value beyond what annotations provide.

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—two sentences front-loading the core purpose, with no redundant information. Every sentence contributes meaningful content.

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 the lack of an output schema and the 5 parameters with poor documentation, the description should provide more details on return values, prerequisites, and error handling. It only partially explains extra outputs with voltage and mentions limited usage, leaving significant gaps for the agent.

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 0% description coverage, and the description only mentions three of five parameters: 'potencia_kW' and 'fp_atual' (implied as required), and 'tensao_kV' (optional). It fails to explain 'api_key' and 'fp_meta' (though it notes the default for fp_meta). This is insufficient compensation for the missing schema descriptions.

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 purpose: sizing capacitor banks for power factor correction to a target (0.92 by default, per REN ANEEL No. 1.000). It uses specific verbs ('dimensiona') and resources ('banco de capacitores', 'fator de potência'), and is distinct from sibling tools (e.g., 'calcular_curto_circuito') which cover 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 implies usage for power factor correction design with a default target, but it does not explicitly specify when to use this tool versus alternatives (e.g., other engineering tools). It mentions a free tier with limited use, which provides some context, but no exclusions or when-not-to-use 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?

Annotations already declare readOnlyHint=true, and the description adds specific behavioral details: it produces a curve with category, current, ANSI point, and inrush point, and is a read-only computation. No contradictions. The extra context justifies a score above baseline.

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?

Description is concise (two sentences), front-loaded with standards and purpose, and lists parameter options inline. It earns its length but could be more structured with bullet points or parameter table for clarity.

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?

Tool has 8 parameters, no output schema, and moderate complexity. Description outlines output components but lacks parameter meaning, units, or examples. While siblings suggest domain familiarity, an agent would benefit from more context to correctly invoke this 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 has 0% description coverage, so description must compensate. It only documents allowed values for fases, frequencia_falta, and tipo, but does not explain required parameters (Sn_kVA, Vn_kV, Vcc_pct) or others (k_inrush, api_key). This is insufficient for an 8-parameter tool.

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?

Description clearly states the tool computes a transformer damage curve per IEEE C57.109/C57.12.59, listing specific outputs (category, maximum through-fault current, ANSI point, inrush point) and its purpose (coordinate upstream protection). This verb+resource combination uniquely identifies the tool among siblings.

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?

Description mentions the tool is used for coordinating upstream protection and specifies allowed values for three parameters, but does not explicitly state when to use this tool versus alternatives like calcular_curto_circuito. The context is implied but lacks exclusion 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?

The description discloses that the tool is free with limited use, which is behavioral context beyond the readOnlyHint annotation. No contradiction with annotations; the tool is indeed a computation and does not modify data.

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 fairly concise and front-loaded with the primary purpose. However, it includes a lot of inline parameter definitions that could be structured more clearly. Still, every sentence earns its place.

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 the tool has 12 parameters and no output schema, the description adequately covers input meaning but fails to describe the output format or return value. For a complex tool, this gap reduces 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?

Despite 0% schema description coverage, the description explains the meaning and allowed values for key parameters like sistema, metodo, material, isolacao, and icc_quadro_kA. This significantly adds value beyond the schema. However, not all parameters (e.g., fp, api_key) are explained.

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 dimensions a BT cable according to ABNT NBR 5410, listing specific aspects like ampacity, voltage drop, and overload coordination. This is a specific verb+resource combination that distinguishes it from sibling tools 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?

The description implies use for cable sizing but does not explicitly state when to use this tool vs. alternatives. No exclusions or comparisons with sibling tools are provided, leaving the agent to infer usage context.

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, which is consistent with the description's indication of a calculation (dimensioning). The description adds that the tool finds the smallest non-saturating primary, but does not elaborate on other behavioral traits such as side effects or required permissions. Given the annotations already cover the read-only nature, the description provides adequate but not exceptional transparency.

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 sentence of about 20 words, efficiently conveying the tool's purpose and key constraints. It is front-loaded and free of unnecessary 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?

Given the tool has 7 parameters (none described in schema), no output schema, and a moderately complex domain (CT dimensioning), the description is too brief. It does not explain the return value ('Plano completo' is vague), nor does it cover all inputs or the expected output format. Additional detail would be needed for correct use.

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 should compensate by explaining parameters. However, it only vaguely mentions 'burden REAL (relé+fiação)' and 'ALF efetivo', which correspond to some inputs (burden_VA, relay_ohm, cable_ohm, ALF) but does not detail each parameter individually. The meaning of Icc_A, secundario_A, and api_key are left entirely implicit.

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 'dimensiona o TC de proteção' and specifies the goal: finding the smallest commercial primary that does not saturate under fault, considering real burden and effective ALF. This is a specific verb-resource pair and differentiates from sibling tools like 'calcular_curto_circuito' 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?

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or situations where it should not be used. The user must infer usage from the domain context.

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 show readOnlyHint=true, so the description's mention of 'verificação de aceitação' adds context that it's a calculation. However, it does not disclose side effects, required permissions, or limits beyond what annotations imply.

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 concise: two sentences plus a clarifying line. Front-loaded with standard references and key parameter explanation. No redundant 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?

Given 9 parameters, 0% schema coverage, and no output schema, the description fails to fully document parameter meanings or return value. 'Plano completo' hints at output but lacks detail. Incomplete 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?

With 0% schema description coverage, the description explains `perda_W` as 'perdas dissipadas no invólucro' and notes dimensions in meters, but leaves 5 other parameters (e.g., ventilado, n_particoes) undocumented in both schema and description. Partial compensation.

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 calculates the internal air temperature rise of a low-voltage panel per IEC 60890 and acceptance check per 61439-1. It distinguishes from sibling tools (e.g., short-circuit, cable sizing) by focusing specifically on panel temperature.

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?

No explicit guidance on when to use this tool vs alternatives. While the name implies its domain, there are no preconditions, exclusions, or hints about when not to use it (e.g., if other panel calculations exist).

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 adds context beyond annotations: it explains the document is prepared for review and signature, and is never autonomous. Annotations already declare readOnlyHint=true, so the description confirms the read-only nature and adds workflow 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?

The description is a single sentence with a dash, which is concise and front-loaded with the purpose. However, it could break into two sentences for clarity. Overall, 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 no output schema and the description does not indicate what the tool returns. The meaning of 'referencia_calculo' is ambiguous. Given the complexity (generating a document), more details on input and output are needed for complete understanding.

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 does not explain the parameters, especially 'referencia_calculo' which is required. Without clarification on what value to pass (e.g., a calculation ID), the agent may be unable to use the tool correctly.

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 generates a signable memorial with ANSI/NBR label, and the title reinforces it is a calculation memorial/report. This distinguishes it from sibling calculation tools 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?

Explicitly states 'NUNCA é emitido autonomamente por IA' (NEVER issued autonomously by AI), providing a strong when-not-to-use guideline. It clarifies the tool prepares a draft for human review, not a final output, making usage boundaries clear.

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 readOnlyHint=true, which the description does not contradict. The description adds context about the standard and method (X'd), but does not disclose additional behavioral traits like return values or limitations.

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, fitting in two lines. It front-loads the core function and mode information, though it could be better structured with separations.

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 10 parameters, 2 required, no output schema, and no parameter descriptions, the description is incomplete. It lacks details about what the tool returns, how to configure parameters, and the scope of the simulation.

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 compensate but only mentions 'modo', 'degrau_kVA+degrau_fp', and 'motor_kW+partida DOL'. Most parameters (tensao_V, Sn_kVA, xd_pct, etc.) are unexplained, leaving the agent to infer meaning from names alone.

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 calculates transient voltage dip for a generator under load step per ISO 8528-5, and specifies two operational modes (block and motor). It is distinct from siblings like calcular_curto_circuito, but could be more explicit about the verb (e.g., 'Calcula').

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 generator load step analysis and gives mode options, but does not explicitly state when to use this tool versus alternatives or provide prerequisites. Usage is derived from context.

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 description adds little beyond that. It mentions listing 'a prateleira' and 'tier', but no additional behavioral traits (e.g., no side effects, no rate limits). With annotations covering safety, this is adequate.

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?

Single sentence, front-loaded with the verb 'Lista'. Every word is functional with no redundancy. Highly concise and well-structured.

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 description is complete enough for this simple tool: it explains the output (list of calculations and tiers). However, it lacks detail on the return format or what 'tier' means. Given no output schema, slightly more context would be beneficial, but still sufficient.

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?

No parameters exist, so schema coverage is 100%. The description adds meaning by specifying what is listed (engineering calculations and tiers), going beyond the empty schema. Baseline 4 is justified for a zero-parameter tool.

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 lists a 'prateleira de cálculos de engenharia elétrica' (shelf of electrical engineering calculations) and their tiers. It is specific about the resource and action, but does not define what 'tier' means, which could cause slight 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?

No explicit guidance on when to use this tool versus alternatives. However, as a catalog tool, usage is implicitly obvious: when an agent needs to discover available tools. No exclusions or context 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 already declare readOnlyHint=true, and the description describes it as a calculation (voltage dip), which is consistent. No additional behavioral traits are disclosed (e.g., what output format is returned, if any side effects).

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, with only two sentences. It front-loads the core purpose and key parameters. However, it could be slightly more informative without being verbose.

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 the complexity (10 parameters, no output schema), the description is insufficient. It does not explain all parameters, nor does it describe the output. 'Plano completo' is vague. More detail is needed for an AI agent to correctly invoke the 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?

With 0% schema description coverage, the description only clarifies 'metodo' (listing possible values) and 'scc_MVA' (source short-circuit level). The other 8 parameters (potencia_kW, tensao_V, fp, eta, Ip_In, cabo_m, cabo_mm2, api_key) are not explained, leaving significant ambiguity.

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?

Description clearly states that the tool computes voltage dip during motor starting using a phasor divider model. It mentions the formula and lists possible starting methods, distinguishing it from sibling tools that handle 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?

No explicit when-to-use or when-not-to-use guidance. However, the sibling tools list provides implicit differentiation, and the description indicates required parameters (potencia_kW, tensao_V, scc_MVA) which gives some context.

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 readOnlyHint=true, matching the calculation nature. Description adds behavioral details on computed quantities (traction, SWBP, occupancy, max tension) beyond the annotation, providing transparency on what the tool does.

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 concise: two sentences covering the standard, application (straight section), computed quantities, and a key constraint on n_cabos. No fluff.

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 10 parameters and no output schema, the description covers the tool's purpose and outputs but lacks details on parameter semantics and return format. It is adequate for a simple calculation but not fully 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 has 10 parameters with 0% description coverage. The description only mentions n_cabos's allowed values (1 or 3) but does not explain any other parameter meanings, units, or constraints. With no param info in the description, this dimension suffers.

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?

Description clearly states the tool calculates cable pulling tension according to IEEE 1185/525 for straight sections, listing specific outputs like traction at capstan, SWBP, duct occupancy, and maximum allowable tension. It distinguishes itself from sibling tools which focus on 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?

Indicates usage for 'trecho reto' (straight section) and constrains n_cabos to 1 or 3 (trifolium), implying it is not for curved sections or other configurations. No explicit when-not or alternative tools, but context is clear.

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 provide readOnlyHint=true, indicating no side effects. The description adds usage limit info ('Gratuito (uso limitado)') and the formulas, but does not disclose further behavioral traits like authentication needs or output format. 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 concise (3 sentences), front-loads the purpose and core formulas, and has no wasted words. Every sentence earns its place.

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 the high parameter count (11), no output schema, and 0% schema coverage, the description is insufficient. It explains only a few parameters and does not describe the return value or expected output format, leaving the agent without full guidance.

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. It explains key parameters for TN (Ia_A, disjuntor_In_A, curva_mcb) and TT (i_dn_mA, RA_ohm), but many parameters (api_key, sistema, material, comprimento_m, secao_fase_mm2) are left undocumented, leaving 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 the tool verifies automatic disconnection against NBR 5410, with specific formulas for TN and TT systems. The title identifies it as an automatic sectioning tool, distinguishing it from sibling tools like calcular_curto_circuito 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?

The description provides clear context for when to use: specify Ia or disjuntor+curva_mcb for TN, or i_dn_mA+RA for TT. It does not explicitly state when not to use or name alternatives, but the context is sufficient for an agent to select this tool over siblings.

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