calc.engineer

inverter sizing

inverter_sizing

Size a DC-to-AC inverter for off-grid solar, battery backup, or mobile power systems. Computes the required continuous VA rating from total load watts and power factor, estimates surge capacity for motor-starting loads (3-7x rated power), applies NEC-recommended 20% derating for continuous operation, and selects the nearest standard inverter size. Also calculates DC input current at the system voltage for cable and fuse sizing. Chain from solar_load_audit to get peak_watts and largest_load_watts, then chain to wire_gauge or wire_ampacity to size the DC cables. Essential for off-grid cabins, RV/van builds, emergency backup, and solar+battery installations.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`efficiency`	No	Inverter efficiency (0.5-1.0). Good pure-sine inverters are 0.90-0.95. Modified-sine are 0.85-0.90. Budget units may be lower.
`surge_watts`	No	Peak surge/starting load in watts. Motors and compressors draw 3-7x rated watts on startup. If omitted, estimated as 3x the largest single load or 2x continuous, whichever is greater.
`derating_pct`	No	Derating percentage for temperature, altitude, and safety margin. NEC recommends 20% (80% continuous rating). Range 0-50%.
`power_factor`	No	Power factor (0.5-1.0). Resistive loads (heaters, lights) are ~1.0. Motor loads (fridge, AC, pump) are 0.6-0.8. Mixed loads typically 0.8.
`system_voltage`	No	DC system voltage. 12V for small/mobile, 24V for medium, 48V for large residential/commercial. Higher voltage = lower current = thinner cables.	48
`continuous_watts`	Yes	Total continuous load in watts. Sum of all appliances that may run simultaneously. Chain from solar_load_audit.peak_watts.
`largest_load_watts`	No	Wattage of the single largest appliance. Used to estimate surge if surge_watts is not provided. Chain from solar_load_audit.largest_load_watts.

Output Schema

TableJSON Schema

Name	Required	Description
`surge_margin_pct`	Yes	How much surge headroom the recommended inverter provides above the estimated surge requirement.
`required_surge_va`	Yes	Required surge/peak VA capacity for motor starting loads.
`battery_cable_note`	Yes	Guidance on DC cable sizing based on the continuous current draw.
`dc_current_surge_a`	Yes	Peak DC input current during surge. Sizes the DC fuse and battery cable.
`derated_continuous_va`	Yes	Continuous VA after applying derating factor. The inverter must be rated at or above this value.
`efficiency_loss_watts`	Yes	Power lost to inverter inefficiency at continuous load, in watts.
`recommended_size_watts`	Yes	Nearest standard inverter size (watts) that meets the derated requirement.
`required_continuous_va`	Yes	Required continuous VA rating accounting for power factor: continuous_watts / power_factor.
`dc_current_continuous_a`	Yes	Continuous DC input current draw at system voltage: VA / (voltage * efficiency). Sizes the DC wiring and fuses.

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description explains core behaviors: it computes, estimates, applies derating, selects standard size, calculates DC current. It does not explicitly state that it is a read-only computation (no mutation), but the nature of the tool implies it. No contradictions.

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

Conciseness4/5

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

The description is a single paragraph that efficiently conveys all key aspects. It is front-loaded with the primary purpose. However, it could be broken into shorter sentences or bullet points for easier scanning.

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

Completeness5/5

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

The description is comprehensive given the tool's complexity (7 parameters, no annotations, output schema exists). It covers inputs, algorithm, outputs (though output structure not detailed), and chaining suggestions. An agent can fully understand what the tool does and how to use it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage. The description adds value by explaining how parameters interact (e.g., surge estimation uses largest_load_watts, derating_pct is NEC 20%, power factor affects VA). It clarifies default behaviors and chaining sources for continuous_watts and largest_load_watts.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with 'Size a DC-to-AC inverter' and explicitly lists the computations (VA rating, surge, derating, standard size, DC input current). It distinguishes from siblings by mentioning chaining from solar_load_audit and to wire_gauge/wire_ampacity, which are present in the sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly states usage scenarios: off-grid solar, battery backup, mobile power systems. It provides chaining guidance (from solar_load_audit, to wire_gauge). However, it does not explicitly mention when not to use this tool or list direct alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All calc.engineer tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation4/5

Despite 89 tools, each has a clearly distinct purpose with detailed descriptions that often reference related tools. Overlap exists (e.g., multiple LoRa/RF tools), but the descriptions are sufficient to distinguish them. Some confusion possible among similar-sounding tools like attenuator_pi and attenuator_tee, but the descriptions explicitly compare them.

Naming Consistency4/5

Consistent underscore-separated lowercase naming. Most tools follow a verb_noun pattern (e.g., capacitor_charge, wire_gauge) or noun_noun (power_cost). Minor inconsistencies such as 'bmi_calculator' vs 'solar_sizing' but overall predictable.

Tool Count2/5

89 tools is far too many for a single MCP server. This scope is more appropriate for multiple specialized servers. The sheer number will slow agent selection and increase cognitive load, reducing coherence.

Completeness3/5

Covers many domains (RF, solar, PCB, networking, math, etc.) but lacks depth in some areas (e.g., no three-phase power, no airflow calculations). Some domains have comprehensive coverage (LoRa/Meshtastic), but others feel incomplete for the tool count.

Resources

Need Help?