Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fronius-mcp How much solar power am I generating now?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Real-time solar data from your Fronius inverter, directly in Claude.
Ask things like:
"How much solar power am I generating right now?"
"What's my battery charge level?"
"Am I currently importing or exporting to the grid?"
"How much energy did I produce this year?"
"What can you do with my solar system?"
"Analyse my photovoltaics for me."
Connects to the Fronius Solar API v1 directly on your local network — no cloud account, no subscription, no data leaving your home.
fronius-mcp is a Model Context Protocol (MCP) server. MCP is an open standard that lets AI assistants like Claude connect to external tools and data sources. Once configured, Claude can call your inverter's local API in real time — whenever you ask a question about your solar system, Claude fetches live data and answers based on what's actually happening right now.
Related MCP server: Enphase Solar MCP Server
A Fronius inverter on your local network with the Solar API (JSON API) enabled
uv — a fast Python package manager (one-line install)
uv is a fast Python package manager used to run fronius-mcp without a permanent install.
macOS / Linux:
curl -LsSf https://astral.sh/uv/install.sh | shWindows (PowerShell):
irm https://astral.sh/uv/install.ps1 | iexRestart your terminal after installing.
Open your claude_desktop_config.json and add the fronius block inside mcpServers:
{
"mcpServers": {
"fronius": {
"command": "uvx",
"args": ["fronius-mcp"]
}
}
}Config file location:
Platform | Path |
macOS |
|
Windows |
|
Windows (Store app) |
|
Tip: If the
mcpServerskey already exists, just add thefroniusblock inside it — don't create a secondmcpServers.
Close and reopen Claude Desktop so it picks up the new server config.
In a new Claude conversation, say:
"Configure my Fronius inverter at 192.168.178.35"
Claude will save your inverter's IP and confirm the connection. This is a one-time step — the address is stored in ~/.fronius-mcp.json and persists across restarts.
Don't know your inverter's IP? Tell Claude: "I want to configure my Fronius inverter but I don't know the IP." Claude will walk you through finding it via your router, Fronius Solar.web, or the inverter's touch display — and how to enable the Solar API in the inverter's web interface if you haven't done that yet.
Once set up, just talk to Claude naturally. Some examples:
"What's my current solar output?" — live PV generation in watts
"How self-sufficient am I right now?" — autonomy and self-consumption percentages
"Is my battery charging or discharging?" — battery power flow and state of charge
"How much have I fed into the grid today?" — energy totals from the smart meter
"What devices are connected to my inverter?" — full system topology
"Give me a full overview of my solar system." — Claude combines all data sources into a summary
Tool | What it does |
| Set your inverter's IP address — run this once on first setup |
| PV generation, grid exchange, house load, battery power, autonomy, energy totals |
| Grid power per phase, cumulative energy in/out, voltage, current, frequency |
| State of charge, voltage, current, temperature, capacity, status |
| All connected devices with type, bus index, and serial number |
Developed and tested on:
Fronius Symo GEN24 10.0 Plus
BYD Battery-Box Premium HV (13.824 kWh)
Fronius Smart Meter (grid feed-in point, 3-phase)
Other Fronius inverters with Solar API v1 support should work. Some API endpoints behave differently across models — if something doesn't work on your hardware, open an issue.
Apache 2.0 — see LICENSE.
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.
Args: host: IP address or hostname of the inverter (e.g. '192.168.178.35'). Scheme and port are stripped automatically.
Returns a confirmation message plus setup instructions, or a connectivity warning if the inverter cannot be reached.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and delivers: it discloses saving to ~/.fronius-mcp.json with persistence, automatic scheme/port stripping, and return behavior (confirmation or connectivity warning).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (4 sentences plus Args/Returns) and well-structured with clear sections. Every sentence adds value; minor redundancy ('useful for first-time setup' is implicit) but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no nesting), the description covers purpose, usage, side effects, parameter details, and return behavior. Output schema exists and description explains return values adequately. Sibling tools are distinct.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides only 'Host' string without description (0% coverage). The description compensates fully: specifies IP/hostname format, example, and behavior (scheme/port stripping).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Configure the Fronius inverter IP address or hostname.' It specifies the verb (configure) and resource (inverter IP/hostname), and distinguishes itself from sibling tools (solar_battery, solar_devices, etc.) which handle other aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Call this once to tell the MCP server where your inverter lives' and notes persistence across restarts. It implies a one-time setup but could explicitly state when not to use or that it's a prerequisite for other tools. Still clear overall.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies a read-only operation with 'Real-time data' and lists return fields, but does not explicitly state non-destructive nature, authentication needs, or rate limits. Annotations are absent, so description carries the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences effectively convey purpose and return data without redundancy. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description sufficiently explains the tool's function and the data it returns. Lacks mention of potential limitations or prerequisites, but adequate for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and schema coverage is 100%, so no additional parameter info is needed. Description adds value with field details but is not required; baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides real-time data from the BYD Battery-Box Premium HV, distinguishing it from sibling tools like configure_inverter, solar_devices, solar_meter, and solar_power_flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, e.g., for specific battery metrics vs. overall system status. The description only lists data fields without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully explains the return format (dict with device classes, list of devices with bus index and serial number) and the meaning of empty lists. Since no annotations are provided, the description carries the full transparency burden and does so completely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences front-loaded with the primary action, followed by detailed output format and a use case. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is complete: it explains the purpose, output structure, and interpretation of results. It adequately covers the tool's functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (empty input schema), so the baseline is 4. The description does not need to add parameter info, and it correctly focuses on the output behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all devices connected to the Fronius inverter system, using specific verb 'lists' and resource 'devices'. It distinguishes from sibling tools like 'configure_inverter' or 'solar_battery' by covering all device classes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a use case ('useful for verifying system topology or diagnosing missing devices'), which implies when to use. It lacks explicit exclusions or direct comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It explains real-time data, sign convention for power, and lists all measurements. Could mention read-only nature but not required. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant words. Every sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description must cover return values. It lists all fields with brief explanations and sign convention. Lacks explicit units for voltage/current (though implied) and error handling, but adequate for a simple data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100%. Description adds value by explaining field meanings and sign convention, which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns real-time data from a Fronius Smart Meter at the grid feed-in point, lists specific measurements, and distinguishes itself from sibling tools like solar_power_flow or solar_battery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for grid feed-in point data, and sibling tools cover other areas (configuration, battery, device list, power flow). However, no explicit 'when not to use' or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It implies a read-only operation but does not explicitly state it as non-destructive or idempotent. The return fields are detailed, but beyond that, no information on permissions, rate limits, or side effects is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, front-loaded with the primary purpose, and the second sentence lists all output fields efficiently. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no parameters and no output schema, the description fully covers what the tool returns, including units and sign conventions. It is complete enough for an agent to understand the tool's output without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema description coverage is 100% trivially. The baseline for zero parameters is 4, and the description appropriately focuses on the output rather than parameters, which is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides real-time power flow data from a specific inverter model, and lists all returned fields. The verb 'Returns' implies a read operation, and the resource is well-defined. It distinguishes itself from sibling tools like solar_battery or solar_meter by focusing on overall power flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention use cases, prerequisites, or when not to use it. The description is purely factual without contextual recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct aspect of the solar system: configuration, battery, devices, meter, and power flow. No two tools have overlapping purposes.
Most tools follow a 'solar_<noun>' pattern (solar_battery, solar_devices, solar_meter, solar_power_flow), but 'configure_inverter' breaks this pattern by using a verb + noun form instead.
With 5 tools, the server covers essential monitoring operations (configuration, battery, devices, meter, power flow) without being bloated or too sparse.
Covers real-time monitoring well but lacks historical data retrieval or energy totals. Missing tools for writing settings (e.g., set battery mode) limits completeness for a full lifecycle.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
WHOOP recovery, strain, sleep and workouts in Claude via official WHOOP OAuth. Free, open source.
Garmin data in Claude & ChatGPT via the Garmin Health API. OAuth sign-in, no password sharing.
Connect Claude to your Intervals.icu watch data for fitness, workout review, and plan writing.
Connect Claude to Fathom meeting recordings, transcripts, and summaries
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/flowiesner/fronius-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
