MCP server for Fronius solar inverters — real-time PV, battery, and grid data in Claude
Server has 5 tools with clear, domain-specific names (solar_power_flow, solar_meter, solar_battery, solar_devices, configure_inverter). Descriptions are present and substantive (100-250 chars), explaining what data is returned and when to use each tool. However, input schemas are minimal or absent for 4 of 5 tools (solar_meter, solar_battery, solar_devices, solar_power_flow all have empty input objects {}). The configure_inverter tool has a proper schema with a 'host' parameter and description. Error handling is weak, no guidance on what to do if the inverter is unreachable or the Solar API is disabled. Output schemas are not documented, forcing LLMs to infer response structure. Tool composition is sound (each does one thing), but lack of input validation and error recovery guidance limits production readiness.
Configure the Fronius inverter IP address or hostname. Call this once to tell the MCP server where your inverter lives. The value is saved to ~/.fronius-mcp.json and persists across restarts. Also returns instructions for finding the inverter IP and enabling the Solar API — useful for first-time setup.
Real-time data from the BYD Battery-Box Premium HV. Returns state of charge (soc_pct), DC voltage and current, cell temperature (temp_c), usable and design capacity in Wh, cell status, enabled flag, and manufacturer/model info.
Lists all devices currently connected to the Fronius inverter system. Returns a dict with device classes (inverter, meter, storage, ohmpilot, etc.) as keys. Each entry is a list of connected devices with their bus index and serial number. Empty list means the device class is supported but nothing is connected. Useful for verifying system topology or diagnosing missing devices.
Real-time data from the Fronius Smart Meter at the grid feed-in point. Returns total grid power (power_w), per-phase real power (power_l1/l2/l3_w), total energy consumed from grid (energy_consumed_wh), total energy fed into grid (energy_fed_wh), per-phase voltage and current (voltage/current_l1/l2/l3), and grid frequency (frequency_hz). Positive power = importing from grid, negative = exporting to grid.
Four tools (solar_power_flow, solar_meter, solar_battery, solar_devices) have empty input schemas ({}). Per hard scoring rules, tools with no input schema must score 0 on schema dimension. This caps per-tool scores at 55 and signals to LLMs that these tools accept no parameters, which is correct but undocumented.
Output schemas are not documented anywhere in the code. LLMs cannot plan downstream operations or extract specific fields without knowing what solar_power_flow() returns (pv_w, grid_w, load_w, etc.). Descriptions mention field names but do not provide a formal schema.
Error handling is minimal. configure_inverter catches exceptions and returns a warning message, but solar_* tools have no visible error handling. If the inverter is offline or the Solar API is disabled, the tools will fail with no guidance on recovery (e.g., 'Check that the JSON API is enabled in the inverter's web interface').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
Real-time power flow data from the Fronius Symo GEN24 inverter. Returns PV generation (pv_w), grid exchange (grid_w, positive = import, negative = export), house load (load_w), battery power (battery_w, positive = charging, negative = discharging), autonomy and self-consumption percentages, daily/yearly/total energy yields, operating mode, and battery standby state.
No input validation or constraint documentation. The configure_inverter tool accepts a 'host' parameter but does not validate format (IP vs hostname), does not reject invalid characters, and does not document expected format in the schema description.
Tool composition is sound, but no pagination or result limits are documented. If solar_devices returns many devices, the response could be large. No limit parameter or pagination guidance is provided.