Cálculos de engenharia elétrica pelas normas brasileiras (NBR), validados, com citação normativa — 11 ferramentas, energia incidente IEEE 1584 validado. Nicho PT-BR.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.9/5 across 20 of 20 tools scored. Lowest: 2.9/5.
Each tool targets a specific calculation or parameter (e.g., short-circuit, incident energy, cable sizing). Even related tools like partida_motor (voltage dip) and tempo_partida_motor (acceleration time) have distinct purposes. Descriptions clearly differentiate them.
All tool names use snake_case and predominantly follow a verb_noun pattern (calcular_, corrigir_, dimensionar_). The few deviations like dano_transformador or k_factor_transformador are still clear and do not break overall consistency.
With 20 tools, the server covers a wide range of electrical engineering calculations without being bloated. Each tool serves a specific purpose, and the count feels well-scoped for the domain.
The tool set covers short-circuit, arc flash, protection coordination, cable sizing, and other key areas. Missing advanced topics like load flow are outside the stated scope; only minor gaps like direct relay coordination tools are absent.
calcular_curto_circuitoCurto-circuito (IEC 60909)ACurto-circuito (IEC 60909) pelo motor da plataforma: Icc 3φ/2φ/fase-terra,
X/R e pico. Informe a rede por potencia_curto_mva OU icc_rede_kA.
com_transformador=True dá o Icc no secundário (trafo_*). xr_rede/xr_trafo
= relações X/R (regem κ, pico ip e assimetria — o making do disjuntor);
tipo_aterramento ∈ {solido, resistivo, isolado} + Rn_ohm regem a corrente de
falta fase-terra (Icc_1φ). com_cabo=True (+ cabo_secao_mm2/cabo_m) dá o Icc no
PONTO de instalação após o cabo (menor que no barramento). Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| Rn_ohm | No | ||
| cabo_m | No | ||
| api_key | No | ||
| xr_rede | No | ||
| com_cabo | No | ||
| xr_trafo | No | ||
| tensao_kv | Yes | ||
| trafo_kVA | No | ||
| icc_rede_kA | No | ||
| trafo_V2_kv | No | ||
| cabo_material | No | Cu | |
| trafo_Vcc_pct | No | ||
| cabo_secao_mm2 | No | ||
| tipo_aterramento | No | solido | |
| com_transformador | No | ||
| potencia_curto_mva | No | ||
| cabo_num_condutores | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which aligns with the calculation nature. The description adds behavioral details: 'Gratuito (uso limitado)' indicates usage limits, and explains how parameters affect results (e.g., com_cabo gives fault current at installation point, lower than busbar). No contradictions 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 compact and front-loaded with the core purpose. It uses abbreviations and compact notation (e.g., 'Icc 3φ/2φ/fase-terra') to save space. While it is a single dense paragraph, it efficiently conveys information without excessive verbosity. Minor structural improvement (e.g., bullet points) could enhance readability.
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 complexity (17 parameters, no output schema), the description provides substantial context but does not explain all parameters nor describe the output format (e.g., what fields are returned). With readOnlyHint, safety is assured, but an agent would still need to infer output structure. Missing details on unmentioned parameters reduce completeness somewhat.
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 several key parameters (potencia_curto_mva, icc_rede_kA, xr_rede, xr_trafo, tipo_aterramento, Rn_ohm, com_cabo, cabo_secao_mm2, cabo_m) with functional meanings. However, it omits explanations for tensao_kv, trafo_kVA, trafo_V2_kv, trafo_Vcc_pct, cabo_material, cabo_num_condutores, and api_key, which are not described. Thus it partially compensates.
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 per IEC 60909, specifying fault types (3φ, 2φ, phase-ground), X/R, and peak current. It uses specific verbs and resource names, and the title reinforces the standard. This distinguishes it from sibling tools like calcular_energia_incidente or grupo_gerador.
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 guidance on key parameter choices (e.g., use potencia_curto_mva OR icc_rede_kA for network data; com_transformador for secondary side; com_cabo for cable effects; tipo_aterramento for phase-ground fault). It does not explicitly state when not to use the tool versus siblings, but the context is adequate for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_energia_incidenteEnergia incidente de arco (IEEE 1584 / NBR 17227)AEnergia incidente (Ei, cal/cm²), LAS e categoria de EPI de um arco elétrico,
pelo motor IEEE 1584:2018 / ABNT NBR 17227:2025 VALIDADO da plataforma (208 V–
15 kV). config ∈ {VCB,VCBB,HCB,VOA,HOA}.
Dois patamares de corrente (IEEE 1584:2018 §4.12): t_arc_s = tempo de
eliminação da proteção na corrente de arco PLENA (Iarc); t_arc_reduzido_s =
tempo na corrente REDUZIDA (Imin ≈ 0,88·Iarc). Como a corrente reduzida costuma
limpar mais devagar (proteção de tempo inverso), o patamar reduzido com
frequência GOVERNA o pior caso. Havendo dispositivo com curva inversa, forneça
os DOIS tempos; sem t_arc_reduzido_s, calcula um único patamar.
larg_mm/alt_mm/prof_mm = invólucro REAL do equipamento (a correção de tamanho
da §4.8 muda o Ei; default = caixa de referência 508³). Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| alt_mm | No | ||
| config | No | VCB | |
| gap_mm | Yes | ||
| ibf_ka | Yes | ||
| api_key | No | ||
| larg_mm | No | ||
| prof_mm | No | ||
| t_arc_s | Yes | ||
| tensao_kv | Yes | ||
| dist_trabalho_mm | Yes | ||
| t_arc_reduzido_s | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description consistently describes a calculation tool. It adds behavioral context: validated model, two current patamares, default enclosure size, and the fact that the reduced current often governs the worst case. 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 a single dense paragraph that front-loads the main purpose. It is reasonably concise but could benefit from structuring (e.g., bullet points for parameters or outputs). Every sentence adds value; no 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?
Given 11 parameters, 5 required, and no output schema, the description explains the core calculation and two-current behavior but lacks details on return format (expected outputs like Ei, LAS, EPI are mentioned but not structure) and parameter constraints (e.g., voltage range). Slightly incomplete for a complex 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%, but the description clarifies the config parameter (enum values), t_arc_s and t_arc_reduzido_s (two current levels), and larg_mm/alt_mm/prof_mm (enclosure dimensions with default 508). However, many parameters (tensao_kv, ibf_ka, gap_mm, dist_trabalho_mm, api_key) are not explained. 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 arc flash incident energy (Ei), LAS, and EPI category per IEEE 1584:2018 / NBR 17227, with a specific voltage range (208 V–15 kV). This distinguishes it from sibling tools like 'calcular_energia_incidente_hv' which likely covers higher voltages.
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 explains when to use the tool (IEEE 1584/NBR 17227, voltage range), the need for two current levels (t_arc_s and t_arc_reduzido_s), and that omitting the reduced time yields a single level. It also notes limited free usage. However, it does not explicitly state when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_energia_incidente_hvEnergia incidente > 15 kV — triagem (OSHA / Lee / EPRI)AEnergia incidente para sistemas > 15 kV — FORA do IEEE 1584:2018 / NBR 17227 (arco ao ar livre fase-terra). É TRIAGEM, NÃO laudo: o motor IEEE 1584 da plataforma NÃO é usado; gap e configuração de eletrodos não se aplicam.
metodo ∈ {osha (padrão), lee, epri}:
• osha — OSHA 1910.269 Apêndice E, Tab. 6/7 (base ArcPro). tipo_trabalho ∈
{luva (Tab.6, 4–46 kV), vara (Tab.7, 4–800 kV)}. Devolve a BANDA de EPI
conservadora (≤4/5/8/12 ou >12 cal/cm²), não um ponto.
• lee — cota TEÓRICA superior; exige dist_trabalho_mm.
• epri — modelo de alta tensão; exige dist_trabalho_mm + comprimento_arco_m
(vão físico fase-terra, em metros).
Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| t_ms | Yes | ||
| ibf_ka | Yes | ||
| metodo | Yes | ||
| api_key | No | ||
| tensao_kv | Yes | ||
| tipo_trabalho | No | luva | |
| dist_trabalho_mm | No | ||
| comprimento_arco_m | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds transparency by stating it is a screening tool (not a report), does not use the IEEE 1584 engine, and is free with usage limits. This goes beyond the annotations and provides 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?
The description is well-structured, starting with the purpose, then method details in bullet points. It is dense but efficient, with no wasted sentences. Could be slightly more concise, but still effective.
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 8 parameters, 0% schema coverage, and no output schema, the description covers core logic and parameter dependencies. However, it does not describe the return format, error handling, or the api_key parameter. Considering the complexity, it is adequate but lacks completeness for a fully autonomous 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?
With 0% schema description coverage, the description compensates well. It explains the metodo parameter in detail, including the specific parameters required for each method (tipo_trabalho for OSHA; dist_trabalho_mm for Lee and EPRI; comprimento_arco_m for EPRI). It also implicitly explains tensao_kv, ibf_ka, and t_ms as voltage, fault current, and time. However, it does not explain the api_key parameter.
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 title and description clearly state that this tool calculates incident energy for systems >15 kV using OSHA, Lee, and EPRI methods. It distinguishes itself from sibling tools like calcular_energia_incidente (likely for IEEE 1584) by specifying it is outside that standard and a screening 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 explicitly states it is for systems >15 kV and outside IEEE 1584, implying when not to use it. It provides context for each method (e.g., OSHA for banded EPI, Lee for theoretical upper bound, EPRI for high voltage). However, it does not explicitly list alternative tools or state when to prefer them, though it clearly implies alternatives for lower voltages or detailed reports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
corrigir_fator_potenciaCorreção de fator de potência (REN 1.000)ADimensiona o banco de capacitores para corrigir o fator de potência à
meta (REN ANEEL nº 1.000; FP-alvo padrão 0,92). Com tensao_kV também dá a
corrente nominal do banco e a norma (IEC 60831/60871).
Un_cap_kV = tensão de placa do capacitor: se ele opera abaixo da Un, entrega
MENOS kvar (derating Q∝V²) e a correção real cai — informe p/ não superestimar.
carga_min_pct = carregamento mínimo (%): dispara o alerta de SOBRECORREÇÃO
capacitiva (banco fixo em carga leve → FP capacitivo, faturável).
scc_MVA = curto na barra do banco → inrush de manobra e a corrente de PROJETO
da proteção/cabo do banco (1,5·In BT, IEEE C37.012). Gratuito.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| fp_meta | No | ||
| scc_MVA | No | ||
| fp_atual | Yes | ||
| Un_cap_kV | No | ||
| tensao_kV | No | ||
| potencia_kW | Yes | ||
| carga_min_pct | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, confirming no side effects. The description adds value by disclosing derating behavior (Q∝V²), overcorrection alerts, and inrush current calculations, which are 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?
The description is well-structured with a clear purpose sentence followed by parameter-specific notes. It is somewhat long but each sentence adds unique value; no redundancy.
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. The description mentions outputs (current, standard, alerts, inrush current) but doesn't define the return format or what is definitely provided. For a calculation tool, output specification is important.
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%, but the description explains optional parameters (tensao_kV, Un_cap_kV, carga_min_pct, scc_MVA) in detail. However, required parameters (potencia_kW, fp_atual) are only implied by the overall purpose, not explicitly described.
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's purpose: dimensioning capacitor banks for power factor correction per REN 1.000 with a target PF of 0.92. It distinguishes itself from sibling tools like 'dessintonia_capacitor' by focusing on correction sizing.
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 (e.g., 'dessintonia_capacitor' or other calc tools). The description lacks 'use this when...' or 'instead of...' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dano_transformadorCurva de dano de transformador (IEEE C57.109)BCurva de dano a faltas passantes do transformador (IEEE C57.109/C57.12.59):
categoria, corrente de falta passante máxima (In/Z), ponto ANSI e ponto de
inrush — para coordenar a proteção a montante. fases ∈ {3ph,1ph};
frequencia_falta ∈ {infrequent,frequent}; tipo ∈ {liquid,dry};
t_inrush_ms = patamar de tempo do ponto de inrush. ligacao (IEEE C37.91)
refere a curva ao OUTRO lado para coordenar com a proteção de lá: {dyg,ygd}
Δ-Yg ×0,58 · {dd,yy} ×0,87 · {ygyg,none} ×1,0. Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| tipo | No | liquid | |
| Vn_kV | Yes | ||
| fases | No | 3ph | |
| Sn_kVA | Yes | ||
| Vcc_pct | Yes | ||
| api_key | No | ||
| ligacao | No | none | |
| k_inrush | No | ||
| t_inrush_ms | No | ||
| frequencia_falta | No | infrequent |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating no side effects. The description adds that it is free with limited use but does not elaborate on authentication, rate limits, or output behavior. With annotations covering safety, the added value is modest.
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, front-loading the core purpose. It is reasonably concise but could be better structured with bullet points or separate sections for parameter details.
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?
Despite complexity (10 parameters, no output schema), the description omits the expected return format (the curve data?) and does not explain the three required parameters. It feels incomplete for an AI agent to use correctly without additional knowledge.
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 explain parameters. It adds meaning for optional params like ligacao (multiplier explanation) and t_inrush_ms (inrush point time), but fails to explain required parameters Sn_kVA, Vn_kV, Vcc_pct. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a transformer damage curve per IEEE C57.109, with specific parameters and purpose for coordinating upstream protection. It distinguishes from sibling tools like calcular_curto_circuito which handles short-circuit 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 mentions the tool is for coordinating upstream protection, but does not explicitly state when to use this tool versus alternatives like tempo_de_atuacao or calcular_curto_circuito. No when-not-to-use guidance or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dessintonia_capacitorDessintonia de banco de capacitores (reator anti-ressonância)ABanco dessintonizado (reator série anti-ressonância). Informe p_pct (fator
de dessintonia XL/XC, ex.: 7 ou 14) OU L_mH. Devolve a tensão ELEVADA no
capacitor V/(1−p), a corrente pelo reator, o reativo efetivo Q/(1−p), a
frequência de sintonia e a classe de tensão sugerida do capacitor (IEC 60831).
Com scc_MVA, avalia a ressonância paralela com a rede. Gratuito.
| Name | Required | Description | Default |
|---|---|---|---|
| L_mH | No | ||
| p_pct | No | ||
| Q_kvar | Yes | ||
| api_key | No | ||
| scc_MVA | No | ||
| Un_cap_kV | No | ||
| tensao_kV | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, confirming no side effects. The description adds behavioral details such as raised voltage calculation and optional resonance evaluation, improving transparency 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?
Description is concise and front-loaded with purpose. Some technical formulas and references are included but not excessive. Could be slightly more compact without losing value.
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?
Outputs are listed, and optional resonance evaluation is noted. However, the optional parameter Un_cap_kV's effect is not explained, and error conditions are missing. Adequate but not comprehensive.
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. Only two parameters (p_pct, L_mH) are explained, while required parameters Q_kvar and tensao_kV are not described, 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 calculates detuned capacitor bank parameters, specifying the inputs and outputs. It distinguishes itself from sibling tools by focusing on a specific calculation (anti-resonance reactor), with no 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 guidance on when to use this tool versus alternatives like 'corrigir_fator_potencia' or other calculators. The description only explains parameters, not usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dimensionar_caboDimensionamento de cabo BT (NBR 5410)ADimensiona a seção de um cabo BT pela ABNT NBR 5410: ampacidade
(Tab. 36-39 + fatores), queda de tensão, coordenação de sobrecarga
(§5.3.4.1), neutro e PE. sistema ∈ {1FN,2F,3F,3FN}; metodo = método de
instalação (A1,A2,B1,B2,C,D,E,F,G); material ∈ {Cu,Al}; isolacao ∈
{PVC,EPR}. icc_quadro_kA = Icc presumida no quadro de origem.
n_circuitos_agrupados = nº de circuitos no mesmo eletroduto/leito (aplica
o fator de agrupamento da Tab. 42 — reduz a ampacidade); arranjo ∈
{feixe,camada}. disjuntor_In_A/curva_disjuntor (B,C,D) = o dispositivo
REAL instalado (sem eles, assume o menor MCB ≥ Ib, curva C). Gratuito.
| Name | Required | Description | Default |
|---|---|---|---|
| fp | No | ||
| metodo | No | B1 | |
| api_key | No | ||
| arranjo | No | feixe | |
| sistema | No | 3FN | |
| isolacao | No | PVC | |
| material | No | Cu | |
| tensao_V | Yes | ||
| potencia_W | Yes | ||
| comprimento_m | Yes | ||
| icc_quadro_kA | No | ||
| queda_max_pct | No | ||
| disjuntor_In_A | No | ||
| curva_disjuntor | No | C | |
| temp_ambiente_C | No | ||
| n_circuitos_agrupados | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it details the calculation method (ampacity, voltage drop, coordination) and parameter effects. No side effects are mentioned, consistent with readOnlyHint.
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 information-dense and concise but lacks structure (single paragraph). Could use bullet points for readability, but no waste.
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 covers parameters thoroughly but does not explain return values or output format. Given no output schema, this is a gap, though complexity is high.
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 coverage, the description compensates by explaining each parameter's meaning, units, and default behavior (e.g., 'assume o menor MCB ≥ Ib, curva C'). This adds significant value.
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 dimensions a BT cable section according to NBR 5410, specifying tables and factors. It distinguishes from sibling tools like calcular_curto_circuito by focusing on cable sizing.
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 lacks explicit guidance on when to use this tool versus alternatives. It provides no context like 'Use for sizing cables in low voltage installations' or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dimensionar_tcDimensionamento de TC (IEC 61869-2)ADimensiona o TC de proteção (IEC 61869-2 / NBR 6856): menor primário
comercial que NÃO satura na falta, considerando o burden REAL (relé+fiação)
e o ALF efetivo. xr (X/R) = liga o critério de saturação na falta
ASSIMÉTRICA (offset CC, IEEE C37.110): um TC que passa no simétrico pode
saturar no transitório, atrasar o relé e ELEVAR a energia incidente de arco.
I_load_A+Fter = corrente de carga p/ o critério térmico contínuo.
Ith_A/Idyn_A = corrente térmica (I²t, com t_curto_s/tth_s) e dinâmica
de catálogo → robustez à falta passante (se o TC AGUENTA o curto sem dano
térmico/mecânico). Rct_ohm = R do secundário de catálogo (None → estimada).
Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| xr | No | ||
| ALF | Yes | ||
| Fter | No | ||
| Icc_A | Yes | ||
| Ith_A | No | ||
| tth_s | No | ||
| Idyn_A | No | ||
| Rct_ohm | No | ||
| api_key | No | ||
| I_load_A | No | ||
| burden_VA | Yes | ||
| cable_ohm | Yes | ||
| relay_ohm | Yes | ||
| t_curto_s | No | ||
| secundario_A | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, which is consistent with a calculator tool. The description adds that it is free with limited use ('Gratuito (uso limitado)') and explains the computational logic without any contradiction.
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 dense paragraph that front-loads the main purpose and then details parameters. It is not overly verbose, but could benefit from structuring (e.g., bullet points) to improve readability.
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 15 parameters and no output schema, the description covers key inputs and behavior but does not describe the output format. The free/limited use note adds context, but completeness is hindered by missing output 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?
Despite 0% schema description coverage, the description adds substantial meaning to many parameters (xr, I_load_A, Fter, Ith_A, Idyn_A, Rct_ohm, etc.), explaining their role in the calculation. Some parameters (e.g., api_key) lack explanation, but the core ones are well-covered.
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?
Clearly states the tool sizes protection CT per standards (IEC 61869-2/NBR 6856) and specifies the goal: smallest primary that avoids saturation. This differentiates it from sibling tools, none of which appear to perform CT sizing.
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 when to use certain parameters (e.g., xr for asymmetric fault, Ith_A/Idyn_A for thermal/dynamic limits) but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or sibling comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
elevacao_temperatura_painelElevação de temperatura em painel (IEC 60890)AElevação de temperatura do ar interno de um painel BT (IEC 60890) e
verificação de aceitação (61439-1). perda_W = perdas dissipadas no
invólucro; dimensões em metros. Exposição das faces (muda a área de
resfriamento): face_topo ∈ {exposto,coberto}; face_traseira/face_laterais
∈ {exposta,coberta} (coberta = encostada na parede / em fila → aquece mais).
tipo_instalacao 1–5 (Fig. 4); limite_equip_C = limite térmico do
equipamento interno (2º veredito); regime ∈ {BT, MT (estimativa)}. Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| regime | No | BT | |
| api_key | No | ||
| perda_W | Yes | ||
| altura_m | Yes | ||
| face_topo | No | exposto | |
| largura_m | Yes | ||
| ventilado | No | ||
| n_particoes | No | ||
| face_laterais | No | exposta | |
| face_traseira | No | exposta | |
| limite_equip_C | No | ||
| profundidade_m | Yes | ||
| temp_ambiente_C | No | ||
| tipo_instalacao | No | ||
| area_ventilacao_cm2 | No |
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.
gerar_memorialMemorial de cálculo (laudo na plataforma)CMemorial assinável + etiqueta ANSI/NBR. NUNCA é emitido autonomamente por IA — o documento é preparado na sua conta da plataforma para revisão e assinatura do responsável técnico.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| referencia_calculo | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations (besides readOnlyHint: true) are contradicted. The description adds the behavioral trait that the document is prepared in the user's platform account for review and signature, which implies a non-final, pending action. However, it doesn't detail permissions, reversibility, or what exactly happens when invoked.
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 with two sentences, the first identifying the tool's output and the second providing a critical usage note. It is front-loaded and efficient, though it could benefit from more structure.
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 of generating a signable memorial, the description is incomplete. It lacks details on input parameters, output format, how to retrieve the document, and the workflow. With no output schema, more completeness is expected.
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%, meaning the description provides no information about the two parameters (api_key and referencia_calculo). This is a significant gap; the description must compensate but fails to do so.
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 it generates a signable memorial with an ANSI/NBR label, and emphasizes it is never autonomously issued by AI, clarifying its purpose as a human-reviewable document. While it doesn't explicitly differentiate from siblings, the name and description are sufficiently specific.
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 that the tool should not be used for autonomous AI emission, implying manual review is required. However, it lacks explicit when-to-use vs. when-not-to-use guidance and does not mention alternatives among the listed siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
grupo_geradorGrupo gerador — degrau de carga (ISO 8528)AAfundamento transitório de tensão ao aplicar um degrau de carga a um
grupo gerador (ISO 8528-5, etapa 1: tensão), via reatância transitória X'd.
modo ∈ {bloco (degrau_kVA+degrau_fp), motor (motor_kW, partida DOL)}.
XR = X/R da X'd (ângulo da queda). cabo_mm2+cabo_m = alimentador
gerador→carga (a queda no cabo soma no ΔV). dv_limite_pct sobrepõe o limite
da classe — OBRIGATÓRIO para classe_iso="G4" (limite por acordo).
motor_fp_rotor_bloqueado = FP de partida (modo motor). Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| XR | No | ||
| modo | No | bloco | |
| Sn_kVA | Yes | ||
| cabo_m | No | ||
| xd_pct | No | ||
| api_key | No | ||
| cabo_mm2 | No | ||
| motor_kW | No | ||
| tensao_V | Yes | ||
| degrau_fp | No | ||
| classe_iso | No | G2 | |
| degrau_kVA | No | ||
| motor_Ip_In | No | ||
| dv_limite_pct | No | ||
| motor_fp_rotor_bloqueado | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds that the tool is free with limited usage and explains the calculation methodology (via transient reactance, cable drop impact), providing context 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 dense and efficient, using a single paragraph with line breaks. Each sentence adds value without redundancy. It could be structured for easier scanning, but it's concise.
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 (15 parameters, no output schema), the description explains the calculation context well but fails to specify the output format or return values. It also omits error conditions and limitations beyond 'uso limitado'.
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 by explaining many key parameters (e.g., modo, XR, cabo_mm2, dv_limite_pct, motor_fp_rotor_bloqueado) and their roles. Not all 15 parameters are detailed, but the essential ones for usage are covered.
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 title and description clearly state the tool calculates transient voltage dip when applying a load step to a generator set per ISO 8528-5. It specifies two modes (block and motor) and distinguishes from sibling tools like partida_motor and 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 explains the two operational modes and the parameters for each, giving clear context for when to use each mode. However, it does not explicitly compare with alternatives or state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
k_factor_transformadorK-factor de transformador (UL 1561)AK-factor (UL 1561) a partir do espectro de corrente {ordem: % de I1}, ex.: {"3": 70, "5": 45, "7": 30}. Devolve o K-factor, o K-rating comercial (trafo K-rated para cargas não-lineares), o F_HL (derating de perdas parasitas, IEEE C57.110) e o THD de corrente. Gratuito.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| espectro_harmonico | Yes |
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.
listar_dispositivosCatálogo de dispositivos de proteçãoALista o catálogo de dispositivos (devices_db) para descobrir o device_id usado
no modo catálogo de tempo_de_atuacao. Por padrão só MCCB/ACB (trip eletrônico com In_A
real); tipo filtra ('MCCB','ACB','Relay','MCB','Fuse','Transformer'); todos=True
inclui todos os tipos. Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| tipo | No | ||
| todos | No | ||
| api_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, and the description confirms a read-only listing. It adds behavioral context by mentioning default filtering behavior and cost limitation ('Gratuito (uso limitado)'), which goes beyond the annotations. 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?
Three sentences, each serving a purpose: primary usage, parameter details, and cost note. No redundant information; efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no output schema, the description covers the essential behavior and parameters. It omits output format details and api_key explanation, but given the tool's simplicity and sibling context, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining 'tipo' (list of allowed values) and 'todos' (include all types). The 'api_key' parameter is not described, but overall the description adds significant meaning beyond the raw schema.
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 the device catalog to discover device_id for use in tempo_de_atuacao. It specifies the resource (devices_db) and the action (list), and distinguishes itself from siblings by referencing a specific usage context.
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 explains default behavior (only MCCB/ACB with electronic trip), how to filter by 'tipo', and how to include all types with 'todos=True'. It also notes that the tool is free but limited. However, it does not explicitly state when not to use it or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
listar_ferramentasCatálogo de ferramentasALista a prateleira de cálculos de engenharia elétrica e o tier de cada um.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
partida_motorPartida de motor — afundamento de tensãoAAfundamento de tensão na partida de motor por divisor fasorial
fonte→cabo→motor (C ∝ V²). fonte_tipo ∈ {scc (nível de curto scc_MVA),
trafo (fonte_trafo_kVA+fonte_trafo_Vcc_pct, com rede a montante opcional
fonte_scc_montante_MVA), gerador (fonte_gmg_kVA+fonte_gmg_xd_pct, X'd
transitório)} — trafo dedicado e GMG são os casos SEVEROS de afundamento.
metodo ∈ {direta, estrela_triangulo, compensadora_65, compensadora_80,
soft_starter, vfd} (aceita 'compensadora'→tap 80% e 'soft'→soft_starter).
fp_partida = FP de rotor bloqueado; Cp_Cn = conjugado de partida/nominal;
C_load_pu = conjugado da carga (×Cn) — SEM ele a aceleração NÃO é avaliada.
Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| fp | No | ||
| eta | No | ||
| In_A | No | ||
| Cp_Cn | No | ||
| Ip_In | No | ||
| cabo_m | No | ||
| metodo | No | direta | |
| api_key | No | ||
| scc_MVA | No | ||
| cabo_mm2 | No | ||
| tensao_V | Yes | ||
| C_load_pu | No | ||
| fonte_tipo | No | scc | |
| fp_partida | No | ||
| potencia_kW | Yes | ||
| dv_limite_pct | No | ||
| fonte_gmg_kVA | No | ||
| fonte_trafo_kVA | No | ||
| fonte_gmg_xd_pct | No | ||
| fonte_trafo_Vcc_pct | No | ||
| fonte_scc_montante_MVA | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=true. The description adds valuable behavioral context: it computes voltage sag, requires certain parameters for acceleration evaluation, and notes that dedicated transformer/generator are severe cases. It also mentions limited free usage. No contradictions 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 single dense paragraph. It is front-loaded with the purpose but packs many details in a somewhat hard-to-parse structure. It could be improved with bullet points or clearer separation for each parameter group.
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's complexity (21 parameters, no output schema, 0% schema description coverage), the description does not fully compensate. It lacks explanations for many parameters, does not describe the return value or result structure, and does not provide comprehensive usage guidelines for all input combinations.
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 several key parameters (fonte_tipo variants, metodo options, fp_partida, Cp_Cn, C_load_pu) but does not cover all 21 parameters, especially required ones like potencia_kW and tensao_V. This partial coverage is adequate 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?
The description clearly states it calculates voltage sag during motor start using a phasor divider. The title and first sentence specify the exact resource and action, distinguishing it from sibling tools like 'tempo_partida_motor' which likely computes start time.
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 some usage context: source types and their severity, the need for C_load_pu to evaluate acceleration, and method aliases. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
puxamento_caboPuxamento de cabo (IEEE 1185/525)ATração de puxamento de cabo (IEEE 1185/525): tração no cabrestante, SWBP
(pressão lateral nas curvas), ocupação do duto (NBR 5410) e tração máxima
admissível. n_cabos ∈ {1,3} (trifólio). curvas_graus = lista dos ângulos
das curvas/cotovelos (graus) — SEM curvas a SWBP (que costuma GOVERNAR) sai
zero; curva_raio_m = raio das curvas (m). attachment ∈ {olhal (no
condutor), malha (na capa, teto 500 kgf)}. convencao ∈ {BR,NA,EU};
swbp_classe/cabo_classe ∈ {BT, MT, controle, armado, ...}. Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| mu | No | ||
| od_mm | Yes | ||
| api_key | No | ||
| n_cabos | No | ||
| material | Yes | ||
| convencao | No | BR | |
| duto_D_mm | Yes | ||
| peso_kg_m | Yes | ||
| secao_mm2 | Yes | ||
| attachment | No | olhal | |
| incl_graus | No | ||
| cabo_classe | No | BT_unipolar | |
| swbp_classe | No | BT | |
| curva_raio_m | No | ||
| curvas_graus | No | ||
| comprimento_m | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read only (readOnlyHint: true) and non-destructive, which matches the description of a computation tool. The description adds behavioral context: 'Gratuito (uso limitado)' indicates free usage with limits. It also explains edge cases like SWBP being zero without curves. No contradictions 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 single dense paragraph with 5 sentences, front-loading the computed quantities. It is efficient but could be better structured with bullets or shorter sentences. Still, it earns its 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?
The description explains inputs but not the output format or how results are presented. Given the tool's complexity (16 parameters, no output schema), this is a gap. However, it addresses most input semantics adequately.
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 adds rich meaning for key parameters: n_cabos ∈ {1,3} (trifólio), curvas_graus as list of angles, attachment types (olhal/malha), convencao options (BR/NA/EU), and swbp_classe/cabo_classe options. It also clarifies that without curves, SWBP is zero.
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 cable pulling tension (tração no cabrestante), sidewall bearing pressure (SWBP), duct occupancy, and maximum allowable tension, referencing IEEE 1185/525 and NBR 5410. It distinguishes itself from siblings like dimensionar_cabo by focusing on cable pulling mechanics.
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 siblings or alternatives. It does not mention exclusions, prerequisites, or typical use cases. The description only lists what it calculates without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
solicitar_orcamentoSolicitar orçamento de estudo/laudo (ART)AEncaminha um pedido de ORÇAMENTO de estudo/laudo assinável com ART (arc flash, curto-circuito, seletividade, adequação NR-10) direto do chat. Informe o e-mail de contato e o escopo (ex.: nº de painéis, classe de tensão, prazo, cidade). A equipe responde pelo e-mail informado. Não consome o limite das calculadoras — funciona inclusive quando o uso gratuito do dia esgotou.
| Name | Required | Description | Default |
|---|---|---|---|
| nome | No | ||
| Yes | |||
| escopo | No | ||
| api_key | No | ||
| empresa | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already have readOnlyHint: true. The description adds that the tool does not consume calculator limits and is available when free usage is exhausted, providing useful behavioral context 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 a single, clear paragraph that front-loads the purpose and includes all essential details without unnecessary repetition or 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?
For a simple request tool with no output schema, the description covers what it does, what input is needed, how the response is delivered, and a special condition (no calculator limit consumption). It is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds meaning for 'email' and 'escopo' (scope), but does not explain 'nome', 'api_key', or 'empresa'. Partial compensation for the lack of 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 title and description clearly state this tool is for soliciting a budget for a study/report with ART. It specifies the types of studies (arc flash, short-circuit) and the process (chat, email response). It is distinct from sibling calculation tools.
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 explicitly states what information to provide (email, scope) and how the team responds (via email). It also notes that it does not consume calculator limits and works even when free usage is exhausted, guiding the agent to use it when other tools are unavailable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tempo_de_atuacaoTempo de atuação da proteção (IEC 60255-151 / IEEE C37.112)ATempo de atuação de um dispositivo de proteção à corrente de falta, pela curva
composta 4-segmentos do motor da plataforma (IEC 60255-151 / IEEE C37.112): 51
inversa · 50 curto-tempo · 50 instantânea. É o ELO entre o curto e o arco: encadeie
calcular_curto_circuito → tempo_de_atuacao → calcular_energia_incidente (o tempo_s
daqui é o t_arc_s, o parâmetro mais difícil de estimar à mão).
MANUAL (universal): pickup_A = pickup do 51 (relé: RTC×tap; disjuntor: Ir); curva
∈ IEC/IEEE; tms = TMS (IEC) ou time-dial (IEEE); instantaneo_A+t_disjuntor_ms
(50 instantânea) e curto_tempo_A+t_curto_tempo_ms (50 temporizada) são opcionais —
sem eles, só a inversa opera. CATÁLOGO: device_id de MCCB/ACB (use listar_dispositivos).
Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| tms | No | ||
| curva | No | IEC Very Inverse (VI) | |
| api_key | No | ||
| pickup_A | No | ||
| device_id | No | ||
| curto_tempo_A | No | ||
| instantaneo_A | No | ||
| t_disjuntor_ms | No | ||
| corrente_falta_A | Yes | ||
| t_curto_tempo_ms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=true, which aligns with a calculation tool. The description adds behavioral context: it uses a composite curve, optional parameters activate specific segments, and it is free with limited use. 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 well-structured with clear sections (purpose, pipeline, manual, catalog, cost). It is somewhat lengthy but every sentence adds value. Could be slightly more concise.
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, no output schema, and sibling tools, the description explains the output usage (tempo_s as t_arc_s) and references related steps. It is sufficiently complete for the tool's 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?
Despite 0% schema description coverage, the description includes a detailed 'MANUAL' section explaining each parameter (pickup_A, curva, tms, etc.), their types, defaults, and purpose. This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calculates protection device operation time using a 4-segment curve, referencing specific standards. It also explains its role as the link between short-circuit calculation and incident energy, distinguishing it from sibling tools.
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 explicitly shows the pipeline order (calcular_curto_circuito -> tempo_de_atuacao -> calcular_energia_incidente), indicating when to use it. It also mentions limited usage, but lacks explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tempo_partida_motorTempo de partida de motor (curva T×n + rotor térmico)CSimula a partida DIRETA no tempo (RK4, J·dω/dt = T_motor − T_carga): tempo
de aceleração, se o motor PARTE ou trava, e o térmico de rotor bloqueado (I²t
da partida vs tempo de rotor bloqueado de placa, critério Petrobras N-313).
polos = nº de polos; inercia_kgm2 = J total (motor+carga); tipo_carga ∈
{constante, linear, parabolica (bomba/ventilador)}; conjugado_partida_carga_pu
/conjugado_pleno_pu = conjugado da carga (×Cn do motor) em n=0 e a plena
rotação; t_rotor_bloqueado_s liga o veredito térmico. Gratuito.
| Name | Required | Description | Default |
|---|---|---|---|
| fp | No | ||
| eta | No | ||
| Cp_Cn | No | ||
| Ip_In | No | ||
| polos | Yes | ||
| cabo_m | No | ||
| api_key | No | ||
| scc_MVA | Yes | ||
| cabo_mm2 | No | ||
| tensao_V | Yes | ||
| fp_partida | No | ||
| tipo_carga | No | parabolica | |
| potencia_kW | Yes | ||
| inercia_kgm2 | Yes | ||
| conjugado_pleno_pu | No | ||
| t_rotor_bloqueado_s | No | ||
| conjugado_partida_carga_pu | No |
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.
verificar_seccionamentoSeccionamento automático (NBR 5410)AVerifica a proteção contra choque por seccionamento automático
(ABNT NBR 5410:2004 §5.1.2.2). TN: Zs ≤ U0/Ia (informe Ia OU disjuntor
In+curva_mcb). TT: RA ≤ 50/IΔn (informe i_dn_mA + RA).
situacao = 1 (seco/usual, U_L=50 V) ou 2 (molhado/externo, U_L=25 V e
tempo da Tab. 25 mais rígido). R_montante_ohm+X_montante_ohm = impedância
do laço A MONTANTE (fonte/trafo + alimentadores) — sem ela o Zs conta só o
circuito e o veredito fica OTIMISTA. circuito_tipo ∈ {terminal_le32,
distribuicao_gt32}; secao_pe_mm2 = PE real (None → mínimo da Tab. 58).
Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| Ia_A | No | ||
| T_op | No | ||
| U0_V | Yes | ||
| RA_ohm | No | ||
| api_key | No | ||
| i_dn_mA | No | ||
| sistema | No | TN | |
| material | No | Cu | |
| situacao | No | ||
| curva_mcb | No | ||
| secao_pe_mm2 | No | ||
| circuito_tipo | No | terminal_le32 | |
| comprimento_m | No | ||
| R_montante_ohm | No | ||
| X_montante_ohm | No | ||
| disjuntor_In_A | No | ||
| secao_fase_mm2 | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description reinforces this by calling it a verification. It adds critical context beyond annotations: the result can be optimistic if R_montante_ohm and X_montante_ohm are not provided, and the tool is free but with limited usage. 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 a single dense paragraph that conveys a lot of information efficiently. It is front-loaded with the purpose and formulas. While effective, it could benefit from bullet points or clearer separation of parameter explanations to improve readability.
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 and no output schema, the description is incomplete. It explains core parameters but omits some important ones (U0_V, comprimento_m, secao_fase_mm2, T_op, material, api_key). There is no description of the return value, which is critical for an agent using the tool. Usage limits are mentioned but not detailed.
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 explain parameters. It does well for key parameters (Ia_A, disjuntor_In_A+curva_mcb, i_dn_mA+RA_ohm, R_montante_ohm, X_montante_ohm, circuito_tipo, secao_pe_mm2, situacao). However, several parameters are not explained (U0_V, T_op, comprimento_m, secao_fase_mm2, material, api_key). The required U0_V is not described, leaving 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?
The description clearly states it verifies automatic disconnection protection per NBR 5410, with specific formulas for TN and TT systems. It distinguishes from siblings like calcular_curto_circuito and tempo_de_atuacao by focusing on the sectioning verification criterion.
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 the tool (verifying protection by automatic disconnection) and differentiates between TN and TT system requirements. It mentions the optimistic result when upstream impedance is omitted and notes usage limits, but does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
