Cálculos de engenharia elétrica pela norma brasileira (NBR), validados, com citação normativa.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4/5 across 20 of 20 tools scored. Lowest: 3.3/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.
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.
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.
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.
calcular_curto_circuitoCurto-circuito (IEC 60909)ACurto-circuito (IEC 60909) pelo motor da plataforma: Icc 3φ/2φ/fase-terra,
X/R e pico. Informe a rede por potencia_curto_mva OU icc_rede_kA.
com_transformador=True dá o Icc no secundário (trafo_*). xr_rede/xr_trafo
= relações X/R (regem κ, pico ip e assimetria — o making do disjuntor);
tipo_aterramento ∈ {solido, resistivo, isolado} + Rn_ohm regem a corrente de
falta fase-terra (Icc_1φ). com_cabo=True (+ cabo_secao_mm2/cabo_m) dá o Icc no
PONTO de instalação após o cabo (menor que no barramento). Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| Rn_ohm | No | ||
| cabo_m | No | ||
| api_key | No | ||
| xr_rede | No | ||
| com_cabo | No | ||
| xr_trafo | No | ||
| tensao_kv | Yes | ||
| trafo_kVA | No | ||
| icc_rede_kA | No | ||
| trafo_V2_kv | No | ||
| cabo_material | No | Cu | |
| trafo_Vcc_pct | No | ||
| cabo_secao_mm2 | No | ||
| tipo_aterramento | No | solido | |
| com_transformador | No | ||
| potencia_curto_mva | No | ||
| cabo_num_condutores | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description details how parameters affect results (e.g., X/R ratios govern peak and asymmetry, grounding type affects phase-earth current, cable inclusion reduces fault current). It also notes the tool is free with limited use, adding 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 a single, dense paragraph with no wasted words. It front-loads the purpose and then logically sequences parameter explanations. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (17 parameters, no output schema), the description covers the main functionality and key parameters. It lacks explanation of return values or full parameter coverage, but provides enough for an agent to use correctly. The readOnlyHint annotation compensates for safety context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description compensates by explaining key parameters like network specification, transformer, X/R ratios, grounding, and cable. However, not all 17 parameters are covered (e.g., `cabo_material`, `cabo_num_condutores`, `api_key` are omitted). Still, it adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates short-circuit currents per IEC 60909, specifying types (Icc 3φ/2φ/phase-earth), X/R, and peak current. It distinguishes from sibling tools, which involve different electrical calculations (e.g., cable sizing, transformer damage).
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 usage guidance on how to specify parameters (e.g., use `potencia_curto_mva` or `icc_rede_kA`) but does not explicitly state when to use this tool over alternatives or any exclusions. Context from sibling tools implies distinct purposes, but no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_energia_incidenteEnergia incidente de arco (IEEE 1584 / NBR 17227)AEnergia incidente (Ei, cal/cm²), LAS e categoria de EPI de um arco elétrico,
pelo motor IEEE 1584:2018 / ABNT NBR 17227:2025 VALIDADO da plataforma (208 V–
15 kV). config ∈ {VCB,VCBB,HCB,VOA,HOA}.
Dois patamares de corrente (IEEE 1584:2018 §4.12): t_arc_s = tempo de
eliminação da proteção na corrente de arco PLENA (Iarc); t_arc_reduzido_s =
tempo na corrente REDUZIDA (Imin ≈ 0,88·Iarc). Como a corrente reduzida costuma
limpar mais devagar (proteção de tempo inverso), o patamar reduzido com
frequência GOVERNA o pior caso. Havendo dispositivo com curva inversa, forneça
os DOIS tempos; sem t_arc_reduzido_s, calcula um único patamar.
larg_mm/alt_mm/prof_mm = invólucro REAL do equipamento (a correção de tamanho
da §4.8 muda o Ei; default = caixa de referência 508³). Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| alt_mm | No | ||
| config | No | VCB | |
| gap_mm | Yes | ||
| ibf_ka | Yes | ||
| api_key | No | ||
| larg_mm | No | ||
| prof_mm | No | ||
| t_arc_s | Yes | ||
| tensao_kv | Yes | ||
| dist_trabalho_mm | Yes | ||
| t_arc_reduzido_s | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=true. The description adds substantial behavioral context: it calculates multiple outputs (Ei, LAS, PPE), uses validated engine, has two current levels, and influences results from enclosure dimensions. It also notes limited free usage. However, it does not discuss authentication (api_key) or error handling, and output structure is not specified.
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 concise paragraph of about six sentences. It is front-loaded with the main purpose and standard, followed by key technical details. While efficient, it could be slightly more structured (e.g., bullet points) for parsing, but overall it is well-sized and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, 5 required, no output schema), the description covers the core calculation and usage patterns but lacks details on return format, authentication (api_key), error conditions, and prerequisites. It is sufficient for an expert but incomplete for an AI agent needing full behavioral specification.
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 config (set of values), t_arc_s/t_arc_reduzido_s (clearing times), and enclosure dimensions (larg_mm/alt_mm/prof_mm) with defaults. However, required parameters (tensao_kv, ibf_ka, gap_mm, dist_trabalho_mm) are mentioned only in context of voltage range and not individually described, leaving gaps for an AI agent.
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 incident energy (Ei), LAS, and PPE category for arc flash using IEEE 1584:2018/NBR 17227:2025, specifying the voltage range (208 V–15 kV). It distinguishes from siblings implicitly via voltage range and provides technical details, making the purpose 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?
The description gives specific usage guidance on providing two clearing times for inverse-curve devices and explains when a single time suffices. However, it does not explicitly compare to sibling tools; the voltage range and standard used serve as indirect differentiators. It also mentions limited free usage, adding context on constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_energia_incidente_hvEnergia incidente > 15 kV — triagem (OSHA / Lee / EPRI)AEnergia incidente para sistemas > 15 kV — FORA do IEEE 1584:2018 / NBR 17227 (arco ao ar livre fase-terra). É TRIAGEM, NÃO laudo: o motor IEEE 1584 da plataforma NÃO é usado; gap e configuração de eletrodos não se aplicam.
metodo ∈ {osha (padrão), lee, epri}:
• osha — OSHA 1910.269 Apêndice E, Tab. 6/7 (base ArcPro). tipo_trabalho ∈
{luva (Tab.6, 4–46 kV), vara (Tab.7, 4–800 kV)}. Devolve a BANDA de EPI
conservadora (≤4/5/8/12 ou >12 cal/cm²), não um ponto.
• lee — cota TEÓRICA superior; exige dist_trabalho_mm.
• epri — modelo de alta tensão; exige dist_trabalho_mm + comprimento_arco_m
(vão físico fase-terra, em metros).
Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| t_ms | Yes | ||
| ibf_ka | Yes | ||
| metodo | Yes | ||
| api_key | No | ||
| tensao_kv | Yes | ||
| tipo_trabalho | No | luva | |
| dist_trabalho_mm | No | ||
| comprimento_arco_m | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No contradiction with annotations (readOnlyHint). Description adds context: it's a screening tool with limited free usage, not a full compliant calculation. Does not mention if any side effects exist, but as a read-only calculation, that's acceptable.
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?
Well-structured with clear sections, but could be slightly more concise. Front-loaded purpose, then method details, then usage note.
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 (8 params, 3 methods, no output schema), the description is comprehensive: covers method-specific behavior, output for OSHA (EPI band), and limitations. Missing explicit output schema but sufficiently described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, description explains each method's parameters in detail, including default values and conditions. Required params are implied; api_key is noted as optional via schema but not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Title and description clearly state it calculates incident energy for >15 kV systems, outside IEEE 1584, as a screening tool. Distinguishes from sibling 'calcular_energia_incidente' which likely covers <=15 kV.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (>15 kV, screening, not full laudo) and method selection criteria. Lacks explicit mention of alternatives but the sibling list provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
corrigir_fator_potenciaCorreção de fator de potência (REN 1.000)ADimensiona o banco de capacitores para corrigir o fator de potência à
meta (REN ANEEL nº 1.000; FP-alvo padrão 0,92). Com tensao_kV também dá a
corrente nominal do banco e a norma (IEC 60831/60871).
Un_cap_kV = tensão de placa do capacitor: se ele opera abaixo da Un, entrega
MENOS kvar (derating Q∝V²) e a correção real cai — informe p/ não superestimar.
carga_min_pct = carregamento mínimo (%): dispara o alerta de SOBRECORREÇÃO
capacitiva (banco fixo em carga leve → FP capacitivo, faturável).
scc_MVA = curto na barra do banco → inrush de manobra e a corrente de PROJETO
da proteção/cabo do banco (1,5·In BT, IEEE C37.012). Gratuito.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| fp_meta | No | ||
| scc_MVA | No | ||
| fp_atual | Yes | ||
| Un_cap_kV | No | ||
| tensao_kV | No | ||
| potencia_kW | Yes | ||
| carga_min_pct | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses detailed behavioral traits: derating due to voltage, overcorrection alert at light load, inrush current for protection design. Annotations only provide readOnlyHint and title, so the description adds significant context beyond them.
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 (5-6 sentences), front-loads the main purpose, and packs technical details without excessive verbosity. It could be slightly more structured, but it is well within acceptable limits.
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 no output schema and 8 parameters, the description covers the main behavior, parameter effects, and outputs (capacitor size, optional current, standard, alerts). It is reasonably complete 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?
With 0% schema description coverage, the description compensates well by explaining optional parameters (tensao_kV, Un_cap_kV, carga_min_pct, scc_MVA) and their effects. However, required parameters (potencia_kW, fp_atual) are not explicitly described, and api_key is not mentioned.
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 capacitor banks for power factor correction to a target (0.92) according to REN ANEEL 1.000. It uses a specific verb ('dimensiona') and resource ('banco de capacitores'), and it distinguishes from sibling tools by focusing on power factor correction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for power factor correction to meet regulatory standards but does not explicitly state when to use this tool versus alternatives. No direct comparison or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dano_transformadorCurva de dano de transformador (IEEE C57.109)BCurva de dano a faltas passantes do transformador (IEEE C57.109/C57.12.59):
categoria, corrente de falta passante máxima (In/Z), ponto ANSI e ponto de
inrush — para coordenar a proteção a montante. fases ∈ {3ph,1ph};
frequencia_falta ∈ {infrequent,frequent}; tipo ∈ {liquid,dry};
t_inrush_ms = patamar de tempo do ponto de inrush. ligacao (IEEE C37.91)
refere a curva ao OUTRO lado para coordenar com a proteção de lá: {dyg,ygd}
Δ-Yg ×0,58 · {dd,yy} ×0,87 · {ygyg,none} ×1,0. Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| tipo | No | liquid | |
| Vn_kV | Yes | ||
| fases | No | 3ph | |
| Sn_kVA | Yes | ||
| Vcc_pct | Yes | ||
| api_key | No | ||
| ligacao | No | none | |
| k_inrush | No | ||
| t_inrush_ms | No | ||
| frequencia_falta | No | infrequent |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, so description need not reiterate safety. Adds context about free but limited usage. Does not contradict annotations. Adequate but no further behavioral details (e.g., output format, prerequisites).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is reasonably concise given technical content, but includes some redundant phrasing (e.g., mentions inrush twice). Front-loaded with purpose. Could be more structured with bullet points for parameter options.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, no output schema, and complex technical context, description lacks explanation of required parameters and return value. Agent cannot infer output format or how curve is presented. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring description to compensate. Description explains 5 optional parameters (fases, frequencia_falta, tipo, t_inrush_ms, ligacao) but fails to describe 3 required parameters (Sn_kVA, Vn_kV, Vcc_pct) and other optional ones (api_key, k_inrush). Insufficient for an agent to understand required inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool computes a transformer damage curve per IEEE C57.109/C57.12.59, specifying purpose (coordinate upstream protection) and parameters. It distinguishes from sibling tools like calcular_curto_circuito or dimensionar_tc which have different functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for protection coordination but does not explicitly state when to use or avoid this tool vs alternatives. No direct comparison to sibling tools or mention of alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dessintonia_capacitorDessintonia de banco de capacitores (reator anti-ressonância)ABanco dessintonizado (reator série anti-ressonância). Informe p_pct (fator
de dessintonia XL/XC, ex.: 7 ou 14) OU L_mH. Devolve a tensão ELEVADA no
capacitor V/(1−p), a corrente pelo reator, o reativo efetivo Q/(1−p), a
frequência de sintonia e a classe de tensão sugerida do capacitor (IEC 60831).
Com scc_MVA, avalia a ressonância paralela com a rede. Gratuito.
| Name | Required | Description | Default |
|---|---|---|---|
| L_mH | No | ||
| p_pct | No | ||
| Q_kvar | Yes | ||
| api_key | No | ||
| scc_MVA | No | ||
| Un_cap_kV | No | ||
| tensao_kV | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description adds value by detailing the computed results (e.g., V/(1−p), Q/(1−p)) and mentioning the tool is free. It does not contradict annotations and provides additional context beyond the structured fields.
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 (four sentences) and front-loads the main purpose. However, it could be more structured by separating required vs. optional parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no output schema), the description is incomplete. It omits explanations of required parameters, return format, units, assumptions, and error handling. The listed outputs are helpful but not fully specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the optional parameters p_pct, L_mH, and scc_MVA, but fails to mention the required parameters Q_kvar and tensao_kV. With 0% schema description coverage, the description should compensate for all parameters, but it leaves major 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 specifies the tool is for detuned capacitor bank (anti-resonance reactor) and lists the exact outputs: increased voltage, reactor current, effective reactive power, tuning frequency, and voltage class. It distinguishes itself from sibling tools by its focus on capacitor bank detuning.
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 guidance on parameter usage: input either p_pct or L_mH, and optionally scc_MVA. However, it does not explicitly state when to use this tool versus alternative tools (e.g., power factor correction) or provide prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dimensionar_caboDimensionamento de cabo BT (NBR 5410)ADimensiona a seção de um cabo BT pela ABNT NBR 5410: ampacidade
(Tab. 36-39 + fatores), queda de tensão, coordenação de sobrecarga
(§5.3.4.1), neutro e PE. sistema ∈ {1FN,2F,3F,3FN}; metodo = método de
instalação (A1,A2,B1,B2,C,D,E,F,G); material ∈ {Cu,Al}; isolacao ∈
{PVC,EPR}. icc_quadro_kA = Icc presumida no quadro de origem.
n_circuitos_agrupados = nº de circuitos no mesmo eletroduto/leito (aplica
o fator de agrupamento da Tab. 42 — reduz a ampacidade); arranjo ∈
{feixe,camada}. disjuntor_In_A/curva_disjuntor (B,C,D) = o dispositivo
REAL instalado (sem eles, assume o menor MCB ≥ Ib, curva C). Gratuito.
| Name | Required | Description | Default |
|---|---|---|---|
| fp | No | ||
| metodo | No | B1 | |
| api_key | No | ||
| arranjo | No | feixe | |
| sistema | No | 3FN | |
| isolacao | No | PVC | |
| material | No | Cu | |
| tensao_V | Yes | ||
| potencia_W | Yes | ||
| comprimento_m | Yes | ||
| icc_quadro_kA | No | ||
| queda_max_pct | No | ||
| disjuntor_In_A | No | ||
| curva_disjuntor | No | C | |
| temp_ambiente_C | No | ||
| n_circuitos_agrupados | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint: true, indicating no destructive side effects. The description adds context about defaults, the standard applied, and parameter meanings. It does not mention output format or error handling, but the behavioral safety is well covered.
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 conveys the purpose and parameters. While front-loaded, it could benefit from more structured formatting (e.g., list of parameters) to improve readability, but it is still concise for the complexity.
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 the calculation basis thoroughly but omits the output format (e.g., what the tool returns). Given no output schema, this is a notable gap. Additionally, it doesn't mention error conditions or prerequisites, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining the meaning, allowed values, and defaults for key parameters like sistema, metodo, material, isolacao, disjuntor_In_A, etc., adding significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: dimension a low voltage cable according to ABNT NBR 5410, listing the specific aspects (ampacity, voltage drop, etc.). It is specific and distinguishes from sibling tools which are 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 tool is implicitly for cable sizing, and sibling tools cover different calculations, so there is no confusion. However, no explicit 'when to use' or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dimensionar_tcDimensionamento de TC (IEC 61869-2)ADimensiona o TC de proteção (IEC 61869-2 / NBR 6856): menor primário
comercial que NÃO satura na falta, considerando o burden REAL (relé+fiação)
e o ALF efetivo. xr (X/R) = liga o critério de saturação na falta
ASSIMÉTRICA (offset CC, IEEE C37.110): um TC que passa no simétrico pode
saturar no transitório, atrasar o relé e ELEVAR a energia incidente de arco.
I_load_A+Fter = corrente de carga p/ o critério térmico contínuo.
Ith_A/Idyn_A = corrente térmica (I²t, com t_curto_s/tth_s) e dinâmica
de catálogo → robustez à falta passante (se o TC AGUENTA o curto sem dano
térmico/mecânico). Rct_ohm = R do secundário de catálogo (None → estimada).
Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| xr | No | ||
| ALF | Yes | ||
| Fter | No | ||
| Icc_A | Yes | ||
| Ith_A | No | ||
| tth_s | No | ||
| Idyn_A | No | ||
| Rct_ohm | No | ||
| api_key | No | ||
| I_load_A | No | ||
| burden_VA | Yes | ||
| cable_ohm | Yes | ||
| relay_ohm | Yes | ||
| t_curto_s | No | ||
| secundario_A | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to restate that. However, it adds valuable behavioral context: explains how xr enables asymmetric fault criterion, how Ith/Idyn relate to thermal/dynamic withstand, and that Rct_ohm can be estimated. This goes beyond annotations, providing operational transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the main purpose. It includes parameter explanations and usage notes without excessive verbiage. While it could be more structured with bullet points, every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, no output schema, no parameter descriptions), the description is remarkably complete. It covers the core algorithm, relevant standards (IEC 61869-2, NBR 6856, IEEE C37.110), and explains how each parameter affects the result. The lack of output schema is compensated by implying the result (smallest commercial primary).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains many key parameters: burden (burden_VA, relay_ohm, cable_ohm), ALF, Icc_A, xr, I_load_A+Fter for thermal criterion, Ith/Idyn for thermal/dynamic, and Rct_ohm. It connects parameters to the mathematical criteria, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Dimensiona o TC de proteção (IEC 61869-2 / NBR 6856): menor primário comercial que NÃO satura na falta...' It uses a specific verb (dimensionar) and resource (TC de proteção) with detailed scope, and distinguishes itself from sibling tools by focusing on CT dimensioning, which no other sibling does.
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 does not provide any explicit guidance on when to use this tool versus alternatives. It mentions 'Gratuito (uso limitado)' but that's a limitation, not usage context. No comparisons to sibling tools or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
elevacao_temperatura_painelElevação de temperatura em painel (IEC 60890)AElevação de temperatura do ar interno de um painel BT (IEC 60890) e
verificação de aceitação (61439-1). perda_W = perdas dissipadas no
invólucro; dimensões em metros. Exposição das faces (muda a área de
resfriamento): face_topo ∈ {exposto,coberto}; face_traseira/face_laterais
∈ {exposta,coberta} (coberta = encostada na parede / em fila → aquece mais).
tipo_instalacao 1–5 (Fig. 4); limite_equip_C = limite térmico do
equipamento interno (2º veredito); regime ∈ {BT, MT (estimativa)}. Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| regime | No | BT | |
| api_key | No | ||
| perda_W | Yes | ||
| altura_m | Yes | ||
| face_topo | No | exposto | |
| largura_m | Yes | ||
| ventilado | No | ||
| n_particoes | No | ||
| face_laterais | No | exposta | |
| face_traseira | No | exposta | |
| limite_equip_C | No | ||
| profundidade_m | Yes | ||
| temp_ambiente_C | No | ||
| tipo_instalacao | No | ||
| area_ventilacao_cm2 | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, indicating no side effects. The description adds context that covered faces increase heating and that the tool is free with limited use. It does not contradict annotations and transparently explains behavioral aspects beyond the structured field.
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 front-loads purpose and then lists parameter details. It is reasonably concise given the number of parameters, but could benefit from better structuring (e.g., bullet points) for easier scanning.
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 15 parameters, no output schema, and only readOnlyHint annotation, the description covers purpose and parameter meanings adequately. However, it lacks explanation of the return value (e.g., temperature rise, pass/fail) and how to interpret results, which is a notable 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 coverage, the description explains key parameters: perda_W, dimensions, face states, tipo_instalacao, limite_equip_C, and regime. It clarifies meanings and allowed values for face parameters. However, some parameters (ventilado, n_particoes, temp_ambiente_C, area_ventilacao_cm2, api_key) are not explained, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates temperature rise of internal air in a LV panel per IEC 60890 and verifies acceptance per 61439-1. It specifies the resource (panel enclosure) and action (temperature rise calculation and verification). Among siblings, it is unique in addressing panel temperature, leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for thermal analysis of LV panels (with MV as estimation), but does not explicitly state when to use this tool versus alternatives or provide exclusions. No sibling comparison or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gerar_memorialMemorial de cálculo (laudo na plataforma)AMemorial 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?
Annotations provide readOnlyHint=true, and the description adds that the document is prepared for review and signature, which implies a non-destructive workflow. However, it does not detail what happens upon invocation (e.g., response format).
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, well-structured sentence that conveys essential information without superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal parameter descriptions, the description lacks critical information. The agent cannot determine the return value or how to properly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Neither the description nor the input schema (0% coverage) provide any explanation of the parameters. The agent cannot infer what 'referencia_calculo' means or how to use 'api_key'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a 'Memorial assinável + etiqueta ANSI/NBR' and emphasizes it is never autonomously issued by AI. This distinguishes it from sibling tools, which are mostly 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 warns that the tool should not be used to autonomously emit the document ('NUNCA é emitido autonomamente por IA'), providing clear context for responsible use. However, it does not explicitly state when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
grupo_geradorGrupo gerador — degrau de carga (ISO 8528)AAfundamento transitório de tensão ao aplicar um degrau de carga a um
grupo gerador (ISO 8528-5, etapa 1: tensão), via reatância transitória X'd.
modo ∈ {bloco (degrau_kVA+degrau_fp), motor (motor_kW, partida DOL)}.
XR = X/R da X'd (ângulo da queda). cabo_mm2+cabo_m = alimentador
gerador→carga (a queda no cabo soma no ΔV). dv_limite_pct sobrepõe o limite
da classe — OBRIGATÓRIO para classe_iso="G4" (limite por acordo).
motor_fp_rotor_bloqueado = FP de partida (modo motor). Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| XR | No | ||
| modo | No | bloco | |
| Sn_kVA | Yes | ||
| cabo_m | No | ||
| xd_pct | No | ||
| api_key | No | ||
| cabo_mm2 | No | ||
| motor_kW | No | ||
| tensao_V | Yes | ||
| degrau_fp | No | ||
| classe_iso | No | G2 | |
| degrau_kVA | No | ||
| motor_Ip_In | No | ||
| dv_limite_pct | No | ||
| motor_fp_rotor_bloqueado | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds behavioral context: it is free but limited use ('Gratuito (uso limitado)'), it uses transient reactance X'd, and parameters like cable dimensions affect the voltage drop. 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 single paragraph that packs substantial detail without wordiness. It uses parentheses to list parameter details efficiently. Could be slightly more structured, but it remains clear and 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?
The tool has no output schema, yet the description does not explain what the tool returns (e.g., voltage sag percentage or a report). It mentions 'ΔV' but does not specify output format. For a complex tool with 15 parameters, this gap reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining many parameters: modo, XR, cabo_mm2, cabo_m, dv_limite_pct, motor_fp_rotor_bloqueado. However, required parameters tensao_V and Sn_kVA are not explicitly defined, relying on the title and context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates transient voltage sag during a load step on a generator group per ISO 8528-5, with two modes (block and motor). It differentiates from siblings like partida_motor and calcular_curto_circuito by focusing on generator response to load steps.
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 operating modes (block and motor) and key parameters like dv_limite_pct for class G4. It does not explicitly state when not to use or name alternatives, but the context of generator load step is clear from the description and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
k_factor_transformadorK-factor de transformador (UL 1561)AK-factor (UL 1561) a partir do espectro de corrente {ordem: % de I1}, ex.: {"3": 70, "5": 45, "7": 30}. Devolve o K-factor, o K-rating comercial (trafo K-rated para cargas não-lineares), o F_HL (derating de perdas parasitas, IEEE C57.110) e o THD de corrente. Gratuito.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| espectro_harmonico | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, consistent with a non-destructive calculation. The description adds that the tool returns multiple computed values and is free, but does not detail rate limits or other constraints.
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 two sentences with no wasted words. It front-loads the purpose and includes a concrete example efficiently.
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, so the description's enumeration of outputs (K-factor, K-rating, F_HL, THD) is valuable. It covers input format and output, but could add details on error handling or value ranges.
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 bears the burden. It explains the main parameter 'espectro_harmonico' with an example format. However, it does not mention the optional 'api_key' parameter, leaving its purpose unclear.
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 K-factor, K-rating, F_HL, and THD from a harmonic current spectrum, referencing standards UL 1561 and IEEE C57.110. It distinguishes itself from sibling tools (e.g., 'calcular_curto_circuito') by its specific purpose.
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 an example input format and lists outputs, implying use for transformer K-factor calculation. It does not explicitly state when not to use it or name alternatives, but the sibling list provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
listar_dispositivosCatálogo de dispositivos de proteçãoALista o catálogo de dispositivos (devices_db) para descobrir o device_id usado
no modo catálogo de tempo_de_atuacao. Por padrão só MCCB/ACB (trip eletrônico com In_A
real); tipo filtra ('MCCB','ACB','Relay','MCB','Fuse','Transformer'); todos=True
inclui todos os tipos. Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| tipo | No | ||
| todos | No | ||
| api_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, consistent with description. Description adds context of limited free usage and default filtering behavior. No contradiction. Could mention output format, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences in Portuguese, front-loaded with purpose and usage. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description explains purpose and integration with sibling tool. Missing api_key parameter explanation and specific return format, but adequate for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description explains 'tipo' and 'todos' parameters with valid values and effect. However, 'api_key' parameter is not described, leaving a 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?
Description clearly states the tool lists the device catalog to find device_id for use with tempo_de_atuacao. It specifies the default filter (MCCB/ACB) and how to change it via parameters, distinguishing it 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?
Description explains default behavior and parameter usage for filtering. It implies usage context (prerequisite for tempo_de_atuacao) but does not explicitly state when not to use or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
listar_ferramentasCatálogo de ferramentasALista a prateleira de cálculos de engenharia elétrica e o tier de cada um.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds that it lists tiers, providing useful behavioral context 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?
Single sentence, no wasted words. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no parameters, the description fully covers what it does and what output to expect (list of calculations with tiers). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema, so description doesn't need to add parameter info. Baseline 4 for zero parameters applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists the catalog of electrical engineering calculations and their tiers. This verb+resource combination distinguishes it from sibling tools like calcular_curto_circuito 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?
No explicit when-to-use or when-not-to-use guidance. Usage is implied: to see available tools. Could mention alternatives like directly calling a specific calculation if you already know which one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
partida_motorPartida de motor — afundamento de tensãoAAfundamento de tensão na partida de motor por divisor fasorial
fonte→cabo→motor (C ∝ V²). fonte_tipo ∈ {scc (nível de curto scc_MVA),
trafo (fonte_trafo_kVA+fonte_trafo_Vcc_pct, com rede a montante opcional
fonte_scc_montante_MVA), gerador (fonte_gmg_kVA+fonte_gmg_xd_pct, X'd
transitório)} — trafo dedicado e GMG são os casos SEVEROS de afundamento.
metodo ∈ {direta, estrela_triangulo, compensadora_65, compensadora_80,
soft_starter, vfd} (aceita 'compensadora'→tap 80% e 'soft'→soft_starter).
fp_partida = FP de rotor bloqueado; Cp_Cn = conjugado de partida/nominal;
C_load_pu = conjugado da carga (×Cn) — SEM ele a aceleração NÃO é avaliada.
Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| fp | No | ||
| eta | No | ||
| In_A | No | ||
| Cp_Cn | No | ||
| Ip_In | No | ||
| cabo_m | No | ||
| metodo | No | direta | |
| api_key | No | ||
| scc_MVA | No | ||
| cabo_mm2 | No | ||
| tensao_V | Yes | ||
| C_load_pu | No | ||
| fonte_tipo | No | scc | |
| fp_partida | No | ||
| potencia_kW | Yes | ||
| dv_limite_pct | No | ||
| fonte_gmg_kVA | No | ||
| fonte_trafo_kVA | No | ||
| fonte_gmg_xd_pct | No | ||
| fonte_trafo_Vcc_pct | No | ||
| fonte_scc_montante_MVA | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true; the description adds behavioral details (source types, method, parameter interdependencies) but does not describe the output or confirm read-only behavior. The 'free limited use' note is extraneous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that front-loads the purpose. Each sentence adds value, though it could be better structured with bullet points for parameter sets.
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 21 parameters and no output schema, the description is incomplete. It lacks explanation for many parameters, does not specify the output format (e.g., voltage dip percentage), and omits usage conditions like required prerequisites or result interpretation.
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 schema description coverage at 0%, the description adds meaning for about 6 key parameters (fonte_tipo, metodo, fp_partida, Cp_Cn, C_load_pu) but leaves many others (tensao_V, potencia_kW, cabo_m, etc.) unexplained. It partially compensates but is insufficient for 21 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates voltage dip during motor starting using a phasor divider model. It specifies the main verb (calculates voltage dip) and resource (motor starting), distinguishing it from sibling tools like tempo_partida_motor (motor 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 context on when to use different source types (e.g., dedicated transformer and generator are severe cases) and notes that acceleration evaluation requires C_load_pu. However, it does not explicitly state when not to use the tool or compare with alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
puxamento_caboPuxamento de cabo (IEEE 1185/525)ATração de puxamento de cabo (IEEE 1185/525): tração no cabrestante, SWBP
(pressão lateral nas curvas), ocupação do duto (NBR 5410) e tração máxima
admissível. n_cabos ∈ {1,3} (trifólio). curvas_graus = lista dos ângulos
das curvas/cotovelos (graus) — SEM curvas a SWBP (que costuma GOVERNAR) sai
zero; curva_raio_m = raio das curvas (m). attachment ∈ {olhal (no
condutor), malha (na capa, teto 500 kgf)}. convencao ∈ {BR,NA,EU};
swbp_classe/cabo_classe ∈ {BT, MT, controle, armado, ...}. Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| mu | No | ||
| od_mm | Yes | ||
| api_key | No | ||
| n_cabos | No | ||
| material | Yes | ||
| convencao | No | BR | |
| duto_D_mm | Yes | ||
| peso_kg_m | Yes | ||
| secao_mm2 | Yes | ||
| attachment | No | olhal | |
| incl_graus | No | ||
| cabo_classe | No | BT_unipolar | |
| swbp_classe | No | BT | |
| curva_raio_m | No | ||
| curvas_graus | No | ||
| comprimento_m | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds behavioral context: it is a calculation tool (no side effects), free with limited use, and explains that SWBP is zero without bends. This goes beyond the annotation's read-only hint.
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 front-loads the main outputs, then explains key parameter constraints. While it includes some extraneous details (e.g., 'Gratuito (uso limitado)'), the overall structure is efficient for the information provided.
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 16 parameters and no output schema, the description explains the calculation purpose and a few parameters, but fails to describe the output format, all conventions, or provide examples. It is moderately complete but leaves gaps for complex usage.
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 explain parameters. It covers some (e.g., n_cabos, curvas_graus, attachment, convencao, swbp_classe, cabo_classe) but neglects required parameters like secao_mm2, material, od_mm, peso_kg_m, duto_D_mm, comprimento_m. This leaves significant gaps for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool computes cable pulling traction per IEEE 1185/525, listing four specific outputs (tração no cabrestante, SWBP, ocupação do duto, tração máxima admissível). This distinguishes 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 implies usage through its technical content (e.g., mentioning that SWBP governs and is zero without bends), but does not explicitly state when to use this tool versus alternatives. No when-not or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
solicitar_orcamentoSolicitar orçamento de estudo/laudo (ART)BEncaminha 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?
The annotation readOnlyHint: true contradicts the description's implication of a write action ('Encaminha um pedido'). The description adds behavioral context about not consuming calculation limits, but the contradiction reduces reliability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) front-loaded with the core purpose. Each sentence adds value: purpose, required info, and special characteristic. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the basic workflow and a key behavioral constraint. However, it lacks details on return values, parameter descriptions for all fields, and prerequisites for using the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'Informe o e-mail de contato e o escopo', covering email and escopo, but omits nome, empresa, and api_key. With 5 parameters, this partial coverage is insufficient.
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 'Encaminha um pedido de ORÇAMENTO de estudo/laudo assinável com ART', specifying the verb (encaminhar/solicitar) and resource (orçamento de estudo/laudo). This distinctly separates it from sibling calculation tools like calcular_curto_circuito.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use: when needing a budget quote, especially noting 'funciona inclusive quando o uso gratuito do dia esgotou'. It does not explicitly state when not to use or name alternatives, but sibling tools naturally provide alternatives for calculations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tempo_de_atuacaoTempo de atuação da proteção (IEC 60255-151 / IEEE C37.112)ATempo de atuação de um dispositivo de proteção à corrente de falta, pela curva
composta 4-segmentos do motor da plataforma (IEC 60255-151 / IEEE C37.112): 51
inversa · 50 curto-tempo · 50 instantânea. É o ELO entre o curto e o arco: encadeie
calcular_curto_circuito → tempo_de_atuacao → calcular_energia_incidente (o tempo_s
daqui é o t_arc_s, o parâmetro mais difícil de estimar à mão).
MANUAL (universal): pickup_A = pickup do 51 (relé: RTC×tap; disjuntor: Ir); curva
∈ IEC/IEEE; tms = TMS (IEC) ou time-dial (IEEE); instantaneo_A+t_disjuntor_ms
(50 instantânea) e curto_tempo_A+t_curto_tempo_ms (50 temporizada) são opcionais —
sem eles, só a inversa opera. CATÁLOGO: device_id de MCCB/ACB (use listar_dispositivos).
Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| tms | No | ||
| curva | No | IEC Very Inverse (VI) | |
| api_key | No | ||
| pickup_A | No | ||
| device_id | No | ||
| curto_tempo_A | No | ||
| instantaneo_A | No | ||
| t_disjuntor_ms | No | ||
| corrente_falta_A | Yes | ||
| t_curto_tempo_ms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions it is a calculation tool with limited free usage, but does not add behavioral context beyond what the readOnlyHint annotation already implies. 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 well-structured and front-loaded, starting with the purpose and chain context. It is moderately long but every sentence adds value; could be slightly more concise but is appropriate for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters, no output schema, and no enum constraints, the description provides sufficient context including the chain usage, manual vs catalog modes, and cost information. It covers the essential aspects for an agent to select and invoke the tool correctly.
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 fully by explaining the purpose of each key parameter (pickup_A, curva, tms, instantaneo_A, t_disjuntor_ms, curto_tempo_A, t_curto_tempo_ms, device_id) and the optional behavior for the 50 instantaneous and short-time elements.
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 operating time of a protection device using specific curves (IEC/IEEE) and positions it within a three-step chain (calcula_curto_circuito → tempo_de_atuacao → calcular_energia_incidente), differentiating it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (after short-circuit calculation, before incident energy) and provides both manual and catalog usage modes. However, it does not explicitly state when not to use it or list alternatives beyond the chain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tempo_partida_motorTempo de partida de motor (curva T×n + rotor térmico)ASimula 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?
Annotations declare readOnlyHint=true, consistent with the simulation. The description adds valuable behavioral details: the numerical method (RK4, differential equation), the specific standard (Petrobras N-313), and the evaluated criteria (I²t vs locked-rotor time). This exceeds minimum disclosure without contradicting 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, information-dense paragraph with no wasted words. It front-loads the purpose and method. However, it could be more structured (e.g., bullet points for parameters) 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 the complexity (17 parameters, no output schema), the description explains the simulation method and some outputs (acceleration time, start/stall, thermal verdict) but omits many parameter meanings and does not describe the full response format. Behavior on invalid inputs or data limits is not addressed, leaving gaps.
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 5 of 17 parameters (polos, inercia_kgm2, tipo_carga, conjugado_partida_carga_pu, conjugado_pleno_pu, t_rotor_bloqueado_s) but leaves critical parameters like potencia_kW, tensao_V, and scc_MVA unexplained. The value added is partial.
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 specifies a precise action: simulating direct motor starting in time using RK4, including acceleration time, start/stall determination, and thermal rotor blocked verification per the Petrobras N-313 criterion. It clearly distinguishes from sibling tools like 'partida_motor' by emphasizing the 'DIRETA' method and thermal analysis.
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 does not provide guidance on when to use this tool over alternatives such as 'partida_motor'. No prerequisites, context, or exclusions are mentioned, leaving the agent to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verificar_seccionamentoSeccionamento automático (NBR 5410)AVerifica a proteção contra choque por seccionamento automático
(ABNT NBR 5410:2004 §5.1.2.2). TN: Zs ≤ U0/Ia (informe Ia OU disjuntor
In+curva_mcb). TT: RA ≤ 50/IΔn (informe i_dn_mA + RA).
situacao = 1 (seco/usual, U_L=50 V) ou 2 (molhado/externo, U_L=25 V e
tempo da Tab. 25 mais rígido). R_montante_ohm+X_montante_ohm = impedância
do laço A MONTANTE (fonte/trafo + alimentadores) — sem ela o Zs conta só o
circuito e o veredito fica OTIMISTA. circuito_tipo ∈ {terminal_le32,
distribuicao_gt32}; secao_pe_mm2 = PE real (None → mínimo da Tab. 58).
Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| Ia_A | No | ||
| T_op | No | ||
| U0_V | Yes | ||
| RA_ohm | No | ||
| api_key | No | ||
| i_dn_mA | No | ||
| sistema | No | TN | |
| material | No | Cu | |
| situacao | No | ||
| curva_mcb | No | ||
| secao_pe_mm2 | No | ||
| circuito_tipo | No | terminal_le32 | |
| comprimento_m | No | ||
| R_montante_ohm | No | ||
| X_montante_ohm | No | ||
| disjuntor_In_A | No | ||
| secao_fase_mm2 | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint: true, and the description does not contradict this. The description adds behavioral context: formulas, dependency on upstream impedance, and 'Gratuito (uso limitado)' indicating usage limits. It does not elaborate on output format, but the core read-only behavior is well supported.
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 without clear structure or bullet points. It conveys much information but could be more concise or organized. It is front-loaded with purpose, but the technical details could be streamlined.
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 covers the most critical aspects but does not explain the output (e.g., pass/fail or numeric result) nor all parameters. It adequately addresses the tool's core functionality for an agent but lacks full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining key parameters: situacao, R_montante_ohm, X_montante_ohm, circuito_tipo, secao_pe_mm2, and the TN/TT parameter choices. However, it omits several parameters like T_op, comprimento_m, and secao_fase_mm2, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Verifica a proteção contra choque por seccionamento automático' (verifies protection against shock by automatic disconnection) with reference to NBR 5410. This verb+resource is specific and distinct from sibling tools like calcular_curto_circuito which focuses on short-circuit current magnitude.
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 usage context by explaining the two system types (TN and TT) with required parameters and conditions. It warns about the optimistic result without upstream impedance. However, it does not explicitly state when to avoid this tool or suggest alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
