calc.engineer

generator offset

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 Schema

TableJSON Schema

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

Output Schema

TableJSON Schema

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

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries full responsibility. It thoroughly explains the tool's behavior: it calculates yearly/cumulative costs, accounts for multiple factors, and outputs specific metrics. No mention of auth or rate limits, but as a calculator, this is acceptable.

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

Conciseness4/5

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

The description is concise and front-loaded with the main purpose. It covers inputs, outputs, and use cases in a few sentences without redundancy. Slight room for tightening, but well-structured.

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

Completeness5/5

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

Given the presence of an output schema, the description need not detail return values. It fully covers the tool's domain, inputs, and applications, providing sufficient context for an AI agent to decide when to use it.

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

Parameters3/5

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

Schema coverage is 100% with each parameter described. The description adds value by summarizing the parameter groups (fuel cost, consumption, etc.) but does not provide additional insight beyond the schema. Baseline 3 is appropriate.

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

Purpose5/5

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

Description clearly states the tool compares total cost of ownership between a fuel generator and a solar+battery system over a configurable time horizon. It specifies calculated outputs and real-world applications, distinguishing it from sibling tools like solar_roi or battery_autonomy.

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 usage context by listing typical applications (off-grid site planning, remote telecom towers, etc.). However, it does not explicitly state when not to use the tool or compare it to alternative solar tools from the sibling list, which would improve guidance.

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?