Skip to main content
Glama

calc.engineer

by engineer.calc

string sizing

string_sizing

Calculates optimal solar panel string and MPPT configuration based on panel electrical specs, inverter/charge-controller MPPT limits, and site temperature extremes. Applies temperature coefficients to determine Voc at minimum temperature (cold) and Vmp at maximum temperature (hot), then computes the safe range of panels per string, maximum parallel strings, and total array wattage. Prevents over-voltage damage in winter and under-voltage MPPT dropout in summer. Essential for NEC 690.7 compliant residential and commercial solar design.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
mppt_imaxYesMaximum MPPT input current in amps
mppt_vmaxYesMaximum MPPT input voltage in volts
mppt_vminYesMinimum MPPT start/operating voltage in volts
panel_impYesPanel maximum power current (Imp) at STC in amps
panel_iscYesPanel short circuit current (Isc) at STC in amps
panel_vmpYesPanel maximum power voltage (Vmp) at STC in volts
panel_vocYesPanel open circuit voltage (Voc) at STC in volts
temp_max_cNoMaximum expected cell temperature in Celsius, default 60
temp_min_cNoMinimum expected site temperature in Celsius, default -10
temp_coeff_voc_pct_per_cNoVoc temperature coefficient in %/C (negative for silicon), default -0.30

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
isc_totalYesTotal short circuit current from all parallel strings (A)
array_wattsYesTotal array power at maximum power point (W)
total_panelsYesTotal panels in the array (strings * panels per string)
vmp_hot_per_stringYesString Vmp at maximum temperature (V)
voc_cold_per_stringYesString Voc at minimum temperature (V)
max_parallel_stringsYesMaximum parallel strings (limited by MPPT Imax)
max_panels_per_stringYesMaximum panels per string (limited by Voc at cold temp)
min_panels_per_stringYesMinimum panels per string (to meet MPPT Vmin at hot temp)
recommended_panels_per_stringYesRecommended panels per string (uses max for best output)

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries full burden and explains the calculation process (temperature coefficient application, voltage limits, string counts, total wattage) and mentions design goal (prevent over/under voltage). It does not explicitly state it is a read-only calculation, but 'calculates' implies no side effects.

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?

Five sentences, front-loaded with purpose, each sentence adds value. Could be slightly more concise, but overall efficient and well-structured for a specialized engineering tool.

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

Completeness4/5

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

Given the complexity (10 parameters, output schema exists), the description covers the algorithm, standards reference, and practical outcomes. It does not discuss error handling or edge cases, but for a calculator tool this is sufficient.

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 covers 100% of parameters with descriptions. The tool description adds overarching context (e.g., why temperature coefficients are used) but does not enrich individual parameter meanings beyond what the schema already provides, so baseline 3 is appropriate.

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 clearly states the tool calculates optimal solar panel string and MPPT configuration using temperature coefficients, and distinguishes from sibling solar tools (e.g., solar_sizing, solar_load_audit) by focusing on string/MPPT specifics and NEC 690.7 compliance.

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?

The description provides clear context for when to use (solar string sizing, cold/hot temperature extremes, NEC compliance) but does not explicitly mention alternatives or when not to use it, though it is implied for specific photovoltaic design.

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

All calc.engineer toolsInspect
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