mcp-fsolar
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FELICITY_PASS | Yes | Felicity Solar account password | |
| FELICITY_PORT | No | HTTP server port (default 3010) | 3010 |
| FELICITY_USER | Yes | Felicity Solar account email | |
| FELICITY_POLL_MS | No | Background poll interval in ms (default 30000) | 30000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_all_batteriesA | Live status of all Felicity batteries: SOC, power, voltage, temperature, charging state. |
| get_batteryA | Detailed status of one battery by alias (Bat1/Bat2/Bat3) or serial number. |
| get_cell_voltagesA | Individual cell voltages (mV) for one battery. Useful for detecting cell imbalance. |
| get_fleet_summaryB | Compact health summary: total energy, worst cell imbalance, temperatures. |
| get_balance_trendA | Balance trend for batteries over the last ~60 min. Shows whether cell delta (mV spread) is improving, stable, or degrading. |
| get_snapshotsA | Raw battery pack snapshots for the last ~60 min (one per ~10 min). Includes cell voltages, delta, SOC, and balancing state. |
| get_healthB | Per-battery health report: cell delta status, temperature status, SOH, weak/outlier cell indices, average C-rate, and discharge-phase delta. |
| get_autonomyA | Fleet autonomy estimate: hours until the pack hits minSoc, hours to full charge, and optional SOC projection at a given sunrise time. |
| get_alertsA | Active alert list ranked by severity. Checks cell imbalance, temperature, SOH, outlier cells, BMS warnings, under-voltage events, and data staleness. |
| get_energy_historyA | Daily charge/discharge energy totals (kWh) — up to 90 days from persistent store, merged with live intraday data. Shows peak rates and net balance. |
| get_cell_statsA | Per-cell voltage statistics from intraday snapshots: mean, stddev, min/max, deviation from pack average, and trend direction. |
| get_module_healthB | Per-module voltage aggregates (min/max/mean/delta) for one battery using live cell voltages. Flags modules containing persistent outlier cells. |
| get_limit_headroomA | Headroom between current voltage/current and BMS protection limits. Useful for spotting packs running close to cutoff thresholds. |
| get_lifetime_statsA | Cycle count, full-charge events, under-voltage events, warning count, and projected remaining LFP cycle life (nominal 4000 cycles). |
| get_capacity_estimateA | Estimates real usable capacity (remainingKwh ÷ SOC%) vs rated capacity per battery. Most accurate at 20–80% SOC. |
| get_power_statsA | Charge/discharge power statistics from intraday snapshots: peak kW, average kW, C-rate, and fraction of samples above 0.5C. |
| get_cost_savingsA | Estimated monetary savings from discharged energy × electricity tariff. Pass tariffKwh or set FELICITY_TARIFF_KWH env var. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 17 tools
Most tools target distinct scopes: fleet vs battery vs cell-level, raw vs statistics, health vs history. However, get_health, get_module_health, get_cell_stats, get_cell_voltages, and get_balance_trend all touch on cell/module health and could be confusing without careful reading, though descriptions clarify granularity.
All tool names follow a consistent get_ + noun pattern, using snake_case for compound names. There are no mixed conventions or vague verbs, making the naming predictable and uniform.
With 17 tools, the server sits in the 16–25 range, feeling somewhat heavy for a monitoring API. While each tool serves a specific data need, the count could be trimmed by merging closely related health/cell tools without losing functionality.
The read-only monitoring surface is fairly complete: live status, health, alerts, energy history, capacity estimates, power stats, cost savings, and lifetime data are all covered. Minor gaps include lack of a dedicated temperature history or per-module raw voltage detail, but these are workarounds via snapshots.