Click on "Deploy 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., "@Sunsynk Solar MCP Server How much did my battery charge overnight?"
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.
A read-only Model Context Protocol server that gives Claude (or any MCP client) access to your Sunsynk inverter, battery and solar data through the Sunsynk Connect cloud API (api.sunsynk.net).
Ask Claude things like "How much did the battery charge overnight?" or "Review my time-of-use settings against my tariff". It pulls live data, settings and history, and answers from them.
Unofficial project. This is not affiliated with, endorsed by or supported by Sunsynk. It uses the undocumented API behind the Sunsynk Connect app, which may change or break without notice. Use at your own risk.
Related MCP server: fronius-mcp
Can:
List your plants (sites) and inverters
Show a real-time snapshot: PV, battery SOC/power/temperature, grid import/export and house load
Show the power-flow diagram data from the app
Pull energy history by day, month, year or lifetime
Read inverter configuration: work mode, time-of-use slots, SOC targets, grid charge and battery limits
Make raw read-only GET calls to other api/v1/ endpoints
Can't:
Change any setting. There are no write tools, by design. Claude can recommend settings, but you apply them in the Sunsynk app or portal.
Log in when the account has MFA / verification codes enabled (see Troubleshooting)
Talk to the inverter locally. Everything goes through the Sunsynk cloud, so data is only as fresh as the dongle's uploads (typically every few minutes).
Claude Desktop (or another MCP client that supports stdio servers)
Node.js 18+ (only needed if you run from source; the .mcpb bundle includes its runtime needs)
A Sunsynk Connect account (the same login as the Sunsynk app) with the inverter registered to it
Download sunsynk.mcpb from the Releases page.
Double-click it, or in Claude Desktop go to Settings → Extensions and install from file.
Enter your Sunsynk Connect email and password when prompted. They're stored in Claude Desktop's secure credential store, not in a file.
Restart Claude Desktop if the tools don't appear straight away.
git clone https://github.com/hpguru123/sunsynk-mcp.git
cd sunsynk-mcp
npm installAdd it to your MCP client config, for example claude_desktop_config.json:
{
"mcpServers": {
"sunsynk": {
"command": "node",
"args": ["/path/to/sunsynk-mcp/server/index.js"],
"env": {
"SUNSYNK_USERNAME": "you@example.com",
"SUNSYNK_PASSWORD": "your-password"
}
}
}
}npm install
npm run pack # produces sunsynk.mcpb using @anthropic-ai/mcpbSetting / env var | Required | Description |
| Yes | Your Sunsynk Connect login email |
| Yes | Your Sunsynk Connect password |
| No | Time zone used for "today" defaults (the extension sets |
| No | Override the API host (default |
When installed as an extension, Claude Desktop prompts for the username and password and passes them in as these variables.
A read-only viewer account is a good idea if your installer can set one up. That limits the damage if the credentials ever leak.
Most tools default to the first plant or inverter on the account, so on a single-inverter system you can usually omit IDs. If you have several, run sunsynk_list_inverters / sunsynk_list_plants first and pass the sn or plant_id.
Tip: some setups need the serial passed explicitly. If a call returns nothing, get the
snfromsunsynk_list_invertersand pass it.
sunsynk_list_plantsLists the sites on your account.
Parameter | Type | Required | Notes |
none |
Returns: plant id, name, current PV power (pac, W), today's and lifetime generation (kWh), status.
sunsynk_list_invertersLists inverters on the account. Start here to get the serial number (sn) the other tools use.
Parameter | Type | Required | Notes |
none |
Returns: sn, model, firmware, status, current power, today's generation.
sunsynk_live_statusReal-time snapshot of one inverter.
Parameter | Type | Required | Notes |
| string | No | Inverter serial; defaults to the first inverter |
| boolean | No | Also return the full raw API payloads, useful for debugging or odd fields |
Returns: PV input, battery (SOC %, power, temperature), grid (import/export power and today's totals), household load and inverter output.
sunsynk_power_flowThe data behind the animated flow diagram in the app.
Parameter | Type | Required | Notes |
| integer | No | Defaults to the first plant |
Returns: PV, battery, grid and load power, battery SOC and flow directions.
sunsynk_energy_historyHistorical energy data.
Parameter | Type | Required | Notes |
|
| Yes | Granularity |
| string | No |
|
| integer | No | Defaults to the first plant |
| What you get |
| Intraday power curves (PV, battery, grid, load, SOC) for that date, ideal for checking overnight charging |
| Daily kWh totals for the month |
| Monthly kWh totals for the year |
| Yearly totals since install |
sunsynk_inverter_settingsReads (never writes) the inverter configuration.
Parameter | Type | Required | Notes |
| string | No | Defaults to the first inverter |
Returns: system work mode, the six time-of-use slots (start time, power, SOC target, grid-charge flag), grid charge settings, battery charge/discharge limits, export limits and related fields.
sunsynk_api_getEscape hatch for endpoints the other tools don't cover. GET only. The path is validated, so it can't reach anything outside api/v1/.
Parameter | Type | Required | Notes |
| string | Yes | Relative path starting |
Returns: the data field of the API response.
You don't need to name the tools. Just ask in plain English:
You ask | Tools Claude will typically use |
"What's my solar and battery doing right now?" |
|
"Did the battery fill up in the cheap window last night?" |
|
"Show my time-of-use slots" |
|
"Review my settings against my tariff: cheap rate 23:00–06:00 at 5.5p, peak 22p, export 5.6p" |
|
"How much did I generate, import and export this month?" |
|
"Compare this summer with last summer" |
|
"What firmware is the inverter on?" |
|
Tip: give Claude your tariff (rates and cheap-window times) in the prompt, or it can't judge whether the settings are cost-optimal.
Sign conventions follow Sunsynk's API and can vary by field. Typically:
Battery power + = discharging, − = charging
Grid power + = importing, − = exporting
If something looks backwards, re-run sunsynk_live_status with include_raw: true and check the raw field.
Units: power in W, energy in kWh, SOC in %.
Time-of-use slots: each slot runs from its start time until the next slot's start time. Slots should be in chronological order; out-of-order times are a common misconfiguration.
AC-coupled generation (e.g. a separate micro-inverter) may show up in load or grid figures rather than PV, depending on how it's wired and whether it's metered by the Sunsynk.
Freshness: cloud data lags the inverter by a few minutes.
Symptom | Cause | Fix |
| MFA / verification code is enabled on the Sunsynk Connect account. This isn't a wrong password. | Turn off MFA in the Sunsynk app/portal, or use a separate viewer account without MFA. MFA login isn't supported yet (PRs welcome). |
Login fails with a credentials error | Wrong email or password | Re-enter them in Settings → Extensions → Sunsynk → Configure (or fix the env vars) and restart |
Tools don't appear in Claude | Extension not loaded | Check it's enabled in Settings → Extensions and restart Claude Desktop |
Empty result from settings or live status | Default inverter not picked up | Pass |
Data looks stale | Dongle offline or uploads delayed | Check the dongle's Wi-Fi; compare with the Sunsynk app |
Sudden errors after working fine | Sunsynk changed its API | Check Issues; the unofficial API can change without notice |
Read-only by design. No tool can change inverter settings, and sunsynk_api_get is restricted to GET under api/v1/. Battery, grid and export limits are safety- and G99-compliance settings, and an AI shouldn't be able to write them unsupervised.
Credentials are only sent to api.sunsynk.net. The password is RSA-encrypted before sending, matching Sunsynk's own login flow. Auth tokens are cached in memory only.
Never commit credentials. Keep them in the extension's credential prompt or environment variables, not in config files in the repo.
Your inverter serial and plant IDs identify your site. Leave them out of issues and logs you post publicly.
Node.js MCP server over stdio
Authenticates against Sunsynk Connect with RSA PKCS#1-encrypted login, caches the bearer token and refreshes automatically when it expires
Endpoint structure informed by James Ridgway's open-source Python library sunsynk-api-client (MIT). This project is an independent Node.js implementation and contains no code from it.
Packaged as a Claude Desktop extension (.mcpb) with a manifest, icon and secure credential prompts
Issues and pull requests are welcome. The most useful addition would be support for Sunsynk's login verification code (MFA). Please keep the server read-only: PRs that add write access to inverter settings won't be merged.
MIT. See LICENSE.
"Sunsynk" is a trademark of its owner and is used here only to describe compatibility. This project is not affiliated with Sunsynk.
Escape hatch: perform a read-only GET against any Sunsynk Connect endpoint under api/v1/ (e.g. 'api/v1/plant/123/realtime?id=123'). Returns the 'data' field of the response.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Relative path starting with api/v1/ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description aligns with them by stating this is read-only and accepts 'any' endpoint. It adds useful behavioral detail beyond annotations, namely that the tool returns the 'data' field of the response instead of the full payload.
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 with no filler. The purpose, scope, example, and return behavior are all front-loaded and clearly separated, making the description quick to parse.
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 one-parameter raw GET escape hatch with openWorldHint and readOnlyHint, the description is fully sufficient: it states the path convention, gives an example, and explains the response envelope. There is no output schema, so explaining the returned 'data' field is the right level of completeness.
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 schema already documents the path parameter with a description, and schema coverage is 100%. The description reinforces the api/v1/ requirement and provides a concrete example including a query string, which adds a little practical guidance but does not fundamentally expand parameter semantics.
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?
Describes exactly what the tool does: 'perform a read-only GET against any Sunsynk Connect endpoint under api/v1/' with a concrete example. The 'escape hatch' framing clearly distinguishes it from the dedicated sibling tools that cover specific endpoints.
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 'escape hatch' label implies use when no dedicated sibling tool covers the endpoint, and the description clearly scopes it to arbitrary paths under api/v1/. It doesn't explicitly say 'use this only when dedicated tools don't apply', but the intent is strongly conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Energy history for a plant. period='day' returns intraday power curves (PV, battery, grid, load, SOC) for the given date (YYYY-MM-DD); 'month' returns daily kWh totals for a month (YYYY-MM); 'year' returns monthly totals for a year (YYYY); 'total' returns yearly totals.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD for day, YYYY-MM for month, YYYY for year; defaults to today/current | |
| period | Yes | Granularity | |
| plant_id | No | Plant id; omit for the first plant |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful details about the output shape for each period (which metrics are returned for 'day' versus totals for other periods), but it does not address behaviors like timezone handling, response pagination, or units. Given the annotation coverage, this is an adequate level of transparency.
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 a single, dense paragraph that front-loads the resource and action, then cleanly enumerates the four period cases with their date formats and return types. Every clause earns its place, with no redundant restatements of the schema or annotations.
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 tool with no output schema, the description provides everything an agent needs to invoke it correctly: the required period parameter, the date format for each period variant, defaults for optional date and plant_id, and a high-level description of what each period returns. Units and timezone details are minor and do not block correct usage.
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 input schema already documents all three parameters (100% coverage), so the baseline is 3. The description adds value by mapping each period enum value to its required date format (YYYY-MM-DD, YYYY-MM, YYYY) and explaining default behavior for date and plant_id. This goes beyond the schema's terse labels like 'Granularity'.
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 this tool returns 'Energy history for a plant' and then specifies exactly what each period value yields (intraday power curves, daily kWh totals, monthly totals, yearly totals). This level of specificity makes the tool easy to distinguish from siblings like sunsynk_live_status or sunsynk_power_flow, which are for real-time/current data.
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 establishes a clear context for use: any request for historical energy data at day/month/year/total granularity. It does not explicitly name alternatives or say when not to use it, but the historical framing is distinct from the live-status siblings. No exclusions are provided, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read (not change) the inverter's configuration: work mode, time-of-use slots and SOC targets, grid charge settings, battery limits, export limits etc.
| Name | Required | Description | Default |
|---|---|---|---|
| sn | No | Inverter serial number; omit for the first inverter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile, and the description reinforces it with '(not change)' while adding scope about which settings are read. It does not go further to describe return format, permissions, or external behavior, but for a read-only settings tool this is acceptable given the annotation.
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?
One tight, front-loaded sentence. It opens with the critical 'Read (not change)' qualifier and then lists the settings scope without filler or repetition.
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 simple one-parameter, read-only tool, the description plus complete schema coverage is mostly sufficient. The main gaps are that no explicit sibling routing is provided and there is no output schema, so the exact return format is unspecified; however, the listed categories give an agent enough context to call the tool correctly.
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 single parameter 'sn' is fully documented in the schema, including the important 'omit for the first inverter' behavior. The description adds no additional parameter-level detail, so the baseline score of 3 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 uses a specific verb ('Read'), explicitly disambiguates from mutation ('not change'), and names the exact resource: the inverter's configuration. It further enumerates concrete settings categories, which clearly separates it from siblings like live_status, power_flow, or energy_history.
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 when to use the tool: when the agent needs inverter configuration such as work mode, SOC targets, or battery limits. However, it does not explicitly name sibling alternatives or state when not to use this tool, leaving some routing decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List inverters on the account with serial number (sn), model, firmware, status, current power and today's generation. Use the sn with other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is covered. The description adds value by specifying the exact fields returned and the fact that the sn is meant for cross-tool usage, which is behavioral context beyond the annotations. It does not mention pagination or ordering, but for a simple list tool this is acceptable given the annotation coverage.
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 concise sentences. The first sentence front-loads the purpose and enumerates the key fields; the second adds a practical usage tip. No filler or redundancy. The structure is efficient and easy to parse.
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 parameterless list tool with no output schema, the description adequately specifies what the agent can expect (the listed fields). Combined with the annotations (read-only, open-world), an agent has enough information to invoke the tool and interpret the result. Nothing critical is missing.
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 zero parameters, so the schema already trivially covers 100% of them. Per the rubric, a baseline of 4 applies for 0 params. The description does not need to explain parameters and does not attempt to, which 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?
States a specific action (list inverters) with a clear resource and enumerates the returned fields (sn, model, firmware, status, power, generation). This distinguishes it from sibling tools like sunsynk_list_plants, which targets a different resource, and from live_status/power_flow that provide real-time telemetry rather than a static list.
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?
Provides a clear use case: it is the tool to obtain the serial number (sn) for use with other tools. This implies a workflow dependency, though it does not explicitly mention alternatives or when not to use it. The context is sufficient for an agent to select it when needing an inventory of inverters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the solar plants (sites) on the Sunsynk Connect account, with id, name, current PV power (pac, W), today's and lifetime generation (kWh) and status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish this as a read-only, open-world call, and the description adds meaningful output context: id, name, current PV power, generation values, and status. It does not mention pagination or latency, but for a zero-parameter listing tool the behavioral disclosure is sufficient.
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?
A single sentence front-loads the action and resource, then compactly lists the returned fields and units. Every phrase earns its place and nothing is redundant.
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 no input parameters, and the description names all relevant output fields since no output schema exists. Combined with the read-only/open-world annotations, this gives an agent everything needed to understand and invoke the tool correctly.
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?
With zero parameters)Skip, the input schema carries no semantic burden and the baseline is 4. The description adds no parameter detail because none exists.
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 uses a specific verb ('List') and an explicit resource ('solar plants (sites) on the Sunsynk Connect account'). It enumerates the exact returned fields, distinguishing it from sibling tools like sunsynk_list_inverters and sunsynk_live_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 account-scoped phrasing and explicit focus on plants/sites make the tool's intended use clear. It does not name sibling alternatives or state when not to use it, but the listing intent is unambiguous and no prerequisites are implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Real-time snapshot of the inverter: solar PV input, battery (state of charge, power, temperature), grid (import/export power and today's totals), household load and inverter output. Sign conventions follow Sunsynk's API (typically battery power + = discharging, − = charging; grid power + = importing, − = exporting) — check the raw fields if unsure. Defaults to the first inverter on the account.
| Name | Required | Description | Default |
|---|---|---|---|
| sn | No | Inverter serial number; omit to use the first inverter | |
| include_raw | No | Also return the full raw API payloads |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world hints. The description adds useful behavioral context: it explains sign conventions for battery and grid power, warns to check raw fields if unsure, and notes the default to the first inverter. These details go beyond the annotations and help the agent interpret results.
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 two sentences with no waste. The main purpose is front-loaded, followed by essential behavioral details. Every sentence earns its place, and the structure is easy to scan.
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?
With no output schema, the description provides a high-level breakdown of the returned data categories, which is helpful. It also covers sign conventions and default behavior. However, it does not list exact field names or error conditions, leaving some ambiguity, but for a read-only tool with annotations covering safety, this is a reasonable level of detail.
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 coverage is 100% for both parameters, so the baseline is 3. The description adds a small note about the 'sn' parameter defaulting to the first inverter, which is already implied by the schema description ('omit to use the first inverter') but is reinforced. It does not add significant meaning for 'include_raw' beyond the 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 the tool provides a real-time snapshot with a specific list of metrics (solar PV, battery, grid, household load, inverter output). It is a specific verb+resource and is easily distinguishable from siblings like energy_history, which would focus on historical data.
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 status but does not explicitly mention when to use this tool versus alternatives such as sunsynk_power_flow or sunsynk_energy_history. It provides no exclusions or alternative routing, leaving the agent to infer the use case from the content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current power-flow view for a plant (the 'animated diagram' data in the app): PV, battery, grid, load power and battery SOC, with flow directions.
| Name | Required | Description | Default |
|---|---|---|---|
| plant_id | No | Plant id; omit for the first plant |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that this is a current snapshot and identifies the data source ('animated diagram' data), but it does not disclose further behavior such as response structure or units. No contradiction with 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?
A single, tightly written sentence front-loads the core purpose ('Current power-flow view for a plant') and then lists the key data fields in a compact parenthetical. No filler or 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?
With one optional parameter, full schema coverage, and read-only/open-world annotations, the description is nearly complete for a simple snapshot tool. It lists the main fields returned, though units and exact value semantics are not provided; since there is no output schema, a bit more detail could be warranted.
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 100% for the single optional parameter plant_id, which is documented as 'Plant id; omit for the first plant.' The tool description does not add parameter details beyond the schema, but with full coverage the baseline of 3 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 identifies the resource ('power-flow view for a plant') and enumerates the data it contains: PV, battery, grid, load power, SOC, and flow directions. It is distinct from siblings like sunsynk_energy_history (historical) and sunsynk_list_plants (list), though it does not explicitly differentiate from sunsynk_live_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 phrase 'Current power-flow view' implies when to use it: when a current snapshot of plant power flow is needed. However, it does not explicitly mention alternatives or state when not to use this tool, leaving some inference to the agent.
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.0sunsynk_api_getsunsynk_energy_historysunsynk_inverter_settingssunsynk_list_inverterssunsynk_list_plantssunsynk_live_statussunsynk_power_flowScored across 7 tools
Each tool targets a distinct aspect of the solar domain: listing plants vs. inverters, live inverter status vs. plant-level power flow, historical energy data, read-only settings, and a generic API escape hatch. Even the two status tools (live_status and power_flow) are clearly differentiated by scope (inverter vs. plant) and the descriptions explicitly note the difference.
All tools share the consistent 'sunsynk_' prefix, but the action part mixes verb-noun (list_plants, list_inverters, api_get) with noun phrases (live_status, power_flow, energy_history, inverter_settings). This is still predictable and readable, but not as uniform as a pure verb_noun scheme.
Seven tools is a well-scoped set for a solar monitoring server. Each tool covers a core need (listing, status, history, settings) without unnecessary bloat, and the escape hatch prevents the need for many niche tools.
The server provides comprehensive read-only coverage: listing resources, real-time status at both inverter and plant levels, historical energy data across multiple time periods, configuration settings, and a generic GET endpoint for any missing API calls. No obvious gaps for a monitoring use case.
WHOOP recovery, strain, sleep and workouts in Claude via official WHOOP OAuth. Free, open source.
Let Claude or ChatGPT search, read and send your WhatsApp messages over MCP. OAuth sign-in.
Connect Amazon Seller Central to Claude or ChatGPT via MCP. Orders, inventory, pricing, fees, FBA.
Connect your ads, shop, analytics, social, CRM and finance platforms once, then let Claude, ChatGPT, Cursor or any MCP client read, join and explain your numbers. Public statistics from the World Bank, IMF, Eurostat, OECD, WHO and SEC filings come as context, searchable and chartable from the same tools. Read-only by design, every number carries its source.
