Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CableSizeCalculatorMCP What size cable for a 20 A, 230 V, 20 m single-phase copper flat 2C+E run in thermal insulation?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An experimental, offline Model Context Protocol server for AC cable-sizing calculations. It evaluates current capacity, voltage drop, selected protection constraints, and conductor thermal withstand using bundled or operator-supplied reference data.
Calculations are experimental and do not certify an installation or establish standards compliance. The bundled reference data is public domain; its numerical accuracy has not been independently validated.
The model supports single-phase and three-phase AC calculations, copper or aluminium active conductors, and separately specified earth conductor material. DC is unsupported because the model uses AC resistance and reactance data. Installation categories and insulation labels describe the model; their suitability depends on the supplied dataset's construction, conductor loading, reference conditions, and other assumptions.
Sizing evaluates every candidate against current capacity and unrounded voltage drop. Optional breaker and fault inputs enable further checks. Results and reports identify which checks were performed or omitted. A successful selection means that the requested calculations passed under the supplied assumptions; it is not a declaration of standards compliance. Network fault impedance, breaker characteristics, actual clearing times, and reference-data applicability must be established for the installation.
For single-phase copper V90 flat 2C+E cable, set cable_construction="flat_2c_earth". With installation_method="in_thermal_insulation", also set insulation_exposure to "partially_surrounded" or "completely_surrounded". For the supplied 20 A, 20 m, 230 V comparison, these select 4 mm² and 6 mm² respectively. The unenclosed-in-air profile selects 2.5 mm².
These profiles use the lower bounds of the supplied JCalc rating ranges and cover only the supplied sizes. Unsupported profile combinations are rejected, and sizing stays within the selected profile's coverage. The default "generic" construction uses the legacy ratings. Results identify the rating basis; profile selection changes current capacity, while the other checks use the dataset's impedance, earth-pairing and thermal tables.
Related MCP server: security-orchestra
Python 3.12 or later and uv are required for the development setup:
uv syncThe server loads the bundled dataset by default. To use a different dataset, set CABLESIZE_DATA_FILE to a local JSON file before starting the process:
$env:CABLESIZE_DATA_FILE = (Resolve-Path "./private-data/cable-data.local.json").Path
uv run cablesizecalculatorexport CABLESIZE_DATA_FILE=/absolute/path/to/cable-data.local.json
uv run cablesizecalculatorUse reference_data.json as the format for a custom dataset. The loader checks metadata and numerical table completeness. Restart the server after changing the dataset. An invalid override fails with a configuration error.
Tests generate a synthetic dataset to exercise the code. Those values are deliberately not electrical design references and must not be used for installation design.
Replace the paths in this example with your checkout and private data locations. Omit the env entry to use the bundled data:
{
"mcpServers": {
"cablesizecalculator": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/CableSizeCalculatorMCP",
"run",
"cablesizecalculator"
],
"env": {
"CABLESIZE_DATA_FILE": "/absolute/path/to/cable-data.local.json"
}
}
}
}size_cable: Select a candidate against the requested model constraints.
calculate_voltage_drop: Calculate AC voltage drop for a given conductor and route.
calculate_derating: Apply conservative temperature, grouping, and burial-depth lookups within supported ranges.
check_loop_impedance: Evaluate the model's earth-fault loop constraint with resistance, reactance, and specified source impedance.
check_short_circuit: Evaluate adiabatic conductor thermal withstand for specified fault conditions.
get_standards_info: Describe model scope and dataset availability and provenance.
generate_calculation_report: Produce an ASCII report of inputs, assumptions, candidate checks, and omitted checks.
uv run pytest
uv buildThe code is licensed under MIT. The bundled reference data is public domain.
Calculate model temperature, grouping and depth factors from the configured data.
ambient_temp_c denotes soil temperature for underground installations and air
temperature otherwise. None uses the dataset's reference value. Unsupported
ranges are rejected; factors between rows use conservative lookup. Installation
labels do not describe every cable construction, grouping layout or soil condition.
| Name | Required | Description | Default |
|---|---|---|---|
| depth_m | No | ||
| insulation | No | V90 | |
| num_circuits | No | ||
| ambient_temp_c | No | ||
| installation_method | No | in_conduit_in_air |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses error behavior ('Unsupported ranges are rejected'), interpolation behavior ('factors between rows use conservative lookup'), and default handling ('None uses the dataset's reference value'). It also flags a limitation of installation labels. Missing is any mention of auth needs or rate limits, but for a local calculation tool this is strong disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then supporting caveats in compact sentences. The final sentence about installation labels is slightly tangential but still earns its place as a usage caveat. No filler.
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?
An output schema exists, so return values need not be described. However, for a 5-parameter tool with 0% schema coverage and no annotations, the description leaves several parameters unexplained and gives no when-to-use context, so it is only minimally adequate.
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 for all 5 parameters. It clarifies ambient_temp_c semantics (soil vs air, None default) and hints at installation_method limits, but says nothing about depth_m, insulation, or num_circuits. Partial compensation leaves clear 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?
States a specific verb (Calculate) and resource (model temperature, grouping and depth factors), which is distinguishable from siblings like calculate_voltage_drop or check_short_circuit. It is clear what the tool computes, though 'model temperature' is slightly awkward phrasing and no sibling is named explicitly.
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 offers no when-to-use guidance or comparison to alternatives such as size_cable or calculate_voltage_drop. It only provides caveats about inputs and data limits, not selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate experimental AC voltage drop using the configured resistance/reactance data.
length_m is the one-way route length, size_mm2 must exist in the configured dataset,
and voltage is line-to-line for 3phase or phase-to-neutral for 1phase. worst_case_pf
uses the impedance magnitude instead of the specified power factor. Threshold flags
apply only to this voltage-drop model and do not establish standards compliance.
| Name | Required | Description | Default |
|---|---|---|---|
| phase | No | 3phase | |
| voltage | No | ||
| length_m | Yes | ||
| size_mm2 | Yes | ||
| load_amps | Yes | ||
| insulation | No | V90 | |
| power_factor | No | ||
| worst_case_pf | No | ||
| conductor_material | No | copper |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose meaningful behavior: the 'experimental' framing, the hard dependency on the configured dataset, and an explicit scope caveat that threshold flags do not establish standards compliance. It omits what happens on a failed dataset lookup and any purity/idempotency note, which keeps it below 5.
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 compact sentences, front-loaded with the core purpose and followed by the parameter semantics an agent cannot infer. The trailing compliance caveat is dense but earns its place; there is no filler.
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 9-parameter engineering calculation tool with an output schema (so return values need not be explained), the description covers the critical ambiguities: voltage reference convention, one-way length, dataset membership requirement, and the meaning of worst_case_pf. The remaining undocumented parameters are enums and numbers with defaults that are largely self-explanatory.
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% across 9 parameters, so the description must compensate and it does explain the genuinely ambiguous ones: length_m as one-way route length, voltage as line-to-line vs phase-to-neutral by phase, and the worst_case_pf impedance-magnitude behavior. However, phase, load_amps, insulation, power_factor and conductor_material receive no semantic elaboration, leaving roughly half the parameters documented only by their self-describing names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Calculate experimental AC voltage drop') and even names the underlying data source (configured resistance/reactance data), which separates it from siblings like calculate_derating or check_loop_impedance. It stops short of explicitly routing the agent away from any named alternative, so it is clear but not sibling-differentiating.
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 real usage constraints (size_mm2 must exist in the configured dataset, threshold flags apply only to this model), but it never says when to pick this tool over size_cable or check_loop_impedance. Usage is implied by the scope rather than stated as a selection rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate an AC earth-fault loop length limit using resistance plus reactance.
nominal_phase_voltage is phase-to-earth voltage. The external source-loop magnitude
defaults to zero and must be supplied for a realistic check. length_m enables the
route-length pass/fail comparison; without it no route check is performed. Material
is specified separately for active and earth conductors. Generic B/C/D trip
multipliers do not verify a specific device's clearing time or guarantee disconnection.
| Name | Required | Description | Default |
|---|---|---|---|
| length_m | No | ||
| mcb_curve | No | C | |
| insulation | No | V90 | |
| earth_size_mm2 | Yes | ||
| active_size_mm2 | Yes | ||
| conductor_material | No | copper | |
| nominal_phase_voltage | No | ||
| earth_conductor_material | No | copper | |
| supply_loop_impedance_ohm | No | ||
| protective_device_rating_amps | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses the zero default for supply_loop_impedance_ohm, that a realistic check requires it, the conditional route check behavior of length_m, and an important limitation on trip multipliers. It omits only failure modes and units 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 core purpose is front-loaded in the first sentence, followed by focused parameter notes and a caveat. It is dense but every sentence carries information; no filler.
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?
An output schema exists, so return values need not be described. For a 10-parameter calculation with zero schema descriptions, the description covers the critical parameters and one major limitation, but several parameters (mcb_curve, insulation, sizes) remain opaque.
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 adds meaning for nominal_phase_voltage, supply_loop_impedance_ohm, length_m, and the separate conductor materials, but leaves mcb_curve, insulation, and both size parameters and the device rating 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 states a specific verb and resource: 'Estimate an AC earth-fault loop length limit using resistance plus reactance.' This clearly distinguishes it from calculation siblings like calculate_voltage_drop or size_cable, though it never explicitly names an alternative.
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?
It gives conditional guidance ('must be supplied for a realistic check', 'without it no route check is performed') and warns that B/C/D multipliers do not verify clearing time. However, it never states when to choose this over check_short_circuit or other siblings, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check experimental adiabatic thermal withstand: I^2t <= k^2S^2.
Supply the applicable fault current in kA and actual protective-device clearing
time in seconds (0 < time <= 5). The default 0.1 s is an assumption, not a device
rating. k comes from configured data and assumes the model's initial/final conductor
temperatures. This check alone does not approve an active or earth conductor.
| Name | Required | Description | Default |
|---|---|---|---|
| size_mm2 | Yes | ||
| insulation | No | V90 | |
| fault_time_s | No | ||
| fault_current_ka | Yes | ||
| conductor_material | No | copper |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose meaningful behavior: k is sourced from configured data, the model assumes specific initial/final conductor temperatures, the default time is not a rating, and the result is not a standalone approval. It omits any note on what the check returns or how it fails, but the assumptions and limits are 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 formula is front-loaded and each subsequent sentence adds a distinct constraint (input units/range, default assumption, k source, approval limit). It is dense with domain notation but has no filler.
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?
An output schema exists, so return values need not be described, and the description supplies the assumption context, input semantics and scope limits an agent needs. The only real gap is the unexplained insulation/material/size 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 compensate. It explains fault_current_ka, fault_time_s (with its valid range and default caveat) and the origin of k, and S is implied by the formula, but size_mm2, insulation and conductor_material are never explained, leaving half the parameters to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise verb and resource ('Check experimental adiabatic thermal withstand') and pins it to a concrete formula (I^2*t <= k^2*S^2), which unambiguously separates it from siblings like check_loop_impedance or calculate_derating.
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?
It tells the agent what to supply (fault current in kA, clearing time in seconds) and warns that the 0.1 s default is an assumption rather than a device rating, plus a scope caveat that this check alone does not approve a conductor. It never names an alternative tool or an explicit when-not-to-use, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an ASCII report of inputs, assumptions and requested experimental checks.
Parameters and assumptions match size_cable. The report identifies optional checks
as passed, failed or not requested; it does not certify standards compliance.
| Name | Required | Description | Default |
|---|---|---|---|
| load | Yes | ||
| unit | No | A | |
| phase | No | 3phase | |
| depth_m | No | ||
| voltage | No | ||
| length_m | Yes | ||
| mcb_curve | No | C | |
| insulation | No | V90 | |
| check_fault | No | ||
| fault_time_s | No | ||
| num_circuits | No | ||
| power_factor | No | ||
| ambient_temp_c | No | ||
| mcb_rating_amps | No | ||
| fault_current_ka | No | ||
| max_volt_drop_pct | No | ||
| cable_construction | No | generic | |
| conductor_material | No | copper | |
| earth_fault_time_s | No | ||
| installation_method | No | in_conduit_in_air | |
| insulation_exposure | No | ||
| earth_fault_current_ka | No | ||
| earth_conductor_material | No | copper | |
| supply_loop_impedance_ohm | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does add real behavioral context: the output is an ASCII report, optional checks are labelled passed/failed/not requested, and critically it 'does not certify standards compliance'. It still omits whether the call is purely read-only and how expensive/large the report is for a 24-parameter input.
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 short sentences, purpose front-loaded, with each sentence adding distinct information (what it produces, parameter lineage, output semantics plus limitation). No filler or repetition of the schema.
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?
An output schema exists so return values needn't be explained, but for a tool with 24 parameters at 0% schema description coverage and no annotations, the description leaves the parameter contract almost entirely to an external tool reference. It is not complete enough for an agent to call confidently without inspecting size_cable.
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% across 24 parameters, so the description must compensate and largely does not — no parameter is explained or exemplified. The only mitigation is the pointer that parameters and assumptions 'match size_cable', which tells the agent where to look but not what any of the 24 fields mean here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (generate) and a concrete artifact (ASCII report of inputs, assumptions and requested checks), which is clearly distinct from the sibling calculators. It further differentiates by noting its parameters and assumptions match size_cable, though it does not state how it relates to the other check_* siblings.
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?
There is no explicit when-to-use or when-not-to-use statement, but the note that parameters 'match size_cable' implies this is the companion reporting step after sizing, which is implied rather than stated guidance. No alternatives are named for producing results in another form.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return model scope and provenance status, without reproducing reference tables.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose one useful boundary behavior — it will not reproduce reference tables, implying a lightweight metadata response — which suggests a read-only, non-mutating operation. It says nothing about output shape, authorization, or caching, but for a zero-parameter informational call the risk surface is small.
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 compact sentence with no padding, and the scope of the response is front-loaded. It is slightly cryptic for its length, but nothing is wasted.
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?
An output schema exists, so return values need not be detailed, and with no parameters the call surface is trivial. Still, the description leaves 'model scope' and 'provenance status' unexplained, which is the one piece of context an agent genuinely needs and cannot get from structured fields.
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 tool takes no parameters (0 count, 100% schema coverage), so the baseline of 4 applies. Nothing about arguments needs explaining, though the description does not note that the call is parameterless and deterministic.
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 verb 'Return' with the resource 'model scope and provenance status' states roughly what the tool does, and the clause about not reproducing reference tables hints it is a metadata tool rather than a calculator. However, 'model scope' and 'provenance status' are undefined jargon, so an agent cannot confidently predict what the payload contains relative to the calculation-oriented siblings.
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?
There is no statement of when to reach for this tool versus the six sibling calculators (check_short_circuit, size_cable, calculate_voltage_drop, etc.), nor any prerequisite or trigger condition. Usage must be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select the smallest candidate passing all requested experimental model checks.
load/unit describe the design load; length_m is the positive one-way route length.
voltage is line-to-line for 3phase and phase-to-neutral for 1phase. DC is unsupported.
ambient_temp_c is air temperature above ground and soil temperature underground;
None uses the configured dataset's reference temperature. num_circuits and depth_m
must fall within the configured data. The model uses V90 at 75 C or X90 at 90 C.
mcb_rating_amps enables the approximate AC loop check; supply_loop_impedance_ohm
is the non-negative external source-loop magnitude (default zero is an assumption).
Supplying a nonzero source-loop magnitude requires mcb_rating_amps.
Check the actual protective device and measured supply impedance independently.
check_fault enables active AND earth adiabatic checking using fault_current_ka and
fault_time_s. The earth conditions default to those active conditions; override them
with earth_fault_current_ka and/or earth_fault_time_s for the actual earth fault.
Earth fault overrides require check_fault=True.
Omitted fault checks are reported as not requested. The earth material is independent
of the active material. An experimental selection is not an installation approval.
cable_construction="flat_2c_earth" selects a dedicated two-loaded-conductor profile
and requires phase="1phase". For in_thermal_insulation, explicitly choose
partially_surrounded or completely_surrounded; unenclosed_in_air uses none.
Unsupported construction/condition combinations are rejected without generic fallback.
The generic default preserves the existing dataset column and does not identify a
physical cable construction or insulation exposure.
| Name | Required | Description | Default |
|---|---|---|---|
| load | Yes | ||
| unit | No | A | |
| phase | No | 3phase | |
| depth_m | No | ||
| voltage | No | ||
| length_m | Yes | ||
| mcb_curve | No | C | |
| insulation | No | V90 | |
| check_fault | No | ||
| fault_time_s | No | ||
| num_circuits | No | ||
| power_factor | No | ||
| ambient_temp_c | No | ||
| mcb_rating_amps | No | ||
| fault_current_ka | No | ||
| max_volt_drop_pct | No | ||
| cable_construction | No | generic | |
| conductor_material | No | copper | |
| earth_fault_time_s | No | ||
| installation_method | No | in_conduit_in_air | |
| insulation_exposure | No | ||
| earth_fault_current_ka | No | ||
| earth_conductor_material | No | copper | |
| supply_loop_impedance_ohm | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses DC is unsupported, None uses the dataset reference temperature, depth/num_circuits must fall within configured data, the V90/X90 temperature basis, that default zero source impedance is an assumption, that unsupported combinations are rejected without fallback, and that the result is not an installation approval. These are exactly the behavioral traits annotations would otherwise supply.
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?
For a 24-parameter tool the length is justified, and the core purpose is front-loaded before the per-parameter detail. It is dense and occasionally repetitive (the earth-material independence note), but each sentence adds actionable information rather than restating the schema.
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?
An output schema exists so return values need no explanation, and the description covers most behavioral constraints for a complex selection tool. Still, with 24 parameters and zero schema descriptions, several inputs (mcb_curve, power_factor, max_volt_drop_pct, conductor_material) have no semantics anywhere, which is a meaningful gap 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% across 24 parameters, so the description must compensate, and it does explain many (load/unit, length_m, voltage convention, ambient_temp_c, num_circuits, depth_m, mcb_rating_amps, supply_loop_impedance_ohm, fault current/time, cable_construction, insulation_exposure). It omits meaning for mcb_curve, power_factor, max_volt_drop_pct, conductor_material, and insulation, leaving roughly a third of parameters undocumented anywhere.
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 opening sentence states a specific action ('Select the smallest candidate passing all requested experimental model checks'), which tells the agent this is a cable-sizing/selection tool. It is clear enough to distinguish from siblings like calculate_voltage_drop or check_short_circuit, but it never explicitly says 'size a cable' and does not name an alternative tool, so sibling differentiation relies on the name.
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 rich conditional guidance for individual features (mcb_rating_amps enables the loop check, check_fault enables adiabatic checking, earth overrides require check_fault=True, flat_2c_earth requires 1phase). However, it never states when to prefer size_cable over siblings such as check_loop_impedance or calculate_derating, so tool-level routing guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0calculate_deratingcalculate_voltage_dropcheck_loop_impedancecheck_short_circuitgenerate_calculation_reportget_standards_infosize_cableScored across 7 tools
Each tool targets a distinct calculation (sizing, voltage drop, derating, thermal withstand, loop impedance, report, standards provenance), but size_cable explicitly duplicates the behaviour of the individual check tools, so an agent may be unsure whether to call size_cable or the granular checks. The descriptions do clarify that the individual checks are for standalone use, keeping the overlap manageable.
All seven names follow a clean snake_case verb_noun pattern (check_short_circuit, get_standards_info, size_cable, calculate_voltage_drop, calculate_derating, check_loop_impedance, generate_calculation_report). The verb set is varied but idiomatic and predictable.
Seven tools is well-scoped for a cable sizing/verification domain, with each tool earning its place as a distinct engineering check or report generator. No filler or redundant tooling exists beyond the intentional granular/aggregate split.
The surface covers the full sizing workflow: derating inputs, voltage drop, adiabatic fault checks, loop impedance, selection, standards provenance and reporting. Minor gaps remain, such as listing/inspecting the configured cable dataset or exporting results beyond an ASCII report, but agents can work around these.
Engineering calculation MCP server for oil and gas engineering applications.
27 engineering compliance and calculation tools for the built environment (UK, EU, UAE).
Design, solve and simulate HVAC systems from real components, weather years and buildings.
Cálculos de engenharia elétrica pela norma brasileira (NBR), validados, com citação normativa.
