Cálculos de engenharia elétrica pelas normas brasileiras (NBR), validados, com citação normativa — 21 ferramentas, energia incidente IEEE 1584 validado. Nicho PT-BR.
Scored across 21 tools
Each tool targets a distinct calculation domain (short-circuit, arc flash, power factor, transformer damage, etc.) with clear boundaries. Overlaps like calcular_energia_incidente vs _hv and calcular_curto_circuito vs montar_rede are explicitly differentiated in descriptions, leaving no ambiguity.
All names use snake_case and Portuguese, with most action tools following a verb_noun pattern (calcular_, dimensionar_, listar_). However, several tools use noun-first phrases (e.g., partida_motor, tempo_de_atuacao, grupo_gerador), creating a minor inconsistency in convention but still readable.
21 tools is on the heavy side for a single MCP server, falling into the borderline 16-25 range. While each tool covers a distinct engineering analysis, the sheer number may overwhelm an agent and increase selection complexity.
The surface covers a broad range of electrical studies (short-circuit, arc flash, protection, cables, motors, panels) and includes support tools like listar_dispositivos and gerar_memorial. Some potential gaps exist (e.g., explicit selectivity/coordination or load-flow tools), but core workflows are well supported.
Curto-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.
Energia 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³).
A resposta declara criterio_ibf: "informado_pelo_usuario": a Ibf é a que
você passou — se veio de calcular_curto_circuito/montar_rede, é a máxima
IEC 60909 (c_max); qualquer outra base (mínima, 1,0 pu) é escolha sua e deve
ser dita ao usuário. 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 |
Energia 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.
Dimensiona 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.
Curva 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.
Banco dessintonizado ou filtro sintonizado (reator série com o capacitor).
Informe p_pct (fator 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).
A leitura do ramo segue a sintonia: a partir de p = 5,67 % (4,2ª) é banco
dessintonizado; entre 4 % e 5,67 % é filtro sintonizado perto da 5ª; abaixo de
4 %, a sintonia fica acima da 5ª. Un_cap_kV = tensão nominal do capacitor ou
do banco montado, entre fases: a tool verifica o contínuo de 1,10·Un. Acima de
24 kV a tool não sugere classe e pede essa tensão. 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 declare only readOnlyHint. The description adds rich behavior: the detuning thresholds (p >= 5.67% detuned, 4-5.67% tuned near the 5th, <4% above the 5th), the 1.10·Un continuous check, the >24 kV fallback where no class is suggested, and parallel-resonance evaluation with scc_MVA.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but front-loaded: it states what it computes, then the either/or input, then the outputs, then edge-case rules. Every sentence carries technical content; the only cost is a slightly run-on middle section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description enumerates the returned quantities (elevated capacitor voltage V/(1−p), reactor current, effective reactive Q/(1−p), tuning frequency, IEC 60831 voltage class), so an agent knows what comes back. Required params Q_kvar and tensao_kV are the remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must carry parameter meaning, and it explains p_pct (XL/XC factor, e.g. 7 or 14), the L_mH alternative, Un_cap_kV, and scc_MVA's role. It leaves Q_kvar, tensao_kV, and api_key unexplained, so coverage is strong but not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a precise verb+resource: it sizes a detuned bank or tuned filter (series reactor with capacitor), which is clearly distinct from siblings like corrigir_fator_potencia. It does not name an alternative sibling, but the technical scope is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives useful invocation guidance ('Informe p_pct ... OU L_mH'), and conditional behavior for Un_cap_kV above 24 kV and scc_MVA. However, it never says when to choose this tool over alternatives like corrigir_fator_potencia, so usage is implied rather than framed against siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dimensiona 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.
Dimensiona 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, do enrolamento
EM USO (None → estimada, e a resposta diz que estimou e por qual fórmula).
AVALIAR O TC INSTALADO: primario_A avalia só aquela relação (em vez de
procurar a menor que atende) e devolve tensão de saturação, ALF efetivo,
ALF exigido no simétrico e com a componente CC, margem, Ks, tempo até a
saturação e o resultado. TC multi-relação: primario_A = a derivação em
uso e primario_pleno_A = a relação de placa — a classe vale para o
enrolamento inteiro. CLASSE: ALF + burden_VA (IEC, ex.: 10P20 de 25 VA)
OU classe_abnt na notação antiga da ABNT (ex.: '10B200', '2,5B100'; o
tipo A, de alta reatância, é recusado). SIMULAÇÃO NO TEMPO (só com
primario_A, exige xr): pickup_sec_A = pickup do elemento no
secundário [A] liga a simulação da calculadora de saturação do IEEE PSRC e
devolve o instante em que o fluxo alcança o de saturação, a menor razão
entre a fundamental que o relé vê e a ideal e o atraso até o pickup.
remanencia_pct = remanência inicial em % do fluxo de saturação (padrão 0;
a classe PR garante até 10 %; 40 % quando desconhecida, pelo manual do
RET630 da ABB). Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| xr | No | ||
| ALF | No | ||
| 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 | No | ||
| cable_ohm | Yes | ||
| relay_ohm | Yes | ||
| t_curto_s | No | ||
| primario_A | No | ||
| classe_abnt | No | ||
| pickup_sec_A | No | ||
| secundario_A | Yes | ||
| remanencia_pct | No | ||
| primario_pleno_A | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnlyHint, so the description carries the behavioral load and does it well: it discloses the rate limit ('Gratuito (uso limitado)'), the silent-estimation behavior for Rct_ohm ('None → estimada, e a resposta diz que estimou e por qual fórmula'), and the defaulting semantics for remanencia_pct. It also enumerates what the response returns (saturação, ALF efetivo, margem, Ks, tempo até saturação).
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?
It is dense and long, but front-loaded (purpose first, then optional criteria, then modes), and nearly every clause conveys a distinct engineering rule or parameter behavior. It could be broken into labelled sections rather than a single block of prose, which is the main structural weakness.
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 20-parameter engineering tool with no output schema, the description supplies the criteria, the mode switches and the returned quantities, so an agent has enough to call it correctly. It does not, however, cover every required parameter's meaning or state the units/bounds expected for the electrical inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does for the high-value parameters: xr, I_load_A+Fter, Ith_A/Idyn_A, t_curto_s/tth_s, Rct_ohm, primario_A, primario_pleno_A, ALF/burden_VA, classe_abnt, pickup_sec_A, remanencia_pct, and even api_key by implication. Gaps remain for Icc_A, secundario_A, relay_ohm and cable_ohm, but overall it adds substantial meaning beyond the bare 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?
States a specific verb and resource ('Dimensiona o TC de proteção') plus the governing standards (IEC 61869-2 / NBR 6856), and immediately narrows scope with 'menor primário comercial que NÃO satura na falta'. No sibling is named, but the domain is so specific that it cannot be confused with calcular_curto_circuito, dimensionar_cabo, or the other sizing 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?
Usage is implied through the parameter-driven modes ('AVALIAR O TC INSTALADO: primario_A avalia só aquela relação... em vez de procurar a menor que atende', 'SIMULAÇÃO NO TEMPO (só com primario_A, exige xr)'), which tells the agent which mode a given call enters. However there is no explicit statement of when to choose this tool over sibling tools, nor any exclusion criteria beyond the ABNT type-A refusal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Elevaçã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.
Memorial 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.
Afundamento 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 (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.
Lista 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') e mostra
aquele tipo mesmo fora do modo catálogo (relé serve à rota manual); 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 declare readOnlyHint=true, but the description adds real behavioral context: the default result set is restricted to MCCB/ACB with electronic trip and real In_A, and it discloses a cost/limit trait ('Gratuito (uso limitado)'). It does not describe pagination or return shape, but the added filtering semantics and rate-limit note go well beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the primary purpose, then layers parameter behavior in a dense but efficient passage with no filler sentences. Slightly packed, but every clause adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-param, zero-schema-coverage, no-output-schema listing tool, the description covers default behavior, filtering semantics, and its role in the tempo_de_atuacao workflow. The unstipulated `api_key` and unmentioned return structure are the only remaining gaps, and a list result needs little return explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden and largely does: `tipo` is documented with its valid values ('MCCB','ACB','Relay','MCB','Fuse','Transformer') and the nuance that it surfaces a type even outside catalog mode, and `todos=True` is explained as including all types. Only `api_key` is left undescribed, keeping it from a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Lista o catálogo de dispositivos') and goes further by naming the downstream goal (discovering `device_id` for tempo_de_atuacao catalog mode). An agent can immediately distinguish this from computation-heavy siblings like calcular_curto_circuito.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly frames when to reach for it: to obtain a `device_id` consumed by tempo_de_atuacao's catalog mode, and it names that sibling explicitly. It lacks an explicit 'when not to use' or a contrast with other listing tools (e.g., listar_ferramentas), so it stays just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista 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.
Monta uma REDE MULTIBARRA (concessionária → transformadores → cabos →
quadros) e calcula o curto-circuito IEC 60909 em TODAS as barras de uma vez,
pelo mesmo motor validado da plataforma (redução nodal do Anexo B: aceita
alimentação radial, em paralelo e malha). Use quando o usuário tem os dados
de VÁRIOS equipamentos — típico de quem acabou de ler um datasheet, uma carta
da concessionária ou um memorial antigo — em vez de chamar
calcular_curto_circuito (que é de UM ponto) várias vezes.
Devolve também projeto_json: o arquivo de projeto da plataforma com a rede
inteira. Entregue esse conteúdo ao usuário para salvar como .json e abrir em
"Abrir projeto" no app — a rede aparece nas tabelas para ele CONFERIR e seguir
para coordenograma, arco elétrico e memorial. Nenhum valor extraído de
documento deve virar laudo sem essa conferência humana.
── barras: lista de objetos ────────────────────────────────────────────────
{"id": "SE_BT", "label": "Subestação 480 V", "Vn_kV": 0.48}
id é o identificador único (sem espaços é mais seguro); Vn_kV é a tensão
NOMINAL da barra em kV (0,48 = 480 V). A barra de conexão com a
concessionária é a que NÃO recebe nenhum elemento (nenhum to_id aponta
para ela) — é ela a raiz da rede.
── elementos: lista de objetos (o que liga uma barra à outra) ──────────────
element_type "transformer": {"from_id","to_id","element_type":"transformer",
"Sn_kVA":1000,"Vcc_pct":5.0,"Pcu_W":10000,"XR_trafo":null,"Rn_ohm":null}
Sn e Vcc são de PLAQUETA e obrigatórios (>0). Pcu_W = perdas no cobre;
XR_trafo (opcional) sobrepõe o X/R estimado por Pcu. Modelado como Dyn
(delta na alta, estrela na baixa). Rn_ohm = resistor de aterramento do
NEUTRO de baixa (NGR), em Ω: ausente = neutro SÓLIDO, e a resposta avisa
que foi assumido. Com NGR a fase-terra cai em ordem de grandeza — SEMPRE
informe quando a instalação tiver. tipo_aterramento (opcional) aceita
'solido' ou 'resistivo' (este exige Rn_ohm), como no
calcular_curto_circuito; 'isolado' é RECUSADO aqui (neutro isolado não
é modelado na rede multibarra). O aterramento é do TRANSFORMADOR, nunca
da fonte.
element_type "cable" (ou "busbar"): {"from_id","to_id","element_type":"cable",
"secao_mm2":95,"material":"Cu","comprimento_m":40,"num_conductors":1}
Liga barras de MESMA tensão (para mudar de tensão use "transformer").
element_type "reactor": {"from_id","to_id","element_type":"reactor",
"u_kR_pct":6,"I_rR_A":400} (reator limitador, §6.5 — u_kR e I_rR de plaqueta)
── fonte: a contribuição da concessionária ────────────────────────────────
{"Vn_kV":13.8, "Scc_MVA":500, "XR":10, "Icc_1ph_kA":0, "XR_1ph":0}
Informe Scc_MVA OU Icc_kA (não os dois). Vn_kV é a tensão do ponto de
conexão. §7.1.2 d): use a contribuição MÁXIMA declarada pela concessionária,
não a de hoje — dimensionar pelo valor de hoje subdimensiona o equipamento
quando a rede reforça. Icc_1ph_kA/XR_1ph são opcionais (0 = estimar Z0).
── motores (opcional): contribuição de motores por barra ────────────────── {"bus_id":"QD-01","P_kW":75,"n_motores":4,"cos_phi":0.85,"rendimento":0.92, "Xd_sub_pu":0.17}
── estudo (opcional): opções do estudo de arco que o projeto leva ─────────
{"banda_padrao":"norma", "t_sem_atuacao_ms":2000}
Ambas nascem DESLIGADAS (ausentes ou null) e não mudam o curto calculado
aqui: vão no projeto_json para o Workspace estudar o arco com elas.
banda_padrao "norma" = ±20 % na instantânea do disjuntor termomagnético
sem banda declarada (IEC 60947-2). t_sem_atuacao_ms = tempo máximo de
arco (> 0 e ≤ 2000 ms) para a barra cuja proteção não vê a falta. Valor
fora disso é erro de forma. A resposta ecoa estudo.
Erro de FORMA (campo faltando, valor não-numérico) e erro de FÍSICA (tensões que não casam num cabo, trafo sem Sn/Vcc, duas alimentações para a mesma barra) voltam em {"erro": ...} explicando o que corrigir — nada é calculado "pela metade". Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | pt | |
| fonte | Yes | ||
| barras | Yes | ||
| estudo | No | ||
| api_key | No | ||
| motores | No | ||
| elementos | Yes |
Afundamento 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.
Traçã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.
Encaminha 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 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).
O tempo é o da borda LENTA da banda de tolerância, a mesma régua do estudo da
plataforma: no modelo do catálogo que declara a banda do fabricante ela é aplicada
(banda: "fabricante"); sem banda declarada, informe tolerancia_pct (± %, só na
instantânea — a do manual do seu disjuntor; a IEC 60947-2 admite ±20 % no
disparador de curto-circuito) e a instantânea sobe para o extremo de cima
(banda: "informada"); sem nada, a curva ajustada (banda: "nenhuma"). A corrente
de arco REDUZIDA que fica entre o ajuste e o extremo da banda cai na curva térmica —
e é ela que costuma governar a energia.
MANUAL (universal): pickup_A = pickup do 51 (relé: RTC×tap; disjuntor: Ir); curva
∈ IEC/IEEE, pelo nome ou pelo apelido dos manuais — NI/SI (= IEC-NI), VI, EI,
LTI, UI, DT/DTL e ANSI/IEEE MI/VI/EI; o nome lido volta em curva e o que você
escreveu em curva_informada. Códigos de fabricante (como U1–U5 e C1–C5) NÃO
são aceitos: cada fabricante numera e escala do seu jeito (a U1 da SEL usa outra
escala de dial). tms = TMS (IEC) ou time-dial (IEEE), 0,10 se omitido; 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);
tms omitido = o padrão do aparelho, e nos disparadores de curva I²t da IEC 60947-2
(3WL, Emax 2, Tmax XT7) o tms é o t1/tR em SEGUNDOS, o número do mostrador.
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 | ||
| tolerancia_pct | No | ||
| corrente_falta_A | Yes | ||
| t_curto_tempo_ms | No |
Simula 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.
Verifica 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
montar_rede1 field changedInput schema / properties / estudoAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Estudo"
+}tempo_de_atuacao1 field changedInput schema / properties / tolerancia_pctAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Tolerancia Pct"
+}tempo_de_atuacao3 fields changedInput schema / properties / tms / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / tms / defaultPrevious value: -0.1New value: +nullInput schema / properties / tms / typeRemoved value: -"number"dimensionar_tc2 fields changedInput schema / properties / pickup_sec_AAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Pickup Sec A"
+}Input schema / properties / remanencia_pctAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Remanencia Pct"
+}dimensionar_tc10 fields changedInput schema / properties / ALF / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / ALF / defaultAdded value: +nullInput schema / properties / ALF / typeRemoved value: -"number"Input schema / properties / burden_VA / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / burden_VA / defaultAdded value: +nullInput schema / properties / burden_VA / typeRemoved value: -"number"Input schema / properties / classe_abntAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Classe Abnt"
+}Input schema / properties / primario_AAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Primario A"
+}Input schema / properties / primario_pleno_AAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Primario Pleno A"
+}Input schema / requiredPrevious value: -[
- "Icc_A",
- "secundario_A",
- "ALF",
- "burden_VA",
- "relay_ohm",
- "cable_ohm"
-]New value: +[
+ "Icc_A",
+ "secundario_A",
+ "relay_ohm",
+ "cable_ohm"
+]montar_redesolicitar_orcamentocalcular_energia_incidente_hvlistar_dispositivostempo_de_atuacaocalcular_curto_circuito5 fields changedInput schema / properties / cabo_mAdded value: +{
+ "default": 50,
+ "title": "Cabo M",
+ "type": "number"
+}Input schema / properties / cabo_materialAdded value: +{
+ "default": "Cu",
+ "title": "Cabo Material",
+ "type": "string"
+}Input schema / properties / cabo_num_condutoresAdded value: +{
+ "default": 1,
+ "title": "Cabo Num Condutores",
+ "type": "integer"
+}Input schema / properties / cabo_secao_mm2Added value: +{
+ "default": 50,
+ "title": "Cabo Secao Mm2",
+ "type": "number"
+}Input schema / properties / com_caboAdded value: +{
+ "default": false,
+ "title": "Com Cabo",
+ "type": "boolean"
+}corrigir_fator_potencia1 field changedInput schema / properties / scc_MVAAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Scc Mva"
+}dano_transformador2 fields changedInput schema / properties / ligacaoAdded value: +{
+ "default": "none",
+ "title": "Ligacao",
+ "type": "string"
+}Input schema / properties / t_inrush_msAdded value: +{
+ "default": 100,
+ "title": "T Inrush Ms",
+ "type": "number"
+}dessintonia_capacitordimensionar_tc4 fields changedInput schema / properties / Idyn_AAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Idyn A"
+}Input schema / properties / Ith_AAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Ith A"
+}Input schema / properties / t_curto_sAdded value: +{
+ "default": 1,
+ "title": "T Curto S",
+ "type": "number"
+}Input schema / properties / tth_sAdded value: +{
+ "default": 1,
+ "title": "Tth S",
+ "type": "number"
+}k_factor_transformadorpartida_motor10 fields changedInput schema / properties / fonte_gmg_kVAAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Fonte Gmg Kva"
+}Input schema / properties / fonte_gmg_xd_pctAdded value: +{
+ "default": 25,
+ "title": "Fonte Gmg Xd Pct",
+ "type": "number"
+}Input schema / properties / fonte_scc_montante_MVAAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Fonte Scc Montante Mva"
+}Input schema / properties / fonte_tipoAdded value: +{
+ "default": "scc",
+ "title": "Fonte Tipo",
+ "type": "string"
+}Input schema / properties / fonte_trafo_Vcc_pctAdded value: +{
+ "default": 5,
+ "title": "Fonte Trafo Vcc Pct",
+ "type": "number"
+}Input schema / properties / fonte_trafo_kVAAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Fonte Trafo Kva"
+}Input schema / properties / scc_MVA / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / scc_MVA / defaultAdded value: +nullInput schema / properties / scc_MVA / typeRemoved value: -"number"Input schema / requiredPrevious value: -[
- "potencia_kW",
- "tensao_V",
- "scc_MVA"
-]New value: +[
+ "potencia_kW",
+ "tensao_V"
+]tempo_partida_motorcalcular_curto_circuito9 fields changedInput schema / properties / Rn_ohmAdded value: +{
+ "default": 0,
+ "title": "Rn Ohm",
+ "type": "number"
+}Input schema / properties / icc_rede_kAAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Icc Rede Ka"
+}Input schema / properties / potencia_curto_mva / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / potencia_curto_mva / defaultAdded value: +nullInput schema / properties / potencia_curto_mva / typeRemoved value: -"number"Input schema / properties / tipo_aterramentoAdded value: +{
+ "default": "solido",
+ "title": "Tipo Aterramento",
+ "type": "string"
+}Input schema / properties / xr_redeAdded value: +{
+ "default": 10,
+ "title": "Xr Rede",
+ "type": "number"
+}Input schema / properties / xr_trafoAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Xr Trafo"
+}Input schema / requiredPrevious value: -[
- "tensao_kv",
- "potencia_curto_mva"
-]New value: +[
+ "tensao_kv"
+]calcular_energia_incidente4 fields changedInput schema / properties / alt_mmAdded value: +{
+ "default": 508,
+ "title": "Alt Mm",
+ "type": "number"
+}Input schema / properties / larg_mmAdded value: +{
+ "default": 508,
+ "title": "Larg Mm",
+ "type": "number"
+}Input schema / properties / prof_mmAdded value: +{
+ "default": 508,
+ "title": "Prof Mm",
+ "type": "number"
+}Input schema / properties / t_arc_reduzido_sAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "T Arc Reduzido S"
+}corrigir_fator_potencia2 fields changedInput schema / properties / Un_cap_kVAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Un Cap Kv"
+}Input schema / properties / carga_min_pctAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Carga Min Pct"
+}dimensionar_cabo4 fields changedInput schema / properties / arranjoAdded value: +{
+ "default": "feixe",
+ "title": "Arranjo",
+ "type": "string"
+}Input schema / properties / curva_disjuntorAdded value: +{
+ "default": "C",
+ "title": "Curva Disjuntor",
+ "type": "string"
+}Input schema / properties / disjuntor_In_AAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Disjuntor In A"
+}Input schema / properties / n_circuitos_agrupadosAdded value: +{
+ "default": 1,
+ "title": "N Circuitos Agrupados",
+ "type": "integer"
+}dimensionar_tc4 fields changedInput schema / properties / FterAdded value: +{
+ "default": 1,
+ "title": "Fter",
+ "type": "number"
+}Input schema / properties / I_load_AAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "I Load A"
+}Input schema / properties / Rct_ohmAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Rct Ohm"
+}Input schema / properties / xrAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Xr"
+}elevacao_temperatura_painel6 fields changedInput schema / properties / face_lateraisAdded value: +{
+ "default": "exposta",
+ "title": "Face Laterais",
+ "type": "string"
+}Input schema / properties / face_topoAdded value: +{
+ "default": "exposto",
+ "title": "Face Topo",
+ "type": "string"
+}Input schema / properties / face_traseiraAdded value: +{
+ "default": "exposta",
+ "title": "Face Traseira",
+ "type": "string"
+}Input schema / properties / limite_equip_CAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Limite Equip C"
+}Input schema / properties / regimeAdded value: +{
+ "default": "BT",
+ "title": "Regime",
+ "type": "string"
+}Input schema / properties / tipo_instalacaoAdded value: +{
+ "default": 3,
+ "title": "Tipo Instalacao",
+ "type": "integer"
+}grupo_gerador5 fields changedInput schema / properties / XRAdded value: +{
+ "default": 20,
+ "title": "Xr",
+ "type": "number"
+}Input schema / properties / cabo_mAdded value: +{
+ "default": 0,
+ "title": "Cabo M",
+ "type": "number"
+}Input schema / properties / cabo_mm2Added value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Cabo Mm2"
+}Input schema / properties / dv_limite_pctAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Dv Limite Pct"
+}Input schema / properties / motor_fp_rotor_bloqueadoAdded value: +{
+ "default": 0.3,
+ "title": "Motor Fp Rotor Bloqueado",
+ "type": "number"
+}partida_motor5 fields changedInput schema / properties / C_load_puAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "C Load Pu"
+}Input schema / properties / Cp_CnAdded value: +{
+ "default": 2,
+ "title": "Cp Cn",
+ "type": "number"
+}Input schema / properties / In_AAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "In A"
+}Input schema / properties / dv_limite_pctAdded value: +{
+ "default": 10,
+ "title": "Dv Limite Pct",
+ "type": "number"
+}Input schema / properties / fp_partidaAdded value: +{
+ "default": 0.25,
+ "title": "Fp Partida",
+ "type": "number"
+}puxamento_cabo6 fields changedInput schema / properties / attachmentAdded value: +{
+ "default": "olhal",
+ "title": "Attachment",
+ "type": "string"
+}Input schema / properties / cabo_classeAdded value: +{
+ "default": "BT_unipolar",
+ "title": "Cabo Classe",
+ "type": "string"
+}Input schema / properties / convencaoAdded value: +{
+ "default": "BR",
+ "title": "Convencao",
+ "type": "string"
+}Input schema / properties / curva_raio_mAdded value: +{
+ "default": 0.6,
+ "title": "Curva Raio M",
+ "type": "number"
+}Input schema / properties / curvas_grausAdded value: +{
+ "anyOf": [
+ {
+ "items": {},
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Curvas Graus"
+}Input schema / properties / swbp_classeAdded value: +{
+ "default": "BT",
+ "title": "Swbp Classe",
+ "type": "string"
+}verificar_seccionamento6 fields changedInput schema / properties / R_montante_ohmAdded value: +{
+ "default": 0,
+ "title": "R Montante Ohm",
+ "type": "number"
+}Input schema / properties / T_opAdded value: +{
+ "default": 70,
+ "title": "T Op",
+ "type": "number"
+}Input schema / properties / X_montante_ohmAdded value: +{
+ "default": 0,
+ "title": "X Montante Ohm",
+ "type": "number"
+}Input schema / properties / circuito_tipoAdded value: +{
+ "default": "terminal_le32",
+ "title": "Circuito Tipo",
+ "type": "string"
+}Input schema / properties / secao_pe_mm2Added value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Secao Pe Mm2"
+}Input schema / properties / situacaoAdded value: +{
+ "default": 1,
+ "title": "Situacao",
+ "type": "integer"
+}calcular_curto_circuitocalcular_energia_incidentecorrigir_fator_potenciadano_transformadordimensionar_cabodimensionar_tcelevacao_temperatura_painelgerar_memorialgrupo_geradorlistar_ferramentaspartida_motorpuxamento_caboverificar_seccionamentoCalculs du bâtiment (France) : chute de tension NF C 15-100 et catalogue de 111 outils.
27 engineering compliance and calculation tools for the built environment (UK, EU, UAE).
Notas fiscais eletrônicas brasileiras: consulta, análise, manifestação e emissão de NFS-e.
Heating, ventilation and energy engineering calculations and diagnostics for AI agents.
Add one secure layer between your agents and this server.
