CableSizeCalculatorMCP

by Drefetr

Overview Schema Source Related Servers Discussions Admin

Python

Local

size_cable

Size and verify AC cables by checking load, voltage drop, derating, fault-loop impedance, and thermal withstand.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	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

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 3, 2026

TDQS

A3.6/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

Deploy Server