Skip to main content
Glama

Arc Flash Platform — Estudos Elétricos

Montar rede multibarra e calcular Icc em todas as barras (IEC 60909)

montar_rede
Read-only

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} 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. 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}

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).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
langNopt
fonteYes
barrasYes
api_keyNo
motoresNo
elementosYes

TDQS

A5/5.0
Behavior5/5

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

Despite readOnlyHint=true already indicating a safe read operation, the description adds valuable behavioral details: it validates inputs and returns structured errors ('nada é calculado pela metade'), warns against using extracted values as laudo without human review, and notes usage limits ('Gratuito (uso limitado)').

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Although long, the description is well-structured with clear sections (barras, elementos, fonte, motores), code examples, and front-loaded purpose. Every sentence adds value, and no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains return values (projeto_json), error formats, root bar identification, physical validation, and important caveats (use maximum concessionária contribution). It is complete for a complex tool with no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description compensates fully by documenting each field for barras, elementos (transformer/cable/reactor), fonte, and motores, including units, required values, and relationships (e.g., 'Sn e Vcc são de PLAQUETA e obrigatórios').

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it 'Monta uma REDE MULTIBARRA... e calcula o curto-circuito IEC 60909 em TODAS as barras de uma vez', distinguishing it from sibling `calcular_curto_circuito` which is for a single point.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'Use quando o usuário tem os dados de VÁRIOS equipamentos... em vez de chamar calcular_curto_circuito... várias vezes' and provides context about reading datasheets, concessionária letters, or old memorials.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation5/5

Each tool targets a specific calculation or parameter (e.g., short-circuit, incident energy, cable sizing). Even related tools like partida_motor (voltage dip) and tempo_partida_motor (acceleration time) have distinct purposes. Descriptions clearly differentiate them.

Naming Consistency5/5

All tool names use snake_case and predominantly follow a verb_noun pattern (calcular_, corrigir_, dimensionar_). The few deviations like dano_transformador or k_factor_transformador are still clear and do not break overall consistency.

Tool Count5/5

With 20 tools, the server covers a wide range of electrical engineering calculations without being bloated. Each tool serves a specific purpose, and the count feels well-scoped for the domain.

Completeness4/5

The tool set covers short-circuit, arc flash, protection coordination, cable sizing, and other key areas. Missing advanced topics like load flow are outside the stated scope; only minor gaps like direct relay coordination tools are absent.

Resources