# calc.engineer (remote · calc.engineer)

88 free engineering calculators: RF link budgets, LoRa/Meshtastic, PCB, solar, homelab. Keyless.

- Trust score: 56/100 (low)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `calc.engineer`: 56/100 (this document), [markdown](https://verifymcp.io/servers/engineer-calc-calc/calc.md), [page](https://verifymcp.io/servers/engineer-calc-calc/calc)

## Channel facts

- Endpoint: `https://calc.engineer/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.0.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 46/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation not fully verified: no authorisation is required to call this server, and 89 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe.
  - HTTPS check failed: the endpoint is reachable over plaintext HTTP.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 42/100
  - 0% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 20141 tokens (~221/item across 91 items; 89 tools + 2 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http engineer-calc-calc https://calc.engineer/mcp
```

### Codex

```toml
[mcp_servers.engineer-calc-calc]
url = "https://calc.engineer/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "engineer-calc-calc": {
      "type": "remote",
      "url": "https://calc.engineer/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add engineer-calc-calc --url https://calc.engineer/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  engineer-calc-calc:
    url: "https://calc.engineer/mcp"
```

### Other

```json
{
  "mcpServers": {
    "engineer-calc-calc": {
      "type": "http",
      "url": "https://calc.engineer/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-03 (score 56, +1)

No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-01 (score 55, +1)

No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-31 (score 54, −1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 55, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-29 (score 54, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-27 (score 53, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 52)

First indexed and scored.

## MCP tools (89)

### `fspl` (~137 tokens)

Calculate free-space path loss (FSPL) in decibels using the ITU-R P.525 standard formula. Given a frequency in MHz and distance in kilometres, returns the expected signal attenuation in an ideal line-of-sight radio link with no obstacles, reflections, or atmospheric absorption. Also computes the RF wavelength. Use this to estimate baseline path loss before adding fade margins, antenna gains, or environmental corrections. Feeds directly into link_budget for full end-to-end analysis.

Input parameters:

- `dist_km` (number, required): Distance between transmitter and receiver in kilometres
- `freq_mhz` (number, required): Carrier frequency in megahertz (MHz)

Output parameters:

- `fspl_db` (number): Free-space path loss in decibels (dB)
- `wavelength_m` (number): RF wavelength in metres

### `link_budget` (~220 tokens)

link budget

Compute a full RF link budget from transmitter power, frequency, distance, and antenna gains. Calculates EIRP, free-space path loss (ITU-R P.525), received power at the receiver, and link margin relative to an optional receiver sensitivity threshold. Use this to determine whether a wireless link closes with adequate margin. Accepts output from noise_figure_cascade and feeds into snr_margin for full receive-chain analysis.

Input parameters:

- `dist_km` (number, required): Link distance in kilometres
- `freq_mhz` (number, required): Carrier frequency in megahertz (MHz)
- `rx_gain_dbi` (number): Receive antenna gain in dBi (default 2.15 for a half-wave dipole)
- `rx_sensitivity_dbm` (number): Receiver sensitivity in dBm; when provided, link margin is calculated
- `tx_dbm` (number, required): Transmitter output power in dBm
- `tx_gain_dbi` (number): Transmit antenna gain in dBi (default 2.15 for a half-wave dipole)

Output parameters:

- `eirp_dbm` (number): Effective isotropic radiated power in dBm
- `fspl_db` (number): Free-space path loss in dB
- `margin_db` (number|null): Link margin in dB (null when sensitivity is not provided)
- `rx_power_dbm` (number): Received signal power in dBm
- `wavelength_m` (number): RF wavelength in metres

### `dipole` (~139 tokens)

Calculate physical dimensions of a dipole antenna for a given frequency. Returns half-wave or quarter-wave element length in metres, feet, and inches. A half-wave dipole is the most common resonant antenna with approximately 2.15 dBi gain. A quarter-wave monopole (ground plane antenna) is half the length and is widely used in handheld radios and vehicle-mounted systems. Use this before building or purchasing an antenna to verify element length for your operating frequency.

Input parameters:

- `freq_mhz` (number, required): Operating frequency in megahertz (MHz)
- `type` (string): Antenna type: half_wave dipole or quarter_wave monopole

Output parameters:

- `length_ft` (number): Element length in feet
- `length_in` (number): Element length in inches
- `length_m` (number): Element length in metres
- `wavelength_m` (number): Full wavelength in metres

### `microstrip` (~203 tokens)

Calculate PCB microstrip trace width for a target characteristic impedance using the Hammerstad-Jensen closed-form equations. Given target impedance (Z0), substrate dielectric constant (er), substrate height, and copper weight, returns the required trace width and effective dielectric constant. Optionally computes effective wavelength at a given frequency. Essential for RF PCB layout to achieve controlled impedance traces (e.g. 50 ohm for SMA connectors). References IPC-2141.

Input parameters:

- `copper_oz` (number): Copper weight in oz/ft2 (1 oz = 0.035 mm thickness)
- `er` (number): Substrate relative dielectric constant (default 4.6 for FR-4)
- `freq_mhz` (number): Optional frequency in MHz for effective wavelength calculation
- `height_mm` (number, required): Substrate height (dielectric thickness) in millimetres
- `z0_ohm` (number): Target characteristic impedance in ohms (default 50)

Output parameters:

- `er_eff` (number): Effective dielectric constant of the microstrip
- `wavelength_eff_mm` (number|null): Effective wavelength in millimetres at the given frequency (null if freq not provided)
- `width_mm` (number): Required trace width in millimetres

### `dbm_convert` (~155 tokens)

dbm convert

Convert a power level in dBm to milliwatts, watts, dBW, and RMS voltage across a given impedance. dBm is the standard unit for RF power referenced to 1 milliwatt. This tool is essential when interfacing datasheets (which use dBm) with circuit analysis (which uses volts and watts). Default impedance is 50 ohms, matching most RF systems. Use this to quickly verify power amplifier output, receiver sensitivity, or regulatory EIRP limits.

Input parameters:

- `dbm` (number, required): Power level in dBm (decibels relative to 1 milliwatt)
- `impedance_ohm` (number): Load impedance in ohms for Vrms calculation (default 50)

Output parameters:

- `dbw` (number): Power in dBW (decibels relative to 1 watt)
- `mw` (number): Power in milliwatts
- `vrms` (number): RMS voltage across the load impedance in volts
- `watts` (number): Power in watts

### `noise_figure_cascade` (~118 tokens)

noise figure cascade

Calculate the cascaded noise figure of a multi-stage receiver chain using the Friis formula. Each stage has a noise figure and gain in dB. The first stage dominates overall system noise, which is why low-noise amplifiers (LNAs) are placed at the front of the chain. Returns total cascaded noise figure, total gain, and equivalent noise temperature. Feeds into link_budget for complete receive-chain sensitivity analysis.

Input parameters:

- `stages` (array, required): Ordered array of receiver chain stages, each with nf_db and gain_db

Output parameters:

- `noise_temp_k` (number): Equivalent noise temperature in kelvin (T0 = 290 K)
- `total_gain_db` (number): Total gain of the chain in dB
- `total_nf_db` (number): Total cascaded noise figure in dB

### `vswr` (~160 tokens)

Convert between VSWR, return loss, and reflection coefficient — provide any one parameter and get all related impedance-mismatch metrics. Computes VSWR (voltage standing wave ratio), return loss in dB, reflection coefficient (gamma), mismatch loss, and percentage of power reflected vs transmitted. Essential for antenna matching, transmission line analysis, and RF system budgeting. Feeds into link_budget for system-level mismatch accounting.

Input parameters:

- `reflection_coefficient` (number): Reflection coefficient magnitude (gamma), 0 to 1
- `return_loss_db` (number): Return loss in decibels (positive value, higher is better match)
- `vswr` (number): Voltage standing wave ratio (>= 1.0, where 1.0 is perfect match)

Output parameters:

- `mismatch_loss_db` (number): Mismatch loss in decibels
- `power_reflected_pct` (number): Percentage of power reflected back toward source
- `power_transmitted_pct` (number): Percentage of power delivered to load
- `reflection_coefficient` (number): Reflection coefficient magnitude (gamma)
- `return_loss_db` (number): Return loss in decibels (positive)
- `vswr` (number): Voltage standing wave ratio

### `attenuator_pi` (~139 tokens)

attenuator pi

Design a Pi-topology resistive attenuator pad. Given a desired attenuation in dB and characteristic impedance (default 50 ohm), computes the three resistor values for a symmetrical Pi-pad network. The Pi attenuator uses two shunt resistors (R1, R3) and one series resistor (R2). Commonly used in RF signal chains to reduce signal level while maintaining impedance match. Compare with attenuator_tee for T-pad topology.

Input parameters:

- `attenuation_db` (number, required): Desired attenuation in decibels (positive value)
- `z0_ohm` (number): Characteristic impedance in ohms (default 50)

Output parameters:

- `r1_ohm` (number): Shunt resistor R1 (input side) in ohms
- `r2_ohm` (number): Series resistor R2 (middle) in ohms
- `r3_ohm` (number): Shunt resistor R3 (output side) in ohms
- `topology` (string): Attenuator topology identifier

### `attenuator_tee` (~139 tokens)

attenuator tee

Design a Tee-topology resistive attenuator pad. Given a desired attenuation in dB and characteristic impedance (default 50 ohm), computes the three resistor values for a symmetrical T-pad network. The Tee attenuator uses two series resistors (R1, R3) and one shunt resistor (R2). Commonly used in RF signal chains to reduce signal level while maintaining impedance match. Compare with attenuator_pi for Pi-pad topology.

Input parameters:

- `attenuation_db` (number, required): Desired attenuation in decibels (positive value)
- `z0_ohm` (number): Characteristic impedance in ohms (default 50)

Output parameters:

- `r1_ohm` (number): Series resistor R1 (input side) in ohms
- `r2_ohm` (number): Shunt resistor R2 (middle) in ohms
- `r3_ohm` (number): Series resistor R3 (output side) in ohms
- `topology` (string): Attenuator topology identifier

### `fresnel_zone` (~154 tokens)

fresnel zone

Calculate the Fresnel zone radius at the midpoint of a radio link. Given frequency in MHz, link distance in kilometres, and zone number (1-5), returns the Fresnel zone radius in metres and feet, plus the 60% clearance threshold used in practical link engineering. The first Fresnel zone defines the region where most RF energy travels; obstructions within 60% of this radius cause significant signal degradation. Feeds into link_budget for path clearance analysis.

Input parameters:

- `dist_km` (number, required): Total link distance in kilometres
- `freq_mhz` (number, required): Operating frequency in megahertz (MHz)
- `zone_number` (integer): Fresnel zone number (1-5, default 1)

Output parameters:

- `clearance_60pct_m` (number): 60% Fresnel zone clearance (practical minimum) in metres
- `radius_ft` (number): Fresnel zone radius at midpoint in feet
- `radius_m` (number): Fresnel zone radius at midpoint in metres
- `wavelength_m` (number): RF wavelength in metres

### `wavelength_freq` (~122 tokens)

wavelength freq

Convert between radio frequency and wavelength. Provide either frequency in MHz or wavelength in metres, and get the full set of equivalent values: frequency in MHz and GHz, wavelength in metres, centimetres, millimetres, and feet. Essential for antenna dimensioning, waveguide selection, and quick band identification. The fundamental relationship is lambda = c / f where c is the speed of light (299 792 458 m/s).

Input parameters:

- `freq_mhz` (number): Frequency in megahertz (MHz)
- `wavelength_m` (number): Wavelength in metres

Output parameters:

- `freq_ghz` (number): Frequency in gigahertz (GHz)
- `freq_mhz` (number): Frequency in megahertz (MHz)
- `wavelength_cm` (number): Wavelength in centimetres
- `wavelength_ft` (number): Wavelength in feet
- `wavelength_m` (number): Wavelength in metres
- `wavelength_mm` (number): Wavelength in millimetres

### `spice_template` (~144 tokens)

spice template

Generate a complete SPICE netlist from a parameterized template. Supports common circuit topologies: low-pass RC filter, voltage divider, common emitter amplifier. Returns a ready-to-simulate netlist string that can be passed directly to spice_simulate. Use this when an agent needs to construct a circuit from high-level parameters without writing raw SPICE syntax. Feeds into spice_simulate for AC/DC/transient analysis.

Input parameters:

- `analysis` (string): SPICE analysis type to include in netlist
- `params` (object, required): Template-specific parameters (e.g. r_ohms, c_farads, v_source)
- `template` (string, required): Circuit template name

Output parameters:

- `analysis_type` (string): Analysis type included in the netlist
- `component_count` (number): Number of components in the generated circuit
- `netlist` (string): Complete SPICE netlist ready for simulation
- `template_name` (string): Template used

### `spice_simulate` (~462 tokens)

spice simulate

Run a SPICE circuit simulation directly in the worker. Accepts a standard SPICE netlist and performs operating-point (.op), DC sweep (.dc), AC frequency sweep (.ac), or transient (.tran) analysis using a built-in modified-nodal-analysis engine with Newton-Raphson nonlinear solving. Supports R, L, C, V, I sources (DC/AC/SIN/PULSE), diodes, BJTs (Ebers-Moll), MOSFETs (Shichman-Hodges level 1), controlled sources (E/G), .param expressions, .subckt/X hierarchical subcircuits, .measure and .four (Fourier/THD), and a built-in parts library (reference 2n3904/2n2222/1n4148/1n5819/2n7000/tl072/lm358/led_red etc. by name and the model is auto-injected), up to 150 components. Returns voltage vectors for all circuit nodes (magnitude + phase for AC). Use spice_template to generate netlists from parameterized templates.

Input parameters:

- `analysis` (string): Override analysis type (auto-detected from netlist if omitted)
- `certify` (boolean): If true, attach an a-posteriori existence certificate for the DC operating point (Newton–Kantorovich: proves a true solution exists within a computed radius, or refuses). Adds ~one extra back-solve.
- `netlist` (string, required): SPICE netlist (ngspice-compatible). Must include at least one analysis command (.ac, .dc, .tran, .op) and end with .end
- `options` (object): Additional ngspice .options (e.g. { reltol: 0.001 })
- `output_node` (string): Node whose voltage is certified over the tolerance box (required with tolerances).
- `temperature_c` (number): Simulation temperature in Celsius
- `tolerances` (object): Component-tolerance box, e.g. {"R1":0.05,"V1":0.02} (fractional). With output_node, returns a certified min/max interval for that node over all component variations. R/V/I elements only.

Output parameters:

- `analysis_type` (string): Analysis type that was performed
- `certificate`: Present when certify=true: {certified, rho, eta, h, ...} existence certificate for the DC operating point
- `component_count` (number): Number of components in the netlist
- `fourier`: Present when the netlist has .four cards: Fourier harmonics + THD per node
- `measures`: Present when the netlist has .measure cards: {name: value}
- `nodes` (array): List of circuit node names
- `runtime_ms` (number): Simulation wall-clock time in milliseconds
- `tolerance_certificate`: Present when tolerances+output_node given: {certified, interval, nominal, ...} certified output range over the component-tolerance box
- `vectors` (object): Named voltage/current vectors keyed by node name
- `warnings` (array): Any ngspice warnings generated during simulation

### `lora_airtime` (~339 tokens)

lora airtime

Calculates LoRa packet time-on-air using the Semtech AN1200.13 formula. Computes symbol duration, preamble time, payload symbol count, effective data rate, and the minimum transmission interval for 1% duty cycle compliance. Essential for capacity planning in LoRaWAN and Meshtastic mesh networks. Accepts spreading factor (SF7-SF12), bandwidth (125/250/500 kHz), coding rate (4/5-4/8), payload size, header mode, CRC, and optional low data rate optimization. Feeds airtime_ms to channel_utilization for mesh load analysis.

Input parameters:

- `bw_khz` (number): LoRa channel bandwidth in kHz. Common values: 125, 250, or 500.
- `cr` (integer): LoRa coding rate denominator (5-8). Represents 4/5 through 4/8 FEC ratio.
- `crc` (boolean): Whether CRC is appended to payload. Recommended true for reliability.
- `explicit_header` (boolean): Whether to use explicit header mode. True for LoRaWAN; false for implicit header.
- `low_data_rate_optimize` (boolean): Enable low data rate optimization. Auto-calculated if omitted: enabled for SF >= 11 at BW 125 kHz.
- `payload_bytes` (integer, required): Application payload size in bytes (0-255).
- `preamble_symbols` (integer): Number of preamble symbols. LoRaWAN uses 8; raw LoRa may vary.
- `sf` (integer): LoRa spreading factor (7-12). Higher SF = longer range but slower data rate.

Output parameters:

- `airtime_ms` (number): Total packet time-on-air in milliseconds.
- `data_rate_bps` (number): Effective data rate in bits per second.
- `duty_cycle_1pct_interval_s` (number): Minimum interval between transmissions in seconds to respect 1% duty cycle regulation.
- `payload_symbols` (integer): Number of symbols used for the payload + header portion.
- `preamble_time_ms` (number): Preamble duration in milliseconds (includes 4.25 sync symbols).
- `symbol_time_ms` (number): Duration of a single LoRa symbol in milliseconds.

### `snr_margin` (~218 tokens)

snr margin

Computes LoRa link SNR margin by comparing received power against the noise floor and the spreading-factor-dependent demodulation threshold from the Semtech SX1276 datasheet. Calculates receiver noise floor from thermal noise (-174 dBm/Hz), channel bandwidth, and receiver noise figure. Returns margin in dB and a boolean link-OK indicator. Use to validate whether a LoRa or Meshtastic link will reliably decode packets. Accepts rx_power from link_budget tool output for end-to-end chain analysis.

Input parameters:

- `bw_khz` (number): LoRa channel bandwidth in kHz. Affects noise floor.
- `noise_figure_db` (number): Receiver noise figure in dB. Typical LoRa radio NF is 6 dB (SX1276).
- `rx_power_dbm` (number, required): Received signal power in dBm (e.g., -110). Typically from a link budget calculation or field measurement.
- `sf` (integer): LoRa spreading factor (7-12). Higher SF tolerates lower SNR.

Output parameters:

- `link_ok` (boolean): True if margin_db > 0 (signal exceeds demodulation threshold).
- `margin_db` (number): SNR margin above demodulation threshold in dB. Positive = link OK, negative = link failure.
- `noise_floor_dbm` (number): Receiver noise floor in dBm, computed from bandwidth and noise figure.
- `required_snr_db` (number): Minimum SNR required for successful LoRa demodulation at the given SF.

### `channel_utilization` (~198 tokens)

channel utilization

Estimates Meshtastic or LoRa mesh channel utilization percentage based on node count, message rate, and per-packet airtime. Determines how much of the shared radio channel is occupied and computes the maximum number of nodes before exceeding a configurable duty cycle limit (default 10%). Returns utilization percentage, headroom, and total packet count. Chain from lora_airtime to get airtime_ms input. Essential for Meshtastic mesh deployment planning to avoid channel congestion and packet collisions.

Input parameters:

- `airtime_ms` (number, required): Time-on-air per packet in milliseconds. Obtain from lora_airtime tool.
- `max_duty_cycle_pct` (number): Maximum acceptable channel utilization percentage. Default 10% is a common Meshtastic guideline.
- `messages_per_hour_per_node` (number): Average messages transmitted per hour per node. Includes position beacons and user messages.
- `nodes` (integer, required): Number of active nodes in the mesh network.

Output parameters:

- `headroom_pct` (number): Remaining headroom before hitting the duty cycle limit (can be negative if over limit).
- `max_nodes_at_limit` (integer): Maximum number of nodes before exceeding the duty cycle limit.
- `packets_per_hour` (number): Total packets per hour across all nodes.
- `utilization_pct` (number): Current channel utilization as a percentage of total airtime.

### `lora_range_estimate` (~323 tokens)

lora range estimate

Estimates LoRa maximum communication range by computing the free-space path loss (FSPL) link budget and applying terrain-dependent correction factors. Calculates total link budget from transmit power, antenna gains, and receiver sensitivity, then solves the FSPL equation for distance after subtracting terrain losses (0 dB open to 50 dB indoor). Returns estimated range in km, link margin at 1 km, and effective path loss. Useful for Meshtastic deployment planning and coverage mapping. Terrain corrections are empirical estimates; real-world range varies with elevation, foliage, and weather.

Input parameters:

- `freq_mhz` (number): Carrier frequency in MHz. Common: 868 (EU), 915 (US/AU), 433 (Asia).
- `rx_gain_dbi` (number): Receive antenna gain in dBi. 2.15 dBi = half-wave dipole.
- `rx_sensitivity_dbm` (number): Receiver sensitivity in dBm. Typical LoRa SF10/BW125: -130 dBm. Varies by SF and bandwidth.
- `terrain` (string): Terrain type for path loss correction. open: line-of-sight, suburban: light buildings, urban: moderate buildings, dense_urban: city center, indoor: inside buildings.
- `tx_dbm` (number): Transmit power in dBm. Typical LoRa: 14-30 dBm depending on region and module.
- `tx_gain_dbi` (number): Transmit antenna gain in dBi. 2.15 dBi = half-wave dipole.

Output parameters:

- `effective_path_loss_db` (number): Maximum allowable path loss in dB (link budget minus terrain correction).
- `margin_at_1km_db` (number): Link margin at 1 km distance in dB. Positive means signal above sensitivity.
- `max_range_km` (number): Estimated maximum range in kilometers accounting for terrain correction.

### `lora_sensitivity` (~205 tokens)

lora sensitivity

Calculates LoRa receiver sensitivity from spreading factor, bandwidth, and noise figure using the Semtech SX1276 datasheet SNR thresholds. Computes the noise floor from thermal noise density (-174 dBm/Hz), channel bandwidth, and receiver noise figure, then adds the spreading-factor-dependent minimum demodulation SNR. Returns sensitivity in dBm, noise floor, required SNR, and thermal noise reference. Essential for link budget planning in LoRaWAN and Meshtastic networks. Feeds sensitivity_dbm to link_budget and lora_range_estimate for end-to-end coverage analysis.

Input parameters:

- `bw_khz` (number): LoRa channel bandwidth in kHz. Lower bandwidth = better sensitivity.
- `noise_figure_db` (number): Receiver noise figure in dB. Typical LoRa radio NF is 6 dB (SX1276).
- `sf` (integer): LoRa spreading factor (7-12). Higher SF = better sensitivity but slower data rate.

Output parameters:

- `noise_floor_dbm` (number): Receiver noise floor in dBm, computed from thermal noise, bandwidth, and noise figure.
- `required_snr_db` (number): Minimum SNR required for LoRa demodulation at the given spreading factor.
- `sensitivity_dbm` (number): Receiver sensitivity in dBm. The minimum signal power for successful demodulation.
- `thermal_noise_dbm` (number): Thermal noise power density at room temperature: -174 dBm/Hz.

### `duty_cycle_budget` (~214 tokens)

duty cycle budget

Calculates LoRa duty cycle budget for EU868, US915, AS923, and AU915 regulatory regions. Computes maximum messages per hour, minimum transmission interval, and effective data rate under regional duty cycle constraints. EU868 and AS923 enforce 1% duty cycle (ETSI); US915 has no duty cycle limit but a 400 ms dwell time per channel (FCC); AU915 has no duty cycle limit. Flags dwell-time-limited regions where packet airtime must not exceed the dwell time. Chain from lora_airtime to get airtime_ms input for end-to-end regulatory compliance analysis.

Input parameters:

- `airtime_ms` (number, required): Packet time-on-air in milliseconds. Obtain from the lora_airtime tool.
- `region` (string): LoRa regulatory region. EU868: 1% duty cycle (ETSI). US915: no duty cycle but 400 ms dwell time (FCC). AS923: 1% duty cycle (varies by country). AU915: no duty cycle limit.

Output parameters:

- `duty_cycle_pct` (number): Applicable duty cycle limit as a percentage. 100 means no duty cycle restriction.
- `dwell_time_limited` (boolean): True if the region enforces a per-transmission dwell time limit (e.g., US915 400 ms).
- `effective_data_rate_bps` (number): Effective throughput in bits per second considering duty cycle. For duty-cycle-limited regions, this reflects actual achievable throughput.
- `max_messages_per_hour` (integer): Maximum messages per hour allowed under the regional duty cycle constraint.
- `min_interval_s` (number): Minimum interval between transmissions in seconds to comply with duty cycle regulation.

### `meshtastic_range` (~376 tokens)

meshtastic range

Estimates Meshtastic node communication range using real hardware profiles and firmware channel presets. Combines device-specific TX power and antenna gain (Heltec V3, RAK WisBlock, T-Beam, T-Beam Supreme, Station G2) with firmware modem presets (Long Fast, Long Slow, Very Long Slow, Medium, Short) to compute receiver sensitivity and FSPL-based range with terrain correction. Automatically populates LoRa parameters from device and channel selection, with optional overrides for custom antennas or power levels. Essential for Meshtastic deployment planning and node placement. Returns range, sensitivity, link budget, and the effective radio parameters used.

Input parameters:

- `antenna_gain_dbi` (number): Override device default antenna gain in dBi. Useful for aftermarket antennas.
- `bw_khz` (number): Custom bandwidth in kHz. Only used when channel_preset is 'custom'.
- `channel_preset` (string): Meshtastic firmware channel preset. Selects spreading factor, bandwidth, and coding rate. long_fast is the default; very_long_slow maximizes range at the cost of throughput.
- `cr` (integer): Custom coding rate denominator (5-8). Only used when channel_preset is 'custom'.
- `device` (string): Meshtastic hardware device. Selects default TX power, antenna gain, and noise figure. Use 'custom' to override all radio parameters manually.
- `sf` (integer): Custom spreading factor (7-12). Only used when channel_preset is 'custom'.
- `terrain` (string): Terrain type for path loss correction. open: line-of-sight, suburban: light buildings, urban: moderate buildings, dense_urban: city center, indoor: inside buildings.
- `tx_power_dbm` (number): Override device default transmit power in dBm.

Output parameters:

- `antenna_gain_dbi` (number): Antenna gain in dBi used for the calculation.
- `channel_name` (string): Human-readable channel preset name.
- `device_name` (string): Human-readable device name.
- `effective_bw_khz` (number): Bandwidth in kHz used for the calculation.
- `effective_sf` (number): Spreading factor used for the calculation.
- `link_budget_db` (number): Total link budget in dB before terrain correction.
- `max_range_km` (number): Estimated maximum range in km accounting for terrain correction.
- `rx_sensitivity_dbm` (number): Receiver sensitivity in dBm for the selected channel preset.
- `tx_power_dbm` (number): Transmit power in dBm used for the calculation.

### `eirp_compliance` (~346 tokens)

eirp compliance

Checks EIRP (Effective Isotropic Radiated Power) compliance against regional regulatory limits for LoRa and Meshtastic operation. Computes EIRP from transmit power, antenna gain, and cable loss, then compares against FCC (US, 36 dBm), ETSI (EU, 16.15 dBm), ACMA (Australia, 30 dBm), IC (Canada, 36 dBm), and ARIB (Japan, 13 dBm) limits. Returns compliance status, margin in dB, and a warning message if over the limit. Critical for Meshtastic deployments using aftermarket high-gain antennas which can easily exceed ETSI/JP limits. Accepts tx_power and antenna_gain from meshtastic_range for chain validation.

Input parameters:

- `antenna_gain_dbi` (number, required): Antenna gain in dBi. Stock Meshtastic antennas: 2-3 dBi. External: 6-10+ dBi.
- `cable_loss_db` (number): Coaxial cable and connector loss in dB. Set 0 for devices with integrated antennas.
- `custom_limit_dbm` (number): Custom EIRP limit in dBm. Only used when region is 'custom'.
- `region` (string): Regulatory region for EIRP limit lookup. FCC_US: 36 dBm, ETSI_EU: ~16 dBm, ACMA_AU: 30 dBm, IC_CA: 36 dBm, JP: 13 dBm.
- `tx_power_dbm` (number, required): Conducted transmit power at the radio output in dBm. Typical LoRa: 14-22 dBm.

Output parameters:

- `compliant` (boolean): True if EIRP is at or below the regional limit.
- `eirp_dbm` (number): Calculated EIRP in dBm: tx_power + antenna_gain - cable_loss.
- `eirp_watts` (number): Calculated EIRP converted to watts.
- `limit_dbm` (number): Regional EIRP limit in dBm.
- `limit_watts` (number): Regional EIRP limit converted to watts.
- `margin_db` (number): Margin below the limit in dB. Positive = compliant, negative = over limit.
- `region_name` (string): Human-readable region name.
- `warning` (string): Warning message if non-compliant, or empty string if compliant.

### `meshtastic_power` (~380 tokens)

meshtastic power

Calculates Meshtastic node power consumption and battery runtime using device-specific power profiles and firmware role-based duty cycling. Models sleep, RX, and TX current draw for Heltec V3, RAK WisBlock, T-Beam, T-Beam Supreme, and Station G2 with GPS, BLE, and display peripheral toggles. Role selection (client, router, repeater, client_muted) controls the duty cycle model: routers stay in RX mode continuously while clients sleep between events. Returns average current, runtime in hours/days, daily Wh consumption, and time distribution across TX/RX/sleep states. Feed daily_wh to solar_sizing for off-grid planning.

Input parameters:

- `battery_mah` (number): Battery capacity in milliamp-hours. Common: 1100 (18650 min), 3000 (typical), 6000 (large).
- `battery_voltage` (number): Nominal battery voltage. 3.7V for single-cell LiPo/Li-ion, 7.4V for 2S packs.
- `bluetooth_enabled` (boolean): Whether Bluetooth is enabled for phone connection.
- `channel_preset` (string): Meshtastic channel preset. Affects TX airtime per message and thus power consumption.
- `device` (string): Meshtastic hardware device. Selects power consumption profile for sleep, RX, TX, GPS, and BLE.
- `gps_enabled` (boolean): Whether GPS is enabled. Significantly increases power draw on devices with built-in GPS.
- `messages_per_hour` (number): Expected messages sent and received per hour. Includes both TX and RX message events.
- `role` (string): Meshtastic node role. client: sleeps between events. router: always listening. repeater: always listening, no display/BLE. client_muted: aggressive sleep.

Output parameters:

- `avg_current_ma` (number): Estimated average current draw in milliamps.
- `daily_wh` (number): Estimated daily energy consumption in watt-hours.
- `runtime_days` (number): Estimated battery runtime in days.
- `runtime_hours` (number): Estimated battery runtime in hours.
- `rx_time_pct` (number): Percentage of time spent in receive mode (radio listening).
- `sleep_time_pct` (number): Percentage of time spent in sleep/low-power mode.
- `tx_time_pct` (number): Percentage of time spent transmitting.

### `lora_param_optimizer` (~332 tokens)

lora param optimizer

Recommends optimal LoRa spreading factor, bandwidth, and TX power based on target range, terrain, and optimization priority. Iterates through all SF (7-12) and BW (125/250/500 kHz) combinations, computing achievable range, airtime, data rate, and battery impact for each. Ranks candidates by priority: 'range' maximizes distance, 'speed' minimizes airtime, 'battery' minimizes power consumption, 'balanced' penalizes extremes. Respects regional TX power limits (FCC/ETSI/ACMA) and duty cycle constraints. Returns the recommended parameters with estimated range, airtime, duty-cycle message limit, battery life, and data rate. Essential for tuning Meshtastic and LoRa deployments to specific requirements.

Input parameters:

- `antenna_gain_dbi` (number): Antenna gain in dBi. 2.15 = half-wave dipole reference.
- `max_payload_bytes` (integer): Maximum payload size in bytes for airtime calculation.
- `priority` (string): Optimization priority. range: maximize distance (high SF, low BW). speed: minimize airtime (low SF, high BW). battery: minimize power draw. balanced: best trade-off across all factors.
- `region` (string): Regulatory region. Determines max TX power and duty cycle limit.
- `target_range_km` (number, required): Desired communication range in kilometers.
- `terrain` (string): Terrain type for path loss model. open: line-of-sight, suburban: light buildings, urban: moderate buildings, dense_urban: city center, indoor: inside buildings.

Output parameters:

- `airtime_ms` (number): Packet airtime in milliseconds for the given payload.
- `data_rate_bps` (number): Effective data rate in bits per second.
- `estimated_battery_hours` (number): Estimated battery life in hours with a 3000 mAh reference battery.
- `estimated_range_km` (number): Estimated achievable range in km with the recommended parameters.
- `messages_per_hour_limit` (integer): Maximum messages per hour under regional duty cycle constraint.
- `recommended_bw_khz` (number): Recommended bandwidth in kHz (125, 250, or 500).
- `recommended_sf` (integer): Recommended spreading factor (7-12).
- `recommended_tx_dbm` (number): Recommended transmit power in dBm.

### `zfs_capacity` (~225 tokens)

zfs capacity

Calculate usable ZFS pool capacity for any RAID level including stripe, mirror, raidz1, raidz2, and raidz3. Computes raw capacity, parity overhead, data disk count, usable terabytes after ZFS metadata overhead (checksums, block pointers, uberblocks), and storage efficiency percentage. Essential for planning NAS builds, TrueNAS/ZFS server storage, and estimating how much usable space a given disk configuration will provide. Supports variable disk sizes and configurable metadata overhead.

Input parameters:

- `disk_count` (integer, required): Total number of physical disks in the pool
- `disk_size_tb` (number, required): Size of each individual disk in terabytes
- `metadata_overhead_pct` (number): Percentage of raw capacity consumed by ZFS metadata, checksums, and internal structures
- `raid_type` (string): ZFS RAID level: stripe (no redundancy), mirror (2-way), raidz1/2/3 (single/double/triple parity)
- `record_size_kb` (number): ZFS record size in kilobytes, affects compression and performance

Output parameters:

- `data_disks` (number): Number of disks (or disk-equivalents) available for data storage
- `efficiency_pct` (number): Storage efficiency as a percentage of raw capacity
- `parity_disks` (number): Number of disks (or disk-equivalents) consumed by parity/mirroring
- `raw_tb` (number): Total raw capacity across all disks in terabytes
- `usable_tb` (number): Usable capacity after parity and metadata overhead in terabytes

### `zfs_ram` (~251 tokens)

zfs ram

Calculate recommended RAM and ARC sizing for a ZFS storage pool based on workload type, pool size, deduplication status, and L2ARC cache size. Computes minimum and recommended RAM in gigabytes, ARC target size, and dedup table overhead. Accounts for workload-specific IO patterns: NAS (sequential, 1GB/TB), database (random, 2GB/TB), virtualization (mixed, 1.5GB/TB). Deduplication adds approximately 5GB per TB for the DDT. L2ARC index requires 1GB RAM per 10GB of L2ARC. Essential for TrueNAS, FreeNAS, and custom ZFS server builds.

Input parameters:

- `dedup_enabled` (boolean): Whether ZFS deduplication is enabled (significantly increases RAM requirements)
- `l2arc_size_gb` (number): Size of L2ARC (read cache SSD) in gigabytes; requires additional RAM for index
- `pool_size_tb` (number, required): Total usable pool size in terabytes
- `workload` (string): Primary workload type: general (mixed), nas (sequential reads/writes), database (random IO), virtualization (mixed random)

Output parameters:

- `arc_target_gb` (number): Target ARC (Adaptive Replacement Cache) size in gigabytes
- `dedup_table_gb` (number): Estimated dedup table (DDT) RAM requirement in gigabytes
- `min_ram_gb` (number): Minimum recommended RAM in gigabytes for stable operation
- `notes` (string): Human-readable sizing rationale and recommendations
- `recommended_ram_gb` (number): Recommended RAM in gigabytes for optimal performance (2x minimum)

### `tcp_throughput` (~200 tokens)

tcp throughput

Calculate maximum TCP throughput using the Bandwidth-Delay Product (BDP) formula. Given link bandwidth and round-trip latency, computes the BDP (maximum in-flight data), achievable throughput with a given TCP window size, link utilization percentage, and recommended window size for full utilization. Critical for diagnosing slow transfers over high-latency links (WAN, VPN, satellite), tuning TCP buffers, and understanding why a 1Gbps link may only deliver 25Mbps with default 64KB windows. Applies to iperf testing, WAN optimization, and network capacity planning.

Input parameters:

- `bandwidth_mbps` (number, required): Available link bandwidth in megabits per second
- `mss_bytes` (number): Maximum Segment Size in bytes (typically 1460 for Ethernet)
- `rtt_ms` (number, required): Round-trip time (latency) in milliseconds
- `window_size_kb` (number): TCP receive window size in kilobytes

Output parameters:

- `bdp_bytes` (number): Bandwidth-Delay Product in bytes: maximum data in flight
- `bdp_kb` (number): Bandwidth-Delay Product in kilobytes
- `max_throughput_mbps` (number): Maximum achievable TCP throughput in megabits per second given the window size
- `recommended_window_kb` (number): Minimum window size in kilobytes needed to fully utilize the link
- `utilization_pct` (number): Percentage of available bandwidth that can actually be used
- `window_sufficient` (boolean): Whether the current window size is large enough to fill the pipe

### `wireguard_mtu` (~202 tokens)

wireguard mtu

Calculate the optimal MTU for a WireGuard VPN tunnel interface with a detailed overhead breakdown. Accounts for WireGuard header (32 bytes), outer IP header (20 bytes IPv4 or 40 bytes IPv6), UDP header (8 bytes), and optional PPPoE encapsulation (8 bytes). Prevents fragmentation and PMTUD black holes by computing the maximum inner packet size that fits within the physical link MTU. Essential for WireGuard setup on residential ISP connections (PPPoE), IPv6 tunnels, and any VPN where incorrect MTU causes slow or stalled connections.

Input parameters:

- `interface_mtu` (integer): MTU of the underlying physical or virtual network interface in bytes
- `ipv6` (boolean): Whether the outer (transport) IP header uses IPv6 (40 bytes) instead of IPv4 (20 bytes)
- `over_pppoe` (boolean): Whether the link uses PPPoE encapsulation (adds 8 bytes of overhead)

Output parameters:

- `breakdown` (object): Itemized breakdown of each overhead component in bytes
- `overhead_bytes` (number): Total encapsulation overhead in bytes subtracted from interface MTU
- `wireguard_mtu` (number): Optimal MTU to set on the WireGuard tunnel interface in bytes

### `subnet_calculator` (~154 tokens)

subnet calculator

Calculate IPv4 subnet details from CIDR notation. Parses a CIDR block (e.g. 192.168.1.0/24) and returns the network address, broadcast address, subnet mask, wildcard mask, first and last usable host addresses, total and usable host counts, prefix length, and classful IP class (A/B/C/D/E). Essential for homelab network planning, VLAN segmentation, firewall rule design, and understanding address space allocation. Handles special cases for /31 point-to-point links (RFC 3021) and /32 host routes.

Input parameters:

- `cidr` (string, required): IPv4 address in CIDR notation, e.g. 192.168.1.0/24

Output parameters:

- `broadcast_address` (string): Broadcast address of the subnet
- `first_usable` (string): First usable host address in the subnet
- `ip_class` (string): Classful IP address class: A, B, C, D (multicast), or E (reserved)
- `last_usable` (string): Last usable host address in the subnet
- `network_address` (string): Network address of the subnet
- `prefix_length` (number): CIDR prefix length, e.g. 24
- `subnet_mask` (string): Subnet mask in dotted decimal notation, e.g. 255.255.255.0
- `total_hosts` (number): Total number of addresses in the subnet including network and broadcast
- `usable_hosts` (number): Number of usable host addresses (excluding network and broadcast)
- `wildcard_mask` (string): Wildcard (inverse) mask, e.g. 0.0.0.255

### `raid_iops` (~287 tokens)

raid iops

Estimate RAID array IOPS performance and latency for ZFS and traditional RAID configurations. Calculates maximum read IOPS, write IOPS (accounting for write penalty/amplification per RAID level), blended IOPS for a configurable read/write workload mix, and rough per-disk latency. Supports stripe, mirror, raidz1, raidz2, and raidz3. Use with HDD IOPS (~150), SATA SSD (~50000), or NVMe SSD (~100000) to compare RAID topologies and plan storage performance for databases, VMs, media servers, and general homelab NAS workloads. Chains from zfs_capacity.data_disks for integrated capacity+performance planning.

Input parameters:

- `disk_count` (integer, required): Total number of physical disks in the array
- `disk_iops` (number): IOPS per individual disk. Typical values: HDD ~150, SATA SSD ~50000, NVMe SSD ~100000
- `raid_type` (string): RAID level: stripe (no redundancy, write penalty 1), mirror (write penalty 2), raidz1 (write penalty 2), raidz2 (write penalty 3), raidz3 (write penalty 4)
- `read_pct` (number): Percentage of workload that is reads (0-100). Typical: 70 for mixed, 90 for read-heavy, 30 for write-heavy

Output parameters:

- `blended_iops` (number): Effective IOPS for the given read/write mix: (read_pct * read_iops + write_pct * write_iops) / 100
- `estimated_latency_ms` (number): Rough per-disk latency estimate in milliseconds: 1000 / (blended_iops / disk_count)
- `read_iops` (number): Maximum read IOPS: disk_count * disk_iops
- `write_iops` (number): Maximum write IOPS: disk_count * disk_iops / write_penalty
- `write_penalty` (number): Write amplification factor for the chosen RAID level

### `power_cost` (~228 tokens)

power cost

Calculate total power consumption, electricity cost, and circuit requirements for a homelab. Enter each device's wattage to get daily/monthly/yearly kWh and cost at your local electricity rate. Accounts for cooling overhead via PUE (Power Usage Effectiveness). Shows amperage draw at 120V and 240V and warns if you exceed the NEC 80% continuous load limit on a 15A breaker. Essential for budgeting homelab operating expenses and ensuring your electrical panel can handle the load. Chain output total_watts into cooling_btu for heat load sizing.

Input parameters:

- `devices` (array, required): List of devices with their wattage
- `hours_per_day` (number): Hours per day the devices are running
- `kwh_rate_cents` (number): Electricity cost in cents per kilowatt-hour
- `pue` (number): Power Usage Effectiveness — ratio of total facility power to IT equipment power. 1.0 means no cooling overhead, 1.2 is typical for a home server closet, 1.5+ for poorly ventilated spaces

Output parameters:

- `amps_at_120v` (number): Current draw at 120V (typical North American outlet)
- `amps_at_240v` (number): Current draw at 240V (typical European / high-power outlet)
- `breaker_15a_pct` (number): Percentage of a 15A / 120V circuit used. NEC requires continuous loads stay under 80% (12A)
- `daily_kwh` (number): Daily energy consumption in kilowatt-hours
- `monthly_cost_usd` (number): Estimated monthly electricity cost in USD
- `monthly_kwh` (number): Monthly energy consumption in kilowatt-hours (30.44 day average)
- `total_watts` (number): Sum of all device wattages before PUE adjustment
- `total_with_pue_watts` (number): Total power draw including cooling overhead (watts * PUE)
- `yearly_cost_usd` (number): Estimated yearly electricity cost in USD
- `yearly_kwh` (number): Yearly energy consumption in kilowatt-hours (365.25 day average)

### `cooling_btu` (~287 tokens)

cooling btu

Estimate the cooling load (BTU/hr) for a homelab or server closet based on equipment wattage, room dimensions, insulation quality, and solar exposure. All electrical power converts to heat — this tool calculates equipment heat output, envelope heat gain through walls, and solar gain to produce a total BTU/hr cooling requirement. Recommends AC tonnage, mini-split sizing (rounded to standard 6K BTU increments), and exhaust fan CFM for ventilation-only cooling. Use after power_cost to size cooling for your homelab room.

Input parameters:

- `ambient_temp_f` (number): Ambient temperature outside the room in degrees Fahrenheit
- `insulation` (string): Wall/ceiling insulation quality: poor (uninsulated garage), average (standard drywall), good (insulated interior), excellent (server room with vapor barrier)
- `room_height_ft` (number): Room ceiling height in feet
- `room_length_ft` (number): Room length in feet
- `room_width_ft` (number): Room width in feet
- `sun_exposure` (string): Solar heat gain: none (interior/basement room), partial (one exterior wall with window), full (multiple sun-facing windows)
- `target_temp_f` (number): Desired room temperature in degrees Fahrenheit
- `total_watts` (number, required): Total power consumption in watts — all power becomes heat

Output parameters:

- `ac_tons` (number): Cooling capacity needed in tons of refrigeration (1 ton = 12,000 BTU/hr)
- `envelope_btu` (number): Heat gain/loss through walls based on room size, insulation, and delta-T
- `equipment_btu` (number): Heat generated by equipment in BTU/hr (watts * 3.412)
- `exhaust_cfm_needed` (number): Exhaust fan airflow needed in cubic feet per minute if using ventilation instead of AC
- `mini_split_btu_recommended` (number): Recommended mini-split size rounded up to nearest 6,000 BTU increment
- `total_btu` (number): Total cooling load in BTU/hr (equipment + envelope + sun)
- `will_overheat` (boolean): True if total heat load is positive and no cooling is provided

### `rack_capacity` (~154 tokens)

rack capacity

Quick rack space and weight sizing calculator for homelab and small data center racks. Enter your devices with their height in rack units, weight, and wattage to get total utilization, remaining free space, weight totals in lbs and kg, and recommended PDU count based on the NEC 80% continuous load rule (1920W per 20A/120V PDU). Estimates cable management overhead at 2U per 10U of installed gear. Outputs total_watts that chains into power_cost and cooling_btu for full infrastructure planning.

Input parameters:

- `devices` (array, required): List of devices to place in the rack
- `rack_units` (integer): Total rack height in rack units (standard is 42U)

Output parameters:

- `effective_free_u` (number): Free rack units after subtracting cable management overhead
- `free_u` (number): Remaining empty rack units
- `overhead_u` (number): Estimated cable management overhead in rack units (2U per 10U of gear)
- `recommended_pdu_count` (number): Recommended number of PDUs (each PDU = 80% of 20A/120V = 1920W)
- `total_watts` (number): Total power draw of all devices in watts
- `total_weight_kg` (number): Total weight of all devices in kilograms
- `total_weight_lbs` (number): Total weight of all devices in pounds
- `used_u` (number): Total rack units consumed by devices
- `utilization_pct` (number): Percentage of rack space used by devices

### `network_bandwidth` (~281 tokens)

network bandwidth

Plan and validate network link capacity for homelab workloads. Determine whether a 1G, 2.5G, 10G, or faster link can handle your concurrent streams (VMs, backups, media, iSCSI). Calculates effective bandwidth after TCP/IP overhead, total required bandwidth, utilization percentage, and remaining headroom. Flags saturation at 80% utilization and identifies whether the bottleneck is network or storage. Provides a 1TB transfer time reference and recommends the next link speed upgrade if your current link is saturated. Useful for planning NIC upgrades, switch purchases, and storage network design.

Input parameters:

- `concurrent_streams` (integer): Number of concurrent data streams / transfers
- `link_speed_gbps` (number, required): Network link speed in gigabits per second (e.g. 1, 2.5, 5, 10, 25, 40, 100)
- `protocol_overhead_pct` (number): TCP/IP protocol overhead as a percentage (typically 3-5% for TCP, ~1% for UDP)
- `storage_throughput_mbps` (number): Maximum storage read/write throughput in megabits per second. If provided, checks whether storage is the bottleneck
- `stream_bandwidth_mbps` (number): Bandwidth required per stream in megabits per second

Output parameters:

- `bottleneck` (string): Identified bottleneck: 'storage', 'network', or 'none'
- `effective_bandwidth_mbps` (number): Usable bandwidth after protocol overhead in Mbps
- `headroom_mbps` (number): Remaining bandwidth after all streams (negative means oversubscribed)
- `recommended_link_speed_gbps` (number|null): Suggested next link speed upgrade if saturated, null if current link is sufficient
- `required_bandwidth_mbps` (number): Total bandwidth required by all streams in Mbps
- `saturated` (boolean): True if utilization exceeds 80% — link is effectively saturated
- `time_to_transfer_1tb_hours` (number): Time to transfer 1 TB over the effective bandwidth, in hours
- `utilization_pct` (number): Percentage of effective bandwidth used by all streams

### `thermal_enclosure` (~255 tokens)

thermal enclosure

Estimate steady-state thermal behaviour of a rectangular enclosure (server rack, electronics housing, equipment cabinet) using a lumped-parameter energy balance with natural-convection and radiation correlations, or forced-flow air energy balance. Accepts enclosure dimensions, heat source positions and wattages, and airflow configuration. Returns temperature extremes, estimated hotspot location, airflow velocity summary, and overall thermal resistance. Runs instantly in-worker; a full CFD container backend is planned for mesh-level detail.

Input parameters:

- `ambient_temp_c` (number): Ambient air temperature in Celsius
- `flow_type` (string, required): Airflow type
- `heat_sources` (array, required): Heat sources inside the enclosure
- `height_m` (number, required): Enclosure height (Z) in metres
- `inlet_position` (string): Inlet location
- `inlet_velocity_ms` (number): Inlet air velocity in m/s (required for forced flow)
- `length_m` (number, required): Enclosure length (X) in metres
- `mesh_density` (string): Mesh density — coarse (~50K cells), medium (~200K), fine (~500K)
- `outlet_position` (string): Outlet location
- `width_m` (number, required): Enclosure width (Y) in metres

Output parameters:

- `avg_temp_c` (number): Volume-averaged temperature (°C)
- `avg_velocity_ms` (number): Average airflow velocity (m/s)
- `hotspot_location` (object): Location of the temperature maximum
- `iterations` (number): Number of solver iterations to convergence
- `max_temp_c` (number): Maximum temperature in the enclosure (°C)
- `max_velocity_ms` (number): Peak airflow velocity (m/s)
- `mesh_cells` (number): Number of mesh cells used
- `min_temp_c` (number): Minimum temperature (°C)
- `runtime_ms` (number): Simulation wall-clock time in milliseconds
- `solver` (string): OpenFOAM solver used
- `thermal_resistance_cw` (number): Overall thermal resistance (°C/W)
- `total_heat_w` (number): Total heat load (W)
- `warnings` (array): Any solver warnings

### `heatsink_cfd` (~244 tokens)

heatsink cfd

Analyze a forced-convection fin-array heatsink using established channel-flow correlations (developing laminar Nusselt, fin efficiency tanh(mH)/mH, parallel-plate friction). Computes base-to-air thermal resistance, pressure drop, base and fin-tip temperatures, fin efficiency, and the optimal fin spacing for the given airflow. Use for heatsink selection and first-pass optimization in electronics cooling. Runs instantly in-worker; mesh-level CFD via container backend is planned.

Input parameters:

- `airflow_velocity_ms` (number, required): Incoming airflow velocity in m/s
- `ambient_temp_c` (number): Ambient air temperature in Celsius
- `base_height_m` (number, required): Base plate thickness in metres
- `base_length_m` (number, required): Heatsink base length in metres
- `base_width_m` (number, required): Heatsink base width in metres
- `fin_count` (integer, required): Number of fins
- `fin_height_m` (number, required): Fin height in metres
- `fin_thickness_m` (number, required): Fin thickness in metres
- `heat_load_w` (number, required): Total heat load applied to base in watts
- `mesh_density` (string): Mesh density

Output parameters:

- `avg_base_temp_c` (number): Average base temperature (°C)
- `fin_efficiency` (number): Fin efficiency (0-1)
- `fin_tip_temp_c` (number): Average fin tip temperature (°C)
- `max_base_temp_c` (number): Maximum base temperature (°C)
- `mesh_cells` (number): Mesh cell count
- `optimal_fin_spacing_m` (number): Suggested optimal fin spacing for this airflow (m)
- `pressure_drop_pa` (number): Pressure drop across the heatsink (Pa)
- `runtime_ms` (number): Simulation time in ms
- `thermal_resistance_cw` (number): Thermal resistance from base to air (°C/W)
- `warnings` (array): Solver warnings

### `pcb_thermal` (~210 tokens)

pcb thermal

Estimate PCB component temperatures by solving a thermal resistance network (thermal↔electrical analogy) with the built-in MNA solver. Each component gets a junction node (package θjb from a typical-datasheet table), a local board node coupled to its neighbours through in-plane FR4/copper conduction, and convection to ambient. Computes per-component junction and case temperatures, board extremes, and flags max-junction violations. Runs instantly in-worker; mesh-level CFD via container backend is planned.

Input parameters:

- `airflow_velocity_ms` (number): Airflow velocity in m/s (0 = natural convection)
- `ambient_temp_c` (number): Ambient temperature in Celsius
- `board_length_m` (number, required): Board length in metres
- `board_thickness_m` (number): Board thickness in metres (default 1.6mm FR4)
- `board_width_m` (number, required): Board width in metres
- `components` (array, required): Components on the board
- `mesh_density` (string): Mesh density

Output parameters:

- `avg_board_temp_c` (number): Average board temperature (°C)
- `component_temps` (array): Per-component thermal results
- `max_board_temp_c` (number): Maximum board surface temperature (°C)
- `mesh_cells` (number): Mesh cell count
- `runtime_ms` (number): Simulation time in ms
- `total_heat_w` (number): Total heat dissipation (W)
- `violations` (number): Number of components exceeding thermal limits
- `warnings` (array): Solver warnings

### `battery_life` (~198 tokens)

battery life

Calculates battery runtime and energy capacity given cell capacity in mAh, nominal voltage, and average current draw. Accounts for real-world discharge efficiency (Peukert-adjacent derating) to produce effective capacity, total energy in Wh, and runtime in hours and days. Useful for IoT sensor node planning, portable device design, UPS hold-up estimation, and solar battery bank cycling analysis. Outputs feed into solar_sizing (battery_kwh) and ups_runtime (battery_wh) for system-level calculations.

Input parameters:

- `capacity_mah` (number, required): Battery capacity in milliamp-hours (mAh)
- `current_draw_ma` (number, required): Average current draw in milliamps (mA)
- `efficiency` (number): Discharge efficiency factor (0-1), accounts for conversion losses and derating, default 0.85
- `voltage` (number): Nominal battery voltage (V), default 3.7 for Li-ion

Output parameters:

- `effective_capacity_mah` (number): Effective usable capacity after efficiency derating (mAh)
- `energy_wh` (number): Total battery energy in watt-hours (capacity_mah * voltage / 1000)
- `runtime_days` (number): Estimated runtime in days
- `runtime_hours` (number): Estimated runtime in hours

### `wire_gauge` (~190 tokens)

wire gauge

Determines the minimum AWG (American Wire Gauge) conductor size for a given current, voltage, one-way cable distance, and maximum allowable voltage drop percentage. Supports copper and aluminum conductors. Computes round-trip resistance, actual voltage drop in volts and percent, and wire cross-sectional area. Essential for DC solar runs, battery bank wiring, EV charging circuits, and low-voltage landscape lighting. NEC recommends 3% max drop for branch circuits and 5% total including feeder. Outputs the smallest AWG that satisfies the drop constraint.

Input parameters:

- `conductor` (string): Conductor material: copper or aluminum
- `current_amps` (number, required): Load current in amperes (A)
- `distance_m` (number, required): One-way conductor distance in meters
- `max_drop_pct` (number): Maximum allowable voltage drop as percentage (default 3%)
- `voltage` (number, required): System voltage (V)

Output parameters:

- `actual_drop_pct` (number): Actual voltage drop percentage with recommended gauge
- `actual_drop_v` (number): Actual voltage drop in volts
- `insufficient` (boolean): True if even the largest AWG (4/0) cannot meet the voltage drop target
- `recommended_awg` (number): Recommended AWG gauge number (smaller number = thicker wire)
- `recommended_awg_label` (string): Human-readable AWG label (e.g. '10' or '0000 (4/0)')
- `resistance_per_m` (number): Resistance per meter of the recommended gauge (ohm/m)
- `wire_area_mm2` (number): Cross-sectional area of recommended gauge in mm^2

### `solar_sizing` (~282 tokens)

solar sizing

Sizes an off-grid solar power system by calculating the number of panels and battery bank capacity required for a given daily energy consumption. Accounts for system losses (inverter, wiring, charge controller), battery depth-of-discharge, and autonomy days for cloudy weather. Outputs panel count, total panel wattage, battery capacity in kWh and Ah, and minimum charge controller amperage (with 25% safety margin per NEC 690.8). Supports 12V, 24V, and 48V system architectures. Use for cabin, RV, telecom tower, and remote IoT deployments.

Input parameters:

- `battery_autonomy_days` (number): Number of days the battery bank should sustain load without solar input
- `daily_kwh` (number, required): Daily energy consumption in kilowatt-hours (kWh)
- `dod` (number): Battery depth of discharge (0-1), default 0.8 for LiFePO4
- `panel_watts` (number): Rated wattage per solar panel (W)
- `peak_sun_hours` (number): Average peak sun hours per day for your location (hours)
- `system_efficiency` (number): Overall system efficiency (0-1), accounts for inverter, wiring, and controller losses
- `system_voltage` (number): Battery bank system voltage: 12, 24, or 48 V

Output parameters:

- `battery_ah` (number): Required battery bank capacity in amp-hours at system voltage
- `battery_kwh` (number): Required battery bank capacity in kWh (before DoD)
- `charge_controller_amps` (number): Minimum charge controller current rating in amps (with 25% margin)
- `daily_solar_kwh` (number): Daily solar energy needed after accounting for system losses (kWh)
- `panels_needed` (integer): Number of solar panels required (rounded up)
- `total_panel_watts` (number): Total installed panel wattage (W)

### `ups_runtime` (~218 tokens)

ups runtime

Estimates UPS (Uninterruptible Power Supply) backup runtime from battery specifications and connected load. Takes VA rating, watt rating, load in watts, and battery configuration (count, voltage, amp-hours) to compute effective stored energy after efficiency losses and runtime in minutes and hours. Detects overload conditions when load exceeds the UPS watt rating. Calculates power factor from VA/W ratings. Ideal for server rack planning, homelab power budgeting, network closet UPS selection, and graceful shutdown timer configuration.

Input parameters:

- `battery_ah` (number): Capacity per battery in amp-hours (Ah)
- `battery_count` (integer): Number of batteries in the UPS
- `battery_voltage` (number): Voltage per battery (V)
- `efficiency` (number): Inverter/conversion efficiency (0-1), default 0.9
- `load_watts` (number, required): Connected load in watts
- `va_rating` (number, required): UPS VA (volt-ampere) rating
- `watt_rating` (number, required): UPS real power (watt) rating

Output parameters:

- `battery_wh` (number): Total battery energy in watt-hours (before efficiency)
- `effective_wh` (number): Usable battery energy after efficiency losses (Wh)
- `load_pct` (number): Load as percentage of UPS watt capacity
- `overloaded` (boolean): True if load exceeds UPS watt rating
- `pf` (number): Power factor (watt_rating / va_rating)
- `runtime_hours` (number): Estimated backup runtime in hours
- `runtime_minutes` (number): Estimated backup runtime in minutes

### `mah_to_wh` (~156 tokens)

mah to wh

Converts battery capacity from milliamp-hours (mAh) to watt-hours (Wh), kilowatt-hours (kWh), and joules (J) given the nominal cell voltage. This is the most common battery unit conversion needed when comparing cells rated in mAh (e.g. 18650, AA) against energy budgets specified in Wh. Essential for airline lithium battery compliance (100 Wh limit for carry-on), solar battery bank sizing, and UPS capacity planning. Echoes back input values for easy chaining into battery_life, solar_sizing, and ups_runtime tools.

Input parameters:

- `capacity_mah` (number, required): Battery capacity in milliamp-hours (mAh)
- `voltage_v` (number, required): Nominal battery voltage (V)

Output parameters:

- `joules` (number): Energy in joules
- `kwh` (number): Energy in kilowatt-hours
- `mah` (number): Input capacity echoed back (mAh)
- `voltage_v` (number): Input voltage echoed back (V)
- `wh` (number): Energy in watt-hours

### `watts_to_amps` (~151 tokens)

watts to amps

Converts electrical power in watts to current in amps (and milliamps) for a given voltage, using the DC power formula P = V * I. Also computes the implied load resistance via Ohm's law (R = V / I) assuming a purely resistive load. This is the most common electrical conversion for circuit design, fuse selection, wire sizing, and breaker rating. Use the output amps value to feed into wire_gauge for conductor sizing or voltage_drop for cable loss analysis. Covers DC circuits; for AC with power factor, adjust watts to true power first.

Input parameters:

- `voltage_v` (number, required): Voltage in volts (V)
- `watts` (number, required): Power in watts (W)

Output parameters:

- `amps` (number): Current in amperes (A)
- `implied_resistance_ohm` (number): Implied load resistance in ohms assuming resistive load (V/I)
- `milliamps` (number): Current in milliamperes (mA)
- `voltage_v` (number): Input voltage echoed back (V)
- `watts` (number): Input power echoed back (W)

### `voltage_drop` (~231 tokens)

voltage drop

Calculates voltage drop across a conductor run given current, wire length, AWG gauge, system voltage, and conductor material (copper or aluminum). Computes round-trip resistance, voltage drop in volts and percent, voltage at the load end, power dissipated in the wire, and NEC compliance flags (3% max for branch circuits, 5% max for feeders). Use this after wire_gauge to verify a specific gauge meets requirements, or to evaluate an existing installation. Critical for solar panel string wiring, EV charger circuits, low-voltage lighting, and any long DC or AC cable run where resistive losses matter.

Input parameters:

- `conductor` (string): Conductor material: copper or aluminum
- `current_amps` (number, required): Load current in amperes (A)
- `voltage_v` (number, required): System voltage (V)
- `wire_gauge_awg` (number, required): Wire gauge in AWG (e.g. 14, 12, 10; use negative for large gauges: -3 = 4/0)
- `wire_length_m` (number, required): One-way wire length in meters

Output parameters:

- `compliant` (boolean): True if voltage drop is within NEC limits (<=3% branch, <=5% feeder)
- `power_loss_w` (number): Power dissipated as heat in the conductor (W)
- `resistance_ohm` (number): Total round-trip conductor resistance (ohm)
- `voltage_at_load_v` (number): Voltage at the load end (V)
- `voltage_drop_pct` (number): Voltage drop as a percentage of system voltage
- `voltage_drop_v` (number): Voltage drop across the conductor run (V)

### `battery_charge_time` (~262 tokens)

battery charge time

Estimates battery charge time given capacity in mAh, charge current in mA, charger efficiency, and initial state of charge. Accounts for real-world charging losses (typically 80-90% efficient) to produce time in hours and minutes, energy required in Wh (at an optional voltage, default 3.7V for Li-ion), and the C-rate of the charge. Useful for solar charge controller sizing, USB charging time estimation, lead-acid float charging, and EV battery planning. The C-rate output helps verify the charge current is within safe limits (typically 0.5C-1C for Li-ion). Chain from solar_sizing charge_controller_amps to size a solar charging system end-to-end.

Input parameters:

- `capacity_mah` (number, required): Total battery capacity in milliamp-hours (mAh)
- `charge_current_ma` (number, required): Charge current in milliamps (mA)
- `efficiency` (number): Charger efficiency factor (0-1), default 0.85
- `initial_soc_pct` (number): Initial state of charge as percentage (0-100), default 0 (empty)
- `voltage_v` (number): Nominal battery voltage for energy calculation (V), default 3.7 for Li-ion

Output parameters:

- `c_rate` (number): C-rate of the charge (charge_current / capacity)
- `charge_time_hours` (number): Estimated charge time in hours
- `charge_time_minutes` (number): Estimated charge time in minutes
- `energy_required_wh` (number): Energy required to charge at nominal voltage (Wh)

### `solar_load_audit` (~161 tokens)

solar load audit

Calculates total daily energy consumption from an appliance list — the critical first step before sizing solar panels or batteries. Enter each appliance with its wattage, hours of daily use, and quantity. Outputs total daily kWh (with configurable safety margin for surge and inrush current), peak simultaneous wattage, and recommended inverter VA rating per NEC 125% continuous load rule. Feeds directly into solar_sizing (daily_kwh) and battery_autonomy (daily_kwh). Essential for residential, RV, cabin, and off-grid system design.

Input parameters:

- `appliances` (array, required): List of appliances with wattage, hours per day, and quantity
- `safety_margin_pct` (number): Safety margin percentage to account for surge/inrush current, default 20%

Output parameters:

- `appliance_count` (integer): Total number of appliance entries
- `largest_load_watts` (number): Wattage of the single largest appliance (W)
- `peak_watts` (number): Peak simultaneous wattage if all appliances run at once (W)
- `recommended_inverter_va` (number): Recommended inverter size in VA (peak watts * 1.25 per NEC)
- `total_daily_kwh` (number): Total daily energy consumption in kilowatt-hours (kWh)
- `total_daily_wh` (number): Total daily energy consumption in watt-hours (Wh)
- `with_margin_kwh` (number): Daily kWh including safety margin

### `solar_roi` (~336 tokens)

solar roi

Calculates solar system return on investment, payback period, and levelized cost of energy (LCOE). Models year-by-year savings accounting for panel degradation, utility rate inflation, federal Investment Tax Credit (ITC), state rebates, and annual maintenance. Outputs net cost after incentives, payback year, total lifetime savings, ROI percentage, and LCOE in cents/kWh. Essential for residential and commercial solar financial analysis, installer proposals, and comparing solar vs. grid economics over a 25-year system lifetime.

Input parameters:

- `annual_degradation_pct` (number): Annual panel degradation rate, default 0.5% per year
- `annual_maintenance_usd` (number): Annual maintenance cost in USD, default $100
- `annual_production_kwh` (number, required): Estimated annual energy production in kWh (from PVWatts or system_size_kw * peak_sun_hours * 365 * 0.80)
- `annual_rate_increase_pct` (number): Annual utility rate increase percentage, default 3%
- `electricity_rate_cents` (number): Current electricity rate in cents per kWh, default 15
- `federal_itc_pct` (number): Federal Investment Tax Credit percentage, default 30% (US ITC)
- `state_rebate_usd` (number): State or local rebate amount in USD, default 0
- `system_cost_usd` (number, required): Total installed system cost in USD
- `system_lifetime_years` (integer): System lifetime in years, default 25
- `system_size_kw` (number, required): System size in kilowatts (kW)

Output parameters:

- `lcoe_cents_per_kwh` (number): Levelized cost of energy in cents per kWh
- `lifetime_production_kwh` (number): Total energy produced over system lifetime (kWh)
- `net_cost_usd` (number): Net system cost after federal ITC and state rebates (USD)
- `payback_years` (number): Number of years to recoup net cost from savings
- `roi_pct` (number): Return on investment percentage over system lifetime
- `total_savings_usd` (number): Total cumulative savings over system lifetime (USD)
- `year_1_savings_usd` (number): First year net savings (USD)
- `year_25_savings_usd` (number): Final year net savings (USD), or last year if lifetime < 25

### `battery_autonomy` (~270 tokens)

battery autonomy

Calculates how many days a battery bank can sustain loads without solar input — critical for off-grid and backup power sizing. Accounts for depth of discharge, round-trip efficiency (lithium vs lead-acid), minimum state of charge, and optional partial solar contribution during cloudy weather. Outputs autonomy in days and hours, usable capacity, and daily deficit. Use with avg_solar_contribution_pct = 0 for worst-case (no sun) scenarios, or 20-30% for realistic cloudy-day modeling. Chains from solar_sizing (battery_kwh) and solar_load_audit (daily_kwh).

Input parameters:

- `avg_solar_contribution_pct` (number): Average solar contribution during autonomy period (0-100%), default 0 for worst-case
- `battery_kwh` (number, required): Total installed battery capacity in kWh
- `daily_kwh` (number, required): Daily energy consumption in kilowatt-hours (kWh)
- `dod` (number): Depth of discharge (0-1), default 0.8 for lithium
- `min_soc_pct` (number): Minimum state of charge percentage, default 20%
- `round_trip_efficiency` (number): Battery round-trip efficiency (0-1), default 0.90 for lithium, use 0.80 for lead-acid

Output parameters:

- `autonomy_days` (number): Number of days the battery can sustain loads
- `autonomy_hours` (number): Number of hours the battery can sustain loads
- `battery_cycles_per_year` (number): Estimated full discharge cycles per year (365 / autonomy_days)
- `daily_deficit_kwh` (number): Effective daily energy need after solar contribution (kWh)
- `usable_kwh` (number): Usable battery capacity after DoD and efficiency losses (kWh)

### `string_sizing` (~317 tokens)

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 parameters:

- `mppt_imax` (number, required): Maximum MPPT input current in amps
- `mppt_vmax` (number, required): Maximum MPPT input voltage in volts
- `mppt_vmin` (number, required): Minimum MPPT start/operating voltage in volts
- `panel_imp` (number, required): Panel maximum power current (Imp) at STC in amps
- `panel_isc` (number, required): Panel short circuit current (Isc) at STC in amps
- `panel_vmp` (number, required): Panel maximum power voltage (Vmp) at STC in volts
- `panel_voc` (number, required): Panel open circuit voltage (Voc) at STC in volts
- `temp_coeff_voc_pct_per_c` (number): Voc temperature coefficient in %/C (negative for silicon), default -0.30
- `temp_max_c` (number): Maximum expected cell temperature in Celsius, default 60
- `temp_min_c` (number): Minimum expected site temperature in Celsius, default -10

Output parameters:

- `array_watts` (number): Total array power at maximum power point (W)
- `isc_total` (number): Total short circuit current from all parallel strings (A)
- `max_panels_per_string` (integer): Maximum panels per string (limited by Voc at cold temp)
- `max_parallel_strings` (integer): Maximum parallel strings (limited by MPPT Imax)
- `min_panels_per_string` (integer): Minimum panels per string (to meet MPPT Vmin at hot temp)
- `recommended_panels_per_string` (integer): Recommended panels per string (uses max for best output)
- `total_panels` (integer): Total panels in the array (strings * panels per string)
- `vmp_hot_per_string` (number): String Vmp at maximum temperature (V)
- `voc_cold_per_string` (number): String Voc at minimum temperature (V)

### `generator_offset` (~313 tokens)

generator offset

Compares total cost of ownership between a fuel generator and a solar+battery system over a configurable time horizon. Calculates yearly and cumulative costs for generator-only, solar-only (amortized), and hybrid scenarios. Accounts for fuel cost, generator consumption rate, maintenance intervals, solar system amortization, and battery coverage. Outputs yearly costs, total savings, breakeven year, solar coverage percentage, and generator hours saved. Essential for off-grid site planning, remote telecom towers, construction sites, and rural electrification proposals.

Input parameters:

- `battery_kwh` (number): Battery storage capacity in kWh (0 means no battery, generator needed at night), default 0
- `daily_kwh_needed` (number, required): Total daily energy requirement in kWh
- `generator_consumption_gph` (number): Generator fuel consumption in gallons per hour at load, default 1.0
- `generator_fuel_cost_per_gallon` (number): Fuel cost per gallon in USD, default $3.50
- `generator_hours_per_day` (number): Generator runtime hours per day, default 8
- `generator_maintenance_per_1000hrs` (number): Generator maintenance cost per 1000 running hours in USD, default $200
- `solar_daily_kwh_produced` (number, required): Daily solar energy production in kWh
- `solar_system_cost_usd` (number, required): Total solar+battery system cost in USD
- `years_to_compare` (integer): Number of years to compare, default 10

Output parameters:

- `breakeven_year` (number): Year when solar cumulative cost becomes cheaper than generator (0 if never)
- `generator_hours_saved_per_year` (number): Generator hours eliminated per year by solar
- `generator_total_cost_usd` (number): Total generator cost over comparison period in USD
- `generator_yearly_cost_usd` (number): Annual generator cost (fuel + maintenance) in USD
- `savings_pct` (number): Percentage savings of solar vs generator
- `savings_usd` (number): Total savings of solar over generator in USD (negative means generator is cheaper)
- `solar_coverage_pct` (number): Percentage of daily energy needs covered by solar+battery
- `solar_total_cost_usd` (number): Total solar cost over comparison period in USD
- `solar_yearly_cost_usd` (number): Annualized solar system cost (amortized + maintenance) in USD

### `wire_ampacity` (~390 tokens)

wire ampacity

Determine minimum wire gauge using NEC Table 310.16 ampacity ratings with full derating. Looks up base ampacity for copper or aluminum conductors at 60°C, 75°C, or 90°C insulation rating, then applies NEC 310.15(C)(1) ambient temperature correction and NEC 310.15(C)(2) conductor count adjustment. Automatically applies the 125% continuous load factor per NEC 210.20(A) when flagged. Returns the minimum AWG that meets the derated requirement, plus a comparison table of all gauges. Different from wire_gauge which focuses on voltage drop — use both together for complete wire sizing. Essential for residential panels, commercial feeders, solar arrays, and EV charging installations.

Input parameters:

- `ambient_temp_c` (number): Ambient temperature in °C. NEC base is 30°C. Higher temps require derating. Typical: 30 (indoor), 40 (attic/hot), 45+ (rooftop conduit).
- `conductor` (string): Conductor material. Copper has higher ampacity; aluminum is lighter and cheaper for large feeders.
- `conductors_in_raceway` (integer): Number of current-carrying conductors in a single raceway or cable. More than 3 requires derating per NEC 310.15(C)(2).
- `continuous_load` (boolean): Whether the load operates continuously (3+ hours). NEC requires 125% sizing for continuous loads. Set false for intermittent loads.
- `current_amps` (number, required): Required circuit current in amperes. Use 125% of continuous load per NEC 210.20(A).
- `insulation` (string): Insulation temperature rating in °C. 60=TW/UF-B, 75=THW/THWN/XHHW (most common), 90=THHN/THWN-2.

Output parameters:

- `all_gauges` (array): All available gauges with their ampacities for comparison.
- `ambient_correction` (number): Ambient temperature correction factor applied (1.0 at 30°C).
- `base_ampacity_a` (number): Base ampacity from NEC 310.16 before any derating, in amperes.
- `conductor_count_correction` (number): Conductor count correction factor (1.0 for 3 or fewer).
- `derated_ampacity_a` (number): Final ampacity after applying ambient temperature and conductor count correction factors, in amperes.
- `insulation_label` (string): Insulation rating description.
- `minimum_awg` (number): Minimum AWG wire gauge that meets the derated ampacity requirement.
- `minimum_awg_label` (string): Human-readable AWG label (e.g. '4/0', '12', '2').
- `required_ampacity_a` (number): Ampacity required to carry the load (includes 125% factor if continuous).

### `inverter_sizing` (~468 tokens)

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 parameters:

- `continuous_watts` (number, required): Total continuous load in watts. Sum of all appliances that may run simultaneously. Chain from solar_load_audit.peak_watts.
- `derating_pct` (number): Derating percentage for temperature, altitude, and safety margin. NEC recommends 20% (80% continuous rating). Range 0-50%.
- `efficiency` (number): 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.
- `largest_load_watts` (number): Wattage of the single largest appliance. Used to estimate surge if surge_watts is not provided. Chain from solar_load_audit.largest_load_watts.
- `power_factor` (number): 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.
- `surge_watts` (number): 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.
- `system_voltage` (string): DC system voltage. 12V for small/mobile, 24V for medium, 48V for large residential/commercial. Higher voltage = lower current = thinner cables.

Output parameters:

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

### `pcb_layout` (~372 tokens)

pcb layout

Turn a SPICE netlist into a fab-ready 2-layer PCB: assigns real footprints (0805, TO-92, DO-35, DIP-8, headers, LED, radial-cap), auto-places components (connectivity-aware; or use your own placement), routes a 2-layer maze router with vias, and VERIFIES the result with DRC (clearance/crossing checks) and ERC (union-find copper connectivity proven against the netlist). Returns the board, routing stats + honest unrouted-net list, DRC violations, ERC net status, a 'manufacturable' flag (true only when DRC+ERC clean and everything routed), SVG layers (top/bottom copper, silkscreen, drill, assembly), and optional Gerber RS-274X + Excellon drill files. Same netlist you simulate with spice_simulate — design, verify, and lay out an entire board through the tool layer. Supply a 'placement' array for production-quality boards; the auto-router is a first-pass best-of-N-seeds.

Input parameters:

- `board` (object): Optional board size in mm; auto-sized if omitted
- `clearance_mm` (number): Minimum copper clearance in mm
- `gerber` (boolean): Also return Gerber RS-274X + Excellon drill files
- `gnd_pour` (boolean): Treat GND as a bottom-layer pour (unions all GND pads for ERC)
- `netlist` (string, required): SPICE netlist (same format as spice_simulate). Components + nets are extracted; .model/.tran/etc. ignored.
- `placement` (array): Optional manual placement; omit for connectivity-aware auto-placement (best of N seeds).
- `trace_width_mm` (number): Routing trace width in mm

Output parameters:

- `board`
- `components`
- `drc`
- `erc`
- `gerber`
- `layers_svg`
- `manufacturable` (boolean)
- `nets`
- `routing`
- `warnings` (array)

### `voltage_divider` (~190 tokens)

voltage divider

Calculates output voltage, current draw, and power dissipation for a resistive voltage divider. Given an input voltage Vin and two resistor values R1 (upper) and R2 (lower), computes Vout = Vin * R2 / (R1 + R2), divider current, individual resistor power dissipation, and the division ratio. Essential for biasing circuits, level shifting, ADC input scaling, and feedback networks. Use before trace_width to size traces for divider current, or chain from a power supply output to verify signal levels.

Input parameters:

- `r1_ohm` (number, required): Upper resistor value in ohms (R1), connected between Vin and Vout node.
- `r2_ohm` (number, required): Lower resistor value in ohms (R2), connected between Vout node and ground.
- `vin` (number, required): Input voltage in volts (V). Must be positive.

Output parameters:

- `current_ma` (number): Current through the divider in milliamps (mA).
- `power_r1_mw` (number): Power dissipated by R1 in milliwatts (mW).
- `power_r2_mw` (number): Power dissipated by R2 in milliwatts (mW).
- `ratio` (number): Voltage division ratio R2/(R1+R2), dimensionless 0-1.
- `total_power_mw` (number): Total power dissipated by the divider in milliwatts (mW).
- `vout` (number): Output voltage in volts at the R1-R2 junction.

### `rc_filter` (~207 tokens)

rc filter

Computes the cutoff frequency, time constant, impedance, and phase shift of a first-order RC filter. Supports both lowpass and highpass topologies. The cutoff frequency is f = 1/(2*pi*R*C) where the signal is attenuated by 3 dB. The time constant tau = R*C governs transient response — the capacitor reaches 63.2% of its final value after one tau. Use for anti-aliasing before ADCs, DC blocking, noise filtering, and signal conditioning. Chain from voltage_divider to design filtered bias networks.

Input parameters:

- `capacitance_f` (number, required): Capacitance in farads (C). The capacitive element of the RC filter.
- `filter_type` (string): Filter topology: 'lowpass' (R then C to ground) or 'highpass' (C then R to ground).
- `resistance_ohm` (number, required): Resistance in ohms (R). The resistive element of the RC filter.

Output parameters:

- `cutoff_freq_hz` (number): Cutoff frequency (-3 dB point) in hertz.
- `cutoff_freq_khz` (number): Cutoff frequency in kilohertz for convenience.
- `impedance_at_cutoff_ohm` (number): Total impedance magnitude at the cutoff frequency in ohms. Equals R * sqrt(2) for a first-order RC filter.
- `phase_at_cutoff_deg` (number): Phase shift at the cutoff frequency in degrees. -45 for lowpass, +45 for highpass.
- `time_constant_ms` (number): RC time constant in milliseconds.
- `time_constant_s` (number): RC time constant (tau) in seconds.

### `lc_resonance` (~204 tokens)

lc resonance

Calculates the resonant frequency of an LC circuit, along with optional Q factor and bandwidth when series resistance is provided. The resonant frequency f0 = 1/(2*pi*sqrt(L*C)) is where inductive and capacitive reactances cancel. Used for designing tank circuits, oscillators, bandpass filters, and antenna matching networks. If resistance R is given, computes quality factor Q = (1/R)*sqrt(L/C) and 3 dB bandwidth = f0/Q. Chain into impedance_match to design matching networks at the resonant frequency.

Input parameters:

- `capacitance_f` (number, required): Capacitance in farads (F). The capacitive element of the LC circuit.
- `inductance_h` (number, required): Inductance in henries (H). The inductive element of the LC circuit.
- `resistance_ohm` (number): Optional series resistance in ohms for Q factor and bandwidth calculation. Omit for ideal LC analysis.

Output parameters:

- `angular_freq_rad` (number): Angular resonant frequency in radians per second (omega_0 = 2*pi*f0).
- `bandwidth_hz` (number|null): 3 dB bandwidth in hertz (f0/Q). Null if no resistance provided.
- `impedance_at_resonance_ohm` (number|null): Impedance at resonance in ohms. Equals the series resistance R if provided; null if ideal (no R).
- `q_factor` (number|null): Quality factor Q = (1/R)*sqrt(L/C). Null if no resistance provided.
- `resonant_freq_hz` (number): Resonant frequency in hertz.
- `resonant_freq_mhz` (number): Resonant frequency in megahertz for convenience.

### `impedance_match` (~192 tokens)

impedance match

Designs an L-network impedance matching circuit between two real impedances at a given frequency. Computes the required shunt and series reactive components (inductor and capacitor) to transform the source impedance to the load impedance. The network Q factor is sqrt(Rh/Rl - 1) where Rh is the higher impedance. Topology is automatically selected: the shunt element is placed across the higher impedance side. Essential for antenna matching, amplifier input/output matching, and maximizing power transfer. Chain from lc_resonance to match at a tank circuit's resonant frequency.

Input parameters:

- `freq_mhz` (number, required): Design frequency in megahertz for component value calculation.
- `load_ohm` (number, required): Load impedance in ohms (real, resistive). Must differ from source impedance.
- `source_ohm` (number, required): Source impedance in ohms (real, resistive). Must differ from load impedance.

Output parameters:

- `q_factor` (number): Network Q factor = sqrt(Rh/Rl - 1), where Rh is the higher impedance.
- `series_component` (object): The series component of the L-network.
- `shunt_component` (object): The shunt (parallel) component of the L-network.
- `topology` (string): Description of the L-network arrangement (which side gets shunt vs series element).

### `trace_width` (~271 tokens)

trace width

Calculates the minimum PCB trace width for a given current using the IPC-2221 standard formula. The IPC-2221 empirical equation relates current capacity to cross-sectional area and temperature rise: I = k * dT^0.44 * A^0.725, where k=0.048 for external layers and k=0.024 for internal layers. Supports configurable copper weight (oz/ft^2) and temperature rise. Also computes approximate DC resistance per centimeter. Essential for power delivery, high-current motor drivers, and ensuring PCB reliability. Chain from voltage_divider or impedance_match to verify trace sizing for computed currents.

Input parameters:

- `copper_oz` (number): Copper weight in ounces per square foot. 1 oz/ft^2 = 1.37 mil (34.8 um) thickness. Common values: 0.5, 1, 2.
- `current_amps` (number, required): Required current capacity in amperes (A).
- `layer` (string): PCB layer type. External layers dissipate heat better (k=0.048); internal layers use k=0.024.
- `temp_rise_c` (number): Allowable temperature rise above ambient in degrees Celsius. IPC-2221 standard uses 10, 20, or 30 C.

Output parameters:

- `area_mil2` (number): Required cross-sectional area in square mils.
- `resistance_per_cm_mohm` (number): Approximate DC resistance per centimeter of trace in milliohms, using copper resistivity.
- `width_mil` (number): Required trace width in mils (thousandths of an inch).
- `width_mm` (number): Required trace width in millimeters.

### `ohms_law` (~209 tokens)

ohms law

Solves Ohm's Law and the power equation given any two of four electrical quantities: voltage (V), current (I), resistance (R), and power (P). Uses V=IR, P=VI, P=I^2R, and P=V^2/R to derive the missing two values. Fundamental for every circuit design task: sizing resistors, estimating current draw, checking power dissipation, and verifying component ratings. Chain into led_resistor for LED circuits or voltage_divider for bias networks.

Input parameters:

- `current_a` (number): Current in amps (A). Provide exactly 2 of the 4 parameters.
- `power_w` (number): Power in watts (W). Provide exactly 2 of the 4 parameters.
- `resistance_ohm` (number): Resistance in ohms. Provide exactly 2 of the 4 parameters.
- `voltage_v` (number): Voltage in volts (V). Provide exactly 2 of the 4 parameters.

Output parameters:

- `current_a` (number): Current in amps (A).
- `power_w` (number): Power in watts (W).
- `resistance_ohm` (number): Resistance in ohms.
- `voltage_v` (number): Voltage in volts (V).

### `resistor_color_code` (~168 tokens)

resistor color code

Decodes 4-band or 5-band resistor color codes into resistance value, tolerance, and min/max range. Accepts an ordered array of color names (left-to-right as printed on the resistor body). Supports standard EIA color codes including gold and silver multiplier/tolerance bands. Outputs the nominal resistance in ohms, a human-readable formatted value (e.g. '4.7kΩ'), tolerance percentage, and the min/max resistance range. Chain into ohms_law or led_resistor for circuit analysis.

Input parameters:

- `bands` (array, required): Array of 4 or 5 color band names from left to right. 4-band: [digit1, digit2, multiplier, tolerance]. 5-band: [digit1, digit2, digit3, multiplier, tolerance].

Output parameters:

- `band_count` (number): Number of bands (4 or 5).
- `max_ohm` (number): Maximum resistance within tolerance.
- `min_ohm` (number): Minimum resistance within tolerance.
- `resistance_formatted` (string): Human-readable resistance string, e.g. '4.7kΩ'.
- `resistance_ohm` (number): Resistance value in ohms.
- `tolerance_pct` (number): Tolerance in percent.

### `led_resistor` (~205 tokens)

led resistor

Calculates the current-limiting resistor for driving one or more LEDs in series from a DC supply. Computes the exact resistance from R = (Vsupply - n*Vf) / I, then selects the nearest E24 standard resistor value. Reports the actual current with the standard resistor, power dissipation, and voltage across the resistor. Supports series LED strings by specifying led_count. Validates that supply voltage exceeds total forward voltage. Chain from ohms_law for power budgeting or into trace_width for PCB layout.

Input parameters:

- `led_count` (integer): Number of LEDs in series. Defaults to 1.
- `led_current_ma` (number): Desired LED current in milliamps (mA). Defaults to 20mA.
- `led_forward_v` (number): LED forward voltage in volts (V). Defaults to 2.0V (typical red LED).
- `supply_voltage_v` (number, required): Supply voltage in volts (V). Must be positive.

Output parameters:

- `actual_current_ma` (number): Actual LED current in milliamps (mA) when using the nearest E24 resistor.
- `nearest_e24_ohm` (number): Nearest standard E24 series resistor value in ohms.
- `power_dissipation_mw` (number): Power dissipated by the resistor in milliwatts (mW), using the E24 value.
- `resistance_ohm` (number): Exact calculated resistance in ohms.
- `voltage_across_resistor_v` (number): Voltage drop across the current-limiting resistor in volts.

### `timer_555` (~332 tokens)

timer 555

Calculates timing parameters for the ubiquitous NE555 / LM555 timer IC in astable (free-running oscillator) and monostable (one-shot pulse) modes. In astable mode, computes frequency, period, duty cycle, and HIGH/LOW durations from R1, R2, and C using f = 1.44 / ((R1 + 2·R2) · C). In monostable mode, computes pulse width from R and C using t = 1.1 · R · C. Standard 555 astable duty cycle is always >50%; for 50% duty cycle use a diode across R2. Useful for generating clock signals, PWM, delays, and debounce circuits. Chain from ohms_law for power calculations or resistor_color_code for component selection.

Input parameters:

- `c_farad` (number, required): Timing capacitor in farads. Typical values range from 1 pF to 1000 µF. Use scientific notation, e.g. 1e-6 for 1 µF.
- `mode` (string, required): Operating mode. 'astable' produces a continuous square wave. 'monostable' produces a single timed pulse.
- `r1_ohm` (number, required): Resistance R1 in ohms. In astable mode this is the charge-path resistor between Vcc and the discharge pin. In monostable mode this is the timing resistor.
- `r2_ohm` (number): Resistance R2 in ohms (astable mode only). Charge/discharge resistor between the discharge and threshold pins. Required for astable mode.

Output parameters:

- `c_display` (string): Human-readable capacitor value string (e.g. '100 nF', '4.7 µF').
- `c_farad` (number): Capacitor value used in farads.
- `duty_cycle_pct` (number|null): Duty cycle as a percentage (astable only, null for monostable). Always > 50% for standard 555.
- `frequency_hz` (number|null): Output frequency in Hz (astable only, null for monostable).
- `mode` (string): Operating mode used for calculation.
- `period_s` (number|null): Total period in seconds (astable only, null for monostable).
- `r1_ohm` (number): R1 value used in ohms.
- `r2_ohm` (number|null): R2 value used in ohms (null for monostable).
- `time_high_s` (number): Output HIGH duration in seconds. In astable this is the charge time; in monostable this is the pulse width.
- `time_low_s` (number|null): Output LOW duration in seconds (astable only, null for monostable).

### `op_amp_gain` (~338 tokens)

op amp gain

Calculate voltage gain and output for operational amplifier circuits in inverting, non-inverting, and differential configurations. For inverting: Av = -Rf/Ri with input impedance equal to Ri. For non-inverting: Av = 1 + Rf/Rg with very high input impedance. For differential: Av = Rf/Ri applied to (V1 - V2). Reports gain in linear and dB, output voltage when input is provided, input impedance, and phase inversion status. Ideal op-amp assumptions (infinite open-loop gain, zero input bias current). Chain from ohms_law for power budgeting or resistor_color_code for component selection.

Input parameters:

- `rf_ohm` (number, required): Feedback resistor Rf in ohms. Sets gain magnitude in all topologies.
- `ri_ohm` (number, required): Input/gain resistor in ohms. For inverting: input resistor Ri. For non-inverting: ground resistor Rg. For differential: input resistor on both channels.
- `topology` (string, required): Op-amp circuit topology. 'inverting' uses Rf/Ri feedback with input to inverting terminal. 'non_inverting' applies input to non-inverting terminal with Rf/Rg feedback. 'differential' amplifies the vo…
- `vin2_v` (number): Second input voltage in volts (differential topology only). This is V2 (inverting input).
- `vin_v` (number): Input voltage in volts (optional). When provided, computes actual output voltage. For differential topology, this is V1 (non-inverting input).

Output parameters:

- `gain` (number): Voltage gain (Av). Negative for inverting topology.
- `gain_abs` (number): Absolute value of voltage gain.
- `gain_db` (number): Gain in decibels: 20 * log10(|Av|).
- `input_impedance_ohm` (number): Input impedance in ohms. Inverting: Ri. Non-inverting: very high (returned as 1e12). Differential: Ri.
- `phase_inversion` (boolean): True if the output is phase-inverted relative to the input.
- `rf_ohm` (number): Feedback resistor value used in ohms.
- `ri_ohm` (number): Input/gain resistor value used in ohms.
- `topology` (string): Op-amp topology used.
- `vout_v` (number|null): Output voltage in volts (null if no input voltage provided).

### `capacitor_charge` (~285 tokens)

capacitor charge

Calculates RC capacitor charge timing, energy storage, and transient voltages. Given resistance, capacitance, supply voltage, and optional initial voltage, computes the RC time constant (τ = R×C), time to reach standard charge thresholds (63%, 86%, 95%, 99%), voltage at key time points, energy stored (E = ½CV²), and peak charging current. Optionally calculates time to reach a specific target voltage using t = -τ × ln((Vsupply - Vtarget) / (Vsupply - Vinitial)). Essential for timing circuits, power-on reset delays, debounce networks, and soft-start designs. Chain from rc_filter for frequency-domain analysis or timer_555 for oscillator timing.

Input parameters:

- `capacitance_f` (number, required): Capacitance in farads (C). Use scientific notation, e.g. 1e-6 for 1 µF.
- `resistance_ohm` (number, required): Series resistance in ohms (R). Controls charge/discharge rate.
- `v_initial` (number): Initial capacitor voltage in volts (default 0 for fully discharged).
- `v_supply` (number, required): Supply voltage in volts. The voltage the capacitor charges toward.
- `v_target` (number): Target voltage to reach in volts (optional). When provided, calculates time to reach this voltage. Must be between v_initial and v_supply.

Output parameters:

- `energy_joules` (number): Energy stored at full charge: E = ½CV² in joules.
- `energy_mj` (number): Energy stored at full charge in millijoules.
- `peak_current_ma` (number): Peak charging current at t=0 in milliamps: Ipeak = (Vsupply − Vinitial) / R.
- `tau_ms` (number): RC time constant in milliseconds.
- `tau_s` (number): RC time constant (τ = R×C) in seconds.
- `time_to_63pct_ms` (number): Time to reach 63.2% of (Vsupply − Vinitial) in milliseconds (1τ).
- `time_to_86pct_ms` (number): Time to reach 86.5% of (Vsupply − Vinitial) in milliseconds (2τ).
- `time_to_95pct_ms` (number): Time to reach 95.0% of (Vsupply − Vinitial) in milliseconds (3τ).
- `time_to_99pct_ms` (number): Time to reach 99.3% of (Vsupply − Vinitial) in milliseconds (5τ).
- `time_to_target_ms` (number|null): Time to reach v_target in milliseconds (null if v_target not specified).
- `v_at_1tau` (number): Capacitor voltage after 1τ in volts.
- `v_at_2tau` (number): Capacitor voltage after 2τ in volts.
- `v_at_5tau` (number): Capacitor voltage after 5τ in volts.

### `pcb_via_current` (~407 tokens)

pcb via current

Calculate PCB via current-carrying capacity using the IPC-2221 standard. A plated via is a hollow copper cylinder whose cross-sectional area is the annular ring of plating: A = pi * (D - t) * t, where D is the drill diameter and t is plating thickness. The IPC-2221 empirical formula I = k * dT^0.44 * A^0.725 (k=0.048) then gives the maximum current for a given temperature rise. Also computes via barrel resistance from copper resistivity (1.724e-6 ohm-cm) and barrel length (board thickness). When a target current is specified, returns how many parallel vias are needed. Essential for power planes, high-current paths, and thermal via arrays. Chain with trace_width to verify both trace and via can handle the same current.

Input parameters:

- `board_thickness_mm` (number): Total PCB board thickness in millimeters. Standard 2-layer is 1.6 mm. Common values: 0.8, 1.0, 1.6, 2.0, 2.4.
- `drill_diameter_mm` (number): Via drill hole diameter in millimeters. Common values: 0.2 (microvia), 0.3 (standard), 0.4, 0.6, 0.8, 1.0.
- `plating_thickness_um` (number): Copper plating thickness on the via barrel wall in micrometers. Standard is 25 um (IPC Class 2). Heavy plating is 50 um (IPC Class 3).
- `target_current_a` (number): Optional target current in amperes. When provided, calculates how many parallel vias are needed to carry this current safely.
- `temp_rise_c` (number): Allowable temperature rise above ambient in degrees Celsius. IPC-2221 standard uses 10, 20, or 30 C.

Output parameters:

- `cross_section_mil2` (number): Copper cross-sectional area of the via barrel annulus in square mils.
- `cross_section_mm2` (number): Copper cross-sectional area of the via barrel annulus in square millimeters.
- `max_current_a` (number): Maximum current capacity of a single via at the specified temperature rise, in amperes.
- `power_dissipation_mw` (number): Power dissipated in the via at maximum rated current in milliwatts.
- `resistance_mohm` (number): DC resistance of the via barrel in milliohms, calculated from copper resistivity and barrel length.
- `vias_needed` (number|null): Number of parallel vias needed for the target current. Null if no target_current_a was provided.
- `voltage_drop_mv` (number): Voltage drop across the via at maximum rated current in millivolts.

### `power_supply_decoupling` (~363 tokens)

power supply decoupling

Select bypass and bulk decoupling capacitors for IC power supply pins. Computes the target PDN (Power Distribution Network) impedance from supply current, voltage, and allowable ripple using Z_target = V_ripple / I_total. Recommends a ceramic bypass capacitor (high-frequency decoupling, placed closest to IC pins) and a bulk capacitor (low-frequency decoupling, near the regulator). Calculates the ceramic cap's self-resonant frequency assuming typical lead inductance, and checks whether ESR-induced ripple stays within limits. Essential for digital, analog, and mixed-signal PCB design. Chain with lc_resonance to verify the decoupling capacitor's resonant behavior, or with trace_width to size the power trace.

Input parameters:

- `esr_mohm` (number): Equivalent series resistance (ESR) of the ceramic bypass capacitor in milliohms. Typical MLCC: 5-20 mohm.
- `max_ripple_mv` (number): Maximum allowable supply ripple in millivolts (mV). Typical: 50 mV for digital, 10 mV for analog/RF.
- `num_ics` (integer): Number of identical ICs sharing this supply rail. Scales the total current demand.
- `supply_current_ma` (number, required): IC supply current draw in milliamps (mA). Use the maximum or typical from the datasheet.
- `supply_voltage_v` (number, required): Supply voltage in volts (V). Common values: 1.8, 2.5, 3.3, 5.0, 12.0.
- `switching_freq_mhz` (number): Primary switching or clock frequency of the IC in MHz. Determines the target impedance frequency range.

Output parameters:

- `bulk_cap_uf` (number): Recommended bulk capacitor value in microfarads (uF). Placed near the voltage regulator for low-frequency decoupling.
- `bulk_cap_value` (string): Nearest standard bulk capacitor value with unit (e.g. '10 uF', '47 uF').
- `bypass_adequate` (boolean): Whether the ESR-induced ripple is within the specified max_ripple_mv limit.
- `ceramic_cap_uf` (number): Recommended ceramic bypass capacitor value in microfarads (uF). Placed closest to IC pins.
- `ceramic_cap_value` (string): Nearest standard E12 capacitor value with unit (e.g. '100 nF', '1 uF').
- `ripple_at_esr_mv` (number): Estimated ripple voltage due to ESR at the switching frequency: V = I_peak * ESR.
- `self_resonant_freq_mhz` (number): Self-resonant frequency of the recommended ceramic capacitor assuming 0.5 nH lead inductance. Above this frequency, the capacitor becomes inductive.
- `target_impedance_ohm` (number): Target supply impedance at the switching frequency: Z_target = V_ripple / I_total. The decoupling network must keep PDN impedance below this value.
- `total_current_ma` (number): Total supply current for all ICs on this rail.

### `log_calc` (~150 tokens)

log calc

Compute logarithms of a positive number in any base. Returns the custom-base logarithm, natural logarithm (ln), common logarithm (log10), and binary logarithm (log2). Useful for signal processing (decibel calculations), information theory (entropy in bits), pH chemistry, and general scientific computation. Uses the change-of-base formula log_b(x) = ln(x) / ln(b). Feeds into exponent_calc for inverse operations and scientific_notation for order-of-magnitude analysis.

Input parameters:

- `base` (number): The logarithm base (default 10). Must be positive and not equal to 1
- `value` (number, required): The positive number to compute the logarithm of

Output parameters:

- `log10` (number): Common logarithm (base 10) of the value
- `log2` (number): Binary logarithm (base 2) of the value
- `natural_log` (number): Natural logarithm (ln) of the value
- `result` (number): Logarithm of the value in the specified base: log_base(value)

### `sig_figs` (~148 tokens)

sig figs

Count significant figures in a number and optionally round to N significant figures. Accepts the number as a string to preserve trailing zeros (e.g. '1.200' has 4 sig figs). Applies standard sig fig rules: leading zeros do not count, trailing zeros after a decimal point count, trailing zeros before a decimal point are treated as significant. Also returns the number in scientific notation. Essential for laboratory measurements, error analysis, and maintaining proper precision in chained calculations.

Input parameters:

- `number_str` (string, required): The number as a string to preserve trailing zeros (e.g. '1.200')
- `round_to_n` (integer): Optionally round the number to this many significant figures

Output parameters:

- `rounded_to_n` (string|null): The number rounded to N significant figures (null if N not provided)
- `scientific_notation` (string): The number expressed in scientific notation
- `sig_figs_count` (number): Number of significant figures in the input

### `scientific_notation` (~116 tokens)

scientific notation

Convert any number to scientific notation and engineering notation. Returns the coefficient, exponent, a formatted string with Unicode superscripts (e.g. '3.14 × 10²'), and engineering notation where the exponent is a multiple of 3. Useful for expressing very large or very small values compactly, common in physics, electronics (picofarads, gigahertz), and astronomy. Accepts output from sig_figs and log_calc for precision-aware formatting.

Input parameters:

- `value` (number, required): The number to convert to scientific notation

Output parameters:

- `coefficient` (number): The coefficient (mantissa) between 1 and 10
- `engineering_notation` (string): Engineering notation with exponent divisible by 3
- `exponent` (number): The power-of-10 exponent
- `notation_string` (string): Formatted scientific notation with Unicode superscripts (e.g. '3.14 × 10²')

### `percentage_calc` (~126 tokens)

percentage calc

Calculate what percentage one number is of another. Given a value and a total, returns the percentage, decimal form, and simplified fraction. For example, 3 out of 4 yields 75%, 0.75, and '3/4'. Commonly used for test scores, survey results, financial ratios, completion rates, and unit conversions. Chain with percentage_increase to compare successive measurements or use with test_grade for academic scoring.

Input parameters:

- `total` (number, required): The whole or denominator value (must not be zero)
- `value` (number, required): The part or numerator value

Output parameters:

- `decimal` (number): The decimal form (e.g. 0.75)
- `fraction_simplified` (string): Simplified fraction as a string (e.g. '3/4')
- `percentage` (number): The percentage value (e.g. 75 for 75%)

### `percentage_increase` (~118 tokens)

percentage increase

Calculate the percentage change between an old value and a new value. Determines whether the change is an increase or decrease, the absolute change, and the percentage change. Essential for financial analysis (stock price changes, revenue growth), scientific measurements (before/ after experiments), performance benchmarks, and population statistics. A positive percentage indicates growth; negative indicates decline. Division by zero (old_value = 0) is handled gracefully.

Input parameters:

- `new_value` (number, required): The new or ending value
- `old_value` (number, required): The original or starting value

Output parameters:

- `absolute_change` (number): Absolute value of the change
- `change` (number): The signed difference (new_value - old_value)
- `is_increase` (boolean): True if new_value > old_value, false otherwise
- `percentage_change` (number): Percentage change from old to new value

### `exponent_calc` (~122 tokens)

exponent calc

Compute the result of raising a base to an exponent (base^exponent). Handles positive and negative exponents, fractional exponents, and zero. Returns the numeric result and a scientific notation string for very large or very small results. Useful for compound interest calculations, exponential growth/decay models, physics power laws, and combinatorics. The inverse of log_calc; chain with scientific_notation for formatted display of extreme values.

Input parameters:

- `base` (number, required): The base number
- `exponent` (number, required): The exponent (power) to raise the base to

Output parameters:

- `result` (number): The computed value of base^exponent
- `scientific_notation` (string): Result in scientific notation for very large/small values

### `square_root` (~124 tokens)

square root

Compute the square root of a non-negative number. Returns the decimal result, whether the input is a perfect square, and a simplified radical form (e.g. '√12' simplifies to '2√3'). For integer inputs, factors are extracted from under the radical sign. Useful for geometry (diagonal/hypotenuse calculations), statistics (standard deviation from variance), signal processing (RMS values), and general algebra. Chain with pythagorean_theorem for triangle side calculations.

Input parameters:

- `value` (number, required): The non-negative number to compute the square root of

Output parameters:

- `is_perfect_square` (boolean): True if the input is a perfect square integer
- `result` (number): The square root of the input value
- `simplified_radical` (string): Simplified radical form (e.g. '2√3' for √12)

### `circumference` (~128 tokens)

Calculate the circumference and area of a circle given either a radius or diameter. Provide one or both; if both are given, radius takes precedence. Returns circumference (C = 2πr), area (A = πr²), and both radius and diameter for completeness. Common in mechanical engineering (pulley systems, pipe sizing), electronics (antenna loop calculations, coil winding), civil engineering (manhole covers, circular foundations), and everyday measurement tasks.

Input parameters:

- `diameter` (number): The diameter of the circle
- `radius` (number): The radius of the circle (takes precedence over diameter)

Output parameters:

- `area` (number): Area of the circle (A = πr²)
- `circumference` (number): Circumference of the circle (C = 2πr)
- `diameter` (number): Diameter of the circle
- `radius` (number): Radius of the circle

### `slope_calc` (~173 tokens)

slope calc

Calculate the slope, y-intercept, line equation, angle, and distance between two points in a 2D Cartesian plane. Given coordinates (x1, y1) and (x2, y2), computes slope (rise/run), y-intercept, the equation in slope-intercept form (y = mx + b), angle in degrees relative to the x-axis, and Euclidean distance. Handles vertical and horizontal lines as special cases. Useful for surveying, civil engineering grade calculations, linear regression visualization, and physics kinematics problems.

Input parameters:

- `x1` (number, required): X-coordinate of the first point
- `x2` (number, required): X-coordinate of the second point
- `y1` (number, required): Y-coordinate of the first point
- `y2` (number, required): Y-coordinate of the second point

Output parameters:

- `angle_degrees` (number): Angle of the line relative to the positive x-axis in degrees
- `distance` (number): Euclidean distance between the two points
- `equation` (string): Line equation in slope-intercept form or 'x = c' for vertical
- `is_horizontal` (boolean): True if the line is horizontal (slope = 0)
- `is_vertical` (boolean): True if the line is vertical (undefined slope)
- `slope` (number|null): Slope of the line (null for vertical lines)
- `y_intercept` (number|null): Y-intercept of the line (null for vertical lines)

### `pythagorean_theorem` (~174 tokens)

pythagorean theorem

Solve for any side of a right triangle using the Pythagorean theorem (a² + b² = c²). Provide any two of the three sides (a, b, c) and the missing side is computed. Also returns the triangle area (0.5 * a * b), perimeter, and confirms it is a right triangle. Side c is always the hypotenuse. Fundamental to surveying, construction (squaring corners), navigation (distance calculations), physics (vector decomposition), and 3D graphics. Chain with slope_calc for coordinate geometry or square_root for simplified radical answers.

Input parameters:

- `a` (number): Length of side a (leg)
- `b` (number): Length of side b (leg)
- `c` (number): Length of side c (hypotenuse)

Output parameters:

- `a` (number): Length of side a
- `area` (number): Area of the right triangle (0.5 * a * b)
- `b` (number): Length of side b
- `c` (number): Length of side c (hypotenuse)
- `is_right_triangle` (boolean): Always true when computed from two sides
- `perimeter` (number): Perimeter of the triangle (a + b + c)

### `p_value` (~222 tokens)

p value

Calculate the p-value for a z-score or t-statistic. Supports one-tailed (left or right) and two-tailed hypothesis tests using either the standard normal distribution or the Student's t-distribution when degrees of freedom are specified. Returns significance flags at the 0.01, 0.05, and 0.10 alpha levels. Essential for interpreting results from t-tests, z-tests, ANOVA post-hoc comparisons, and regression coefficients. Uses the Abramowitz & Stegun normal CDF approximation and regularized incomplete beta function for the t-distribution.

Input parameters:

- `degrees_of_freedom` (integer): Degrees of freedom for the t-distribution. Omit to use the standard normal (z) distribution.
- `test_statistic` (number, required): The z-score or t-statistic from your hypothesis test. Positive values indicate the observed value is above the null hypothesis mean.
- `test_type` (string): Tail type: one_tail_left (p from left), one_tail_right (p from right), or two_tail (both tails combined).

Output parameters:

- `p_value` (number): The computed p-value representing the probability of observing a result at least as extreme as the test statistic under the null hypothesis.
- `significant_at_01` (boolean): Whether the result is statistically significant at the 0.01 (1%) level.
- `significant_at_05` (boolean): Whether the result is statistically significant at the 0.05 (5%) level.
- `significant_at_10` (boolean): Whether the result is statistically significant at the 0.10 (10%) level.
- `test_type` (string): The tail type used for this calculation.

### `confidence_interval` (~248 tokens)

confidence interval

Calculate the confidence interval for a sample mean. Given a sample mean, sample size, standard deviation, and confidence level, computes the margin of error, lower and upper bounds, critical z-score, and standard error. Supports finite population correction (FPC) when a population size is provided, which narrows the interval for samples that are a large fraction of the population. Uses the Abramowitz & Stegun rational approximation for the inverse normal CDF to derive the critical z-value. Common in survey analysis, A/B testing, and quality control.

Input parameters:

- `confidence_level` (number): Confidence level as a decimal between 0 and 1 (e.g. 0.95 for 95%). Default is 0.95.
- `population_size` (integer): Total population size for finite population correction (FPC). Omit for infinite population assumption.
- `sample_mean` (number, required): The observed sample mean (x-bar) around which the confidence interval is centered.
- `sample_size` (integer, required): The number of observations in the sample (n). Must be a positive integer.
- `standard_deviation` (number, required): The standard deviation of the sample or population. Must be a positive number.

Output parameters:

- `confidence_level` (number): The confidence level used (echoed back).
- `lower_bound` (number): Lower bound of the confidence interval.
- `margin_of_error` (number): Half-width of the confidence interval (z_score * standard_error).
- `standard_error` (number): Standard error of the mean, optionally adjusted with finite population correction.
- `upper_bound` (number): Upper bound of the confidence interval.
- `z_score` (number): Critical z-value used for the given confidence level.

### `sales_tax` (~172 tokens)

sales tax

Calculates total cost including sales tax for a purchase. Given a unit price, tax rate percentage, and optional quantity, computes the subtotal (price times quantity), the tax amount rounded to two decimal places, and the final total. Useful for estimating purchase costs across US states and municipalities with different tax rates, comparing pre-tax and post-tax prices, and budgeting. Chain into salary_to_hourly to see how many work-hours a purchase represents.

Input parameters:

- `price` (number, required): Unit price of the item in dollars (or any currency). Must be positive.
- `quantity` (integer): Number of items to purchase. Defaults to 1.
- `tax_rate_pct` (number): Sales tax rate as a percentage (e.g. 8.875 for 8.875%). Defaults to 0 — enter your local rate.

Output parameters:

- `effective_rate_pct` (number): The tax rate applied, echoed back for confirmation.
- `subtotal` (number): Price times quantity before tax.
- `tax_amount` (number): Total tax amount, rounded to two decimal places.
- `total` (number): Subtotal plus tax amount.

### `salary_to_hourly` (~197 tokens)

salary to hourly

Converts compensation between annual salary, monthly pay, weekly pay, and hourly wage. Accepts any of the four pay periods as input and derives all others. Uses configurable hours per week (default 40) and weeks per year (default 52). Daily rate assumes an 8-hour workday; monthly is annual divided by 12. Useful for comparing job offers quoted in different pay periods, freelance rate-setting, and budgeting. Chain from sales_tax to see how many hours a purchase costs.

Input parameters:

- `amount` (number, required): The salary or wage amount to convert.
- `from_type` (string): The pay period of the input amount. Defaults to 'annual'.
- `hours_per_week` (number): Hours worked per week. Defaults to 40 for a standard full-time schedule.
- `weeks_per_year` (number): Working weeks per year. Defaults to 52. Use 50 to account for 2 weeks unpaid vacation.

Output parameters:

- `annual` (number): Annual salary.
- `biweekly` (number): Biweekly (every two weeks) earnings.
- `daily` (number): Daily earnings assuming an 8-hour workday.
- `hourly` (number): Hourly wage.
- `monthly` (number): Monthly earnings (annual / 12).
- `weekly` (number): Weekly earnings.

### `loan_amortization` (~221 tokens)

loan amortization

Computes a full loan amortization schedule given principal, annual interest rate, and term in months. Returns the fixed monthly payment, total interest, total payments, and a month-by-month breakdown of principal vs interest. Supports optional extra monthly payments — shows months saved and interest saved. Works for mortgages (30yr/15yr), auto loans, personal loans, and student loans. All currency-agnostic. Use with /run?page=1&page_size=12 to paginate the schedule array for context-friendly agent consumption.

Input parameters:

- `annual_rate_pct` (number, required): Annual interest rate as a percentage (e.g., 6.5 for 6.5%).
- `extra_payment` (number): Optional fixed extra monthly payment toward principal. Defaults to 0.
- `principal` (number, required): Loan principal amount in dollars (or any currency unit).
- `term_months` (integer, required): Loan term in months. Max 600 (50 years). Common values: 360 (30yr), 180 (15yr), 60 (5yr auto).

Output parameters:

- `interest_saved` (number): Interest saved by extra payments vs. full term. 0 if no extra payments.
- `monthly_payment` (number): Fixed monthly payment (excluding extra payments).
- `payoff_months` (number): Actual number of months to pay off (may be less than term with extra payments).
- `schedule` (array): Month-by-month amortization schedule.
- `total_extra_paid` (number): Total extra payments made.
- `total_interest` (number): Total interest paid over the life of the loan.
- `total_payments` (number): Sum of all payments over the life of the loan.

### `compound_interest` (~235 tokens)

compound interest

Calculates compound interest growth over time using the formula A = P(1 + r/n)^(nt). Given a principal, annual rate, duration in years, and compounding frequency, returns the future value, total interest earned, effective annual rate (APY), and a year-by-year growth schedule. Supports optional recurring monthly contributions for savings projections. Works for savings accounts, CDs, investment returns, and retirement planning. Currency-agnostic.

Input parameters:

- `annual_rate_pct` (number, required): Annual interest rate as a percentage (e.g., 5.5 for 5.5%).
- `compounds_per_year` (integer): How often interest compounds per year. Allowed: 1 (annually), 2 (semi-annually), 4 (quarterly), 12 (monthly), 52 (weekly), 365 (daily). Defaults to 12.
- `monthly_contribution` (number): Optional recurring monthly contribution added at each month. Defaults to 0.
- `principal` (number, required): Initial investment or deposit amount (any currency unit).
- `years` (number, required): Investment duration in years. Max 100.

Output parameters:

- `effective_annual_rate_pct` (number): Effective annual rate accounting for compounding frequency (APY).
- `future_value` (number): Final balance after all compounding and contributions.
- `schedule` (array): Year-by-year growth schedule.
- `total_contributions` (number): Total of all contributions (principal + recurring).
- `total_interest` (number): Total interest earned over the full period.

### `test_grade` (~229 tokens)

test grade

Calculates a test or exam grade from the number of correct answers and total questions. Returns the percentage score, letter grade, points missed, and GPA points. Supports US grading (A/B/C/D/F with 4.0 GPA scale), UK grading (First/2:1/2:2/Third/Fail), and percentage-only mode. US thresholds: A>=90, B>=80, C>=70, D>=60, F<60. UK thresholds: First>=70, 2:1>=60, 2:2>=50, Third>=40, Fail<40. Useful for students checking scores and teachers computing class statistics.

Input parameters:

- `correct` (integer, required): Number of questions answered correctly. Must be a non-negative integer.
- `grading_scale` (string): Grading scale to use. 'us' for A-F letter grades, 'uk' for First/2:1/2:2/Third/Fail, 'percentage_only' for just the percentage.
- `total` (integer, required): Total number of questions on the test. Must be a positive integer.

Output parameters:

- `gpa_points` (number|null): GPA points on a 4.0 scale (US only). A=4.0, B=3.0, C=2.0, D=1.0, F=0. Null for UK and percentage_only.
- `letter_grade` (string|null): Letter grade based on the selected grading scale. Null if percentage_only.
- `percentage` (number): Score as a percentage (0-100).
- `points_missed` (number): Number of questions answered incorrectly (total - correct).

### `square_footage` (~133 tokens)

square footage

Calculates area and perimeter for common shapes — rectangle, circle, or triangle — in both imperial and metric units. Returns area in square feet, square meters, and acres, plus perimeter in feet and meters. For rectangles: area = length * width, perimeter = 2*(length + width). For circles: area = pi * r^2, perimeter = 2 * pi * r. For triangles: area = 0.5 * base * height, perimeter approximated as base + height + sqrt(base^2 + height^2). Useful for real estate, flooring, landscaping, and construction estimates.

Output parameters:

- `area_acres` (number): Area in acres (sqft / 43560).
- `area_sqft` (number): Area in square feet.
- `area_sqm` (number): Area in square meters (sqft * 0.092903).
- `perimeter_ft` (number): Perimeter in feet.
- `perimeter_m` (number): Perimeter in meters.

### `unit_convert` (~244 tokens)

unit convert

Convert between units across 10 categories: length (m, km, mi, ft, in, yd, nmi), mass (kg, lb, oz, g, ton), volume (l, gal, ml, cup, fl_oz), area (m2, ft2, acre, hectare), speed (mps, kph, mph, knot), pressure (pa, psi, bar, atm, mmhg), energy (j, kwh, btu, cal, wh), data (b, kb, mb, gb, tb), time (s, ms, min, hr, day, year), and temperature (c, f, k). Accepts any value with source and target unit abbreviations. Returns the converted result with the formula used.

Input parameters:

- `from` (string, required): Source unit abbreviation (e.g., 'km', 'lb', 'f', 'psi', 'kwh'). Case-insensitive.
- `to` (string, required): Target unit abbreviation (e.g., 'mi', 'kg', 'c', 'bar', 'btu'). Case-insensitive.
- `value` (number, required): The numeric value to convert.

Output parameters:

- `category` (string): Unit category (length, mass, volume, area, speed, pressure, energy, data, time, temperature).
- `formula` (string): Human-readable conversion formula applied.
- `from_unit` (string): Normalized source unit abbreviation.
- `result` (number): The converted value.
- `to_unit` (string): Normalized target unit abbreviation.

### `hex_converter` (~202 tokens)

hex converter

Convert numbers between hexadecimal, binary, decimal, and octal bases. Accepts any base as input (prefix 0x for hex, 0b for binary, 0o for octal, or plain decimal) and returns all four representations simultaneously. Also reports bit width, byte count, ASCII character (if printable), and signed interpretations (8-bit, 16-bit, 32-bit two's complement). Essential for embedded programming, register debugging, network protocol analysis, and color code conversion. Example: 0xFF → decimal 255, binary 0b11111111, octal 0o377, 8 bits, 1 byte.

Input parameters:

- `value` (string, required): The number to convert. Prefix with 0x for hex (0xFF), 0b for binary (0b1010), 0o for octal (0o17). Plain numbers are treated as decimal. Supports negative values with leading minus.

Output parameters:

- `ascii` (string|null): ASCII character if the value is a printable character (32-126), null otherwise.
- `binary` (string): Binary string with 0b prefix (e.g. '0b11111111').
- `bits` (number): Minimum number of bits needed to represent this value (unsigned).
- `bytes` (number): Minimum number of bytes needed (ceil(bits/8)).
- `decimal` (number): Decimal (base-10) value.
- `hex` (string): Hexadecimal string with 0x prefix (e.g. '0xFF').
- `hex_upper` (string): Hexadecimal with uppercase letters (e.g. '0xFF').
- `octal` (string): Octal string with 0o prefix (e.g. '0o377').
- `signed_16` (number|null): Signed 16-bit interpretation (-32768 to 32767), null if out of range.
- `signed_32` (number|null): Signed 32-bit interpretation, null if out of range.
- `signed_8` (number|null): Signed 8-bit interpretation (-128 to 127), null if out of range.

### `timestamp_converter` (~167 tokens)

timestamp converter

Convert between Unix timestamps and human-readable date/time formats. Accepts Unix epoch (in seconds or milliseconds), ISO 8601 strings, or 'now' for the current time. Returns both Unix seconds and milliseconds, ISO 8601 UTC string, date and time components, day of the week, relative time description ('2 hours ago'), and past/future indicator. Auto-detects whether a numeric input is seconds or milliseconds based on magnitude. Essential for debugging logs, API timestamps, cron scheduling, and time zone conversions.

Input parameters:

- `value` (string, required): A timestamp to convert. Accepts Unix epoch (seconds or milliseconds), ISO 8601 string (e.g. '2024-01-15T10:30:00Z'), or 'now' for the current time.

Output parameters:

- `day_of_week` (string): Day of the week (e.g. 'Monday').
- `is_past` (boolean): True if the timestamp is in the past.
- `iso_8601` (string): ISO 8601 formatted string in UTC (e.g. '2024-01-15T10:30:00.000Z').
- `iso_date` (string): Date portion only (YYYY-MM-DD).
- `iso_time` (string): Time portion only (HH:MM:SS).
- `relative` (string): Human-readable relative time (e.g. '2 hours ago', 'in 3 days').
- `unix_milliseconds` (number): Unix timestamp in milliseconds since epoch.
- `unix_seconds` (number): Unix timestamp in seconds since epoch (Jan 1 1970 00:00:00 UTC).

### `bmi_calculator` (~167 tokens)

bmi calculator

Calculate Body Mass Index (BMI) from weight and height using the WHO standard formula. Supports metric (kg/cm) and imperial (lbs/inches) units. Returns the BMI value, WHO classification (Underweight, Normal, Overweight, Obese Class I-III), and the healthy weight range for the given height. Formula: BMI = weight_kg / (height_m)^2. Useful for health screening, fitness planning, and clinical intake forms.

Input parameters:

- `height` (number, required): Height. Units determined by the 'unit' parameter.
- `unit` (string): Unit system. 'metric' = kg and cm. 'imperial' = lbs and inches. Defaults to 'metric'.
- `weight` (number, required): Body weight. Units determined by the 'unit' parameter.

Output parameters:

- `bmi` (number): Body Mass Index value rounded to 1 decimal.
- `category` (string): WHO BMI classification: Underweight, Normal weight, Overweight, Obese Class I/II/III.
- `healthy_weight_range_high` (number): High end of healthy weight range (BMI 24.9) in the input unit system.
- `healthy_weight_range_low` (number): Low end of healthy weight range (BMI 18.5) in the input unit system.
- `weight_unit` (string): Unit of the weight values in this response (kg or lbs).

### `tip_calculator` (~180 tokens)

tip calculator

Calculate tip and split a restaurant bill among multiple people. Given a bill amount, tip percentage, and number of diners, returns the tip amount, total with tip, per-person share, and effective tip percentage. Supports rounding up to the nearest whole number for convenience. Defaults to 18% tip for 1 person. Currency-agnostic — works with any monetary unit.

Input parameters:

- `bill_amount` (number, required): Total bill amount before tip (any currency).
- `round_up` (boolean): Round the total up to the nearest whole number. Defaults to false.
- `split` (integer): Number of people splitting the bill. Defaults to 1 (no split).
- `tip_pct` (number): Tip percentage. Common values: 15 (standard), 18 (good), 20 (great), 25 (excellent). Defaults to 18%.

Output parameters:

- `effective_tip_pct` (number): Actual tip percentage after rounding (if round_up is true, may differ from input).
- `per_person_tip` (number): Each person's share of the tip.
- `per_person_total` (number): Each person's total including their share of the bill and tip.
- `tip_amount` (number): Tip amount.
- `total` (number): Bill plus tip.

### `date_difference` (~137 tokens)

date difference

Calculate the difference between two dates in days, weeks, months, years, and business days. Accepts dates in YYYY-MM-DD format. Returns the absolute difference (order doesn't matter) plus a flag indicating whether the end date is in the future relative to start. Business days count only Monday through Friday. Useful for project planning, deadline tracking, contract duration calculations, and age computations.

Input parameters:

- `end_date` (string, required): End date in YYYY-MM-DD format (e.g., '2024-12-31').
- `start_date` (string, required): Start date in YYYY-MM-DD format (e.g., '2024-01-15').

Output parameters:

- `business_days` (number): Number of weekdays (Monday-Friday) between the dates.
- `days` (number): Total number of days between the two dates (absolute value).
- `is_future` (boolean): True if end_date is after start_date.
- `months` (number): Approximate number of months (days / 30.44).
- `weeks` (number): Number of complete weeks.
- `years` (number): Approximate number of years (days / 365.25).

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/engineer-calc-calc/calc#diagnostics

## Score history

- 2026-08-03: 56
- 2026-08-02: 55
- 2026-08-01: 55
- 2026-07-31: 54
- 2026-07-30: 55
- 2026-07-29: 54
- 2026-07-28: 53
- 2026-07-27: 53
- 2026-07-26: 52

## Links

- Remote endpoint: https://calc.engineer/mcp
- Website: https://calc.engineer/
- Changelog RSS feed: https://verifymcp.io/servers/engineer-calc-calc/calc/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/engineer-calc-calc/calc/changelog.json
- HTML version of this page: https://verifymcp.io/servers/engineer-calc-calc/calc