A lean Model Context Protocol (MCP) server that gives AI assistants like Claude structured access to a SolarEdge PV installation via the official SolarEdge Monitoring API.
Disclaimer — this is an unofficial, community project. It is not affiliated with, authorized, maintained, sponsored, or endorsed by SolarEdge Technologies, Inc. "SolarEdge" and related marks are trademarks of their respective owner and are used here only to describe what this software talks to. Use it at your own risk and in accordance with the SolarEdge API Terms & Conditions.
It exposes four high-level tools that bundle and interpret several API endpoints, so the assistant gets ready-made insights instead of raw payloads:
Tool | What it returns |
| Current power, live energy flow (PV / battery / grid / load), battery charge level, and today / this-month / lifetime production. Reports both |
| Production, consumption, self-consumption, feed-in and grid-purchase over a period, plus derived self-consumption rate and self-sufficiency (autarky). The summary reports both |
| Inverter status & firmware, data freshness, and (in |
| A heuristic production estimate from the historical daily average. The SolarEdge API has no forecast endpoint, so this is a simple statistical projection and is clearly labelled as an estimate (no weather data). |
Sites with a DC-coupled battery (StorEdge) expose two different "production" figures, and confusing them is a common source of "the numbers don't match the app" reports:
AC production (ac_production, energy_today_wh) — the inverter's AC
production meter. PV energy that charges the battery over the DC bus never
crosses this meter, so on sunny days with a charging battery it
under-reports PV.
PV generation (pv_generation, pv_generation_today_wh) — AC production
plus the net energy stored in the battery (integrated from storageData).
This matches the value shown in the SolarEdge mobile app / HEMS portal.
Use pv_generation for "how much did the system generate?" and ac_production
for AC-side energy-balance math (production = self_consumption + feed_in).
When ac_grid_charging is true the battery was charged from the grid rather
than from PV, so pv_generation may be slightly overstated. Adding the battery
correction costs one extra storageData API call per analysis (chunked into
≤ 1-week windows for longer ranges, since that is the endpoint's limit).
Related MCP server: MeteoControl MCP Server
Python 3.10+
A SolarEdge Monitoring API key and your site ID:
Log in to the SolarEdge monitoring portal.
Generate a site-level API key under Site Admin → Site Access → Access Control → API Access.
Your site ID is the number shown in the portal (also visible in the dashboard URL).
The API allows 300 requests/day and 3 concurrent calls per token. This server caches aggressively and guards the daily budget (see Rate limits).
git clone https://github.com/holger1411/unofficial-solaredge-mcp.git
cd unofficial-solaredge-mcp
python3 -m venv .venv
.venv/bin/pip install -e .The server reads its credentials from environment variables. For local use, copy the example file and fill in your values:
cp .env.example .env
# then edit .envSOLAREDGE_API_KEY=your_solaredge_api_key_here
SOLAREDGE_SITE_ID=1234567Variables (a local .env file or real environment variables both work):
Variable | Required | Default | Description |
| yes | – | Your SolarEdge Monitoring API key |
| yes | – | Your SolarEdge site ID (integer) |
| no |
| API base URL |
Add an entry to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"solaredge": {
"command": "/absolute/path/to/unofficial-solaredge-mcp/.venv/bin/solaredge-mcp",
"env": {
"SOLAREDGE_API_KEY": "your_solaredge_api_key_here",
"SOLAREDGE_SITE_ID": "1234567"
}
}
}
}Passing credentials via env (rather than relying on a .env file) is the most
reliable approach, because Claude Desktop launches the process from a different
working directory.
Troubleshooting: if the server fails to start with
No module named 'solaredge_mcp'(editable installs can break on some Python/setuptools combinations), use the interpreter directly and pointPYTHONPATHatsrc:{ "mcpServers": { "solaredge": { "command": "/absolute/path/to/unofficial-solaredge-mcp/.venv/bin/python", "args": ["-m", "solaredge_mcp.server"], "env": { "SOLAREDGE_API_KEY": "your_solaredge_api_key_here", "SOLAREDGE_SITE_ID": "1234567", "PYTHONPATH": "/absolute/path/to/unofficial-solaredge-mcp/src" } } } }
Then fully quit and restart Claude Desktop. Try prompts like:
"How is my SolarEdge system doing right now?" → solaredge_live_status
"Show me my energy balance for the last week." → solaredge_energy_analysis
"Run a diagnosis of my system." → solaredge_diagnosis
The server speaks MCP over stdio. Any MCP-compatible client can launch it via:
/path/to/unofficial-solaredge-mcp/.venv/bin/solaredge-mcpwith SOLAREDGE_API_KEY and SOLAREDGE_SITE_ID set in the environment
(or python -m solaredge_mcp.server with PYTHONPATH=/path/to/src, see the
troubleshooting note above).
The SolarEdge API permits 300 requests/day and 3 concurrent requests per token.
Responses are cached by data type: live data ~2 min, time series ~15 min, static data (inventory/details) ~1 hour. Cached responses cost no API quota.
A daily-request counter blocks further calls before hitting the API limit, returning a clear error instead of an HTTP 429.
The API key is never written to logs or used in cache keys.
No real forecast. The SolarEdge API has no forecast endpoint; the forecast tool is a historical-average heuristic (no weather).
Alerts are only returned by the API when using an account-level key, so
diagnosis does not report alerts when a site-level key is used.
Single site (for now). The server targets one configured site, but the
internals thread site_id everywhere, so multi-site support can be added
without restructuring.
Times are interpreted in the site's local timezone by the API.
.venv/bin/pip install -e ".[dev]"
.venv/bin/pytestAll tests use a mocked HTTP layer and require no real credentials or network access. See CONTRIBUTING.md.
MIT © 2026 Holger Koenemann
System health: inverter status/firmware, data freshness, and (for check_type='comprehensive') battery state of charge and State of Health. check_type: health|performance|comprehensive.
| Name | Required | Description | Default |
|---|---|---|---|
| check_type | No | comprehensive | |
| include_recommendations | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as idempotency, side effects, authentication requirements, or rate limits. It only describes the output content, which is insufficient for a tool with no annotations.
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 concise with two sentences plus a line for parameters. It is front-loaded with the key purpose ('System health:'). However, it could be more structured, e.g., by separating parameter details more clearly.
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?
The tool has two optional parameters and an output schema. The description covers the main output categories and the check_type values, but lacks detail on the effect of 'include_recommendations' and does not address usage context like time ranges or prerequisites. Given the existence of an output schema, some gaps are acceptable, but overall completeness is moderate.
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 description adds value for the 'check_type' parameter by listing possible values ('health|performance|comprehensive') that are not present in the input schema. However, the 'include_recommendations' parameter is not explained, and schema coverage is 0%, so the description only partially compensates for the missing schema descriptions.
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's purpose: diagnosing system health including inverter status, firmware, data freshness, and optionally battery state of charge and health. It distinguishes from sibling tools like energy_analysis, forecast, and live_status, which focus on different 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 implies usage for health diagnosis but does not explicitly state when to use this tool versus its siblings or when not to use it. No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Energy balance and derived metrics (self-consumption rate, self-sufficiency)
over a period. time_range: today|1d|1w|1m|3m|1y|custom. For 'custom' supply
start_date and end_date as 'YYYY-MM-DD HH:MM:SS'. meters: optional comma list
(Production,Consumption,SelfConsumption,FeedIn,Purchased). The summary reports
both ac_production (inverter AC meter) and pv_generation (= AC + net
battery storage), the latter matching the SolarEdge app/HEMS for DC-coupled
batteries.
| Name | Required | Description | Default |
|---|---|---|---|
| time_range | No | 1w | |
| start_date | No | ||
| end_date | No | ||
| meters | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains key metrics (ac_production vs pv_generation) and parameter details, but omits information about read-only nature, data freshness, authentication, or potential side effects. The description adds value but is incomplete for a tool with zero annotations.
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 relatively concise at 4-5 sentences, with key information front-loaded (energy balance and derived metrics). It uses line breaks to separate concepts, making it scannable. It could be slightly more structured, but it earns its sentences 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 an output schema (so return values are covered), 4 parameters with 0% schema coverage, and no annotations, the description covers essential usage details including special metrics explanation. It lacks coverage of error conditions or data availability, but overall it is complete enough for a 4-parameter 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?
Schema description coverage is 0%, so the description must compensate. It effectively explains time_range values (today|1d|1w|1m|3m|1y|custom), start_date/end_date format (YYYY-MM-DD HH:MM:SS), and meters as a comma-separated list of specific options (Production,Consumption,SelfConsumption,FeedIn,Purchased). This adds significant meaning beyond the schema, though it doesn't detail each meter's effect.
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 provides 'Energy balance and derived metrics (self-consumption rate, self-sufficiency) over a period.' It distinguishes from sibling tools (diagnosis, forecast, live_status) by focusing on historical analysis. The purpose is specific and understandable, though the verb 'analyze' is implicit.
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 provides detailed guidance on parameter usage, including time_range values, date formatting for 'custom', and the optional meters parameter. However, it does not explicitly state when to use this tool versus siblings, nor does it mention when not to use it or provide alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Heuristic production estimate from the historical daily average (no weather data). forecast_type: daily|weekly.
| Name | Required | Description | Default |
|---|---|---|---|
| forecast_type | No | daily | |
| lookback_days | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It states the heuristic nature and lack of weather data, which is informative. However, it does not cover other behavioral aspects like data source specifics, accuracy, or potential failure modes.
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 concise with two short sentences. The key information is front-loaded: the purpose and method. Every part 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's simplicity and the presence of an output schema, the description provides essential purpose and a parameter hint. However, it lacks guidance on when to use this tool vs siblings and does not explain the effect of lookback_days on the forecast.
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 description coverage is 0%, so the description must compensate. It adds meaning for forecast_type by listing possible values, but completely ignores lookback_days, leaving its semantics unclear beyond the schema's type and default.
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 a heuristic production estimate using historical daily average without weather data, and specifies the forecast_type parameter. This distinguishes it from siblings by emphasizing the simplicity and lack of weather integration.
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 through 'heuristic' and 'no weather data', but does not explicitly state when to use this tool over siblings for diagnosis, analysis, or live status. No alternative tools or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current power, energy flow (PV/battery/grid/load), battery charge level,
and today/this-month/lifetime production for the configured site.
energy_today_wh is AC production; pv_generation_today_wh adds the energy
stored in the DC-coupled battery and matches the SolarEdge app/HEMS.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides detailed behavioral context, clarifying that energy_today_wh is AC production and pv_generation_today_wh includes DC-coupled battery energy. With no annotations, this fully informs the agent.
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?
Three sentences, no fluff. The first sentence provides an overview, the second clarifies a technical distinction. Every sentence adds value.
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 presence of an output schema and no parameters, the description covers all necessary context: what data is returned and how to interpret key metrics.
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, so schema coverage is 100%. The description appropriately adds no parameter information, meeting the baseline for a zero-parameter tool.
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 returns current power, energy flow, battery charge, and production metrics. It distinguishes itself from siblings like diagnosis and analysis by focusing on live instantaneous status.
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 use for live monitoring, but does not explicitly state when to use vs. alternatives. However, the context and sibling names make it clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0solaredge_diagnosissolaredge_energy_analysissolaredge_forecastsolaredge_live_statusScored across 4 tools
Each tool serves a clearly distinct purpose: diagnosis for system health, energy analysis for historical metrics, forecast for production estimates, and live status for current data. No overlaps or ambiguity.
All tools follow a consistent 'solaredge_' prefix followed by a descriptive verb_noun pattern (e.g., live_status, energy_analysis). Naming is uniform and predictable.
Four tools cover the core aspects of solar monitoring: health, historical analysis, forecast, and live status. The count is appropriate for the domain without being excessive or insufficient.
The set covers essential monitoring and analysis functions. Minor gaps exist, such as missing tools for site configuration, alerts, or detailed component history, but core workflows are supported.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
