Arc Flash Platform — Estudos Elétricos
Server Details
Cálculos de engenharia elétrica pelas normas brasileiras (NBR), validados, com citação normativa — 11 ferramentas, energia incidente IEEE 1584 validado. Nicho PT-BR.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 3.4/5 across 13 of 13 tools scored. Lowest: 2.6/5.
Each tool targets a distinct electrical engineering calculation (short circuit, arc flash, power factor, transformer damage, cable sizing, CT sizing, panel temperature, generator, motor starting, cable pulling, disconnection verification, plus memorial and list). No two tools have overlapping purposes, so an agent can easily distinguish them.
Tool names are descriptive but mix verb-first (calcular_, dimensionar_, corrigir_, gerar_, listar_, verificar_) and noun-first patterns (dano_, elevacao_, grupo_, partida_, puxamento_). This inconsistency can be confusing, though each name still conveys the topic.
13 tools is well-scoped for an electrical engineering calculation server. Each tool addresses a specific, non-trivial calculation, and the count is neither too few to be useful nor too many to navigate.
The tool set covers major electrical study areas (short circuit, arc flash, cable sizing, motor starting, etc.). Minor gaps exist (e.g., no load flow, protection relay coordination, or harmonics), but the core workflow for typical studies is present.
Available Tools
13 toolscalcular_curto_circuitoCurto-circuito (IEC 60909)BRead-onlyInspect
Curto-circuito (IEC 60909) pelo motor da plataforma: Icc 3φ/2φ/fase-terra,
X/R e pico. com_transformador=True dá o Icc no secundário (trafo_*). Plano
completo.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| tensao_kv | Yes | ||
| trafo_kVA | No | ||
| trafo_V2_kv | No | ||
| trafo_Vcc_pct | No | ||
| com_transformador | No | ||
| potencia_curto_mva | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true; the description adds context about secondary-side behavior with transformer flag, but does not disclose other behavioral traits.
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 extremely concise, consisting of two sentences with no redundancy. Key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema, the description is too brief. It does not specify input units, return values, or how to set other parameters, leaving the tool under-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?
With 0% schema description coverage, the description must explain parameters. It only addresses com_transformador, leaving tensao_kv, potencia_curto_mva, and transformer parameters undocumented.
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 the tool calculates short-circuit currents per IEC 60909, including 3-phase, 2-phase, phase-to-ground, X/R ratio, and peak current. This clearly distinguishes 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?
The description provides a conditional usage hint for the com_transformador parameter, but no explicit guidance on when to use this tool vs. alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_energia_incidenteEnergia incidente de arco (IEEE 1584 / NBR 17227)CRead-onlyInspect
Energia incidente (Ei, cal/cm²), LAS e categoria de EPI de um arco elétrico,
pelo motor IEEE 1584:2018 / ABNT NBR 17227:2025 VALIDADO da plataforma (208 V–
15 kV). config ∈ {VCB,VCBB,HCB,VOA,HOA}. O tempo de eliminação (t_arc_s) vem
da coordenação da proteção — é o que mais pesa. Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| config | No | VCB | |
| gap_mm | Yes | ||
| ibf_ka | Yes | ||
| api_key | No | ||
| t_arc_s | Yes | ||
| tensao_kv | Yes | ||
| dist_trabalho_mm | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the read-only nature is covered. The description adds context about the validated method, voltage range, and config options, but does not detail other behavioral traits like rate limits or required permissions beyond mentioning '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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with no redundant information. It front-loads the output and includes critical details like validation and voltage range. Minor improvement would be to structure parameter hints.
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 params, no output schema, many siblings), the description lacks key information: parameter explanations, output format, and when to prefer this tool over calcular_curto_circuito. It is adequate only for domain experts.
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?
Input schema has 7 parameters with 0% description coverage. The description only explains config and mentions t_arc_s, leaving the meaning of tensao_kv, ibf_ka, gap_mm, dist_trabalho_mm, and api_key entirely unexplained. This is insufficient for an AI to set them correctly.
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 calculates incident energy, LAS, and PPE category for arc flash using validated IEEE/NBR standards. It specifies the resource and action, but does not explicitly differentiate from sibling 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?
No guidance on when to use this tool versus alternatives. It mentions that t_arc_s comes from protection coordination and that it is free with limited use, but fails to provide usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
corrigir_fator_potenciaCorreção de fator de potência (REN 1.000)ARead-onlyInspect
Dimensiona o banco de capacitores para corrigir o fator de potência à
meta (REN ANEEL nº 1.000; FP-alvo padrão 0,92). Com tensao_kV também dá a
corrente nominal do banco e a norma (IEC 60831/60871). Gratuito (uso
limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| fp_meta | No | ||
| fp_atual | Yes | ||
| tensao_kV | No | ||
| potencia_kW | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, indicating the tool does not modify state. The description adds that with 'tensao_kV' the tool also gives nominal current and applicable standard (IEC 60831/60871), which is useful behavioral context. However, it does not elaborate on output behavior or side effects beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short sentences that pack essential information: main purpose with regulation and default, additional functionality with voltage, and usage limitation. No redundant words; front-loaded with the core action.
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 5 parameters and no output schema. The description only hints at additional outputs when voltage is provided (nominal current and standard), but does not describe the primary return value or the format of results. The api_key parameter remains unexplained. Given the complexity of capacitor bank dimensioning, the description is incomplete.
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 bears the burden. It explains the target power factor (fp_meta default 0.92), current power factor (fp_atual), power (potencia_kW), and voltage (tensao_kV) for additional outputs. The api_key parameter is not mentioned, which is a gap. Overall, the description adds significant meaning beyond the schema's bare titles and types.
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 banco de capacitores para corrigir o fator de potência à meta'. This is a specific verb-resource combo (dimension capacitor bank) and includes regulatory context (REN ANEEL nº 1.000) and default target factor (0.92). The sibling tools (e.g., dimensionar_cabo, calcular_curto_circuito) are distinct, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description mentions 'Gratuito (uso limitado)' but does not specify prerequisites, exclusions, or conditions for choosing this tool over siblings. The agent must infer usage context from the tool name and other sibling tools.
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)ARead-onlyInspect
Curva de dano a faltas passantes do transformador (IEEE C57.109/C57.12.59):
categoria, corrente de falta passante máxima (In/Z), ponto ANSI e ponto de
inrush — para coordenar a proteção a montante. fases ∈ {3ph,1ph};
frequencia_falta ∈ {infrequent,frequent}; tipo ∈ {liquid,dry}. Plano
completo.
| Name | Required | Description | Default |
|---|---|---|---|
| tipo | No | liquid | |
| Vn_kV | Yes | ||
| fases | No | 3ph | |
| Sn_kVA | Yes | ||
| Vcc_pct | Yes | ||
| api_key | No | ||
| k_inrush | No | ||
| frequencia_falta | No | infrequent |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds value by specifying the IEEE standards and computed outputs. It does not contradict annotations and provides useful behavioral context beyond the annotation alone.
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 sentence that efficiently conveys key information, but it is somewhat dense. Front-loading is good, but bullet points could 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?
No output schema exists, and while the description lists output concepts, it does not explain the return format or details. Parameter descriptions are partial. For a calculator tool with 8 parameters, the description is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description partially compensates by explaining possible values for 'fases', 'frequencia_falta', and 'tipo'. However, it does not cover all parameters (e.g., Sn_kVA, Vn_kV, Vcc_pct, k_inrush, api_key), 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 it computes the transformer damage curve per IEEE C57.109, listing outputs (category, max through-fault current, ANSI point, inrush point) and purpose (upstream protection coordination). It distinguishes itself from sibling calculation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for coordinating upstream protection but does not explicitly state when to use versus alternatives or give when-not-to-use guidance. The context of sibling tools helps, but explicit direction is missing.
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)BRead-onlyInspect
Dimensiona a seção de um cabo BT pela ABNT NBR 5410: ampacidade
(Tab. 36-39 + fatores), queda de tensão, coordenação de sobrecarga
(§5.3.4.1), neutro e PE. sistema ∈ {1FN,2F,3F,3FN}; metodo = método de
instalação (A1,A2,B1,B2,C,D,E,F,G); material ∈ {Cu,Al}; isolacao ∈
{PVC,EPR}. icc_quadro_kA = Icc presumida no quadro de origem (default 4,5;
informe o real para a verificação do disparo magnético). Gratuito (uso
limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| fp | No | ||
| metodo | No | B1 | |
| api_key | No | ||
| 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 | ||
| temp_ambiente_C | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=true, and description does not contradict. It adds context about limited usage (gratuito, uso limitado) and explains parameter details, but does not describe output format or error handling.
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 relatively concise, front-loading the main purpose. It uses inline code for parameter details, but lacks structured formatting (e.g., bullet points). Still efficient for its length.
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 12 parameters and no output schema, the description should be more comprehensive. It does not explain return values, algorithm steps, or constraints beyond the standard. Missing critical context for agent 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 description coverage is 0%, so description must compensate. It explains 5 parameters (sistema, metodo, material, isolacao, icc_quadro_kA) with allowed values, but 7 other parameters (e.g., fp, potencia_W, tensao_V) are left unexplained. Incomplete coverage.
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: dimensioning low voltage cable sections per NBR 5410, listing specific aspects (ampacity, voltage drop, overload coordination, neutral and PE). It differentiates from siblings by specifying the exact scope and standard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Mentions 'Gratuito (uso limitado)' but does not compare with sibling tools like 'dimensionar_tc' or 'puxamento_cabo'.
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)BRead-onlyInspect
Dimensiona o TC de proteção (IEC 61869-2 / NBR 6856): menor primário comercial que NÃO satura na falta, considerando o burden REAL (relé+fiação) e o ALF efetivo. Plano completo.
| Name | Required | Description | Default |
|---|---|---|---|
| ALF | Yes | ||
| Icc_A | Yes | ||
| api_key | No | ||
| burden_VA | Yes | ||
| cable_ohm | Yes | ||
| relay_ohm | Yes | ||
| secundario_A | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation 'readOnlyHint: true' is present, so the tool is clearly read-only. The description adds minimal behavioral context beyond 'dimensiona' and 'plano completo', which suggests but does not detail output. It does not contradict annotations, but it also does not meaningfully enhance transparency regarding side effects or 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 concise (two sentences) and front-loaded with the primary action. Every sentence adds value: the first defines the core function, the second indicates output scope ('plano completo'). There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, 6 required, specialized domain) and no output schema, the description is incomplete. It does not specify return values, expected input formats, or assumptions about the fault scenario. 'Plano completo' is vague and does not equip an agent to interpret results.
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% (no parameter descriptions). The description mentions key terms like 'Icc', 'secundario', 'ALF', 'burden', 'relé+fiação', which loosely map to parameters, but it does not explain units, ranges, or how they relate to each other. This is insufficient for an agent to correctly set parameters without external domain knowledge.
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's purpose: to size protection CTs according to IEC/NBR standards, selecting the smallest commercial primary that doesn't saturate under fault, considering real burden and effective ALF. It uses specific verb ('dimensiona') and resource ('TC de proteção'), distinguishing it from sibling tools like 'calcular_curto_circuito' or 'dimensionar_cabo'.
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 states what the tool does but does not explicitly indicate when to use it versus alternatives. No comparative context or exclusion criteria are provided. Usage is implied (for CT sizing tasks) but lacks guidance on prerequisites or situations where other tools are more appropriate.
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)CRead-onlyInspect
Elevação de temperatura do ar interno de um painel BT (IEC 60890) e
verificação de aceitação (61439-1). perda_W = perdas dissipadas no
invólucro; dimensões em metros. Plano completo.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| perda_W | Yes | ||
| altura_m | Yes | ||
| largura_m | Yes | ||
| ventilado | No | ||
| n_particoes | No | ||
| profundidade_m | Yes | ||
| temp_ambiente_C | No | ||
| area_ventilacao_cm2 | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the description does not need to repeat that. The description adds context about the computation method (IEC 60890) and parameter meaning, but it does not disclose other behavioral aspects like rate limits or side effects. It is consistent with annotations, adding modest value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus a code-style note. It front-loads the purpose and standard, then adds parameter clarification. No redundant or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and no default descriptions, the description should provide more context about expected outputs, default values, and behavior. It lacks explanation of what the tool returns (e.g., temperature rise value, pass/fail) and does not cover many parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It explains perda_W (power loss) and notes dimensions are in meters, but does not clarify the other 7 parameters (ventilado, n_particoes, temp_ambiente_C, area_ventilacao_cm2, api_key). Given the high number of parameters, this 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 the tool computes temperature rise in a low-voltage panel per IEC 60890 and acceptance per 61439-1. It specifies the main parameter (perda_W) and dimensions unit. While it does not explicitly differentiate from siblings, the specialized topic and unique standard reference make the purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or situations where it should not be used. Sibling tools are listed but without comparison.
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)BRead-onlyInspect
Memorial assinável + etiqueta ANSI/NBR. NUNCA é emitido autonomamente por IA — o documento é preparado na sua conta da plataforma para revisão e assinatura do responsável técnico.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| referencia_calculo | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, but the description says the document is 'preparado na sua conta da plataforma', implying creation or modification. This contradicts the readOnlyHint. The description adds workflow context but does not resolve the inconsistency.
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, front-loading the key purpose. It is concise and avoids unnecessary details, though it could briefly mention 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?
The tool lacks an output schema and has no parameter documentation. The description does not explain what 'referencia_calculo' is or how the document generation process works, leaving a significant knowledge gap for the agent given the tool's complexity and sibling 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?
Schema description coverage is 0%, and the description does not explain any parameters. The required parameter 'referencia_calculo' and optional 'api_key' lack any semantic meaning or usage guidance in the description, leaving the agent without necessary context to fill them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Memorial de cálculo (laudo na plataforma)' and description clearly state that the tool generates a signable calculation memorial document with ANSI/NBR label. It is distinct from sibling calculation tools which perform specific engineering calculations, not document generation.
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 'NUNCA é emitido autonomamente por IA', indicating the tool should not be used to autonomously issue the document. It clarifies that the document is prepared for review and signature by a technical responsible, providing clear when-to-use and when-not-to-use guidance.
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)BRead-onlyInspect
Afundamento transitório de tensão ao aplicar um degrau de carga a um
grupo gerador (ISO 8528-5, etapa 1: tensão), via reatância transitória X'd.
modo ∈ {bloco (degrau_kVA+degrau_fp), motor (motor_kW, partida DOL)}.
Plano completo.
| Name | Required | Description | Default |
|---|---|---|---|
| modo | No | bloco | |
| Sn_kVA | Yes | ||
| xd_pct | No | ||
| api_key | No | ||
| motor_kW | No | ||
| tensao_V | Yes | ||
| degrau_fp | No | ||
| classe_iso | No | G2 | |
| degrau_kVA | No | ||
| motor_Ip_In | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating no destructive side effects. The description adds that it simulates a transient event via X'd and follows ISO 8528-5, but it does not detail what the output contains or any additional behavioral 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 short and front-loaded with the main purpose. The term 'Plano completo' at the end is slightly vague but does not add unnecessary verbosity. It earns its place with minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema, no parameter descriptions in schema), the description is insufficient. It lacks explanation of return values, units, or usage examples, making it incomplete for an unfamiliar user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, but it only explains the mode parameter and its dependent parameters (degrau_kVA+degrau_fp for bloco, motor_kW for motor). Many other parameters (e.g., api_key, classe_iso) are not described, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates transient voltage dip when applying a load step to a generator set, referencing ISO 8528 standard. This is a specific verb+resource that distinguishes it from siblings like partida_motor or 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 mentions two modes (bloco and motor) with associated parameters, providing some usage context. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites.
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 ferramentasARead-onlyInspect
Lista a prateleira de cálculos de engenharia elétrica e o tier de cada um.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so no destructive behavior. The description adds that it 'lists the shelf of calculations and tiers,' providing context beyond the annotation by specifying the nature of the listing.
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?
A single sentence with no unnecessary words. It is direct and front-loaded with the main action ('Lista a prateleira'). Every word earns its place.
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 no parameters and only performs a simple listing, the description fully conveys what it does. No output schema is needed as the return is implied to be a list of calculations and tiers.
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 exist, so the description does not need to add parameter semantics. Baseline 4 is appropriate as the description is complete regarding input.
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 'Lists the shelf of electrical engineering calculations and the tier of each one.' It uses a specific verb (lista) and resource (prateleira de cálculos), and distinguishes this from sibling tools that are individual calculations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for browsing available calculations and their tiers. It does not explicitly state when to use it vs alternatives, but given no parameters and a listing purpose, the use case is clear. A more explicit 'use this to see all available tools' would improve it.
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ãoARead-onlyInspect
Afundamento de tensão na partida de motor por divisor fasorial
fonte→cabo→motor (C ∝ V²). metodo ∈ {direta, estrela_triangulo,
compensadora, soft, vfd}; a fonte entra como nível de curto scc_MVA.
Plano completo.
| Name | Required | Description | Default |
|---|---|---|---|
| fp | No | ||
| eta | No | ||
| Ip_In | No | ||
| cabo_m | No | ||
| metodo | No | direta | |
| api_key | No | ||
| scc_MVA | Yes | ||
| cabo_mm2 | No | ||
| tensao_V | Yes | ||
| potencia_kW | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description is consistent. It adds behavioral details by describing the calculation as a phasor divider model and listing key parameters (method, scc_MVA). This provides context beyond the annotation, though it could mention whether results are instantaneous or RMS.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and inline code. It front-loads the purpose and key constraint (C ∝ V²). However, the phrase 'Plano completo' is vague and could be more explicit. Overall, it avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema, no enum definitions), the description is insufficient. It lacks explanation of input ranges, default values, units, or output format. The agent needs more guidance to invoke the tool correctly, especially for parameters like cabo_mm2 and api_key.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It clarifies only two parameters (metodo and scc_MVA) and gives a formula hint. The other 8 parameters (potencia_kW, tensao_V, fp, eta, etc.) are not described in any detail, leaving the agent without understanding of their meaning or units.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calculates voltage dip ('afundamento de tensão') during motor starting using a phasor divider method. It specifies the resource (motor starting) and the verb (calculate voltage dip). It includes the method parameter and source short-circuit level, distinguishing it from siblings like 'calcular_curto_circuito'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly provide when to use this tool vs alternatives. It implies usage for motor starting voltage dip analysis but lacks context on when specific methods are appropriate or when to prefer sibling tools. No exclusions or alternative recommendations are given.
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)BRead-onlyInspect
Tração de puxamento de cabo (IEEE 1185/525) num trecho reto: tração no
cabrestante, SWBP, ocupação do duto (NBR 5410) e tração máxima admissível.
n_cabos ∈ {1,3} (trifólio). Plano completo.
| Name | Required | Description | Default |
|---|---|---|---|
| mu | No | ||
| od_mm | Yes | ||
| api_key | No | ||
| n_cabos | No | ||
| material | Yes | ||
| duto_D_mm | Yes | ||
| peso_kg_m | Yes | ||
| secao_mm2 | Yes | ||
| incl_graus | No | ||
| comprimento_m | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true. The description adds behavioral context: it computes specific physical quantities (traction, SWBP, occupancy, max allowable traction) and notes n_cabos ∈ {1,3} for trifoil. No permissions or rate limits are needed for a read-only calculation.
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?
Two sentences with targeted information. First sentence lists computed outputs; second adds constraint on n_cabos and claims 'full plan'. Minor improvement could be to separate outputs and parameter clarification.
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, so description must detail return values. It vaguely lists outputs but not format or units. With 10 parameters and no parameter descriptions, the agent is underinformed about inputs beyond names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only adds meaning for n_cabos (∈ {1,3}) and implies parameters relate to cable pulling. It does not explain the role of mu, api_key, material, dimensions, or weight. The agent lacks sufficient param hints.
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 computes cable pulling tension (IEEE 1185/525) for a straight section, including traction at capstan, SWBP, duct occupancy, and maximum allowable traction. It is distinct from sibling tools like calcular_curto_circuito or dimensionar_cabo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs alternatives. The description does not mention prerequisites, limitations, or exclusions. Agent must infer usage context from the domain.
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)BRead-onlyInspect
Verifica a proteção contra choque por seccionamento automático (ABNT NBR 5410:2004 §5.1.2.2). TN: Zs ≤ U0/Ia (informe Ia OU disjuntor In+curva_mcb). TT: RA ≤ 50/IΔn (informe i_dn_mA + RA). Gratuito (uso limitado).
| Name | Required | Description | Default |
|---|---|---|---|
| Ia_A | No | ||
| U0_V | Yes | ||
| RA_ohm | No | ||
| api_key | No | ||
| i_dn_mA | No | ||
| sistema | No | TN | |
| material | No | Cu | |
| curva_mcb | No | ||
| comprimento_m | No | ||
| disjuntor_In_A | No | ||
| secao_fase_mm2 | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, consistent with the verification nature of the tool. The description adds 'Gratuito (uso limitado)' indicating cost and usage constraints, but does not detail rate limits or authentication needs beyond mentioning an api_key parameter. 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 brief and front-loaded with purpose and relevant formulas. It packs regulation reference, system-specific instructions, and usage note into few sentences without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having many parameters (11) and no output schema, the description does not explain what the tool returns, how to interpret results, or how parameters relate. It covers only a few parameters indirectly, leaving significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description references Ia, disjuntor In+curva_mcb, i_dn_mA, RA, and U0 in formulas but does not map them clearly to the schema parameters. It hints at mutual exclusivity between Ia and disjuntor In+curva_mcb but provides no formal semantics or format requirements. Most parameters remain unexplained.
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 verifies protection against electric shock by automatic disconnection according to a specific standard (NBR 5410). The formulas for TN and TT systems further specify the scope. This distinguishes it from sibling tools like dimensionar_cabo or calcular_curto_circuito, which address different electrical design tasks.
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 checking seccionamento automatico by providing formulas for TN and TT systems. However, it does not explicitly state when to use this tool versus alternatives or mention prerequisites or limitations beyond 'uso limitado'. There is no clear guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Discussions
No comments yet. Be the first to start the discussion!