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

A4.8/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses error behavior ('Erro de FORMA... voltam em {"erro": ...}'), the no partial calculation policy, the interpretation of source contribution maximum (§7.1.2 d), and the free but limited usage. It also clarifies that the tool does not persist anything and returns content for the user to save.

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

Conciseness4/5

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

The description is long but well-structured with headers, code block examples, and clear hierarchical organization. It is appropriately detailed for a complex multi-parameter tool; however, some sentences could be tightened (e.g., the 'mesmo motor validado' phrase is somewhat promotional). Overall it remains efficient for the complexity.

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

Completeness4/5

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

The description covers input structure, error handling, the returned `projeto_json`, and user workflow. However, since there is no output schema, it does not fully specify the exact success output format for the calculated short-circuit results (e.g., per-bar Icc fields), leaving a slight gap in return-value transparency.

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?

Despite 0% schema description coverage, the description provides detailed semantics for all substantive parameters: `barras`, `elementos`, `fonte`, and `motores`, including field names, units, required/optional status, physical constraints, and examples. Only generic parameters like `lang` and `api_key` are left undocumented, but the core parameters are thoroughly explained.

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?

The description clearly states a specific action: 'Monta uma REDE MULTIBARRA... e calcula o curto-circuito IEC 60909 em TODAS as barras de uma vez'. It explicitly differentiates from the sibling tool `calcular_curto_circuito` by noting it is for 'VÁRIOS equipamentos' rather than 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?

The description gives explicit usage guidance: 'Use quando o usuário tem os dados de VÁRIOS equipamentos' and tells the agent to prefer this tool over calling `calcular_curto_circuito` multiple times. It also explains what to do with the returned `projeto_json` (save as .json, open in app, human review).

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

A4.1/5.0
Disambiguation5/5

Each tool targets a distinct electrical calculation or administrative task. Overlapping concepts like 'calcular_curto_circuito' and 'partida_motor' have clearly different purposes (short-circuit vs. voltage dip). No two tools appear to do the same thing.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in Portuguese, using snake_case. Examples include 'calcular_curto_circuito', 'dimensionar_cabo', and 'verificar_seccionamento'. There are no deviations or mixed conventions.

Tool Count5/5

20 tools is well-scoped for a specialized electrical engineering calculations server. Each tool addresses a specific need without redundancy or excessive breadth. The count feels appropriate for the domain.

Completeness5/5

The tool set covers a comprehensive lifecycle: calculation (short-circuit, arc flash, motor starting), design (cable sizing, CT sizing, capacitor banks), coordination (protection time curves), verification (shock protection), and workflow (report generation, quote request). No obvious gaps for the intended purpose.

Resources