calc.engineer

meshtastic power

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 Schema

TableJSON Schema

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

Output Schema

TableJSON Schema

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

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description must fully convey behavioral traits. It discloses that the tool models sleep/RX/TX current draw, uses device profiles, and returns time distribution and daily Wh. As a calculator, it is implicitly read-only and non-destructive, but the description does not explicitly state that it does not modify state or require authorization.

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

Conciseness5/5

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

The description is two sentences totaling about 100 words. The first sentence immediately states the tool's purpose and scope. The second sentence elaborates on role behavior and outputs. No filler or redundant information; every sentence adds value.

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

Completeness4/5

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

Given the tool's 8 parameters, enums, and existence of an output schema, the description adequately covers core functionality and context (e.g., role duty cycles, solar_sizing integration). It does not delve into every parameter detail, but the schema covers those. Minor gap: it doesn't explain output schema fields explicitly, but that is covered by the output schema itself.

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

Parameters4/5

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

All 8 parameters have schema descriptions (100% coverage), so baseline is 3. The tool description adds meaningful context beyond enums: it explains that 'role' controls duty cycling (router vs. client behavior), mentions peripheral toggles (GPS, BLE, display) affect current draw, and notes that 'channel_preset' impacts TX airtime. This enriches the param understanding.

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

Purpose5/5

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

The description explicitly states the tool calculates 'Meshtastic node power consumption and battery runtime' using specific device profiles and duty cycling models. It lists five device types and four roles, clearly distinguishing this from sibling calculators like 'solar_sizing' and 'battery_life' by referencing Meshtastic-specific terminology.

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

Usage Guidelines4/5

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

The description provides clear context on when to use the tool (for power and runtime estimation) and how role selection affects duty cycling (e.g., routers stay in RX mode, clients sleep). It also mentions feeding output to 'solar_sizing'. However, it does not explicitly exclude scenarios where alternative tools would be more appropriate, leaving some ambiguity.

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

All calc.engineer tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation4/5

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

Naming Consistency4/5

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

Tool Count2/5

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

Completeness3/5

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

Resources

Need Help?